Erreur serveur (5xx) dans la Search Console : un frein sur tout le crawl
Dans la Google Search Console, « Erreur serveur (5xx) » est le seul statut d'erreur dont l'effet déborde l'URL concernée. Une 404 reste cantonnée à sa page ; une 5xx, elle, pousse Google à lever le pied sur l'exploration de l'ensemble du site, d'autant plus fort que le nombre d'URLs en erreur grimpe.
Cette mécanique de ralentissement change la lecture du rapport. Que signale vraiment un serveur qui n'a pas pu répondre, quand le code ne dit rien du contenu de la page ? Pourquoi une poignée de 5xx ne pèse-t-elle pas comme une vague qui revient à chaque montée en charge ? Et combien de temps Google patiente-t-il avant de retirer une URL longtemps indexée ?
Trois questions qui font la différence entre un hoquet ponctuel et un frein installé sur tout le crawl.
Erreur serveur (5xx) : ce que dit la Search Console
Le statut signifie qu'au passage de Googlebot, votre serveur a renvoyé un code 5xx (de 500 à 599) au lieu de servir la page. Le code ne révèle rien du contenu : il indique seulement que le serveur n'a pas pu répondre à cet instant. Le rapport « Indexation des pages » de la Search Console regroupe ces cas sous l'étiquette « Erreur serveur (5xx) ».
C'est la nuance qui sépare une 5xx d'une 4xx. Une 4xx est une réponse sur la page : la 404 dit « cette URL n'existe pas », la 403 dit « l'accès est interdit ». Une 5xx ne dit rien de la page, parce que le serveur n'est jamais allé jusqu'à la traiter. Il s'est tu. Pour Googlebot, ce silence est un signal différent d'un refus explicite, et c'est précisément ce qui déclenche le comportement particulier des 5xx sur le crawl.
Ce silence distingue aussi la 5xx du Soft 404, où le serveur répond pourtant bien un code 200 « OK » mais sert une page vide ou un message d'erreur. Côté 5xx, le serveur ne ment pas sur l'état de la page : il avoue ne pas pouvoir répondre. Le Soft 404, lui, prétend que tout va bien alors que la page n'a rien à offrir. Deux problèmes opposés, deux corrections différentes.
Les codes derrière le « 5xx » : 500, 502, 503, 504
| Code | Nom | Ce que cela veut dire côté infra |
|---|---|---|
| 500 | Internal Server Error | Bug applicatif générique : une exception non gérée, un script qui plante, une dépendance indisponible. |
| 502 | Bad Gateway | Une passerelle (reverse proxy, CDN, load balancer) a reçu une réponse invalide du serveur en amont (upstream). |
| 503 | Service Unavailable | Service temporairement indisponible : surcharge, redémarrage, ou maintenance planifiée. |
| 504 | Gateway Timeout | Une passerelle a attendu trop longtemps une réponse de l'amont : le délai a été dépassé. |
La Search Console agrège tous ces cas sous une seule étiquette « 5xx ». Pour connaître le code précis qui s'est produit, il faut le récupérer ailleurs : dans les logs serveur, ou via une inspection qui remonte la réponse réellement reçue par Googlebot.
5xx, 4xx, robots.txt : trois blocages très différents
| 5xx | 4xx | robots.txt (disallow) | |
|---|---|---|---|
| Le code dit-il quelque chose sur la page ? | Non : le serveur n'a pas pu répondre. | Oui : la page n'existe pas (404) ou l'accès est interdit (403). | Non : exclusion volontaire, la page n'est pas lue. |
| Effet sur le taux de crawl ? | Ralentit l'exploration de tout le site, proportionnellement au nombre d'URLs en erreur. | Aucun effet sur le rythme (sauf le 429). | Aucun effet. |
| Désindexation | Sursis, puis abandon si l'erreur persiste. | Retrait progressif (Google réessaie avant d'abandonner). | L'URL peut rester indexée sans que son contenu soit lu. |
Cette grille met en évidence le trait propre aux 5xx : c'est le seul des trois cas dont l'effet ne s'arrête pas à l'URL fautive. Une 4xx et un blocage robots.txt concernent uniquement la page visée ; une 5xx, elle, retentit sur le rythme d'exploration de tout le site.
Pourquoi une 5xx freine le crawl de tout le site
Les erreurs 5xx (et le code 429) poussent Googlebot à ralentir temporairement le crawl de tout le site, proportionnellement au nombre d'URLs en erreur. Les 4xx, à l'inverse, n'ont aucun effet sur le rythme d'exploration. La logique de Google est simple : un serveur qui répond par des 5xx est sans doute en difficulté, et continuer à le solliciter au même rythme risquerait de l'achever.
Googlebot adopte donc un réflexe de protection. Plus le volume de 5xx augmente, plus il réduit sa cadence pour ne pas aggraver la situation. Ce comportement est documenté par Google dans sa page sur les erreurs HTTP et réseau, qui range explicitement les 5xx et le 429 parmi les réponses qui font lever le pied à l'explorateur.
La conséquence pour le SEO est indirecte mais réelle. Pendant ce ralentissement, vos pages parfaitement saines sont crawlées moins souvent. Une mise à jour de contenu, une nouvelle page, une correction sur une fiche produit : tout cela est vu plus tard par Google. Le frein ne pénalise pas que les URLs en erreur, il pénalise le rythme auquel Google découvre l'ensemble de vos changements. C'est ce qui rend la 5xx fondamentalement différente d'une erreur Introuvable (404), qui reste cantonnée à sa propre page sans toucher au reste.
Ponctuel ou récurrent : calibrer l'urgence
Toutes les 5xx ne se valent pas. Un pic isolé, lié à un déploiement ou à un redémarrage, est un hoquet : le serveur a flanché une fraction de seconde puis a repris. Une vague récurrente, déclenchée à chaque montée en charge, est un frein structurel installé. La distinction commande directement le niveau de priorité à donner à la correction.
Les 5xx ponctuelles (déploiement, redémarrage, à-coup réseau)
Une 5xx ponctuelle survient au moment précis où Googlebot frappe à la porte pendant que le serveur est indisponible une fraction de seconde. Un déploiement qui redémarre l'application, un conteneur recyclé, un pic réseau passager : la fenêtre d'indisponibilité est étroite, et la plupart de vos visiteurs ne la remarquent même pas.
Ces erreurs apparaissent dans le rapport, mais elles se résorbent souvent d'elles-mêmes au passage suivant de Googlebot. Le bon réflexe n'est pas de paniquer à la première ligne 5xx, mais de regarder si le phénomène se répète d'une analyse à l'autre. Une 5xx qui apparaît une fois puis disparaît n'a pas le même poids qu'une 5xx qui revient à chaque relevé.
Les 5xx récurrentes ou induites par la charge
C'est le cas qui mérite vraiment de l'attention. Ici, le serveur sature, soit sous la charge du trafic réel, soit sous celle du crawl lui-même quand Googlebot explore beaucoup d'URLs en peu de temps. Les erreurs sont alors intermittentes : elles surgissent aux pics, puis s'effacent quand la charge retombe.
Le piège, c'est leur invisibilité. Vous ouvrez l'URL dans votre navigateur au moment du calme, elle répond parfaitement un 200, et vous concluez à un faux positif de la Search Console. En réalité, la page était bien en 5xx au moment où Googlebot l'a sollicitée, en plein pic. C'est aussi une erreur HTTP que l'on retrouve, dans une autre logique, avec le statut Bloquée en raison d'une interdiction d'accès (403) : ce que vous voyez à un instant donné ne reflète pas toujours ce que Googlebot a reçu lors de son dernier passage.
Identifier les pages en 5xx à l'échelle
L'inspecteur d'URL de la Search Console donne le verdict 5xx page par page, ce qui le rend impraticable dès que vous voulez mesurer l'ampleur du phénomène. Or les 5xx sont souvent intermittentes : une URL qui répond correctement quand vous la testez a très bien pu renvoyer une 5xx au dernier passage de Googlebot. D'où l'intérêt d'un verdict daté du passage de Google, plutôt que d'un test que vous lancez vous-même à un moment de calme.
C'est toute la difficulté du diagnostic des 5xx. Un crawl maison vous dit l'état du serveur maintenant, sous votre charge à vous. Le verdict de Google, lui, vous dit l'état du serveur au moment où Googlebot a frappé, sous la charge de ce moment-là, qui est souvent celle qui fait saturer le serveur. Ces deux photographies ne coïncident pas toujours, et c'est la seconde qui détermine ce que Google retient.
💡 Besoin de voir combien de vos URLs renvoient une 5xx, et lesquelles ? IndexProbe inspecte votre liste d'URLs via l'API de la Search Console et remonte, par page, le code que Googlebot a réellement reçu, daté de son dernier passage. Tester IndexProbe en accès anticipé →
Du « code par URL » au taux d'erreurs : ce que la GSC ne montre pas
La Search Console vous donne le statut d'une URL, mais elle ne vous donne pas, sur la liste de pages qui vous intéresse, la part exacte qui renvoie une 5xx ni la liste précise des URLs concernées. Vous savez qu'il y a un problème, sans en mesurer le contour. Et comme l'inspecteur fonctionne une URL à la fois, reconstituer ce taux à la main sur des milliers de pages relève de l'impossible.
C'est exactement le passage que IndexProbe automatise. L'outil est la version en masse de l'inspecteur d'URL de la Search Console : là où la GSC vous fait inspecter vos pages une par une, IndexProbe passe au crible la liste d'URLs que vous fournissez, ou que vous constituez depuis votre GSC, et remonte pour chacune le code reçu par Googlebot. Vous obtenez d'un seul tenant la part de 5xx parmi les pages analysées et la liste exacte des URLs à traiter, là où l'inspecteur une-à-la-fois vous laisserait recroiser les résultats manuellement.
Corriger une erreur serveur 5xx
Corriger une 5xx, c'est rendre le serveur de nouveau capable de renvoyer un code 200. Selon la cause, cela passe par alléger la charge (cache, CDN, montée en capacité), corriger le bug applicatif responsable, ou optimiser les requêtes trop lentes qui font expirer les délais. Pour Google, le seul signal de fin est le retour d'un code 2xx au passage suivant de Googlebot.
Réflexes par code (500, 502, 503, 504)
Chaque code oriente vers une famille de causes, et donc vers un point de départ pour le diagnostic.
- 500 (Internal Server Error) — Direction les logs applicatifs. Une exception non gérée, une dépendance externe tombée, une variable d'environnement manquante après un déploiement : le 500 est un bug côté code, et c'est dans la trace d'erreur que se trouve la réponse.
- 502 (Bad Gateway) — Le problème est entre la passerelle et le serveur en amont. Vérifiez que le service applicatif tourne bien, que le reverse proxy ou le CDN pointe sur la bonne cible, et que l'amont ne renvoie pas de réponse malformée.
- 503 (Service Unavailable) — Souvent un signe de saturation ou de redémarrage. Si c'est la charge, il faut ajouter de la capacité ou du cache. Si c'est une maintenance, le 503 est justement la bonne réponse, à condition de l'accompagner correctement (voir ci-dessous).
- 504 (Gateway Timeout) — Une requête met trop de temps à aboutir. Cherchez les traitements lents : requêtes de base de données non optimisées, appels à des services tiers sans délai d'expiration, calculs lourds sur le chemin critique.
Maintenance planifiée : la bonne réponse est 503 + Retry-After
⚙️ Couper proprement pour une maintenance
Pour une coupure d'un ou deux jours, la bonne réponse est un code 503 assorti de l'en-tête
Retry-After, qui indique à Googlebot quand revenir. Google patiente alors sans pénaliser le site, en comprenant que l'indisponibilité est volontaire et temporaire.À éviter absolument : renvoyer un code 200 accompagné d'un message « Site en maintenance ». Pour Google, c'est une page valide au contenu vide, donc un Soft 404 en puissance.
Attention enfin à la durée : au-delà de quelques jours, un 503 prolongé finit par faire sortir les pages de l'index. La méthode est documentée par Google dans son guide Pause d'une activité en ligne.
Vérifier que la correction a fonctionné
Trois mouvements mesurables confirment que la correction a porté : le nombre de pages en 5xx baisse, le taux d'erreurs 5xx sur le périmètre suivi recule, et les pages crawlées sur 30 jours repartent à la hausse, signe que Google relâche le frein. La méthode consiste à comparer deux analyses du même périmètre, avant et après l'intervention.
Un point à garder en tête : la reprise du crawl est progressive, pas instantanée. Une fois les 5xx résorbées, Googlebot ne réaccélère pas d'un coup. Il reteste prudemment, vérifie que le serveur tient, puis relève peu à peu sa cadence. Les pages crawlées sur 30 jours remontent donc sur plusieurs relevés, pas du jour au lendemain.
💡 Suivez la reprise du crawl, analyse après analyse. IndexProbe vous donne le verdict officiel 5xx de Google, daté de son dernier passage, sur la liste d'URLs que vous fournissez ou constituez depuis la GSC. En relançant la même analyse, vous comparez deux relevés du même périmètre et vous mesurez la baisse réelle des erreurs et la reprise de l'exploration, sans recroiser l'inspecteur d'URL une page à la fois. Tester IndexProbe en accès anticipé →
Questions fréquentes
Une erreur 5xx désindexe-t-elle ma page ? Pas immédiatement. Tant que l'erreur est ponctuelle, Google laisse un sursis à la page et continue de la considérer comme indexée. C'est seulement si la 5xx persiste sur la durée que l'URL finit par sortir de l'index. Le retour d'un code 2xx au passage suivant de Googlebot remet la page en lice.
Quelle différence entre une 5xx et une 404 pour le SEO ? Une 404 reste cantonnée à sa propre page et n'a aucun effet sur le rythme d'exploration du reste du site. Une 5xx, elle, ne dit rien du contenu de la page mais ralentit le crawl de tout le site, proportionnellement au nombre d'URLs en erreur. La 404 est un problème local, la 5xx un problème qui déborde.
Combien de temps Google patiente-t-il avant de retirer une URL en 5xx ?
Google ne publie pas de durée précise. Sa documentation parle d'erreurs « persistantes » sans fixer de seuil chiffré. Le seul cas borné est la maintenance avec un 503 et un en-tête Retry-After : Google patiente alors quelques jours, mais au-delà, le 503 prolongé finit aussi par faire sortir les pages.
Faut-il renvoyer un 503 ou un 500 pendant une maintenance ?
Un 503 accompagné de l'en-tête Retry-After. Le 503 indique une indisponibilité volontaire et temporaire, que Google comprend et tolère. À l'inverse, un 500 subi est un bug, et un 200 avec un message « Site en maintenance » est un faux signal qui sera interprété comme une page vide, donc un Soft 404 potentiel.
Le 429 est-il traité comme une 5xx ? Du point de vue du crawl, oui. Le 429 (« Too Many Requests ») est la seule erreur de la famille 4xx qui, comme les 5xx, fait ralentir l'exploration de tout le site. Google le classe avec les erreurs serveur précisément parce qu'il signale une surcharge, et adopte donc le même réflexe de protection.