Combien de temps votre site peut-il rester hors ligne avant d'être désindexé par Google ?

Qu'entend Google par « période prolongée » ?

Google reste volontairement flou sur la durée exacte. Plusieurs jours peut signifier 48 heures comme une semaine, selon le contexte. Le moteur n'applique pas de seuil fixe mais utilise des heuristiques pour évaluer chaque situation.

Ces heuristiques prennent en compte l'historique de fiabilité du site, sa fréquence de crawl habituelle, et probablement l'importance perçue de ses contenus. Un site d'actualité majeur bénéficiera d'une plus grande tolérance qu'un blog peu consulté.

Comment Google décide-t-il de retirer un site de l'index ?

Le processus repose sur l'accumulation d'erreurs HTTP lors des tentatives de crawl successives. Si Googlebot rencontre systématiquement des codes 500, 503 ou des timeouts, il interprète ces signaux comme une indisponibilité durable.

Contrairement à une erreur 404 qui indique qu'une page spécifique n'existe plus, une erreur serveur globale suggère un problème technique majeur. Google ne peut pas savoir si le site reviendra demain ou jamais. Par précaution, il finit par nettoyer son index des URL inaccessibles.

Pourquoi cette politique existe-t-elle ?

Google cherche à maintenir la qualité de ses résultats. Proposer des liens vers des sites en panne dégrade l'expérience utilisateur. Le moteur doit arbitrer entre patience envers les sites temporairement indisponibles et rapidité à écarter ceux qui ne reviendront peut-être jamais.

Cette approche protège aussi les ressources de crawl. Pourquoi continuer à solliciter un serveur qui ne répond jamais ? Mieux vaut réallouer ce budget à des sites actifs.

• Pas de délai fixe : Google adapte sa décision selon l'historique et l'autorité du site
• Erreurs serveur critiques : codes 500/503 déclenchent des alertes plus rapidement que des 404
• Objectif qualité : Google privilégie l'expérience utilisateur sur la patience infinie
• Optimisation du crawl : ne pas gaspiller de ressources sur des sites morts
• Réversibilité possible : un site qui revient peut être réindexé, mais pas instantanément

Cette déclaration correspond-elle aux observations terrain ?

Oui, globalement. On observe régulièrement des désindexations massives suite à des migrations ratées ou des pannes serveur prolongées. Un site qui reste en maintenance pendant 72 heures sans page de substitution voit souvent ses positions s'effondrer.

Mais le diable se cache dans les détails. [A vérifier] Google ne précise jamais le seuil exact en heures, ni comment l'autorité du domaine module ce délai. Un site avec un PageRank historique élevé et des backlinks puissants tiendra probablement plus longtemps qu'un domaine récent sans notoriété.

Quelles nuances faut-il apporter ?

Toutes les pannes ne se valent pas. Une erreur 503 avec un en-tête Retry-After correctement configuré signale une maintenance temporaire planifiée. Google peut interpréter ce signal différemment d'un timeout brutal ou d'un 500 générique.

De même, une panne qui touche 100% du site aura un impact plus violent qu'un problème partiel affectant certaines sections. Si Googlebot réussit à crawler 80% de vos URL mais rencontre des erreurs sporadiques sur les 20% restants, il ne désindexera probablement pas tout le domaine. Le contexte compte énormément.

Dans quels cas cette règle s'applique-t-elle différemment ?

Les sites d'actualité haute fréquence semblent bénéficier d'une tolérance réduite paradoxalement. Google crawle intensivement ces domaines et détecte donc plus vite une anomalie, mais il accorde aussi davantage de crédit à leur retour rapide. Un média qui tombe 6 heures peut perdre des positions fraîches sans être totalement désindexé.

À l'inverse, un site corporate à faible fréquence de mise à jour peut rester en maintenance 48 heures sans conséquence immédiate, car Google ne le visite qu'une fois tous les trois jours de toute façon. Le rythme de crawl habituel détermine en partie la vitesse de réaction du moteur.

Que faut-il mettre en place avant une maintenance planifiée ?

Configurez une page de maintenance propre avec un code HTTP 503 et un en-tête Retry-After indiquant la durée estimée. Cela informe Googlebot que l'indisponibilité est temporaire et planifiée, ce qui peut moduler sa réaction.

Maintenez au minimum quelques URL critiques accessibles : homepage, pages de catégorie principales, contenus à forte valeur SEO. Si tout le site ne peut pas rester en ligne, isolez les sections stratégiques sur une infrastructure de secours.

Comment réagir si une panne imprévue survient ?

Rétablissez le service le plus vite possible, évidemment. Mais ne comptez pas sur une réindexation instantanée. Soumettez manuellement vos URL prioritaires via la Search Console dès le retour en ligne pour accélérer le processus.

Surveillez vos logs serveur et la Search Console pour identifier quelles sections Google a tenté de crawler pendant la panne. Ces données vous indiquent quelles URL risquent le plus de perdre leur statut indexé. Concentrez vos efforts de relance sur ces priorités.

Quelles erreurs éviter absolument ?

Ne laissez jamais un site renvoyer des erreurs 500 silencieuses pendant des jours en espérant que personne ne remarque. Google remarque toujours. Et vos concurrents aussi, qui en profiteront pour grignoter vos positions.

Évitez aussi de basculer vers une page d'accueil générique 200 OK affichant « Maintenance en cours » sur toutes les URL. Google interprétera ça comme du contenu dupliqué massif ou du thin content, ce qui peut déclencher d'autres problèmes algorithmiques.

• Implémenter un code 503 avec Retry-After lors des maintenances planifiées
• Tester votre configuration de maintenance sur un sous-domaine avant déploiement
• Maintenir accessible au moins la homepage et les pages de conversion critiques
• Monitorer la Search Console quotidiennement pendant et après l'incident
• Soumettre manuellement les URL prioritaires via sitemap XML dès le retour en ligne
• Documenter chaque panne avec sa durée et son impact SEO observé pour affiner vos protocoles