Codes de statut HTTP pour le SEO et les performances web

La réponse courte est simple : renvoyez 200 pour une page qui existe, une redirection permanente pour une page qui a été déplacée définitivement, 404 ou 410 pour du contenu qui n'existe plus, et des erreurs serveur temporaires uniquement lorsque la défaillance est réellement temporaire. Ne renvoyez pas 200 pour une page d'erreur et n'utilisez pas des redirections pour masquer une indisponibilité.

Cette distinction compte à la fois pour les moteurs de recherche et pour les personnes. Google indique qu'une réponse 2xx peut être prise en compte pour l'indexation, sans la garantir. Il ignore le contenu renvoyé avec une réponse 4xx ou 5xx, et des erreurs serveur persistantes peuvent finir par retirer des URL de l'index. La même réponse détermine également si un navigateur, un CDN, un robot ou un système de supervision considère la requête comme réussie, mise en cache, à réessayer ou défaillante.

Signification de chaque classe de statut

HTTP regroupe les codes de réponse selon leur premier chiffre. La classe est utile, mais le code exact porte la signification opérationnelle.

• Succès 2xx : la requête a réussi. 200 OK est la réponse normale pour une page HTML indexable. 204 No Content convient à un endpoint qui ne renvoie volontairement aucun corps, pas à une page qui n'a pas réussi à s'afficher. Une page qui affiche « introuvable » tout en renvoyant 200 est une soft 404 et peut être exclue de la recherche.
• Redirection 3xx : la ressource demandée est ailleurs ou le client peut réutiliser sa représentation en cache. 301 et 308 indiquent un déplacement permanent. 302 et 307 indiquent un déplacement temporaire. Google traite les formes permanentes comme des signaux de canonicalisation plus forts, tandis que les formes temporaires préservent généralement l'URL source.
• Erreur client 4xx : le serveur ne peut pas servir la ressource demandée telle qu'elle est demandée. 404 Not Found est la réponse normale pour une URL inconnue. 410 Gone est utile lorsqu'un contenu a été délibérément et définitivement supprimé. 401 et 403 décrivent le contrôle d'accès, pas une manière recommandée de ralentir les robots. 429 Too Many Requests est particulier : Google le traite comme une erreur serveur, car il peut indiquer une surcharge.
• Erreur serveur 5xx : le serveur ou une passerelle n'a pas pu achever une requête pourtant valide. 500 est une défaillance applicative générique, 502 indique habituellement une mauvaise réponse amont, 503 indique une indisponibilité temporaire et 504 indique un délai d'attente amont.

Une séquence d'audit pratique

1. Inventorier les URL par intention

Commencez par une liste d'URL représentative : pages de destination importantes, modèles, pages produit et catégorie, API, ressources, flux, robots.txt et sitemaps XML. Incluez les URL des journaux serveur, de Search Console, de l'analytique, des liens internes et du CDN. Un tableau de bord de statut qui vérifie uniquement la page d'accueil passera à côté des défaillances dans un chemin localisé, une route d'API ou une variante de cache.

Pour chaque URL, consignez la réponse depuis la périphérie publique et, si possible, depuis l'origine. Comparez le statut, l'URL finale, le temps de réponse, le type de contenu, le statut de cache, Location, Cache-Control, les directives canonical et robots. Un CDN peut renvoyer un code ou un corps différent de l'origine ; testez donc les deux couches lors d'une investigation.

2. Classer chaque réponse autre que 200

Pour une page déplacée, faites correspondre l'ancienne URL directement à la destination équivalente la plus proche avec une seule 301 ou 308 côté serveur. Évitez les chaînes allant d'une ancienne URL à une URL intermédiaire puis à l'URL finale. Mettez à jour les liens internes, les URL canoniques et les sitemaps pour qu'ils pointent directement vers la destination.

Pour une page supprimée, utilisez 404 ou 410 lorsqu'il n'existe pas de remplacement pertinent. Ne redirigez pas chaque URL supprimée vers la page d'accueil : cela dégrade l'expérience utilisateur et peut être interprété comme une soft 404. Une page d'erreur personnalisée utile convient, mais la réponse HTTP doit toujours rester une erreur.

