Corriger les soft 404 avant qu'ils vident l'index

J'ai mis trois jours à comprendre pourquoi une famille d'URL refusait l'index. Le maillage était propre, les titres tenaient, le serveur répondait vite. Chaque adresse affichait une seule phrase : « Cette catégorie ne contient aucun article. » L'onglet réseau montrait un code HTTP 200. Le rapport d'indexation, lui, parlait de soft 404.

La page avouait l'échec. Le serveur certifiait une ressource valide. Le robot a suivi le contenu vide.

Pourquoi le statut 200 rend le soft 404 trompeur

Le code HTTP prime sur le texte

Un visiteur lit « produit introuvable » et comprend. Un robot commence par le statut. Un 200 annonce une ressource qui existe, à traiter comme une page normale. Le message d'erreur arrive ensuite, simple paragraphe au milieu du HTML.

J'ai vu des gabarits soignés, picto et lien de retour compris, partis quand même en 200. Les humains avaient leur explication. Le protocole annonçait une page trouvée. Le rapport d'indexation nomme ça un soft 404. Dès que le motif dépasse une poignée d'URL, je le place en haut de la pile.

L'effet sur le crawl et l'index

Chaque 200 entre dans le circuit habituel. Le robot télécharge la page, la compare, y revient si un lien interne la désigne. Catégories vides, promos expirées, routes fantômes : autant de créneaux pris sur des fiches qui avaient quelque chose à dire.

Aucun plafond chiffré ne s'affiche à l'écran. L'arbitrage reste terre à terre. Un site qui sert des impasses « réussies » fait parcourir du vide. Un corps réduit à un constat d'échec a peu de chances de rester dans l'index.

Un menu qui pointe encore vers la rubrique vide relance l'URL. Le robot y retourne. Le 200 le conforte.

Les endroits où je les trouve presque à chaque audit

Gabarit d'erreur mal branché

Dans mes notes, la panne la plus fréquente est celle-ci : la page 404 existe, elle est propre, elle part en 200.

Sous Apache, ErrorDocument 404 /404.html garde en principe le statut 404. La panne vient d'une réécriture qui envoie toute URL inconnue vers /404 ou vers l'accueil, sans code forcé. Le texte est le bon. Le statut parle d'un document trouvé.

Sous nginx, error_page 404 /404.html; convient si le statut d'origine reste. Un try_files qui chute sur /index.html répond 200 à chaque route inconnue. Fréquent sur une application d'une seule page. Gênant dès qu'une URL publique ne mène nulle part.

Erreur que j'ai faite longtemps : ouvrir l'adresse du gabarit pour tester. Cette adresse existe, elle répond 200. Le test porte sur une URL absente. Seul le statut de cette requête-là, dans l'onglet réseau, compte.

Pages vides, archives et routes d'application

Le gabarit n'explique pas tout le rapport. En production, les mêmes motifs reviennent.

• Catégorie ou étiquette vide, phrase « aucun résultat », statut 200.
• Pagination après la fin réelle, comme une page 12 sur une liste qui s'arrête à 4.
• Contenu retiré qui affiche encore « ce contenu n'est plus disponible ».
• Fiche produit vidée par une synchro ratée, toujours publiée.
• Route connue seulement du navigateur : le serveur a déjà répondu 200, le script écrit ensuite « page inconnue ».

Même après exécution du script, il ne reste qu'un constat d'échec. Le statut n'a jamais annoncé l'échec.

Les recherches internes à zéro résultat gonflent le même motif quand elles répondent 200. Même grille pour elles : statut honnête, ou vraie page utile.

Repérer les URL concernées

Dans le rapport d'indexation

J'ouvre le rapport d'indexation des pages et je filtre le motif soft 404. J'exporte la liste, ou je la parcours si elle est courte. Puis je groupe par dossier.

Un dossier entier, promo ou catégories à zéro, se règle par une règle ou un modèle. La rustine adresse par adresse vient après, sur les cas isolés.

« Explorée, actuellement non indexée » est un autre motif. Une page solide peut y attendre son tour. Le soft 404 a déjà été jugé creux. Présente des deux côtés, l'URL mérite d'abord une lecture du contenu.

Dix minutes de vérification manuelle

Le rapport traîne. Une page corrigée hier peut y figurer encore. Je contrôle un échantillon avant de modifier le serveur.

1. Cinq à dix URL du motif, prises dans des dossiers différents.
2. Ouverture avec l'onglet réseau et le cache désactivé.
3. Statut du document HTML.
4. Corps réel : titre d'erreur, texte très court, liste vide, ou simple bouton vers l'accueil.
5. Title et canonical, surtout si elle vise l'accueil.
6. Une URL inventée, du genre /ceci-n-existe-pas, pour voir le sort d'une vraie inconnue.

Inconnue en 200 : le trou est global. Inconnue en 404, et seules les rubriques vides en 200 : le trou est dans ces modèles. Je sais alors qui voir, l'hébergement ou la personne des gabarits.

Quelle réponse HTTP pour quel cas

Lire le tableau avant de toucher au serveur

Le statut suit le sort réel de l'URL. Le look du gabarit vient après.

Situation	Statut à renvoyer	Devenir du contenu
URL supprimée définitivement	410	Court message et deux liens vers des pages encore valides
URL inconnue ou faute de frappe	404	Même gabarit, avec le statut 404 conservé
Rubrique utile, vide quelques semaines	200 et noindex	Noindex retiré quand le texte tient de nouveau
Page légitime, trop mince par oubli	200	Réécriture : texte, objets attendus, liens internes
Doublon technique d'une URL valide	301 vers la cible	Une seule adresse indexable à l'arrivée

