Erreur 404 et soft 404 : que corriger ?

Corriger une erreur 404 : réparer le lien qui y mène

Une adresse qui répond 404 n'a pas à disparaître. Ce qui se corrige, c'est ce qui y envoie le visiteur : un lien de votre propre site, dans une page, un menu ou un pied de page. Celui qui clique attend une page et tombe sur une erreur, à cause d'un lien que vous maîtrisez.

Dans l'exemple de rapport d'un site vitrine B2B, le logo du pied de page mène à /old-home, une adresse qui répond 404, et ce sur toutes les pages analysées. Le rapport le range parmi les défauts de gabarit : un seul lien à corriger, une fois, pour toutes les pages qui le portent.

Le reste se décide adresse par adresse. Une page déplacée reçoit une redirection 301 en un seul saut vers sa nouvelle adresse. Une page supprimée sans équivalent garde sa 404. Une adresse qui n'a jamais existé, née d'une faute de frappe ou d'un lien erroné sur un autre site, aussi : la 404 est la bonne réponse, et une page d'erreur utile fait le reste.

Soft 404 : une erreur à l'écran, un succès dans le code

Chaque réponse d'un serveur commence par un code, dont la norme HTTP (RFC 9110) fixe le sens. Le texte de la page s'adresse au visiteur. Le code s'adresse aux programmes, comme les moteurs de recherche, les navigateurs et les outils qui vérifient les liens, et beaucoup ne lisent que lui. Une soft 404 est une page qui annonce une erreur au visiteur pendant que son code annonce un succès.

Google ne s'arrête pas au code. Quand une page répond 200 mais que son contenu ressemble à une erreur, ou qu'elle est vide, il peut la classer en soft 404 et la signaler dans la Search Console ; sa documentation sur les erreurs d'exploration la juge mauvaise pour l'utilisateur. Les vraies erreurs sont plus simples : Google traite toutes les erreurs de la famille 400 de la même façon, sauf 429. L'adresse sort de l'index et il la visite de moins en moins souvent : pour lui, 404 et 410 se valent.

Les autres programmes s'en tiennent au code. Sur un site en soft 404, un lien vers une page supprimée répond 200, exactement comme un lien valide, et tout contrôle des liens qui lit les codes le compte comme un lien qui fonctionne. Les liens morts du site deviennent invisibles, et personne ne sait qu'il faudrait les corriger.

Comment un site finit par répondre 200 à une page absente

Ce pourcentage porte sur une trentaine de sites audités entre le 14 août 2026 et le 24 septembre 2026, ceux où le point a pu être vérifié. Beaucoup ont été audités parce qu'un défaut s'y voyait vite : le chiffre décrit nos audits, pas l'ensemble des sites.

Le faux succès peut venir d'un réglage, de la façon dont le site est construit, ou d'un contenu trop mince pour que Google le distingue d'une erreur :

• Une page d'erreur personnalisée servie avec un code 200. Le serveur ou le gestionnaire de contenu affiche la page prévue, sans le code qui va avec.
• Toute adresse inconnue redirigée vers l'accueil. Le visiteur arrivé par un lien ancien atterrit sur l'accueil sans savoir que la page qu'il cherchait n'existe plus, et le code reçu à l'arrivée est un succès. La documentation de Google sur les migrations prévient que rediriger de nombreuses anciennes adresses vers une seule destination sans rapport, comme l'accueil, peut être traité comme une soft 404.
• Une application rendue dans le navigateur, qui renvoie le même document à toutes les adresses et laisse le script afficher « page introuvable ». C'est la construction de plusieurs outils de création de site par IA ; le guide sur le référencement des sites rendus par JavaScript décrit ce que Google en fait, et les deux remèdes qu'il propose.
• Une page qui existe mais n'a rien à montrer, comme une catégorie sans produit. Google peut la classer en soft 404 d'après son seul contenu.

Sur un site créé avec un outil d'IA, la soft 404 est l'un des points à regarder ; les autres sont réunis dans le guide pour contrôler un site généré par une IA.