Pour une indisponibilité, renvoyez une erreur serveur temporaire adaptée et rétablissez rapidement le service. Une 503 peut inclure Retry-After lorsqu'une estimation de nouvelle tentative utile est connue. Veillez à ce qu'un corps d'erreur ne soit pas accidentellement mis en cache longtemps dans le navigateur ou le CDN.

3. Vérifier le chemin de réponse, pas uniquement le code applicatif

Testez depuis plusieurs réseaux et régions avec une requête qui suit les redirections et une autre qui ne les suit pas. Confirmez que HTTPS, la normalisation de l'hôte, les règles de barre oblique finale, le routage des langues, l'authentification et le basculement d'origine produisent tous le résultat attendu. Vérifiez HEAD seulement en complément : de nombreux visiteurs et robots réels utilisent GET, et un serveur peut gérer les deux méthodes différemment.

La vérification générique suivante rend visibles les sauts de redirection :

request https://www.example.test/old-page
inspect status, Location, cache headers, and final URL
repeat from a second region and with a crawler user agent

Pour un travail SEO spécifique, SEO technique/GEO relie la fiabilité des réponses au comportement d'exploration et à l'analyse des journaux. Pour la diffusion, un CDN managé peut faciliter la comparaison entre les réponses de périphérie et d'origine, tandis que Multi CDN ajoute un autre chemin de défaillance à observer indépendamment.

4. Surveiller les taux et les transitions

Suivez les décomptes de statut par nom d'hôte, modèle de chemin, méthode, région, user agent, statut de cache et version de mise en production. Alertez sur les changements de taux de 5xx, 429, boucles de redirection, chaînes de redirection, soft 404 et réponses 200 inattendues depuis des routes d'erreur connues. Associez le taux à la latence et à la saturation d'origine : une hausse des 504 peut être un problème de délai d'attente, tandis qu'une hausse des 502 peut être un problème de protocole ou de connexion amont.

Maintenez un budget d'erreur pour la visibilité dans les moteurs de recherche comme pour la disponibilité. Examinez les journaux de crawl et Search Console après des changements de routage ou d'application. Google recommande d'utiliser ses outils Crawl Stats et URL Inspection pour examiner les problèmes de disponibilité et de rendu, et indique que l'exploration peut reprendre progressivement une fois le site de nouveau sain.

5. Définir le retour arrière avant de modifier les codes

Déployez les changements de code de statut derrière une configuration ou une mise en production réversible. Gardez disponibles les règles de routage, la version applicative et la politique de cache précédentes. Si une nouvelle table de redirections augmente les erreurs, restaurez la dernière table connue comme fonctionnelle et purgez uniquement les réponses affectées. Si un nouveau gestionnaire d'erreurs provoque un pic de 5xx, rétablissez la version applicative précédente. Ne résolvez pas un mauvais déploiement en renvoyant 200 pour chaque requête ; cela masque l'incident et crée du bruit d'indexation.

Erreurs fréquentes

• Renvoyer 200 avec un modèle d'erreur, un résultat de recherche vide ou une charge utile d'API en échec.
• Utiliser 302 pour une migration d'URL permanente ou 301 pour une page de maintenance temporaire.
• Laisser plusieurs sauts de redirection après un changement de site ou d'hôte.
• Traiter 403 ou 401 comme un contrôle du taux d'exploration. Google documente plutôt 429, et temporairement 503, pour les situations de surcharge.
• Mettre en cache une réponse 404 ou 503 au-delà de ce que permet le plan de rétablissement.
• Vérifier uniquement l'origine alors que le CDN sert un ancien corps, un statut différent ou une erreur obsolète.
• Oublier qu'une réponse 2xx n'est qu'un signal d'éligibilité. L'indexation dépend toujours du contenu renvoyé et d'autres systèmes de recherche.

Lisez le guide de migration CDN avant de modifier la couche qui génère ou met en cache vos réponses, et utilisez le guide du budget de performance web pour relier le temps de réponse à des limites de diffusion mesurables.

Il n'existe que deux problèmes difficiles en informatique : l'invalidation du cache et le nommage des choses.