Le 410 marque un retrait voulu et définitif : offre ancienne, article sans successeur, produit qui ne reviendra pas. Le 404 reste le code de l'inconnu. Une page qui revient à la saison prochaine garde un autre traitement.

Le noindex couvre la rubrique vide pour quelques semaines. Le lien reste vivant, le message est clair, l'index met la page en pause. Je retire la consigne dès le retour du contenu. Oubliée sur un dossier saisonnier, elle a laissé des pages pleines hors de l'index.

Redirection vers l'accueil, le faux ami

Envoyer tout un lot de fiches mortes vers l'accueil rassure au premier coup d'œil. Le visiteur voit un site vivant. Le robot voit des URL différentes finir au même endroit, loin de la demande initiale. J'ai rangé ce réflexe au placard.

Une redirection ne vaut que vers un équivalent : le successeur du produit, ou la nouvelle URL après un changement de slug. Sans équivalent, 404 ou 410. La personne lit une phrase et choisit, au lieu d'atterrir par surprise.

Corriger sans casser l'expérience

Côté serveur

Je pars d'une URL témoin. Une seule. Elle doit renvoyer le bon statut. Je recharge sans cache, je lis l'onglet réseau, puis j'étends la règle.

Quatre réflexes sur un site servi de façon classique.

• Les inconnues passent par le gestionnaire d'erreur qui garde le 404. Sous nginx, try_files $uri $uri/ =404; évite la chute vers une page 200.
• Les retraits voulus renvoient 410 dans l'application, ou par une règle étroite. Une règle large peut condamner une adresse encore bonne.
• Toute redirection permanente vise un équivalent, en un seul saut.
• Le cache des pages d'erreur reste court. Un ancien 200 mémorisé longtemps survit au correctif.

J'ai déjà corrigé nginx trop vite. Le cache a continué de servir l'ancien 200 tout l'après-midi. Depuis, je purge l'URL témoin avant de croire le déploiement.

Pour l'application qui servait la même coquille partout, les routes prévues restent en 200. Le reste répond 404 dès le serveur, avec un HTML simple. Le script peut afficher « page inconnue » sur les routes réelles de l'appli. Il cesse d'être le seul à déclarer qu'une URL publique est absente.

Côté modèle de page

Un bon statut ne remplit pas une catégorie que vous voulez garder.

J'y mets une matière qui existe même sans produit du moment : critères de choix, sous-rubriques, un guide court, des liens vers les familles voisines. Une liste vide coiffée d'une phrase courte reste faible. Le noindex couvre l'attente. Il ne rédige rien à votre place.

Le gabarit d'erreur reste sobre. Un titre qui dit l'absence, un paragraphe, un lien vers l'accueil et deux rubriques solides. Bourré de liens et servi en 200, ce gabarit redevient un soft 404 habillé en page normale.

Sur un 404 ou un 410, la canonical ne vise pas l'accueil. Elle relie deux pages valides. Une erreur n'a pas de version officielle.

Menus, plan de site HTML, blocs automatiques : j'en retire les URL devenues des erreurs. Les laisser, c'est rappeler le robot.

Après le déploiement, je rejoue la témoin et deux voisines. Statut, corps, canonical, noindex présent ou absent selon le cas prévu. Je compare avec une navigation privée, au cas où un cache intermédiaire servirait encore l'ancienne réponse. Le motif dans la Search Console suit la prochaine exploration. Je note le jour du correctif et je relis la liste plus tard. Les demandes d'indexation, je les garde pour les pages réécrites que je veux voir revenir.

Un 404 franc vieillit mieux qu'un 200 poli

Un soft 404 est une politesse mal placée. On veut éviter l'écran sec, on répond 200, et le robot conclut seul que la page ne vaut rien.

J'ai perdu moins de temps depuis que je lis le statut comme une phrase à part entière. La personne qui a gardé l'ancienne offre en favori mérite deux lignes vraies, et un code qui dit la même chose.

Le robot aussi.

Quand les URL vides cessent de se faire passer pour des documents, l'exploration se reporte sur les pages qui ont quelque chose à dire. Le reste du site respire mieux.

Questions fréquentes

Une soft 404 est-elle la même chose qu'une erreur 404 ?

L'erreur 404 envoie le code 404. Le soft 404 envoie 200, avec un contenu d'impasse ou de page vide. Le rapport d'indexation sépare les deux motifs. Selon le sort de l'URL, je la passe en 404, en 410, je la remplis pour de bon, ou je pose un noindex le temps du trou.

Le 410 est-il préférable au 404 ?

Le 410 sert au retrait définitif que vous assumez. Le 404 sert à l'adresse inconnue, faute de frappe comprise. Les deux sortent l'URL du circuit des documents valides. Je réserve le 410 aux suppressions dont je suis sûr.

Le noindex règle-t-il un soft 404 ?

Il aide les pages gardées en ligne le temps de les remplir. Pour une URL qui ne doit plus exister, un 404 ou un 410 va droit au but. Un noindex oublié sur une page déjà remplie la laisse hors de l'index. Je le contrôle à chaque remise en ligne saisonnière.

Le rapport bouge-t-il dès le déploiement ?

Le statut se vérifie dans la minute, dans le navigateur. Le motif du rapport change à la prochaine exploration. Le délai suit la fréquence de crawl du site. Je note le jour du correctif et je relis ensuite. Les demandes d'indexation restent réservées aux pages réécrites.