Erreurs soft 404 : ce que c'est et comment les corriger

Réponse courte : Un soft 404 est une page qui indique « introuvable » au visiteur (ou n'affiche presque rien) mais répond avec le statut de succès 200 au lieu de 404. Google traite cela comme une erreur : quand le contenu d'une réponse 2xx laisse penser à une erreur, la Search Console signale un soft 404. La correction consiste à faire envoyer par le serveur le statut qui correspond à la réalité : 404 ou 410 pour les pages supprimées, un 301 vers une page équivalente pour les pages déplacées, et un vrai contenu pour les pages qui doivent exister.

Qu'est-ce qu'un soft 404 ?

Toute réponse d'un serveur web commence par un code de statut, et ce code arrive avant n'importe quel contenu. 200 signifie « OK, voici la page ». 404 signifie « il n'y a rien ici ». Un soft 404 est un décalage entre les deux : la page affichée à l'écran dit « introuvable » ou « 0 résultat », ou n'offre rien qui vaille d'être lu, et pourtant le statut est 200.

Google décrit ce cas dans sa documentation sur les codes de statut HTTP et les erreurs réseau. Pour une réponse 2xx, Google prend le contenu en compte. Si ce contenu laisse penser à une erreur, par exemple une page vide ou un message d'erreur, la Search Console affiche une erreur soft 404. Pour un véritable statut 4xx, Google n'utilise pas du tout le contenu de l'URL.

Dans un terminal, la différence se voit. Sur un site qui a ce problème, une requête vers une adresse qui n'existe pas donne ceci (l'adresse est fictive) :

$ curl -s -o /dev/null -w "%{http_code}\n" https://votre-site.example/page-inexistante
200

La bonne réponse est 404. Le visiteur voit le même message « Page introuvable » dans les deux cas. Seul le statut diffère, et c'est la première chose qu'un robot lit.

Le mot « soft » (mou, doux) ne veut pas dire « bénin ». Il signifie que le serveur affirme que tout va bien alors que la page dit le contraire.

Pourquoi un soft 404 pose-t-il problème ?

Voici ce qui est documenté, et ce qui ne l'est pas.

Documenté :

• La Search Console liste l'URL comme une erreur soft 404 : Google lui-même y voit donc un problème.
• Avec un vrai 404 ou 410, Google n'utilise pas le contenu de l'URL. Avec un 200, vous laissez Google deviner, d'après le contenu, si la page est une erreur.

Non documenté : un effet direct sur le classement. Google nomme l'erreur dans son rapport. Il ne dit pas qu'un soft 404 tire vers le bas d'autres pages de votre site, et nous n'avons trouvé aucune source qui le prouve. Méfiez-vous des affirmations du genre « les soft 404 détruisent votre SEO ».

Notre avis, et rien de plus : une page sans valeur ne devrait pas être proposée comme résultat, et la correction coûte peu. Il existe aussi un aspect pratique qui n'a rien à voir avec Google : les vérificateurs de liens et les outils de surveillance lisent les codes de statut. Si toutes les adresses répondent 200, ils ne peuvent pas vous dire qu'un lien est cassé, et les visiteurs qui suivent un ancien lien ne sont jamais prévenus que la page a disparu.

D'où vient un soft 404 ?

Les soft 404 viennent typiquement de schémas comme ceux-ci :

• Une application monopage qui répond à chaque chemin avec la même coquille. Le serveur envoie l'application, avec le statut 200, pour n'importe quelle adresse. Ce n'est qu'après l'exécution du JavaScript que l'écran affiche « introuvable ». Le statut a été décidé avant, et c'est 200. Google traite ces pages par étapes (exploration, rendu, indexation), et une page au statut 200 entre dans la file d'attente du rendu. Les bases de JavaScript pour la recherche de Google expliquent ce modèle. Google précise aussi que tous les robots n'exécutent pas JavaScript : plus le statut est correct dès la première réponse du serveur, moins vous dépendez de l'exécution d'un script.
• Une jolie page d'erreur avec le statut 200. Un CMS, un framework ou une règle de proxy affiche un gabarit « introuvable » soigné, mais oublie de fixer le statut.
• Des pages de liste vides. Une page de catégorie, de mot-clé ou de recherche interne sans résultat répond quand même 200 et affiche « 0 résultat » ou un cadre vide.
• Des produits épuisés ou retirés du catalogue. La page reste en ligne avec à peine plus qu'un « indisponible ». Une page qui porte encore une vraie description et une indication de disponibilité est un cas différent d'un simple avis nu.
• Tout rediriger vers la page d'accueil. Une page supprimée qui renvoie les visiteurs vers l'accueil se termine par un 200 avec un contenu sans rapport. La page d'accueil est rarement l'équivalent de la page disparue.

