Comment arrêter temporairement un site sans perdre son classement Google ?

Pourquoi un arrêt temporaire peut-il affecter votre référencement ?

Lorsqu'un site devient inaccessible, Googlebot interprète cette indisponibilité selon les signaux HTTP renvoyés par le serveur. Si le crawler détecte des erreurs 404 ou 500 répétées, il conclut que les pages n'existent plus ou que le site est défaillant.

Cette lecture déclenche un processus de désindexation progressive : Google retire les URLs de son index après plusieurs tentatives infructueuses. Le problème se pose surtout lors de maintenances non signalées ou mal configurées, où le serveur répond par défaut avec un code d'erreur inapproprié.

Quel est le mécanisme recommandé par Google pour la maintenance ?

La solution officielle repose sur le code HTTP 503 Service Unavailable, accompagné d'un en-tête Retry-After qui indique la durée estimée de l'indisponibilité. Ce signal informe explicitement Googlebot que l'interruption est temporaire et planifiée.

Lorsque le crawler reçoit ce code 503 avec Retry-After, il met les URLs en attente sans les désindexer. Il reviendra automatiquement après le délai spécifié, préservant ainsi le classement et l'autorité accumulée.

Quelle durée d'arrêt Google tolère-t-il sans conséquence ?

Google ne communique pas de seuil officiel en nombre d'heures ou de jours. L'essentiel est que l'en-tête Retry-After soit cohérent avec la durée réelle de maintenance. Une maintenance annoncée pour 2 heures mais prolongée sur 48 heures risque de déclencher une réindexation partielle.

Dans la pratique, les observations terrain montrent qu'un arrêt de 24 à 48 heures correctement signalé ne génère aucun impact mesurable. Au-delà de 72 heures, même avec un 503 propre, certains signaux annexes (trafic nul, absence de mise à jour) peuvent influencer le crawl budget alloué au retour.

• Code 503 + Retry-After : signal clair pour Googlebot que l'arrêt est temporaire
• Éviter les 404/500 : ces codes déclenchent une désindexation progressive
• Cohérence durée annoncée/réelle : un écart trop important peut déclencher une réévaluation
• Crawl budget préservé : Google ne pénalise pas les maintenances correctement gérées
• Au-delà de 72h : risque de signaux négatifs cumulés (trafic, freshness, engagement nul)

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Les tests menés sur des sites clients confirment que le 503 avec Retry-After protège effectivement le classement lors d'arrêts courts (moins de 48h). Les positions se stabilisent dès le retour en ligne, sans chute mesurable dans les SERP. Ce comportement est reproductible sur différents types de sites (e-commerce, média, B2B).

En revanche, [A vérifier] la tolérance exacte de Google au-delà de 72 heures reste floue. Certains sites ont maintenu leur ranking après une semaine en 503, d'autres ont subi une érosion progressive après 4 jours. Les variables non documentées (autorité du domaine, fréquence de crawl habituelle, historique de fiabilité) semblent jouer un rôle.

Quelles nuances faut-il apporter à cette recommandation officielle ?

Google ne mentionne pas les arrêts non planifiés (crash serveur, attaque DDoS, problème infrastructure). Dans ces cas, impossible de configurer proprement un 503 avec Retry-After : le site renvoie souvent des timeouts ou des 500 aléatoires. L'impact SEO dépend alors de la rapidité de remise en ligne et de la fréquence de crawl.

Autre point non abordé : la gestion des fichiers statiques (CSS, JS, images). Si le site affiche une page de maintenance mais que Googlebot ne peut pas accéder aux ressources, le rendu peut échouer. Google a confirmé par le passé que des ressources bloquées nuisent à l'indexation, même si la page HTML est accessible.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Les sites avec un crawl budget déjà contraint (millions de pages, architecture complexe, autorité faible) ne bénéficient pas toujours de la même tolérance. Si Googlebot ne passe que deux fois par semaine, un arrêt de 48h peut coïncider avec une tentative de crawl, prolongeant de facto l'indisponibilité perçue.

Les sites sous Google News ou Discover subissent des règles plus strictes. Ces flux privilégient la fraîcheur et la disponibilité : une indisponibilité, même signalée en 503, peut entraîner une exclusion temporaire du carrousel. Le retour dans ces flux prend parfois plusieurs jours après la remise en ligne.

Que faut-il faire concrètement avant une maintenance planifiée ?

Configurer une page de maintenance avec code 503 et en-tête Retry-After est la priorité absolue. Ce header doit indiquer le délai en secondes (ex : Retry-After: 3600 pour 1 heure) ou une date précise au format HTTP (ex : Retry-After: Wed, 21 Oct 2025 07:28:00 GMT).

Testez cette configuration avant la mise en production sur un environnement de staging. Vérifiez avec les outils développeur du navigateur, puis avec un crawler comme Screaming Frog ou Sitebulb. Assurez-vous que le CDN ou le reverse proxy ne réécrit pas le code en 200 ou 302.

Quelles erreurs éviter pendant l'arrêt temporaire ?

Ne jamais utiliser de redirections 302 vers une page de maintenance hébergée sur un sous-domaine ou une URL différente. Google peut interpréter ce signal comme un déplacement de contenu, déclenchant une réévaluation des URLs originales. Le 503 doit être renvoyé depuis l'URL canonique elle-même.

Évitez de bloquer l'accès de Googlebot via robots.txt pendant la maintenance. Cette pratique empêche le crawler de voir le code 503, l'obligeant à revenir plus tard sans information sur la durée. Résultat : crawl budget gaspillé et incertitude sur le statut réel du site.

Comment vérifier que le site est correctement protégé après la remise en ligne ?

Consultez la Search Console dans les 24 à 48 heures suivant le retour. Vérifiez l'absence de pics d'erreurs 5xx ou 4xx dans le rapport de couverture. Si Google a correctement interprété le 503, aucun changement brutal ne doit apparaître dans les pages indexées.

Lancez un crawl manuel complet avec un outil dédié pour repérer d'éventuelles pages orphelines ou ressources bloquées apparues pendant la maintenance. Validez que les performances ne se sont pas dégradées (Core Web Vitals, temps de réponse serveur) : un site lent au redémarrage peut perdre du ranking même si l'arrêt était propre.

• Configurer code 503 + en-tête Retry-After avec durée réaliste
• Tester la réponse HTTP avec curl ou outils de crawl avant maintenance
• Vérifier que le CDN/proxy ne masque pas le 503
• Ne jamais rediriger vers une page de maintenance sur une URL différente
• Laisser Googlebot accéder au site (pas de blocage robots.txt)
• Monitorer Search Console dans les 48h post-remise en ligne
• Crawler le site après retour pour détecter anomalies ou ressources bloquées
• Valider stabilité des Core Web Vitals et temps de réponse serveur