Codes HTTP 5xx : erreurs serveur et impact SEO

Réponse courte

Les codes HTTP 5xx signalent que le serveur a compris la requête mais n’a pas pu y répondre. C’est la seule famille où la durée compte plus que le nombre : quelques minutes ne se voient pas, quelques jours font reculer l’exploration sur tout le domaine. Et c’est la seule où avouer la panne protège, là où la maquiller en 200 fait indexer l’écran d’erreur.

Le réflexe à corriger : afficher une page d’excuse en 200 pendant un incident. Le visiteur est rassuré, et Google enregistre une page parfaitement valide dont le contenu annonce que rien ne fonctionne.

11 codes

au registre, mais quatre suffisent à décrire ce qui arrive à un site : le 500, le 502, le 503 et le 504.

La durée

le facteur qui décide. Un incident de quelques minutes passe inaperçu, le même étalé sur des jours désindexe.

503

le seul code de la famille qu’on écrit volontairement. Avec un en-tête Retry-After, il transforme une panne en rendez-vous.

Schéma des codes 5xx courants : une fenêtre de navigateur affiche un 500 Internal Server Error, à côté d’une liste où figurent 502 Bad Gateway, 503 Service Unavailable et 504 Gateway Timeout. — Les quatre codes 5xx qu’un site rencontre, et l’endroit où l’échec se produit : le 500 dans l’application, le 502 et le 504 sur un maillon intermédiaire, le 503 dans une indisponibilité assumée.

Les onze codes de la famille 5xx

La famille tient entièrement dans un tableau, contrairement aux vingt-neuf codes de la famille 4xx. Quatre d’entre eux couvrent la quasi-totalité des incidents réels.

Code	Ce qu’il signale	Enjeu SEO
500	Une erreur interne a empêché le serveur de traiter la requête	Répété, réduit l’exploration du domaine
501	La méthode demandée n’est pas gérée par le serveur	Aucun, cas applicatif
502	Un intermédiaire a reçu une réponse invalide de l’origine	Même effet qu’un 500, cause différente
503	Le service est indisponible, et c’est temporaire	Compris si l’indisponibilité reste brève
504	Un intermédiaire a attendu l’origine trop longtemps	Exploration interrompue avant lecture
505	La version du protocole HTTP n’est pas prise en charge	Aucun, très rare
506	La négociation de contenu est mal configurée	Aucun, erreur de configuration
507	Le serveur n’a plus l’espace nécessaire pour écrire	Symptôme d’infrastructure à traiter
508	Une boucle a été détectée et la requête abandonnée	Aucun, propre à WebDAV
510	Une extension attendue manque à la requête	Aucun, très rare
511	Une authentification réseau est exigée avant l’accès	Portail captif : le contenu n’est jamais atteint

500, 502 ou 504 : où l’échec se produit

Les trois annoncent la même chose au visiteur, une page qui ne s’affiche pas. Seule la place de l’échec dans la chaîne les distingue, et c’est elle qui oriente le diagnostic.

500 : l’application elle-même

Le serveur qui héberge le site a rencontré une erreur en exécutant votre code. Le problème est chez vous : une exception non gérée, une extension en conflit, une base de données inaccessible. Les journaux applicatifs disent quoi.

502 : un maillon intermédiaire

Un serveur placé devant le vôtre a reçu une réponse qu’il n’a pas su interpréter. Le problème est à la frontière : entre le répartiteur de charge et l’application, entre le CDN et l’origine. Les deux extrémités peuvent fonctionner isolément.

504 : le temps

L’intermédiaire a bien joint l’origine, mais celle-ci a mis trop de temps à répondre. Rien n’est cassé, tout est lent. C’est le code des requêtes coûteuses, des bases surchargées et des délais d’attente mal réglés.

Impact SEO des codes HTTP 5xx

Google ne sanctionne pas une panne. Il en tire une conclusion, ce qui revient au même quand elle dure.

À retenir

01Un incident bref ne coûte rien. Googlebot repasse, la page reste dans l’index, aucune trace ne subsiste.
02Un incident qui dure fait reculer l’exploration sur l’ensemble du domaine, pour éviter d’aggraver la surcharge.
03Une erreur installée fait sortir les pages de l’index, dans l’ordre inverse de leur importance : les moins visitées d’abord.

C’est la seule famille où l’effet se propage au-delà des URL concernées. Un 404 reste local, un 5xx répété se traduit par une baisse d’exploration sur tout le site, y compris sur les pages qui répondent parfaitement. Voir la fiche budget de crawl.

Quand une erreur 5xx est acceptable

Une infrastructure sans aucune erreur serveur n’existe pas. Trois situations où le code est la bonne réponse, à condition d’être servi correctement.

Une maintenance planifiée : un 503 accompagné d’un en-tête Retry-After indiquant la durée prévue. Google le documente explicitement comme la marche à suivre.
Une surcharge maîtrisée : mieux vaut un 503 franc qu’une page qui met quarante secondes à s’afficher. Le premier est compris, la seconde dégrade l’exploration en silence.
Un incident ponctuel corrigé vite : quelques minutes ne laissent aucune trace, à condition que la correction soit réelle et pas seulement masquée.

