Les erreurs HTTP sont des codes à trois chiffres qu’un serveur web renvoie au navigateur pour signaler le résultat d’une requête. Le premier chiffre indique la nature du problème : un code 4xx signale une erreur côté client, un code 5xx signale une erreur côté serveur. Identifier cette distinction est le point de départ de tout diagnostic.
Erreurs 4xx : quand le problème vient de la requête client
Les erreurs de la famille 4xx signifient que le serveur a bien reçu la requête, mais qu’il ne peut pas y répondre en raison d’un problème lié à ce que le client a envoyé : une URL incorrecte, des droits d’accès insuffisants ou une syntaxe malformée.
Erreur 400 : requête mal formée
Une erreur 400 (Bad Request) apparaît lorsque le serveur ne peut pas interpréter la requête envoyée par le navigateur. La cause la plus fréquente est une URL contenant des caractères invalides ou un cookie corrompu.
Pour la corriger, videz le cache et les cookies du navigateur, puis rechargez la page. Si le problème persiste côté serveur, vérifiez que l’URL ne contient pas de caractères spéciaux non encodés.
Erreur 401 : authentification requise
Une erreur 401 (Unauthorized) indique que la ressource demandée exige une authentification qui n’a pas été fournie ou qui est invalide. Elle apparaît typiquement sur des espaces membres ou des interfaces d’administration.
Vérifiez vos identifiants de connexion. Si l’erreur survient en dehors d’un espace protégé, examinez la configuration des en-têtes d’authentification côté serveur.
Erreur 403 : accès refusé
Contrairement au 401, une erreur 403 (Forbidden) signifie que le serveur a identifié la requête, mais refuse d’y répondre même avec une authentification valide. Les causes les plus fréquentes sont des permissions de fichiers incorrectes ou une restriction explicite dans la configuration serveur.
Sur un hébergement Linux, vérifiez que les permissions des dossiers sont en 755 et celles des fichiers en 644. Un fichier .htaccess mal configuré peut également bloquer l’accès à une ressource entière.
Erreur 404 : page introuvable
L’erreur 404 (Not Found) signale que la ressource demandée n’existe pas à l’URL indiquée. Elle peut survenir après la suppression d’une page, un changement d’URL ou un lien mal orthographié.
Un 404 n’est pas automatiquement un problème SEO. Si une page supprimée n’a pas de remplacement pertinent, Google considère ce comportement comme normal. En revanche, une page d’erreur qui répond avec un code 200 crée une « soft 404 », un signal que les moteurs de recherche traitent différemment d’une vraie page introuvable. Pour les 404 sur des pages qui ont un équivalent, configurez une redirection 301 vers l’URL de destination.
Erreurs 5xx : quand le serveur est en cause
Les erreurs 5xx indiquent une défaillance côté serveur. Le serveur a reçu la requête, mais quelque chose l’a empêché de la traiter correctement. Ces erreurs sont souvent plus urgentes car elles peuvent rendre un site entièrement inaccessible.
Erreur 500 : erreur interne du serveur
L’erreur 500 (Internal Server Error) est la plus générique des erreurs serveur. Elle signale qu’une condition inattendue a empêché le serveur de répondre, sans préciser laquelle.
La première action est de consulter les journaux d’erreurs du serveur (fichier error.log). Sur WordPress, une cause fréquente est un plugin défaillant ou un fichier .htaccess corrompu. Renommez temporairement ce fichier pour le désactiver et testez si le site redevient accessible.
Erreur 502 : passerelle incorrecte
Une erreur 502 (Bad Gateway) apparaît quand un serveur intermédiaire (proxy, load balancer) reçoit une réponse invalide d’un serveur en amont. Elle est souvent temporaire et liée à une surcharge ou à un redémarrage de service.
Attendez quelques minutes et rechargez la page. Si l’erreur persiste, vérifiez l’état du service en amont et les paramètres de timeout du proxy.
Erreur 503 : service indisponible
L’erreur 503 (Service Unavailable) signale que le serveur est temporairement incapable de traiter les requêtes, généralement en raison d’une surcharge ou d’une maintenance. Un 503 temporaire est préférable à une page de maintenance qui répond 200 : le code doit refléter l’indisponibilité réelle du service pour que les robots d’exploration interprètent correctement la situation.
Des erreurs 5xx persistantes peuvent ralentir l’exploration d’un site par les moteurs de recherche et, à terme, conduire au retrait des URL concernées de l’index. Un 503 de courte durée ne pose pas de problème, mais une récurrence doit déclencher une investigation de l’infrastructure.
Erreur 504 : délai d’attente dépassé
Une erreur 504 (Gateway Timeout) survient quand un serveur intermédiaire n’obtient pas de réponse à temps du serveur en amont. Elle diffère du 502 en ce qu’il n’y a pas de réponse invalide, mais une absence de réponse dans le délai imparti.
Vérifiez la charge du serveur d’application et augmentez si nécessaire les valeurs de timeout dans la configuration du proxy.
Checklist de diagnostic par type d’erreur HTTP
Avant d’intervenir sur la configuration serveur, appliquer une séquence de vérification structurée permet d’isoler la cause réelle et d’éviter des modifications inutiles.
- Erreurs 4xx (400, 401, 403, 404) : vérifiez d’abord l’URL exacte, les permissions de fichiers et les règles de réécriture dans le .htaccess. Consultez les journaux d’accès pour confirmer que la requête arrive bien au serveur sous la forme attendue.
- Erreurs 5xx (500, 502, 503, 504) : consultez immédiatement les journaux d’erreurs serveur. Testez en désactivant les plugins ou extensions un par un. Vérifiez la charge CPU et mémoire de l’hébergement. Si le site utilise un proxy ou un CDN, examinez les logs de la couche intermédiaire.
- Erreurs récurrentes ou intermittentes : les échecs de crawl ne se limitent pas aux codes HTTP. Des problèmes DNS, des délais de connexion ou des erreurs de redirection peuvent survenir avant même qu’un serveur renvoie un statut. Les journaux d’infrastructure et les outils de crawl permettent de distinguer une erreur applicative d’un problème réseau.
Robots.txt et comportement des crawlers face aux erreurs HTTP
Le code HTTP renvoyé par l’URL du fichier robots.txt influence directement le comportement des robots d’exploration. Une réponse 4xx (hors 429) sur cette URL est interprétée comme une absence de règles d’exploration valides : un moteur de recherche peut alors supposer qu’aucune restriction ne s’applique et explorer l’ensemble du site.
Une panne DNS ou réseau qui empêche la récupération du robots.txt produit un effet différent d’une erreur HTTP classique et doit être traitée séparément, en vérifiant la résolution DNS et la disponibilité réseau du serveur avant d’inspecter la configuration applicative.
Surveiller régulièrement les codes HTTP renvoyés par les pages importantes d’un site, en particulier après une migration ou une modification de configuration, reste la pratique la plus fiable pour éviter qu’une erreur passée inaperçue ne dégrade la couverture d’indexation.