Il y a encore la page maigre : un gabarit presque sans contenu, comme un texte provisoire ou une rubrique à moitié construite. Un contenu qui ressemble à un message d'erreur ou à une page vide peut être signalé, même si personne n'a voulu en faire une page d'erreur.

Comment trouver les soft 404 ?

Vous avez trois moyens, qui se complètent.

1. La Search Console. Ouvrez le rapport sur l'indexation des pages (« Page indexing » dans l'interface anglaise) et cherchez le motif « Soft 404 ». Il liste les URL que Google a lui-même rangées dans cette catégorie. L'outil « Inspection de l'URL » montre ce que Google obtient d'une adresse précise.
2. Un terminal. Demandez une adresse qui ne peut pas exister et lisez le statut (commande ci-dessous).
3. Le navigateur. Ouvrez les outils de développement, passez à l'onglet « Réseau », chargez une adresse inventée et regardez le statut de la première requête. La page elle-même ne vous apprend rien, car elle a le même aspect quel que soit le statut.

Pour la vérification au terminal, l'option -L suit les redirections, ce qui vous montre aussi où l'adresse aboutit :

curl -s -L -o /dev/null -w "%{http_code} %{url_effective}\n" https://votre-site.example/page-inexistante-12345

Ce que vous voulez, c'est 404. Si vous obtenez 200 https://example.com/, le serveur redirige les adresses inconnues vers la page d'accueil. Utilisez GET comme ici plutôt que curl -I, car certains serveurs répondent autrement à une requête HEAD.

Testez de l'extérieur : demandez l'adresse publique, pas directement l'application. Un CDN, un cache ou un pare-feu placé devant l'application peut modifier la réponse.

Comment SEOgrinder teste un soft 404

L'analyse gratuite de SEOgrinder demande à votre site une adresse qu'elle invente, avec un nom aléatoire qui ne peut pas exister. Si la réponse est 200, elle signale un constat. Une redirection de cette adresse vers votre page d'accueil compte comme le même constat, puisqu'elle se termine aussi par un 200. Le résultat apparaît dans l'onglet « Page sur Google », dans la carte « Indexation », sous la forme d'une ligne : « Les adresses inconnues renvoient correctement une 404 » ou « Les adresses inconnues renvoient 200 au lieu de 404 ». Le constat entre dans la liste des tâches avec le conseil de renvoyer un véritable 404 ou 410.

Deux limites, dites honnêtement. Première limite : ce test regarde comment votre serveur traite les adresses qui n'existent pas. Il ne vous dit pas lesquelles de vos vraies URL Google a classées comme soft 404. Pour les URL isolées, le verdict se trouve dans la Search Console. Dans une installation locale connectée à la Search Console, SEOgrinder lit en plus l'état d'indexation enregistré de la page analysée et le signale quand Google la range parmi les soft 404. Seconde limite : le test ne peut pas dire si l'une de vos pages maigres paraît vide aux yeux de Google. L'exploration du site signale bien les pages maigres et les liens internes cassés, qui sont les endroits où le problème commence souvent.

Quel code de statut choisir ? Un tableau de décision

La bonne réponse dépend de ce qui est vrai pour la page. Changez le statut pour qu'il corresponde à la réalité, jamais l'inverse.

Google traite 301 et 308 comme un signal fort que la cible de la redirection doit être traitée, et 302 et 307 comme un signal faible. Il suit par défaut jusqu'à dix étapes de redirection et ignore le contenu de l'URL qui redirige. Redirigez donc une seule fois, directement vers l'adresse finale.

Corriger un soft 404 dans nginx, Node et les applications monopages

nginx

Cette configuration sert une page d'erreur soignée et conserve le statut 404. La ligne error_page 404 /404.html; garde le statut d'origine tant que vous n'ajoutez pas =200 : n'en ajoutez donc pas.

server {
    root /var/www/example;
    error_page 404 /404.html;

    location / {
        try_files $uri $uri/ =404;
    }

    location = /404.html {
        internal;
    }

    # supprimée volontairement
    location /ancienne-campagne/ {
        return 410;
    }

    # déplacée
    location = /ancienne-page {
        return 301 https://example.com/nouvelle-page;
    }
}

Node

Pour les routes qui reposent sur des données, le code doit d'abord chercher l'enregistrement, puis décider du statut. Cet exemple n'utilise que les modules propres à Node :

import http from 'node:http';

const products = new Map([['mug-bleu', 'Mug bleu']]); // à remplacer par votre base de données

http.createServer((req, res) => {
  const { pathname } = new URL(req.url, 'http://localhost');
  const match = /^\/products\/([a-z0-9-]+)$/.exec(pathname);
  const name = match && products.get(match[1]);
  res.writeHead(name ? 200 : 404, { 'content-type': 'text/html; charset=utf-8' });
  res.end(name ? `<h1>${name}</h1>` : '<h1>Page introuvable</h1>');
}).listen(3000);

