Une URL qui renvoie un code d’erreur HTTP ne signale pas toujours le même dysfonctionnement. Entre une requête mal formée (400), une page supprimée (404) et un serveur saturé (503), la cause, l’impact sur l’indexation et la marche à suivre diffèrent radicalement. Mesurer l’écart entre ces codes permet de prioriser les corrections et de limiter les dégâts sur le référencement.
Codes d’erreur HTTP : écarts d’impact entre familles 4xx et 5xx
Le premier chiffre du code de statut détermine de quel côté se situe le problème. Les familles 4xx et 5xx ne pèsent pas du tout le même poids sur l’exploration d’un site par les robots de Google.
| Code | Famille | Origine du problème | Conséquence sur l’indexation |
|---|---|---|---|
| 400 | 4xx (client) | URL mal formée, caractères non encodés, paramètre manquant | Page traitée comme inexistante, retirée de l’index après quelques tentatives |
| 403 | 4xx (client) | Accès refusé par le serveur (permissions, .htaccess) | Page non indexée tant que l’accès reste bloqué |
| 404 | 4xx (client) | Page supprimée, URL modifiée sans redirection, lien cassé | Page retirée de l’index progressivement |
| 500 | 5xx (serveur) | Erreur interne : script défaillant, configuration rompue | Ralentissement de l’exploration du site entier |
| 502 | 5xx (serveur) | Réponse invalide reçue par le proxy ou la passerelle | Idem 500, exploration freinée |
| 503 | 5xx (serveur) | Serveur indisponible (maintenance, surcharge) | Exploration suspendue, pages indexées potentiellement retirées si l’erreur persiste |
Le point à retenir : une erreur 5xx persistante peut entraîner le retrait de pages déjà indexées. Une 404 isolée, elle, reste sans conséquence réelle sur le reste du site.
Google précise que les réponses 5xx et 429 ralentissent temporairement ses robots d’exploration. Si le problème dure, l’impact se propage aux autres URL de l’hôte. Un guide détaillé explique comment corriger une URL de serveur invalide en distinguant précisément chaque famille de code.
Erreur sur robots.txt : le cas qui bloque l’exploration complète d’un site
Les concurrents traitent rarement ce scénario, qui provoque pourtant les dégâts les plus étendus. Une réponse 5xx sur le fichier robots.txt suspend l’exploration de tout l’hôte. Google tente de récupérer ce fichier avant chaque session de crawl. S’il reçoit une erreur serveur, il préfère ne rien explorer plutôt que de risquer d’accéder à des pages interdites.
Le diagnostic commence donc par ce fichier. Vérifier son accessibilité ne prend que quelques secondes avec une requête directe dans le navigateur (votredomaine.com/robots.txt). Si la page renvoie un code 200 avec un contenu lisible, le problème se situe ailleurs.
Quand le proxy masque la vraie cause
Une erreur 502 ou 504 sur robots.txt peut provenir d’un intermédiaire (reverse proxy, CDN) et non du serveur applicatif. Pour isoler la source, il faut examiner la communication entre le proxy et le serveur amont. Les journaux du proxy (Nginx, Varnish, Cloudflare) indiquent si la requête a bien atteint le serveur d’origine ou si elle a expiré en chemin.
Confondre un timeout de proxy avec une panne applicative mène à des corrections inutiles sur le code, alors que le problème réside dans la configuration réseau.
Détecter les URL invalides : méthodes et outils à croiser
Un seul outil ne suffit pas. Chaque source couvre un angle différent de la détection, et les croiser évite les angles morts.
- Le rapport « Statistiques sur l’exploration » de Google Search Console montre la fréquence des erreurs rencontrées par Googlebot, leur type (5xx, 404, timeout DNS) et leur évolution dans le temps. C’est la vue côté moteur de recherche.
- Les journaux du serveur (access.log, error.log) fournissent le détail brut : adresse IP du client, URL demandée, code renvoyé, heure exacte. Ils permettent de repérer des pics d’erreurs liés à un déploiement ou à une surcharge.
- Un crawler comme Screaming Frog ou Sitebulb parcourt le site en suivant les liens internes et signale toute URL qui renvoie un code anormal. Il détecte aussi les liens cassés dans le maillage interne, invisibles depuis Search Console.
Croiser Search Console et les logs serveur reste la méthode la plus fiable. Search Console signale les URL que Google n’a pas pu atteindre, les logs révèlent pourquoi et quand le serveur a renvoyé l’erreur.
Erreur DNS ou timeout : distinguer les faux positifs
Un problème DNS ne signifie pas que le serveur est en panne. Le serveur DNS peut être temporairement injoignable alors que le site fonctionne normalement. Google signale ces cas dans Search Console sous « Erreur DNS ». Avant de modifier quoi que ce soit côté applicatif, vérifier la résolution DNS avec un outil comme dig ou nslookup permet d’écarter cette hypothèse.
Corriger les erreurs serveur : prioriser selon le code et la durée
Toutes les erreurs ne méritent pas la même urgence. Une 503 temporaire avec un en-tête Retry-After est moins grave qu’une 500 permanente sur une page à fort trafic organique.
Maintenance planifiée et en-tête Retry-After
La norme HTTP prévoit qu’un serveur peut répondre 503 et inclure un en-tête Retry-After pour indiquer aux robots quand revenir. Sans cet en-tête, Google traite la 503 comme un incident ordinaire et ralentit l’exploration sans savoir quand réessayer. Ajouter cet en-tête lors d’une maintenance planifiée limite les conséquences sur l’indexation.
Redirections 301 pour les 404 récurrentes
Une page supprimée qui recevait des liens entrants perd toute sa valeur SEO si elle reste en 404. Une redirection 301 vers la page la plus pertinente transfère la majorité du signal. En revanche, rediriger toutes les 404 vers la page d’accueil est contre-productif : Google finit par ignorer ces redirections génériques.
Le tri se fait en croisant deux données : le nombre de liens entrants vers l’URL en erreur (via Search Console ou Ahrefs) et le volume de trafic qu’elle générait avant la suppression. Les URL sans lien et sans trafic peuvent rester en 404 sans conséquence.
La donnée qui ressort de l’ensemble : les erreurs 5xx persistantes affectent l’exploration globale du site, là où les erreurs 4xx restent localisées à la page concernée. Vérifier l’accessibilité de robots.txt et croiser les rapports Search Console avec les logs serveur constituent les deux contrôles à exécuter en priorité lors de tout incident.