Une page d'erreur utile, envoyée avec le code 404

Rien de ceci ne demande de toucher au serveur vous-même. Ce sont des décisions à transmettre à votre développeur, à votre agence ou à votre hébergeur, dans cet ordre :

1. Exigez que la page d'erreur soit servie avec le code 404. C'est la même page, à la même charte : seul le code change.
2. Faites retirer toute règle qui envoie les adresses inconnues vers l'accueil. Seules les pages réellement déplacées gardent une redirection permanente, une par adresse, vers leur équivalent.
3. Faites corriger les liens de votre site qui mènent à une 404, en commençant par ceux du gabarit, comme le menu et le pied de page : une seule correction vaut alors pour toutes les pages.
4. Faites de la page d'erreur une page utile : elle dit clairement que l'adresse n'existe pas, garde l'en-tête et la navigation du site, et propose une suite, comme l'accueil, la recherche ou les rubriques principales. Le visiteur arrivé par un lien ancien repart vers ce qu'il cherchait, au lieu de quitter le site.
5. Pour une catégorie vide, décidez si elle doit exister. Si elle n'a durablement rien à montrer, elle répond 404 ; si elle reste en ligne, elle a besoin d'un contenu qui ne ressemble pas à une erreur.
6. Après une refonte, un changement d'hébergement ou de gestionnaire de contenu, faites revérifier ce que le site répond à une adresse inconnue. Le réglage vit dans le serveur, et il ne suit pas toujours le site.

Les fichiers suivent la même règle. Une image, un script ou une feuille de style supprimés répondent eux aussi 404, et la page qui les demande s'affiche incomplète : le guide sur les images et fichiers qui ne se chargent plus leur est consacré.

Une page d'erreur servie en 200 se corrige une fois, dans le serveur ou le gestionnaire de contenu, et une règle qui renvoie tout vers l'accueil se retire aussi simplement. Le travail devient un projet sur une application rendue dans le navigateur, quand le serveur ne sait pas quelles adresses existent. Il faut alors qu'il l'apprenne, par un rendu côté serveur ou un pré-rendu, ou appliquer l'un des deux remèdes décrits par Google. C'est un changement de construction, qui se planifie.

Une adresse inventée, demandée comme le ferait un visiteur

Pendant l'audit, une adresse inventée, qui ne peut exister sur aucun site, est demandée au serveur depuis un navigateur. Les redirections sont suivies : c'est le code reçu à l'arrivée qui compte.

• Un code 404 ou 410 : la réponse est correcte, quelle que soit la page affichée.
• Un code de succès à l'arrivée, qu'il accompagne une page d'erreur, l'accueil ou une page vide : c'est une soft 404, comptée comme un défaut dans le pilier expérience et fiabilité, parce que le visiteur est le premier concerné.
• Un refus d'accès ou une page de vérification anti-robot : le serveur n'a pas dit ce qu'il répond à une adresse inconnue. Le point est déclaré non vérifiable, jamais compté comme conforme.

Ce test règle aussi la lecture du reste du rapport. Sur un site en soft 404, le relevé des liens morts de l'audit, qui lit les codes, compte lui aussi un lien vers une page supprimée comme valide : des liens morts peuvent lui échapper.

Le test dit ce que le serveur répond à une adresse inconnue, pas quelles adresses vos visiteurs demandent réellement. L'audit en rencontre une partie en parcourant le site : les liens internes qui mènent à une erreur sont relevés sur les pages de l'échantillon, et une catégorie qui annonce qu'elle est vide est relevée avec la phrase trouvée.

Les deux exemples publiés montrent le cas inverse. Le site vitrine B2B et la boutique en ligne répondent tous deux par une vraie 404. C'est ce qui a permis de relever le lien du pied de page vers /old-home sur le premier. Sur la seconde, c'est ce qui donne sa valeur au résultat : aucun lien interne cassé sur l'ensemble des liens parcourus, et une page d'erreur, « Page non disponible », servie avec le bon code.