Soft 404 : comment les repérer et les corriger

Un matin, la Search Console d'un catalogue m'a affiché une longue liste d'URL en soft 404. Je les ai ouvertes une par une. Le serveur répondait 200, le thème montrait le menu, le pied de page, et une phrase du style « aucun contenu ». Rien à lire, rien à acheter. J'ai passé l'heure d'après à trier : rediriger, assumer la page morte, ou la remplir pour de bon.

Ce tri revient dans presque chaque audit technique. Les vraies 404 sautent aux yeux. Les soft 404, elles, ont l'air d'une page normale.

Ce qu'une soft 404 fait au crawl

Le code HTTP dit oui, le contenu dit non

Un code 200 promet une page : un titre clair, un texte à soi, une raison d'exister. Sur une soft 404, le serveur tient la promesse et le contenu la rompt. On tombe sur « article introuvable », « 0 produit », ou une coquille où seuls le header et le footer ont du poids.

Le moteur compare cette réponse à l'idée d'une page utile. S'il juge que l'URL ne mène nulle part, il la range avec les introuvables. Une sonde de disponibilité peut rester verte pendant que la Search Console sort l'URL de l'index utile.

J'ai déjà forcé un 200 sur d'anciennes fiches d'un petit site vitrine, histoire de faire taire un monitoring trop bruyant. Tout est passé au vert. Deux crawls plus tard, la ligne soft 404 avait gonflé. Le code rassurant masquait le vide, et le vide a été reconnu quand même.

Pourquoi ces URL restent si longtemps dans l'index

Une 404 franche se comprend vite. Une page 200 maigre laisse un doute, alors le robot repasse. Il peut garder l'URL un moment, avec un titre pauvre, parfois visible quand quelqu'un tape la marque plus le nom de l'ancienne page.

Chaque passage sur cette coquille en est un de moins sur une fiche valable, une catégorie mise à jour, un article tout juste publié. Sur un site court, ça se sent peu. Sur un catalogue où déclinaisons, filtres et pages de saison s'empilent, la file du robot se remplit de portes murées.

Le maillage entretient la file. Un lien dans le menu, un bloc « vous aimerez » généré tout seul, une ligne encore présente dans le sitemap, un fil d'Ariane qui cite l'ancienne fiche : autant d'invitations à revenir. Je retire ces invitations avant de trancher. Sinon le code change et le site continue d'appeler le robot vers le même trou.

Comment je les chasse sur un site

Le rapport Pages, ligne par ligne

Dans la Search Console, le rapport Pages donne le motif pour lequel une URL n'est pas indexée. J'ouvre la ligne soft 404 quand des adresses disparaissent alors qu'aucun noindex n'a été posé. J'exporte la liste, puis je groupe par répertoire.

Les paquets apparaissent tout seuls. Un dossier d'archives entier. Des fiches dont la taille n'existe plus. Des URL de tri. Un paquet se traite par une règle. Une URL isolée se traite à la main.

Le rapport a du retard. Une mise en ligne le mardi ne vide pas la ligne le mercredi. Je note la date de dernier crawl sur un échantillon et je m'en sers comme repère. Décider que « rien n'a bougé » dès le lendemain mène souvent à une deuxième correction trop tôt, pire que la première.

Le passage au crible, à la main

L'export ne montre pas ce que voit un humain. Je prends deux URL par dossier suspect. Je regarde le titre, le H1, le texte hors menu, le code réellement servi. Le crawl complète : peu de mots hors gabarit, un titre « Page introuvable » répété partout, une canonical qui pointe vers l'accueil.

Je lis aussi le HTML initial, celui qu'un robot peut voir sans dérouler toute la chaîne de scripts. S'il contient déjà « 0 résultat » en dur, le classement est cohérent. S'il contient la liste des produits et qu'un script la vide ensuite, le souci est ailleurs. Je le note à part, pour ne pas le mélanger avec les gabarits vides.

Avant une règle générale, cinq points :

1. Le code HTTP final, avec chaque saut de redirection noté.
2. Le titre et le H1.
3. Le texte propre à la page, gabarit mis de côté.
4. La présence dans le sitemap XML.
5. Les liens internes qui pointent encore vers l'URL.

Quatre familles que je croise tout le temps

Presque tout tient dans quatre tiroirs. Ranger d'abord évite les 301 absurdes.

1. La fiche ou l'article supprimé, avec des liens qui restent.
2. La catégorie ou le filtre qui affiche zéro élément.
3. Le gabarit d'erreur personnalisé qui répond encore 200.
4. La page quasi vide laissée « au cas où », avec un paragraphe fourre-tout.

Le gabarit « rien à afficher »

Les thèmes soignent les états vides : une image, une phrase, un bouton vers l'accueil. Pour un visiteur qui a filtré trop fort, c'est une aide. Pour une URL exposée à l'indexation, c'est une soft 404 en attente. Un filtre n'a pas besoin d'adresse canonique. Une catégorie qui revient chaque année peut rester, à condition de porter un texte stable et des liens vers les rayons voisins. Une coquille avec une icône ne joue pas ce rôle.

L'erreur maquillée en page normale

Sur un site audité l'an dernier, la belle page 404 renvoyait 200. Le développeur l'avait branchée comme une page ordinaire du thème. Le dessin était réussi. Le serveur confirmait un succès. Une partie des URL a fini en soft 404. D'autres sont restées indexées avec le titre de la page d'erreur, au risque de voir « Page introuvable » sortir dans les résultats à côté du nom de la marque.

Le correctif est petit. Cette route doit renvoyer 404 ou 410. La mise en page reste. Le code change.

