Effet des codes d'état HTTP, ainsi que des erreurs réseau et DNS sur la recherche Google

Cette page décrit l'impact des différents codes d'état HTTP, erreurs réseau et erreurs DNS sur la recherche Google. Nous présentons les 20 codes d'état les plus courants rencontrés par Googlebot sur le Web, ainsi que les erreurs réseau et DNS les plus visibles. Les codes d'état plus rares, tels que 418 (I'm a teapot), ne sont pas couverts. Tous les problèmes mentionnés sur cette page génèrent une erreur ou un avertissement correspondant dans le rapport sur l'indexation des pages de la Search Console.

Codes d'état HTTP

Les codes d'état HTTP sont générés par le serveur qui héberge le site lorsqu'il répond à une requête envoyée par un client, par exemple un navigateur ou un robot d'exploration. Chaque code d'état HTTP a une signification différente, mais le résultat de la requête est souvent le même. Par exemple, différents codes d'état indiquent une redirection, mais leur résultat est le même.

La Search Console génère des messages d'erreur pour les codes d'état dans la plage 4xx–5xx et pour les redirections ayant échoué (3xx). Si le serveur répond avec un code d'état 2xx, le contenu reçu dans la réponse peut être pris en compte pour l'indexation.

Le tableau suivant présente les codes d'état HTTP les plus souvent rencontrés par Googlebot et explique comment Google traite chaque code d'état.

Codes d'état HTTP

2xx (success)

Google prend en compte le contenu pour l'indexation. Si le contenu suggère une erreur, par exemple une page vide ou un message d'erreur, la Search Console affiche une erreur soft 404.

200 (success)

Google transmet le contenu au pipeline d'indexation. Les systèmes d'indexation peuvent indexer le contenu, mais cela n'est pas garanti.

201 (created)
202 (accepted)

Googlebot attend de recevoir le contenu pendant un temps limité, puis transmet ce qu'il reçoit au pipeline d'indexation. Le délai d'expiration dépend du user-agent. Par exemple, il peut différer selon que Googlebot pour smartphone ou Googlebot pour les images est utilisé.

204 (no content)

Googlebot signale au pipeline d'indexation qu'il n'a reçu aucun contenu. La Search Console peut afficher une erreur soft 404 dans le rapport sur l'indexation des pages du site.

3xx (redirection)

Googlebot suit jusqu'à 10 sauts de redirection. Si le robot d'exploration ne reçoit pas de contenu au bout de ces 10 sauts, la Search Console affiche une erreur de redirection dans le rapport sur l'indexation des pages du site. Le nombre de sauts que Googlebot suit dépend du user-agent. Par exemple, Googlebot pour les smartphones peut présenter une valeur différente de celle de Googlebot pour les images.

Dans le cas du fichier robots.txt, Googlebot suit au moins cinq sauts de redirection, tels que définis par la RFC 1945, puis arrête et affiche l'état 404.

Googlebot ignore tout contenu reçu via l'URL de redirection est ignoré, et prend en compte le contenu de l'URL de la cible finale pour l'indexation.

301 (moved permanently)

Googlebot suit la redirection, et le pipeline d'indexation utilise cette redirection comme un signal fort indiquant que la cible de la redirection est canonique.

302 (found)

Googlebot suit la redirection, et le pipeline d'indexation utilise cette redirection comme un signal faible indiquant que la cible de la redirection est canonique.

303 (see other)
304 (not modified)

Googlebot indique au pipeline d'indexation que le contenu est identique à celui de la dernière exploration. Le pipeline d'indexation peut recalculer les signaux pour l'URL, mais le code d'état n'a aucun effet sur l'indexation.

307 (temporary redirect) Équivaut à 302.
308 (moved permanently) Équivaut à 301.

4xx (client errors)

Le pipeline d'indexation de Google ne prend pas en compte les URL qui renvoient un code d'état 4xx pour l'indexation. De même, les URL qui sont déjà indexées et qui renvoient un code d'état 4xx sont supprimées de l'index.

Tout contenu reçu par Googlebot à partir d'URL renvoyant un code d'état 4xx est ignoré.

400 (bad request)

Toutes les erreurs 4xx, à l'exception de 429, sont traitées de la même manière : Googlebot signale au pipeline d'indexation que le contenu n'existe pas.

Le pipeline d'indexation supprime l'URL de l'index si elle a déjà été indexée. Les nouvelles pages 404 ne sont pas traitées. La fréquence d'exploration diminue progressivement.

401 (unauthorized)
403 (forbidden)
404 (not found)
410 (gone)
411 (length required)
429 (too many requests)

Googlebot traite le code d'état 429 comme un signal indiquant que le serveur est surchargé. Il est considéré comme une erreur de serveur.

5xx (server errors)

Les erreurs de serveur 5xx et 429 invitent les robots d'exploration de Google à ralentir temporairement l'exploration. Les URL déjà indexées sont conservées, mais finissent par être supprimées de l'index.

Si le fichier robots.txt renvoie un code d'état indiquant une erreur de serveur pendant plus de 30 jours, Google utilise la dernière copie en cache du fichier robots.txt. Si aucune copie en cache n'est disponible, Google considère qu'aucune restriction d'exploration ne s'applique.

Tout contenu reçu par Googlebot à partir d'URL renvoyant un code d'état 5xx est ignoré.

500 (internal server error)

Googlebot diminue la vitesse d'exploration du site. La baisse de la vitesse d'exploration est proportionnelle au nombre d'URL individuelles qui renvoient une erreur de serveur. Le pipeline d'indexation de Google supprime de l'index les URL qui renvoient continuellement une erreur de serveur.

502 (bad gateway)
503 (service unavailable)

Erreurs soft 404

Une erreur de type soft 404" désigne une URL renvoyant une page qui indique à l'internaute que la page n'existe pas, ainsi qu'un code d'état 200 (success). Dans certains cas, il peut s'agir d'une page sans contenu principal ou vide.

Ces pages peuvent être générées pour diverses raisons par le serveur Web ou le système de gestion de contenu de votre site Web, ou par le navigateur de l'internaute. Exemple :

  • Un fichier d'inclusion côté serveur est manquant
  • Une perte de la connexion à la base de données
  • Une page de résultats de recherche interne vide
  • Un fichier JavaScript non chargé ou manquant

En renvoyant un code d'état 200 (success), puis en affichant ou suggérant un message d'erreur ou un type d'erreur sur la page, vous altérez l'expérience utilisateur. Les internautes peuvent penser que la page en ligne est accessible, mais voient s'afficher une erreur. Ces pages sont exclues de la recherche.

Lorsque les algorithmes de Google détectent qu'il s'agit bien d'une page d'erreur en fonction de son contenu, la Search Console affiche une erreur soft 404 dans le rapport sur l'indexation des pages du site.

Corriger les erreurs soft 404

Selon l'état de la page et le résultat souhaité, vous pouvez résoudre les erreurs soft 404 de différentes manières :

Essayez de déterminer la solution la plus adaptée à vos utilisateurs.

La page et le contenu ne sont plus disponibles

Si vous avez supprimé la page sans la remplacer par une page au contenu similaire, renvoyez un code de réponse (état) 404 (not found) ou 410 (gone). Ces codes d'état indiquent aux moteurs de recherche que la page n'existe pas et que son contenu ne doit pas être indexé.

Si vous avez accès aux fichiers de configuration de votre serveur, vous pouvez personnaliser ces pages d'erreur afin d'améliorer l'expérience utilisateur. Une page d'erreur 404 personnalisée permet aux internautes de trouver les informations qu'ils recherchent, et leur fournit également d'autres contenus utiles pour les inciter à explorer votre site. Voici quelques conseils pour concevoir une page 404 personnalisée utile :

  • Indiquez clairement aux internautes que la page qu'ils recherchent est introuvable. Adoptez un langage avenant et agréable.
  • Assurez-vous que votre page 404 a la même apparence (y compris la navigation) que le reste de votre site.
  • Pensez à ajouter des liens vers vos articles ou messages les plus consultés, ainsi que vers la page d'accueil de votre site.
  • Pensez à proposer aux internautes la possibilité de signaler les liens non fonctionnels.

Les pages 404 personnalisées sont créées exclusivement pour les utilisateurs. Comme ces pages sont inutiles du point de vue du moteur de recherche, assurez-vous que le serveur affiche un code d'état HTTP 404 pour éviter qu'elles soient indexées.

La page ou le contenu se trouve ailleurs

Si votre page a été déplacée ou si elle a été remplacée, renvoyez l'erreur 301 (permanent redirect) pour rediriger l'utilisateur. Cette opération n'interrompt pas l'expérience de navigation et constitue un excellent moyen d'indiquer aux moteurs de recherche le nouvel emplacement de la page. Dans l'outil d'inspection d'URL, vérifiez si votre URL renvoie le code approprié.

La page et le contenu existent toujours

Si une page qui ne présente aucun autre problème est signalée par une erreur soft 404, il est probable qu'elle ne se soit pas chargée correctement pour Googlebot, qu'elle ne contenait pas certaines ressources critiques lors de l'affichage ou qu'elle ait affiché un message d'erreur visible lors du rendu. Utilisez l'outil d'inspection d'URL pour examiner le contenu affiché et le code HTTP renvoyé. Si la page affichée est vierge, presque vide, ou si un message d'erreur s'affiche, il est possible qu'elle fasse référence à de nombreuses ressources qui ne se chargent pas (images, scripts et autres éléments non textuels). Cela peut être interprété comme une erreur soft 404. Plusieurs raisons peuvent expliquer que les ressources ne se chargent pas. Elles peuvent être bloquées (par un fichier robots.txt), elles peuvent être trop nombreuses ou trop volumineuses, leur chargement peut être lent, ou diverses erreurs de serveur peuvent se produire.

Erreurs réseau et DNS

Les erreurs réseau et DNS ont des effets négatifs rapides sur la présence d'une URL dans la recherche Google. Googlebot traite les délais d'expiration du réseau, la réinitialisation de la connexion et les erreurs DNS de la même manière que les erreurs de serveur 5xx. En cas d'erreurs réseau, l'exploration se met immédiatement à ralentir, car une erreur réseau indique que le serveur ne peut pas gérer la charge de diffusion. Étant donné que Googlebot n'a pas pu accéder au serveur qui héberge le site, Google n'a pas non plus reçu de contenu depuis le serveur. Le manque de contenu signifie que Google ne peut pas indexer les URL explorées. Les URL déjà indexées qui sont inaccessibles seront supprimées de l'index Google sous quelques jours. La Search Console peut générer des messages d'erreur pour chaque erreur.

Déboguer les erreurs réseau

Ces erreurs se produisent avant l'exploration de l'URL par Google ou pendant son exploration. Étant donné que ces erreurs peuvent se produire avant que le serveur ne réponde et avant qu'un code d'état ne permette d'identifier le problème, le diagnostic de ces erreurs peut être plus difficile. Pour déboguer les erreurs liées au délai d'expiration et à la réinitialisation de la connexion, procédez comme suit :

  • Examinez les paramètres et les journaux de votre pare-feu. Il se peut qu'une règle de blocage ne soit pas suffisamment précise. Assurez-vous que les adresses IP de Googlebot ne soient bloquées par aucune règle de pare-feu.
  • Examinez le trafic réseau. Utilisez des outils tels que tcpdump etWireshark pour capturer et analyser les paquets TCP, puis rechercher les anomalies qui pointent vers un module réseau ou un composant réseau spécifique.
  • Si vous ne trouvez rien de suspect, contactez votre hébergeur.

L'erreur peut provenir de n'importe quel composant de serveur qui gère le trafic réseau. Par exemple, les interfaces réseau surchargées peuvent ne pas traiter certains paquets, entraînant ainsi des délais d'expiration (impossibilité d'établir une connexion), et réinitialiser les connexions (paquet RST envoyé en raison de la fermeture par erreur d'un port).

Déboguer les erreurs DNS

Les erreurs DNS sont généralement dues à une mauvaise configuration, mais peuvent aussi être liées à une règle de pare-feu qui bloque les requêtes DNS de Googlebot. Pour déboguer les erreurs DNS :

  • Examinez vos règles de pare-feu. Vérifiez qu'aucune adresse IP Google n'est bloquée par une règle de pare-feu, et que les requêtes UDP et TCP sont autorisées.
  • Examinez vos enregistrements DNS. Vérifiez que les enregistrements A et CNAME pointent respectivement vers les adresses IP et le nom d'hôte appropriés. Exemple : 
    dig +nocmd example.com a +noall +answer
    dig +nocmd www.example.com cname +noall +answer
  • Vérifiez que tous vos serveurs de noms pointent vers les bonnes adresses IP de votre site. Exemple : 
    dig +nocmd example.com ns +noall +answer
example.com.    86400  IN  NS  a.iana-servers.net.
example.com.    86400  IN  NS  b.iana-servers.net.
dig +nocmd @a.iana-servers.net example.com +noall +answer
example.com.    86400  IN  A  93.184.216.34
dig +nocmd @b.iana-servers.net example.com +noall +answer
...
  • Si vous avez modifié votre configuration DNS au cours des dernières 72 heures, vous devrez peut-être attendre que vos modifications soient appliquées sur le réseau DNS global. Pour accélérer la propagation, vous pouvez vider le cache DNS public de Google.
  • Si vous exécutez votre propre serveur DNS, assurez-vous qu'il est opérationnel et qu'il n'est pas surchargé.