Le raccourci à éviter. Servir une page d’erreur en 200 pendant l’incident. C’est le geste le plus courant, et le plus coûteux : Google enregistre une réponse valide, indexe un contenu qui dit « le site est indisponible », et l’écran de panne remplace la vraie page dans les résultats. Le 503 fait exactement l’inverse : il protège la page en refusant de la remplacer.

Sur votre site

Vos erreurs serveur durent-elles assez pour vous coûter des pages ?

Je relève dans vos journaux les 5xx que Googlebot a réellement rencontrés, leur durée, les pages touchées et l’évolution de la cadence d’exploration qui a suivi. Réponse sous 24 heures ouvrées.

Demander un audit technique →

Bonnes pratiques de gestion des erreurs 5xx

Quatre gestes, du plus urgent au plus structurant.

01Servir le bon code pendant l’incident. Un 503, jamais un 200. C’est le seul geste qui protège l’index, et il se décide avant la panne, pas pendant.
02Surveiller la disponibilité en continu. Une sonde externe qui vérifie le site toutes les minutes coûte quelques euros et révèle les coupures nocturnes que personne ne voit passer.
03Lire les journaux serveur, pas seulement la Search Console. Le rapport d’indexation signale les erreurs avec plusieurs jours de retard. Les journaux les montrent à la minute, avec l’URL et la fréquence exactes.
04Traiter la cause, pas la trace. Un 504 récurrent est un problème de délai d’exécution, un 502 un problème de chaîne, un 500 un problème applicatif. Remettre le service debout n’est pas corriger.

Après un incident long, la cadence d’exploration ne revient pas immédiatement à son niveau antérieur. Elle remonte progressivement, sur plusieurs jours, une fois la stabilité constatée. C’est normal et cela ne demande aucune action, sinon de ne pas provoquer un second incident pendant la remontée.

Les codes 5xx en détail

500Internal Server Error L’échec vient de l’application elle-même. Le code ne dit pas ce qui a échoué, seulement que quelque chose a échoué. Lire la fiche → 503Service Unavailable L’indisponibilité est temporaire et assumée. Le seul 5xx qui protège le site quand il est bien servi. Lire la fiche → 502Bad Gateway Un intermédiaire a reçu une réponse invalide de l’origine. Documenté sur la page de référence. Voir la référence → 504Gateway Timeout L’origine a mis trop de temps à répondre. Documenté sur la page de référence. Voir la référence →

Les autres familles de codes

1xxRéponses informatives Des étapes intermédiaires, jamais un résultat. Sans effet sur l’indexation, sauf le 103 Early Hints. Lire la fiche → 2xxRequêtes réussies La famille qu’on croit acquise. Un seul de ses codes rend une page indexable, sans le mériter. Lire la fiche → 3xxRedirections La seule famille que vous écrivez vous-même. Un 3xx n’arrive pas, il se décide. Lire la fiche → 4xxErreurs client La famille où le compteur ne veut rien dire. C’est l’emplacement de l’erreur qui coûte, jamais son nombre. Lire la fiche →

Questions fréquentes sur les codes 5xx

Combien de temps une erreur 5xx peut-elle durer sans conséquence ?

Quelques minutes ne laissent aucune trace : Googlebot repasse et trouve la page. Au-delà de quelques heures, la cadence d’exploration baisse. Au-delà de quelques jours, des pages commencent à sortir de l’index. Il n’existe pas de seuil officiel, mais l’ordre de grandeur est celui-là, et il vaut pour le domaine entier, pas seulement pour les URL touchées.

Faut-il un 503 ou une page de maintenance pour une mise à jour planifiée ?

Les deux, ensemble. Une page de maintenance lisible pour le visiteur, servie avec un code 503 et un en-tête Retry-After pour le robot. Google documente cette combinaison comme la marche à suivre. L’erreur consiste à afficher la page de maintenance en 200 : le contenu de l’écran de panne remplace alors la vraie page dans l’index.

Quelle différence entre un 500 et un 502 ?

Le 500 vient de l’application qui héberge le site : une erreur s’est produite en exécutant le code. Le 502 vient d’un intermédiaire placé devant elle, qui a reçu une réponse qu’il n’a pas su interpréter. Pour le visiteur, c’est identique. Pour le diagnostic, cela change tout : le premier envoie vers les journaux applicatifs, le second vers la chaîne de serveurs.

Les erreurs 5xx font-elles perdre des positions ?

Pas directement, il n’y a pas de pénalité. La perte vient de la désindexation : une page absente de l’index n’a plus de position du tout. Tant que la page reste indexée, un incident passé n’a pas d’effet durable. C’est la raison pour laquelle la durée est le seul chiffre qui compte.

Faut-il bloquer Googlebot pendant un incident ?

Non. Bloquer l’accès dans le fichier robots.txt aurait un effet plus large et plus long que l’incident lui-même, et un robots.txt servi en erreur pose ses propres problèmes. Le 503 remplit exactement ce rôle, sans les inconvénients : il dit au robot de revenir plus tard, sans rien retirer.