Corriger sans casser le maillage

Je classe l'échantillon avant de toucher au serveur. La question tient en une ligne : existe-t-il aujourd'hui une page qui répond à la même intention ?

Situation	Décision
Équivalent clair (produit remplacé, article fusionné)	301 vers cette page, un seul saut
Plus aucun équivalent	404 ou 410, liens internes retirés, sitemap nettoyé
Filtre ou recherche interne vide	URL non indexable, ou aucune URL du tout
Page utile trop maigre	Compléter le contenu, conserver le 200
Gabarit d'erreur servi en 200	Garder le design, passer en 404 ou 410

Quel code renvoyer selon le cas

La redirection 301 se justifie quand la cible est précise. Envoyer un paquet d'anciennes fiches vers l'accueil noie le signal. J'ai arrêté le jour où l'accueil est devenu la canonical fantôme d'une série d'URL mortes. Sans cible honnête, l'URL meurt proprement.

Le 410 annonce un retrait voulu. Le 404 annonce que rien ne correspond. Les deux sortent l'URL de la file des pages à indexer. J'emploie le 410 pour ce que je maîtrise (produit arrêté, campagne close) et le 404 pour l'imprévu (faute de frappe, lien externe vers une adresse jamais créée). Une seule convention par type de page : l'audit d'après reste lisible.

Si la page mérite de vivre, j'ajoute de la matière. Un descriptif, des liens vers des pages enfants encore en ligne, un titre unique. Une catégorie qui montre ses produits et une introduction n'a plus de raison de rester en soft 404. Si le rapport la conserve après un crawl frais, je retourne au HTML servi. Le tableau de bord ne m'expliquera pas le gabarit.

Ce que je relis deux semaines plus tard

Quatre contrôles, dans le même ordre.

1. Un échantillon des anciennes soft 404 : code final, une seule redirection, bonne URL d'arrivée.
2. Le sitemap, vidé de ces URL mortes.
3. Les liens internes : ils ne poussent plus vers les 404, sauf choix rare et assumé.
4. Les pages réécrites : un texte à elles, un titre distinct, autre chose qu'un menu.

La Search Console suit le rythme du robot. Elle confirme. Elle ne sert pas à juger le déploiement dès le lendemain.

Les pièges qui reviennent à chaque refonte

Le modèle de recherche sans résultat

Dès qu'une recherche interne possède des URL, certaines finissent crawlées. Une requête sans résultat n'affiche alors que le header et une phrase. Si les paramètres s'empilent, le robot peut rencontrer une quantité énorme de variantes vides. Je rends ce modèle non indexable, je le retire du sitemap, et je vérifie un piège classique des refontes : la balise noindex doit pouvoir être lue. Quand le robots.txt interdit déjà le crawl, la balise reste invisible, et d'anciennes URL traînent avec un statut flou.

Les fiches retirées du catalogue

Le scénario le plus fréquent chez moi : le produit quitte le flux, l'URL reste, le modèle montre le nom, un prix vide, un bouton inactif. Code 200. De loin, on dirait une fiche. De près, c'est creux. Belle candidate à la soft 404.

Deux sorties propres. Un successeur existe : la 301 va vers lui, et vers lui seul. La gamme est morte : la fiche renvoie 410, et les liens internes remontent vers la catégorie parente, qui a encore de quoi répondre. Garder la fiche « pour les anciens backlinks » guide le robot vers le vide. Reporter ces liens sur la catégorie rend le crawl utile à nouveau.

Une page polie coûte plus cher qu'une erreur franche

Quand un audit aligne des erreurs, l'envie est forte d'obtenir un tableau tout vert. Les soft 404 naissent souvent de là. On habille l'absence pour qu'elle ressemble à une page. Le robot ne prend pas le décor pour une réponse. Il voit une URL, un code trop optimiste, un contenu qui ne sert personne.

Depuis que je traite cette ligne comme un tri, les audits sont plus calmes. Une partie des URL disparaît, et c'est voulu. Une autre redevient une vraie page. Le robot passe moins de temps dans les couloirs vides.

La prochaine URL « OK » qui ne mérite pas les résultats, demandez-vous qui elle sert. Si la réponse est personne, donnez-lui un code qui le dit clairement.

Questions fréquentes

Une soft 404 est-elle une erreur 404 classique ?

Le serveur annonce souvent un succès, en général un code 200. Google range pourtant l'URL avec les pages qu'il considère introuvables, parce que le contenu ne tient pas lieu de page. Dans les logs, la ligne a l'air saine. Dans l'index, elle ne l'est plus.

La Search Console liste-t-elle toutes les soft 404 ?

Elle liste celles qu'elle a crawlées et jugées ainsi. Le site peut en créer de nouvelles entre deux passages, et d'anciennes adresses restent parfois affichées plusieurs semaines. Un crawl interne, plus quelques pages ouvertes à la main, vient compléter le rapport.

Faut-il envoyer chaque soft 404 vers l'accueil ?

Je ne le fais plus. L'accueil ne répond pas à l'intention de l'ancienne adresse. Une redirection n'a de sens que vers une page précise, du même sujet. Sans cette page, l'URL passe en 404 ou en 410, puis les liens et le sitemap sont nettoyés.

Quand le rapport se met-il à jour après correction ?

Au rythme du robot. Sur les sites que je suis, je contrôle un échantillon au bout de deux semaines, puis le rapport quand les dates de dernier crawl ont avancé. Échantillon au bon code, sitemap propre : j'attends. Empiler une deuxième couche de règles dans la précipitation fabrique des chaînes de redirections, et c'est un autre chantier.