Une erreur 404 est un code de statut HTTP renvoyé par un serveur lorsqu’il ne trouve pas la ressource demandée à l’URL indiquée. Le navigateur reçoit ce code, affiche un message du type « page introuvable », et le visiteur quitte le site. Pour les moteurs de recherche, la situation est différente : Googlebot enregistre cette réponse, la consigne dans ses rapports, et ajuste son comportement d’exploration en conséquence.
Erreur 404 et soft 404 : deux problèmes, deux corrections
Google opère une distinction nette entre une erreur 404 classique et un soft 404. La première survient quand le serveur renvoie explicitement le code HTTP 404 ou 410 : la page n’existe plus, le serveur le confirme. Le traitement est limpide.
Le soft 404, lui, pose un problème plus sournois. La page renvoie un code HTTP 200 (succès), mais son contenu ressemble à une page vide, un message d’erreur ou un résultat sans donnée. Google la classe alors comme soft 404 dans le rapport d’indexation de la Search Console, même si techniquement le serveur n’a signalé aucune erreur.
Cette distinction change la correction à appliquer. Pour une page réellement supprimée, le code 404 ou 410 est la bonne réponse, il suffit de décider si une redirection 301 vers un contenu pertinent se justifie. Pour un soft 404, il faut soit enrichir le contenu pour qu’il mérite d’exister, soit renvoyer un vrai code 404.
Avant toute action, il est utile de comprendre l’erreur 404 sur Google pour poser un diagnostic fiable.
Soft 404 sur les sites dynamiques : le piège du rendu JavaScript
Les sites e-commerce et les médias génèrent souvent des pages de résultats filtrés, de facettes produits ou de catégories temporairement vides. Ces pages « zéro résultat » sont une cause fréquente de soft 404 à grande échelle. Google les explore, constate un template quasi vide, et les signale massivement dans la Search Console.
Un autre cas piège concerne le rendu JavaScript. Une page peut s’afficher correctement dans un navigateur, avec tout son contenu chargé côté client, mais apparaître vide ou incomplète pour Googlebot si le rendu JS échoue. La page fonctionne pour un humain, pas pour le robot. Google la classe alors en soft 404 sans que le webmaster ne s’en aperçoive en navigation classique.
La vérification passe par l’outil d’inspection d’URL dans la Search Console, qui montre la version de la page telle que Google la voit. Si le rendu affiché diffère de ce que le navigateur montre, le problème est côté JavaScript, pas côté serveur.
Trier les erreurs 404 avant de les corriger
Corriger toutes les 404 d’un site sans distinction est une perte de temps. La bonne pratique consiste à trier chaque URL signalée selon son statut réel avant d’agir. Quatre catégories se dégagent :
- Les URL qui correspondent à du contenu supprimé volontairement : le code 404 ou 410 est la réponse correcte. Aucune action nécessaire, Google finira par les retirer de son index.
- Les URL qui pointaient vers du contenu déplacé ou renommé : une redirection 301 vers la page équivalente est la seule correction pertinente. Rediriger vers la page d’accueil est traité par Google comme un soft 404.
- Les URL générées par des liens internes cassés (faute de frappe, changement de structure) : il faut corriger le lien à la source, dans le contenu ou dans le menu, plutôt que de créer une redirection permanente.
- Les URL provenant de liens externes sur lesquels le webmaster n’a pas de contrôle : une redirection 301 vers le contenu le plus proche préserve le jus de lien transmis par ces backlinks.
Ce tri évite de créer des dizaines de redirections inutiles qui alourdissent la configuration serveur et masquent les vrais problèmes.
Détecter les 404 dans Google Search Console : lecture du rapport d’indexation
Le rapport « Pages » de la Search Console liste les URL que Google n’a pas pu indexer, classées par motif. Les erreurs 404 apparaissent sous le libellé « Introuvable (404) » et les soft 404 sous « Soft 404 ». Ces deux catégories méritent une lecture séparée.
Pour chaque URL listée, la Search Console indique la date de dernière exploration et la source de découverte (sitemap, lien interne, lien externe). La source de découverte oriente la correction : une 404 découverte via le sitemap signifie que le fichier XML référence une page qui n’existe plus. Une 404 découverte via un lien interne signale un maillage cassé dans le site.
Un crawler externe comme Screaming Frog complète ce diagnostic en parcourant l’intégralité du site depuis la racine. Il repère les liens internes qui pointent vers des 404 même si Google ne les a pas encore signalées, ce qui permet d’agir avant que le problème ne remonte dans la Search Console.
Surveiller les 404 dans le temps
Un audit ponctuel ne suffit pas. Les erreurs 404 apparaissent à chaque mise à jour de contenu, chaque suppression de produit, chaque modification de structure d’URL. La surveillance régulière du rapport d’indexation, combinée à un crawl mensuel, permet de détecter les nouvelles 404 avant qu’elles ne s’accumulent.
Redirection 301 et code 410 : choisir le bon signal
La redirection 301 indique à Google que le contenu a été déplacé de façon permanente vers une nouvelle URL. Elle transfère une partie de l’autorité de l’ancienne page vers la nouvelle. C’est la correction adaptée quand un contenu équivalent existe ailleurs sur le site.
Le code HTTP 410 (Gone) indique que la ressource a été supprimée définitivement et qu’aucun remplacement n’est prévu. Google traite le 410 comme un signal plus fort que le 404 pour retirer l’URL de son index. Pour du contenu obsolète sans équivalent, le 410 est plus explicite.
Une erreur fréquente consiste à rediriger toutes les 404 vers la page d’accueil. Google identifie ce pattern et le traite comme un soft 404 : la redirection n’apporte aucune valeur à l’utilisateur, et la page d’accueil ne correspond pas à l’intention de l’URL d’origine. Chaque redirection doit pointer vers le contenu le plus proche du sujet initial.
La gestion des erreurs 404 n’a rien de spectaculaire, mais elle conditionne la façon dont Google explore et indexe un site. Un sitemap nettoyé, des liens internes vérifiés après chaque modification de structure, et un tri méthodique des URL signalées suffisent à maintenir un site techniquement propre sur ce point.