Une maintenance mal configurée produit deux mensonges opposés. Le premier symptôme répond 200 OK avec une page « revenez bientôt » sur toutes les URL : les sondes croient le site sain et les robots peuvent associer ce contenu générique aux pages commerciales. Le second renvoie durablement 404, 403 ou une interdiction robots.txt : une interruption temporaire ressemble alors à une suppression ou à une restriction permanente. Dans les deux cas, l’exploitation perd le signal dont elle a besoin.
En pratique, le vrai enjeu est qu’un mode maintenance forme un contrat HTTP borné. Il décrit une indisponibilité réelle avec 503 Service Unavailable, propose une estimation de reprise, reste suffisamment léger pour fonctionner lorsque l’application est arrêtée et conserve une voie de contrôle. Mais la meilleure maintenance globale est souvent celle qu’on évite : désactiver seulement le paiement ou l’écriture préserve l’information, la visibilité et la relation client.
Vous allez décider le niveau d’arrêt, construire la réponse, tester le CDN et réouvrir sans laisser d’erreurs résiduelles. Notre accompagnement en SEO technique transforme ce runbook en tests reproductibles pour que la fenêtre planifiée protège en même temps les utilisateurs, le crawl et les revenus.
Choisir entre fonction limitée et arrêt complet
Préserver les pages lisibles chaque fois que l’architecture le permet
La documentation Google Mettre temporairement en pause une activité en ligne recommande de limiter la fonctionnalité plutôt que de désactiver tout le site. Un catalogue peut rester consultable pendant que le panier est fermé ; un espace éditorial peut rester en ligne pendant une migration de commande ; une page produit peut signaler une indisponibilité sans disparaître. Cette option minimise la rupture pour les personnes et pour la recherche.
Classez les fonctions selon leur dépendance à l’opération prévue. Lecture de pages statiques, images et aide peuvent être servies depuis le bord. Connexion, paiement, écriture et calcul en temps réel peuvent être désactivés ou mis en file. Pour chaque fonction limitée, expliquez l’état et proposez une alternative : wishlist, demande de rappel, numéro de support ou date de reprise. Une bannière informative en 200 sur des pages réellement disponibles n’est pas un mode maintenance global.
L’arrêt complet se justifie lorsque schéma de données, routage, infrastructure ou sécurité rendent toute lecture incertaine. Il doit rester très court, idéalement quelques heures et au maximum quelques jours selon Google. Au-delà, la stratégie change : conserver au moins une page d’accueil indexable et utile peut être préférable à des 503 prolongés. La décision appartient conjointement au responsable technique, au métier et au SEO, avec une durée et un seuil d’abandon explicites.
Définir le contrat HTTP du mode maintenance
Retourner 503 seulement lorsqu’un service est réellement indisponible
Le RFC 9110 définit 503 Service Unavailable comme l’incapacité temporaire du serveur à traiter la requête en raison d’une surcharge ou d’une maintenance. C’est la sémantique attendue pour une URL qui ne peut pas fournir sa représentation normale pendant une courte fenêtre. La réponse peut contenir un document utile ; son statut reste 503. Un reverse proxy qui réécrit le statut en 200 détruit cette information.
L’en-tête Retry-After indique combien de temps le client devrait attendre avant une nouvelle tentative. Le même RFC autorise une date HTTP ou un nombre de secondes. Choisissez une estimation réaliste et mettez-la à jour si la fenêtre dérive. Une valeur de 300 secondes convient à un contrôle rapproché ; une date peut mieux communiquer une fenêtre planifiée. Cet en-tête ne garantit pas que tous les robots réessaieront exactement à cet instant, mais il explicite l’intention.
Conservez des en-têtes cohérents : type text/html, langue, politique de cache calculée, sécurité minimale et identifiant de maintenance. N’ajoutez ni noindex ni redirection vers une URL unique. Le contenu temporaire ne doit pas devenir une représentation canonique. Testez aussi les méthodes : une page publique en GET peut recevoir le document 503 ; un POST transactionnel doit être arrêté avant toute écriture partielle et ne pas être rejoué sans idempotence.
Construire une page 503 légère et autonome
Servez un fichier HTML statique depuis Nginx, le load balancer ou le CDN, indépendamment de la base, du framework et des services modifiés. Le document contient un titre clair, la nature temporaire de l’arrêt, l’heure de dernière mise à jour, l’estimation de reprise et un moyen de contact. Il ne doit pas exposer la migration, les versions ni une trace d’erreur. Un langage honnête vaut mieux qu’une promesse précise impossible à tenir.
Minimisez les dépendances : CSS inline limité, logo intégré ou asset stable, aucune police tierce, aucun script d’analyse obligatoire et aucune API pour afficher l’état. Google recommande précisément un HTML statique avec peu de ressources externes. Si la page dépend du même cluster arrêté, elle peut répondre tardivement ou échouer en cascade. Le poids réduit protège aussi la capacité lorsque les clients réessaient.
Prévoyez une page accessible : contraste, structure de titres, message compréhensible, focus visible et coordonnées utilisables sans JavaScript. Traduisez-la pour les marchés essentiels ou choisissez une information multilingue très courte. Le contenu ne cherche pas à se positionner ; il rassure et donne une action. Ne recopiez pas toutes les balises SEO des pages normales sur la même réponse générique, car les systèmes ne peuvent de toute façon pas actualiser ces métadonnées à partir d’un 503.
Exemple concret : une migration de base de quatre heures conserve accueil, pages services et documentation depuis un cache préchauffé. Les formulaires affichent une indisponibilité locale et répondent 503 sur l’endpoint d’envoi. Si une incohérence apparaît, un commutateur bascule tout le hostname vers la page statique 503. L’entreprise préserve son information tant que possible et possède un repli global indépendant lorsque la lecture n’est plus fiable.
Appliquer le bon statut au bon périmètre
Énumérez les routes et dépendances. Les pages réellement disponibles restent en 200 avec leur contenu normal. Une fonction temporairement indisponible répond 503 sur sa propre URL ou son action. Les ressources inexistantes restent 404 ; les redirections canoniques restent 301 ou 308 si leur destination est disponible. Transformer tous les statuts en 503 masque les vraies erreurs et empêche de distinguer une route oubliée de la maintenance.
Décidez si le périmètre est un chemin, une application, un hostname ou tout le domaine. Une maintenance du back-office ne doit pas toucher le site public. Une panne de paiement peut laisser le catalogue intact. Si plusieurs domaines partagent l’infrastructure, vérifiez chacun : domaine nu, www, API, assets et sous-domaines locaux. Les règles au CDN peuvent diverger selon le host et créer une expérience impossible à reproduire depuis une seule URL.
N’accordez pas un contenu normal à Googlebot lorsque les utilisateurs reçoivent une page d’arrêt. Cette divergence complexifie la recette et peut ressembler à une présentation différente selon le client. Servez la même disponibilité réelle, sauf voies d’administration explicitement sécurisées. Les adresses IP internes et VPN peuvent accéder au système pour tester, mais cette exception ne doit pas modifier ce que les sondes externes et les robots observent.
Maintenir robots.txt accessible pendant l’arrêt
Le fichier /robots.txt doit rester accessible avec un statut 200 et sa configuration normale. Google déconseille de lui retourner 503 pendant la fermeture, car cela bloque le crawl au niveau du site. Ne remplacez pas non plus son contenu par Disallow: / : une interdiction valide sur toute l’arborescence peut avoir des conséquences sur la présence des URL et ne décrit pas une indisponibilité de service.
Servez robots.txt depuis une couche stable et incluez-le dans les sentinelles. Vérifiez son corps, son type et son statut après chaque bascule CDN. Si le site a plusieurs hostnames, chacun possède son propre fichier. Une page de maintenance globale implémentée par wildcard doit comporter une exception explicite pour robots.txt, ainsi que pour les endpoints de santé qui ne représentent pas une page publique.
Ne profitez pas de la fenêtre pour modifier simultanément les règles de crawl, les canoniques et le sitemap. Chaque changement supplémentaire rend la reprise moins attribuable. Si une migration de structure impose de nouvelles URL, testez redirections et métadonnées dans un lot distinct avant ou après la maintenance. Le cadre budget de crawl et indexation aide à vérifier la reprise une fois le service revenu.
Maîtriser CDN, cache et Retry-After
Éviter qu’une réponse temporaire survive à la réouverture
Documentez la politique de cache de la page 503 et le comportement de chaque intermédiaire. Un CDN peut mettre en cache des erreurs selon sa configuration, parfois avec un TTL distinct des réponses normales. Choisissez une durée courte, compatible avec la charge, puis préparez une purge ciblée. Un Retry-After d’une heure n’est pas une directive de cache ; il indique le délai conseillé avant nouvelle tentative. Ne supposez pas qu’il expirera automatiquement l’objet au bord.
Avant la bascule, préchauffez les pages qui resteront disponibles et la ressource statique de maintenance. Pendant l’arrêt, surveillez HIT, MISS et statut à l’origine. Une règle « stale-if-error » peut garder un contenu sain pendant une courte panne, mais elle risque de servir un prix ou un stock obsolète. Réservez-la aux représentations où la fraîcheur tolérée est connue et affichez une information si une action dynamique reste indisponible.
À la reprise, désactivez d’abord la règle de génération du 503, purgez uniquement les réponses temporaires et contrôlez plusieurs points de présence. Une purge totale peut créer un pic de MISS et surcharger l’origine juste après la maintenance. Étalez le réchauffement sur les pages prioritaires, puis le long tail. Le seuil de réouverture associe taux de 2xx, TTFB, erreurs applicatives et capacité restante, pas seulement la réussite d’une URL depuis le bureau.
Répéter la bascule et le retour avant le jour J
Le test en préproduction simule le chemin complet : activation depuis la couche prévue, vérification externe, accès administratif, maintien de robots.txt, statut des assets, mise à jour de Retry-After, désactivation et purge. Utilisez curl -I pour lire les en-têtes, puis un navigateur sans cache pour contrôler le contenu. Rejouez depuis au moins deux régions si un CDN intervient.
curl -sS -D - -o /dev/null https://www.exemple.fr/page-critique
# Attendu pendant l'arrêt : HTTP 503 et Retry-After cohérent
curl -sS -D - https://www.exemple.fr/robots.txt
# Attendu : HTTP 200 et règles habituellesProvoquez trois échecs : le fichier statique indisponible, la purge CDN retardée et la maintenance dépassant son heure prévue. Le runbook doit décrire la réponse à chacun. Une page locale de second niveau peut secourir le fichier principal ; une commande de purge par tag évite l’invalidation globale ; un message mis à jour et un nouveau Retry-After maintiennent l’honnêteté lorsque la durée dérive.
Mesurez le temps réel d’activation et de retour. La personne d’astreinte exécute la procédure sans aide orale, avec droits de production contrôlés. Le test n’est réussi que lorsque les statuts sont corrects au bord, les écritures sont réellement bloquées, les pages normales reviennent et aucun 503 n’est encore servi depuis les caches testés. Versionnez la configuration avec la release.
Cas concret. Si le 503 dépasse le seuil de quinze minutes sur un POP alors que les autres régions sont revenues, purgez uniquement ce segment et gardez le canari fermé. La décision protège les visiteurs touchés sans provoquer un MISS global, puis un contre-test externe confirme le retour du contenu normal.
Surveiller utilisateurs, robots et dépendances
Créez des sondes distinctes : page normale attendue en 200 avant et après, page de maintenance attendue en 503 pendant, robots.txt attendu en 200 en continu, fonction désactivée attendue en 503 et endpoint de santé interne. La sonde ne doit pas considérer tout statut inférieur à 500 comme un succès. Elle vérifie le statut exact, un marqueur distinctif, l’en-tête de reprise et l’identifiant de configuration.
Suivez le nombre de 503 par template, les régions, le cache, la latence de la page statique et les tentatives sur fonctions arrêtées. Contrôlez les requêtes Googlebot vérifiées sans leur réserver un chemin différent. Une maintenance courte réduira temporairement le crawl ; l’objectif est surtout d’éviter les faux 200, les erreurs permanentes et la prolongation. Si les 503 continuent après désactivation, recherchez cache, règle WAF, instance ancienne ou DNS pointant vers un environnement non rouvert.
Les métriques métier restent nécessaires : demandes au support, abandon, inscriptions aux alertes et transactions mises en attente. Une maintenance techniquement parfaite peut être mal comprise si aucune heure n’est affichée. Désignez une personne qui actualise le message selon les jalons réels. Les équipes techniques ne doivent pas reconstruire la formulation en urgence ; les variantes de communication sont préparées avec le runbook.
Rouvrir progressivement sans conserver de 503
Valider la santé avant de relancer toutes les fonctions
Rouvrez d’abord les lectures sur une cohorte interne ou un petit pourcentage externe. Vérifiez schéma, caches, sessions, rendu, recherche interne et dépendances. Activez ensuite les écritures non critiques, puis paiement et traitements asynchrones. Les files accumulées peuvent créer une seconde saturation ; contrôlez leur débit et appliquez du backpressure. Une réouverture totale immédiate concentre visiteurs, robots et tâches différées sur une origine encore froide.
Purger les réponses 503 ne suffit pas. Vérifiez le document final, les redirections, canoniques, données structurées, formulaires et ressources. Comparez une liste d’URL sentinelles à l’état d’avant maintenance. La chaîne de tests de non-régression SEO technique en CI/CD permet d’automatiser statut, contenu et métadonnées sur ce corpus.
Après retour, surveillez 24 à 48 heures selon le trafic : taux de crawl, 5xx, TTFB, logs de cache et conversions. N’envoyez pas artificiellement des milliers d’URL à l’inspection. Les sitemaps et les liens normaux soutiennent la reprise ; une inspection ciblée peut vérifier quelques pages prioritaires. Clôturez seulement lorsque le trafic est stable et qu’aucune région ne conserve l’ancienne réponse.
Pour qui arbitrer durée, fraîcheur et continuité commerciale
Servir un contenu ancien depuis le cache peut préserver l’information mais présenter un prix ou un stock faux. Choisissez par type de donnée. Les articles, guides et coordonnées peuvent tolérer une fraîcheur supérieure ; un stock ou une promotion exige une mention ou une désactivation de l’action. Le compromis doit être écrit avant la fenêtre, quand l’équipe peut encore consulter le métier.
Un arrêt nocturne simplifie parfois l’audience humaine et peut coïncider avec un cycle de crawl ou un marché international actif. Basez l’horaire sur le trafic par région, les transactions, la disponibilité des équipes et la capacité de support. Une fenêtre plus courte avec davantage d’ingénieurs peut coûter moins qu’un arrêt long supposé discret. Calculez revenu exposé, coût d’astreinte et risque de retour arrière.
Contre-intuitivement, cacher tout le site « pour éviter que Google voie la maintenance » aggrave souvent le risque. Un 503 explicite et court permet aux clients de comprendre une indisponibilité temporaire. Un blocage robots.txt ou un faux 200 retire cette sémantique. L’excellence n’est pas l’absence de trace : c’est une trace exacte, bornée et vérifiable.
Erreurs fréquentes d’un mode maintenance
- Servir la même page de maintenance en 200 sur toutes les URL et masquer la panne aux sondes.
- Rediriger toutes les pages vers l’accueil ou une URL d’arrêt, ce qui détruit la sémantique des ressources.
- Retourner 404, 410, 403 ou noindex pour une indisponibilité temporaire.
- Mettre robots.txt en 503 ou ajouter un
Disallow: /pendant la fenêtre. - Faire dépendre la page statique de la base ou des assets en maintenance.
- Ignorer le cache d’erreur CDN et découvrir des 503 après la réouverture.
- Ouvrir tout le trafic sur une origine froide sans canari, préchauffage ni contrôle des files.
Une dernière erreur consiste à ne prévoir que l’activation. La majorité du risque se trouve parfois dans la reprise : purge, migrations incompatibles, tâches différées et anciennes instances. Le runbook doit consacrer autant de contrôles au retour qu’à l’arrêt. Le propriétaire de chaque étape confirme une preuve, une heure et le seuil qui déclenche le repli.
Questions fréquentes sur une fermeture temporaire
Combien de temps peut-on servir 503 ?
Il n’existe pas de durée universelle sans effet, mais Google réserve l’arrêt complet à une très courte période, quelques jours au maximum. Plus l’indisponibilité dure, plus le crawl ralentit et les URL risquent de perdre leur présence. Pour des semaines, limitez les fonctions ou conservez une page utile en 200.
Retry-After oblige-t-il Googlebot à revenir à l’heure indiquée ?
Non. Il communique une estimation selon la sémantique HTTP ; le client garde sa stratégie. Utilisez une valeur réaliste, mettez-la à jour et ne la confondez pas avec un TTL de cache. La reprise se vérifie dans les logs, pas dans l’intention de l’en-tête.
Peut-on laisser l’accueil en 200 et le reste en 503 ?
Oui si l’accueil fournit réellement une information durable et si les autres ressources sont indisponibles. Ne faites pas répondre son contenu en 200 sous toutes les URL. Chaque chemin conserve son statut et son identité ; l’accueil peut expliquer la situation et les pages arrêtées répondre 503.
Faut-il fermer l’accès à Googlebot pendant la migration ?
Non. Servez-lui le même 503 temporaire que les visiteurs pour les ressources indisponibles et gardez robots.txt accessible. Une exception de contenu complique la validation. Une voie administrative protégée peut être utilisée par les équipes, mais elle ne représente pas la réponse publique.
Articles complémentaires à lire ensuite
Préparez la reprise avec les contrôles SEO techniques de CI/CD, puis suivez l’effet sur le budget de crawl et l’indexation. Ces deux protocoles donnent une preuve avant, pendant et après la fenêtre.
Les sentinelles QA comparent chaque route, son HTML, son canonical et son cache après invalidation. Pour les rendus SSR ou ISR, la revalidation doit éliminer toute réponse 503 résiduelle avant d’ouvrir le trafic complet aux utilisateurs et à Googlebot.
Plan d’action maintenance en douze étapes
- Lister les fonctions et choisir la limitation ciblée avant d’envisager l’arrêt complet.
- Définir périmètre, durée, propriétaire, seuil d’abandon et décision de rollback.
- Construire une page statique légère, accessible, autonome et sans données sensibles.
- Configurer 503 et un Retry-After réaliste sur les seules ressources indisponibles.
- Maintenir robots.txt en 200 avec ses règles habituelles sur chaque hostname.
- Documenter cache d’erreur, TTL, tags de purge et comportement stale du CDN.
- Préparer accès administratif, sondes externes et communication client.
- Répéter activation, dépassement de durée, échec de page statique et désactivation.
- Vérifier statuts, contenu, cache et régions avec curl et navigateur neuf.
- Rouvrir en canari, préchauffer les pages prioritaires et contrôler les files.
- Purger les 503 sans déclencher un MISS global qui sature l’origine.
- Surveiller 24 à 48 heures puis clore quand contenu, crawl, capacité et transactions sont stables.
- À valider : robots.txt reste en 200 et toutes les régions récupèrent le contenu attendu.
- À replier : un cache d’erreur persiste, la capacité chute ou une écriture devient incohérente.
Conclusion : une indisponibilité honnête, courte et réversible
Le meilleur mode maintenance conserve les pages et limite uniquement la fonction arrêtée. Lorsque l’indisponibilité globale est inévitable, un 503 explicite, un Retry-After raisonnable et une page statique autonome décrivent correctement l’état. Robots.txt reste disponible et aucune directive permanente ne tente de cacher l’interruption.
La qualité se joue dans la répétition et la reprise : tester CDN, statuts, caches, dépendances et commandes de repli, puis rouvrir progressivement sur une origine contrôlée. La fenêtre devient alors un changement réversible avec des seuils, et non une bannière activée dans l’urgence.
Pour concevoir ce dispositif, automatiser les sentinelles et protéger vos pages stratégiques pendant les opérations sensibles, sollicitez notre expertise en SEO technique. Nous alignons exploitation, développement et acquisition autour d’une maintenance courte, observable et sans dette d’indexation durable.