La page d'erreur peut être conviviale et soignée, le statut reste 404. La plupart des frameworks fournissent une fonction ou un point d'accroche « introuvable » dans ce but. Cherchez celui qui fixe le statut et ne se contente pas d'afficher un gabarit.

Applications monopages (SPA)

Le serveur doit savoir quels chemins sont réels. Le raccourci courant, « envoyer index.html pour tout », est précisément ce qui crée le problème. Dans nginx, vous pouvez lister les vraies routes et répondre 404 pour le reste :

location = / {
    try_files /index.html =404;
}

location ~ ^/(a-propos|contact|docs)/?$ {
    try_files /index.html =404;
}

location / {
    try_files $uri =404;
}

Les ressources comme les scripts et les images sont trouvées par le dernier bloc, et tout autre chemin reçoit un 404. Si la liste des routes est longue ou change souvent, générez-la à partir de votre routeur au moment du build. L'autre solution consiste à produire de vraies pages sur le serveur ou à l'avance, de sorte que chaque adresse ait son propre fichier HTML et que le serveur puisse répondre pour elle. Google lui-même juge le rendu côté serveur ou le pré-rendu toujours judicieux, car il rend la page plus rapide pour les utilisateurs et pour les robots, et parce que tous les robots n'exécutent pas JavaScript. Pour les applications où fixer un code de statut est impossible ou peu pratique, les bases de JavaScript pour la recherche de Google citent deux autres voies : rediriger avec JavaScript vers une adresse qui répond 404 (par exemple /not-found), ou ajouter <meta name="robots" content="noindex"> avec JavaScript sur les pages d'erreur.

Après chaque modification, relancez la vérification avec curl et testez une vraie page, une page déplacée et une adresse qui ne peut pas exister.

Erreurs fréquentes

• Corriger l'apparence plutôt que le statut. Une belle page « introuvable » qui envoie 200 reste un soft 404.
• Rediriger toutes les pages manquantes vers la page d'accueil. Cela cache le problème à vos propres outils et donne aux visiteurs autre chose que ce qu'ils demandaient. Redirigez vers une page équivalente, ou répondez 404.
• error_page 404 =200 /index.html; et les raccourcis du même genre. Ils font passer toute adresse inconnue au statut 200.
• Ne tester que dans le navigateur. Le navigateur a le même aspect pour tous les statuts. Lisez le statut.
• Bloquer les adresses dans le robots.txt au lieu de corriger le statut. Un robot qui n'a pas le droit de demander une page ne voit jamais son code de statut.
• Laisser des adresses mortes dans le sitemap. Un sitemap ne doit lister que des pages qui existent et répondent 200.
• Attendre que le rapport se vide aussitôt. L'entrée de la Search Console change quand Google demande de nouveau l'URL. Personne ne peut promettre quand cela arrivera.

Questions fréquentes

Un soft 404 nuit-il à mon classement ?

Ce n'est pas démontré. Google le signale comme une erreur dans la Search Console, c'est documenté. Une pénalité directe de classement pour le reste de votre site ne figure dans aucune des sources que nous avons utilisées. La lecture raisonnable : corrigez-le parce que la réponse est fausse, pas en vue d'un gain promis.

Un soft 404, est-ce la même chose qu'un 404 ?

Non. Un 404 est une réponse honnête : le statut dit que la page n'existe pas. Un soft 404 dit 200 alors que le contenu affirme le contraire.

Faut-il envoyer 404 ou 410 ?

Ce sont deux statuts d'erreur 4xx, et Google n'utilise le contenu de l'URL ni pour l'un ni pour l'autre. 404 est la réponse habituelle pour « introuvable ». 410 dit « disparue pour de bon » : il convient aux pages que vous avez retirées volontairement.

Puis-je avoir une page 404 personnalisée ?

Oui, et vous devriez. Donnez-lui le design que vous voulez, ajoutez un lien vers la page d'accueil ou une recherche, mais veillez à ce que le statut soit 404.

Comment vérifier tout mon site ?

Lancez l'analyse gratuite pour tester la façon dont votre serveur répond aux adresses inconnues, et consultez le rapport de la Search Console pour les URL que Google a signalées. Contrôlez à la main une dernière chose : les pages qui ne portent qu'un court avis.

Votre prochaine étape

Lancez curl sur une adresse qui ne peut pas exister sur votre propre site. Si vous n'obtenez pas 404, corrigez cela d'abord. Lancez ensuite l'analyse gratuite avec SEOgrinder, repérez la ligne sur le soft 404 dans la carte « Indexation » de l'onglet « Page sur Google », et cliquez sur « Réanalyser » après votre modification pour voir le nouveau résultat. Pour replacer ce point dans une vue d'ensemble, parcourez la checklist audit SEO.