// diagnostic GSC
Erreur serveur (5xx) : corriger ce statut.
Le seul statut d'exclusion qui s'aggrave tout seul : chaque 5xx servie à Googlebot ralentit le crawl, et un serveur durablement instable finit désindexé page après page. Diagnostiquer vite, stabiliser, puis surveiller la reprise du crawl.
Ce que signifie ce statut.
"Erreur serveur (5xx)" regroupe les URLs pour lesquelles Googlebot n'a pas obtenu de réponse exploitable : erreur interne (500), passerelle défaillante (502), service indisponible (503), délai dépassé (504) ou connexion interrompue. À la différence d'une 404 qui affirme "cette page n'existe pas", la 5xx dit "le serveur n'a pas réussi à répondre" : Google ne sait pas si la page existe encore.
Cette incertitude explique le traitement particulier : Google réessaie d'abord, préserve l'index quelques jours, puis interprète la persistance de l'erreur comme une disparition.
// à retenir
Les 5xx sont le seul statut d'exclusion à effet cumulatif : elles dégradent à la fois l'indexation des pages touchées ET la fréquence de crawl de tout le site. Priorité absolue quand le volume grimpe.
La spirale : du 5xx à la désindexation.
La réaction de Google aux erreurs serveur suit une logique de protection documentée : ne jamais aggraver la charge d'un serveur en difficulté.
- 01
Ralentissement immédiat du crawl
Dès que le taux de 5xx augmente, Googlebot réduit sa cadence de requêtes. Visible dans Paramètres > Statistiques d'exploration : la courbe "Nombre total de demandes d'exploration" chute en même temps que la courbe des erreurs monte. Les nouvelles pages attendent, les mises à jour ne sont plus vues.
- 02
Sursis pour les pages indexées
Les pages déjà indexées conservent leur place quelques jours : Google sert sa copie en cache et retente le crawl. Un incident court (heures, un à deux jours) n'a en pratique aucun impact durable sur les positions.
- 03
Désindexation progressive
Au-delà de plusieurs jours d'échecs répétés, Google traite les URLs comme disparues et les retire de l'index, en commençant par les moins consultées. La récupération n'est pas symétrique : une fois le serveur stabilisé, le retour dans l'index suit le rythme du re-crawl, étalé sur des semaines. Les délais d'indexation habituels s'appliquent à nouveau.
Identifier la cause.
Sous-dimensionnement ou surcharge
Hébergement mutualisé saturé, pic de trafic, tâche cron gourmande : le serveur rend des 500/503 aux heures de charge. Les 5xx servies à Googlebot sont souvent le premier symptôme visible, avant même les plaintes utilisateurs.
Timeout applicatif sur URLs lourdes
Requêtes SQL lentes, filtres à facettes générant des pages coûteuses, exports. Seules certaines familles d'URLs sont touchées : regarder les motifs communs dans la liste exportée du rapport.
Rate limiting et anti-bot
Un pare-feu qui limite les requêtes par IP transforme les rafales de crawl en 503. Symptôme typique : erreurs intermittentes, site parfaitement fonctionnel au test manuel. Proche cousin du blocage 403.
Défaillance d'un maillon (CDN, proxy, backend)
Les 502/504 pointent un maillon intermédiaire : le CDN ou reverse proxy répond, mais le backend derrière ne suit pas (déploiement raté, service down, certificat expiré côté origine).
Croiser systématiquement trois sources : la liste d'URLs du rapport GSC (motifs communs), les statistiques d'exploration (dates, volumes), et les logs serveur au moment des passages de Googlebot.
Stabiliser et revalider.
- Traiter la cause racine : upgrade d'hébergement, cache HTTP devant les pages coûteuses, optimisation des requêtes lentes, exception pour les bots vérifiés dans le rate limiting. Un site majoritairement statique ou bien caché ne sert quasiment jamais de 5xx à Googlebot.
- Pour les maintenances planifiées : répondre 503 avec header
Retry-After, jamais une page de maintenance en 200. Google met le crawl en pause et préserve l'index. - Confirmer côté Google : test en direct via Inspection de l'URL sur les pages touchées, puis "Valider la correction" dans le rapport. Surveiller le retour du volume de crawl dans les statistiques d'exploration sur les 2 semaines suivantes.
- Ré-accélérer l'indexation : après un incident long, resoumettre le sitemap et pousser les pages stratégiques via les méthodes de forçage d'indexation.
Panorama des autres statuts d'exclusion et de leur gravité relative dans le guide page non indexée par Google ; lecture détaillée du rapport dans maîtriser Search Console.
Questions fréquentes.
Que signifie le statut "Erreur serveur (5xx)" dans Search Console ?
Quand Googlebot a demandé la page, le serveur a répondu par un code d'erreur de la famille 500 : 500 (erreur interne), 502 (bad gateway), 503 (service indisponible), 504 (timeout), ou n'a pas répondu du tout. Google n'a pas pu lire le contenu : la page est exclue de l'index jusqu'à obtention d'une réponse valide.
Des erreurs 5xx ponctuelles sont-elles graves ?
Quelques 5xx isolées sont sans conséquence : Google réessaie plus tard et le statut se résorbe seul. Le danger est la récurrence : si le serveur répond souvent en erreur, Google réduit sa fréquence de crawl pour ne pas aggraver la charge (impact direct sur le crawl budget), puis finit par retirer de l'index les pages durablement injoignables.
Google désindexe-t-il un site à cause d'erreurs 5xx prolongées ?
Oui, progressivement. Après plusieurs échecs consécutifs sur une URL, Google la traite comme disparue et la retire de l'index. Un incident de quelques heures est sans effet ; une instabilité de plusieurs jours entame l'indexation, et une panne de plusieurs semaines peut désindexer une grande partie du site. La récupération après correction est ensuite étalée sur des semaines de re-crawl.
Pourquoi Googlebot reçoit des 5xx alors que le site fonctionne pour les visiteurs ?
Trois explications classiques : le crawl de Googlebot arrive en rafales qui déclenchent un rate limiting ou saturent un serveur dimensionné pour le trafic humain ; une protection anti-bot renvoie des 503 aux crawlers (à distinguer du blocage 403) ; ou l'erreur ne touche que certaines URLs profondes (pages à paramètres, requêtes lourdes) que les visiteurs ne consultent jamais.
Faut-il renvoyer un 503 pendant une maintenance ?
Oui, c'est exactement son rôle : le 503 avec un header Retry-After dit à Google "indisponibilité temporaire, revenez plus tard". Google préserve alors l'index existant. À ne jamais faire : servir la page de maintenance en code 200 (risque de l'indexer à la place du contenu) ou laisser un 503 permanent, qui devient un signal de disparition au bout de quelques jours.
Comment suivre le retour à la normale après correction ?
Deux endroits : Paramètres > Statistiques d'exploration (la courbe des réponses 5xx doit retomber à zéro et le volume de crawl remonter), et la ligne "Erreur serveur (5xx)" du rapport de pages, avec le bouton "Valider la correction". Le volume de crawl revient à son niveau antérieur en quelques jours à quelques semaines selon la durée de l'incident.
// passer à l'action
Contrôler la réponse serveur d'une URL.
Le diagnostic gratuit mesure le code de réponse, le temps de réponse et 15 autres points d'indexabilité en quelques secondes.