Ce qu’est réellement un soft 404 (et pourquoi Google s’en préoccupe)

Un « soft 404 » signifie que Google dit : « Ça ressemble à une page manquante, même si votre serveur n’a pas envoyé un 404 correct. » Habituellement, le serveur renvoie 200 OK (ou parfois 302 ou 403) avec un contenu qui ressemble à une page d’erreur, une page presque vide, une page « aucun résultat » ou un gabarit générique.

Le rôle de Google est d’empêcher les déchets d’entrer dans l’index. Si une URL renvoie 200 mais se comporte comme « désolé, rien ici », l’indexer polluerait les résultats. Google tente donc d’inférer l’intention : contenu manquant, contenu maigre, gabarit dupliqué ou comportements trompeurs causés par redirections/caches.

Opérationnellement, les soft 404 ne sont pas « juste un truc SEO ». C’est un problème d’architecture distribuée : caches, CDN, logique de redirection, frontières d’authentification, traitement des bots et codes de statut incohérents. Googlebot n’est qu’un autre client avec des opinions bien arrêtées.

Une règle pratique : votre site doit être ennuyeux pour les crawlers. Codes de statut prévisibles, contenu cohérent, minimal de surprises. Les surprises sont pour les lancements produits, pas pour les réponses HTTP.

Pourquoi les sites WordPress déclenchent des soft 404

1) Pages 404 « jolies » qui renvoient 200

Beaucoup de thèmes WordPress affichent une belle page « Page non trouvée » mais oublient d’envoyer le 404 Not Found côté serveur. Parfois c’est le thème, parfois un plugin, parfois une couche de cache qui a stocké une page 404 et la sert comme 200.

2) Résultats de recherche, archives de tags et pagination qui semblent vides

WordPress peut générer beaucoup d’URLs : /tag/, /author/, /page/99/, résultats de recherche internes, archives par date. Quand ces pages contiennent peu de contenu (ou « Aucun article trouvé »), Google peut les traiter comme des soft 404 — surtout si vous renvoyez 200 avec un gabarit majoritairement boilerplate.

3) « Nettoyage » par redirection qui efface le sens

Les plugins qui « corrigent » les liens cassés en redirigeant tout vers la page d’accueil sont des générateurs classiques de soft 404. Pour un utilisateur c’est amical. Pour Google, c’est un décalage : une URL spécifique qui devrait être inexistante est remplacée par une page générique. Ce n’est pas une correction ; c’est masquer la preuve.

4) Modes maintenance, WAF et blocages de bots trop astucieux

Certaines sites renvoient 200 avec un contenu « maintenance », ou bloquent les bots et renvoient une page HTML « Accès refusé » en 200. Googlebot indexe la page de rejet ou la classe en soft 404. Si vous devez bloquer, faites-le proprement avec les bons codes (503 pour maintenance avec Retry-After, 401/403 pour auth) et un comportement cohérent.

5) Rendu incohérent : le bot voit une chose, les humains en voient une autre

Règles géo, tests A/B, personnalisation, bannières de consentement et problèmes de rendu JS peuvent modifier le contenu. Si Googlebot reçoit une page dépouillée, un interstitiel ou une coque vide, il peut la classer comme « manquante ». Parfois rien n’est « cassé » de votre côté — jusqu’à ce que vous testiez en tant que Googlebot et découvriez la triste vérité.

Blague #1 : Un soft 404, c’est comme votre collègue qui dit « Je ne démissionne pas » en rangeant son bureau dans une boîte.

Guide de diagnostic rapide (vérifiez ceci dans l’ordre)

Si vous voulez de la rapidité, arrêtez de deviner. Utilisez une boucle serrée : vérifiez le code de réponse, regardez le contenu servi, vérifiez s’il change pour Googlebot, puis tracez la couche source.

Première étape : vérifiez le statut HTTP et la destination finale

• L’URL renvoie-t-elle 200 tout en affichant un message 404 ?
• Y a-t-il une chaîne de redirections qui finit sur la page d’accueil ou une page de recherche ?
• Le canonique pointe-t-il ailleurs ?

Deuxième étape : comparez ce que Googlebot reçoit et ce que vous voyez

• Récupérez avec un user agent Googlebot. Comparez la longueur du HTML, le titre, la meta robots, le canonique et le corps du contenu.
• Vérifiez si un WAF/CDN injecte des challenges ou des interstitiels.

Troisième étape : isolez la couche qui ment

• Le serveur d’origine (WordPress/PHP) renvoie-t-il le mauvais statut ?
• La couche de cache réécrit-elle ou met-elle en cache des pages d’erreur incorrectement ?
• Un plugin crée-t-il des redirections ou une gestion « intelligente » des 404 ?

Quatrième étape : décidez de l’intention de l’URL

• Doit-elle exister ? Rendez-la substantielle et indexable.
• Doit-elle disparaître ? Retournez 404 ou 410 et ne redirigez pas vers des pages non pertinentes.
• Doit-elle exister mais ne pas être indexée ? Retournez 200 avec noindex, mais gardez un contenu utile pour les utilisateurs.

Comment Google juge qu’une page est « soft 404 »

Google ne publie pas l’ensemble du classificateur (et vous ne voudriez pas qu’il le fasse), mais on peut inférer les signaux :

• Similarité de contenu avec des gabarits d’erreur connus : « Non trouvé », « plus disponible », « rien ici », etc.
• Contenu maigre : principalement navigation, en-tête/pied de page, sans contenu principal.
• Redirections inattendues : beaucoup d’URLs manquantes redirigeant vers une page générique.
• Faible valeur unique : archives facettées ou pages auto-générées avec quasi-aucune différenciation.
• Anomalies de fetch/rendu : ressources bloquées, erreurs JS, interstitiels, murs de consentement, challenges WAF.
• Consistance dans le temps : la même URL bascule entre « vrai contenu » et « vide » selon l’état du cache ou la géolocalisation.

Google regarde aussi le schéma global du site. Si des milliers d’URLs se comportent comme « pages vides » avec 200, le crawler devient rapidement sceptique.

Une citation opérationnelle qui devrait figurer dans tous les runbooks : Vous le construisez, vous le gérez. — Werner Vogels

Tâches pratiques : commandes, sorties et décisions

Ci-dessous des vérifications pratiques que vous pouvez lancer depuis un serveur ou une station de travail. Chaque tâche inclut : une commande, un exemple de sortie, ce que ça signifie et la décision suivante. Faites-les dans l’ordre si vous déboguez. Faites-les sélectivement si vous auditez.

Task 1: Check the final HTTP status and redirect chain

cr0x@server:~$ curl -sSIL https://example.com/suspect-url | sed -n '1,25p'
HTTP/2 301
date: Sat, 27 Dec 2025 10:12:11 GMT
location: https://example.com/
cache-control: max-age=3600
server: nginx

HTTP/2 200
date: Sat, 27 Dec 2025 10:12:11 GMT
content-type: text/html; charset=UTF-8
cache-control: max-age=300
server: nginx

Ce que cela signifie : L’URL redirige vers la page d’accueil. Si cela concerne des pages manquantes, Google signale souvent un soft 404 car la destination est sans rapport.

Décision : Si l’URL a vraiment disparu, cessez de la rediriger vers la page d’accueil. Retournez 404 ou 410. Si elle a déménagé, redirigez vers la page la plus proche équivalente, pas une page générique.

Task 2: Verify the body contains a “not found” template despite 200

cr0x@server:~$ curl -sS https://example.com/missing-page | grep -Ei 'not found|404|no posts found|nothing here' | head
404
Sorry, the page you are looking for could not be found.

Ce que cela signifie : Votre site indique aux utilisateurs que la page est manquante, mais vous renvoyez peut-être toujours 200.

Décision : Corrigez les codes de statut à la source (thème/template ou hooks WordPress), puis retestez. Une jolie page 404 est acceptable ; une page 404 renvoyée en 200 ne l’est pas.

Task 3: Compare what Googlebot sees vs a normal browser

cr0x@server:~$ curl -sS -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/product/widget | sed -n '1,20p'
<html>
<head>
<title>Access Denied</title>
<meta name="robots" content="noindex,nofollow">
</head>
<body>Request blocked.</body>

Ce que cela signifie : Une règle WAF/CDN traite Googlebot différemment. Même si les humains voient la page produit, Google voit une page de blocage.

Décision : Corrigez l’accès des bots. Autorisez Googlebot (prudemment), ou retournez un code honnête (403) et acceptez qu’il ne soit pas indexé. Ne servez pas une page « Accès refusé » en 200.

Task 4: Confirm the real status code from origin (bypass CDN if possible)

cr0x@server:~$ curl -sSIL --resolve example.com:443:203.0.113.10 https://example.com/missing-page | sed -n '1,12p'
HTTP/2 200
date: Sat, 27 Dec 2025 10:14:02 GMT
content-type: text/html; charset=UTF-8
server: nginx
x-cache: MISS

Ce que cela signifie : En forçant le DNS vers l’IP d’origine, vous voyez que l’origine renvoie 200. Le bug vient probablement du WordPress/thème ou de la configuration d’origine, pas du CDN.

Décision : Corrigez la gestion côté WordPress (template, règles de rewrite, plugins) pour que les pages manquantes produisent 404/410.

Task 5: Check headers for caching of error-like pages

cr0x@server:~$ curl -sSIL https://example.com/missing-page | egrep -i 'HTTP/|cache-control|age|x-cache|cf-cache-status|vary|location'
HTTP/2 200
cache-control: public, max-age=86400
age: 43122
x-cache: HIT
vary: Accept-Encoding

Ce que cela signifie : Votre CDN/proxy met en cache l’expérience « manquante » pendant une journée. Si cette page est en réalité une erreur transitoire ou une requête mal routée, Google verra encore et encore la mauvaise version.

Décision : Ne mettez pas en cache les templates 404 en tant que 200. Définissez les codes de statut corrects et envisagez des TTL différents pour les réponses d’erreur. Purgez les entrées de cache après correction.

Task 6: Inspect robots directives and canonical tags

cr0x@server:~$ curl -sS https://example.com/suspect-url | egrep -i 'rel="canonical"|meta name="robots"' | head

Ce que cela signifie : Le canonique pointe vers la page d’accueil. Cela peut être légitime dans de rares cas, mais si beaucoup de pages se canonicalisent vers la home, Google les considérera comme des duplicatas ou du contenu faible ressemblant à des soft 404.

Décision : Corrigez la génération des balises canoniques. Chaque vraie page devrait se canonicaliser elle-même ; les pages non-canoniques doivent être gérées via redirections ou noindex avec une raison claire.

Task 7: Find WordPress “empty archive” patterns in access logs

cr0x@server:~$ sudo awk '$7 ~ /\/tag\/|\/author\/|\/page\/[0-9]+\/|\/\?s=/' /var/log/nginx/access.log | tail -n 5
198.51.100.21 - - [27/Dec/2025:10:10:01 +0000] "GET /tag/obsolete/ HTTP/2.0" 200 18432 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
198.51.100.21 - - [27/Dec/2025:10:10:03 +0000] "GET /author/ghostwriter/ HTTP/2.0" 200 18012 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
198.51.100.21 - - [27/Dec/2025:10:10:06 +0000] "GET /page/99/ HTTP/2.0" 200 17655 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Ce que cela signifie : Googlebot parcourt des URLs d’archives maigres/vides qui produisent souvent des flags soft 404.

Décision : Décidez si ces archives méritent l’indexation. Si non, mettez-les en noindex, ou resserrez le maillage interne et la génération de sitemap pour ne pas inviter les crawlers sur des URLs inutiles.

Task 8: Check if WordPress is sending the right status for 404 pages

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/this-should-404 | head -n 8
HTTP/2 200
date: Sat, 27 Dec 2025 10:16:31 GMT
content-type: text/html; charset=UTF-8
server: nginx

Ce que cela signifie : Drapeau rouge évident. Une page manquante renvoie 200.

Décision : Corrigez à la source : vérifiez la gestion des 404 par WordPress, désactivez les plugins suspects, revoyez les règles de rewrite et assurez-vous que votre serveur ne réécrit pas les URLs manquantes vers index.php sans logique 404 appropriée.

Task 9: Identify “redirect everything” rules in Nginx

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n 'try_files|error_page|return 301|rewrite' | head -n 25
45:    try_files $uri $uri/ /index.php?$args;
88:    error_page 404 =200 /index.php;
132:   rewrite ^/old/(.*)$ / permanent;

Ce que cela signifie : error_page 404 =200 /index.php; est une classique mine anti-personnelle. Cela convertit un vrai 404 en 200, servant souvent un template 404 du thème comme succès.

Décision : Supprimez ou corrigez cela. Si vous avez besoin de pages d’erreur personnalisées, conservez le statut 404. Dans Nginx, privilégiez error_page 404 /404.html; (sans forcer =200), ou laissez WordPress gérer les 404 mais assurez-vous qu’il envoie le statut correct.

Task 10: Inspect Apache for error document misconfiguration

cr0x@server:~$ sudo apachectl -t -D DUMP_VHOSTS 2>/dev/null | head
VirtualHost configuration:
*:80                   example.com (/etc/apache2/sites-enabled/000-default.conf:1)

cr0x@server:~$ sudo grep -R "ErrorDocument 404" -n /etc/apache2/sites-enabled /var/www 2>/dev/null | head
/etc/apache2/sites-enabled/000-default.conf:23:ErrorDocument 404 /index.php

Ce que cela signifie : Si Apache redirige les 404 vers /index.php sans préserver le statut 404, WordPress peut finir par répondre 200 avec une page ressemblant à une 404.

Décision : Utilisez un document 404 dédié qui conserve le statut, ou assurez-vous que la couche PHP/WordPress définit le bon code quand elle rend « not found ».

Task 11: Confirm WordPress can produce a true 404 via WP-CLI evaluation

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ wp eval 'echo is_404() ? "is_404\n" : "not_404\n";'
not_404

Ce que cela signifie : Si vous lancez ceci en contexte de requête c’est plus délicat, mais en vérification rapide cela peut révéler que WordPress ne traite pas certains patterns « manquants » comme des 404 (fréquent avec des rewrites personnalisés ou des plugins).

Décision : Auditez les règles de rewrite et le routage des types de contenu personnalisés. Si un plugin détourne le routage, désactivez-le et retestez. Si c’est du code sur mesure, corrigez la requête et la gestion 404 pour que WordPress déclenche correctement un 404.

Task 12: Detect “soft 404 by thinness” using content length

cr0x@server:~$ curl -sS https://example.com/tag/obsolete/ | wc -c
8123

cr0x@server:~$ curl -sS https://example.com/real-article/ | wc -c
128944

Ce que cela signifie : La page de tag est minuscule comparée au vrai contenu. Ce n’est pas toujours incorrect, mais si elle est surtout boilerplate avec « Aucun article trouvé », Google la classera probablement en soft 404.

Décision : Améliorez-la (ajoutez du texte unique, affichez de vrais éléments) ou marquez-la noindex et cessez de la lier de manière à la présenter comme une page centrale.

Task 13: Check sitemap entries for URLs that shouldn’t exist

cr0x@server:~$ curl -sS https://example.com/sitemap.xml | grep -Eo '<loc>[^<]+' | head
https://example.com/
https://example.com/tag/obsolete/
https://example.com/page/99/

Ce que cela signifie : Votre sitemap annonce des URLs minces/vides. Google les explorera, les jugera, puis vous signalera. C’est logique.

Décision : Corrigez la génération du sitemap (paramètres du plugin SEO). N’incluez que des URLs dignes d’indexation. Les sitemaps sont un contrat ; ne signez pas ce que vous ne pouvez pas tenir.

Task 14: Verify the server returns 410 for permanently removed content

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/old-campaign-2019 | head -n 6
HTTP/2 410
date: Sat, 27 Dec 2025 10:20:09 GMT
content-type: text/html; charset=UTF-8
server: nginx

Ce que cela signifie : 410 Gone communique clairement la permanence. Google supprime généralement ces pages plus vite que des 404.

Décision : Utilisez 410 pour les contenus supprimés intentionnellement que vous ne prévoyez pas de remplacer, surtout s’ils continuent d’être crawlés. Utilisez 404 pour les URLs inconnues/typos.

Task 15: Verify no “helpful” redirect plugin is masking 404s

cr0x@server:~$ wp plugin list --status=active
+---------------------+----------+--------+---------+
| name                | status   | update | version |
+---------------------+----------+--------+---------+
| redirection         | active   | none   | 5.4.2   |
| wp-super-cache      | active   | none   | 1.9.4   |
| seo-plugin          | active   | none   | 21.2    |
+---------------------+----------+--------+---------+

Ce que cela signifie : Les plugins de redirection sont utiles — jusqu’à ce que quelqu’un active une règle globale comme « rediriger tous les 404 vers la page d’accueil ».

Décision : Auditez les règles. Supprimez les redirections globales 404→home. Remplacez-les par des redirections 301 spécifiques qui mappent les anciennes URLs aux nouvelles plus proches.

Task 16: Confirm your 404 page is marked as 404 (not cached as 200)

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/definitely-missing | egrep -i 'HTTP/|cache-control|age|x-cache|via'
HTTP/2 404
cache-control: no-cache, must-revalidate, max-age=0
x-cache: MISS

Ce que cela signifie : C’est ce que vous voulez : statut correct, mise en cache prudente.

Décision : Déployez cela. Puis purgez tous les 200 obsolètes en cache et demandez un recrawl dans Search Console pour les URLs clés après les corrections.

Trois mini-récits d’entreprise du terrain

Mini-récit n°1 : L’incident causé par une mauvaise hypothèse

Une entreprise e‑commerce de taille moyenne a migré d’un ancien CMS vers WordPress avec un thème flambant neuf. L’équipe a fait ce que font toutes les équipes : testé manuellement les 50 pages principales. Tout semblait « fonctionner ». Ils ont déployé la bascule un vendredi après-midi, parce que bien sûr ils l’ont fait.

En une semaine, Search Console s’est enflammé avec des soft 404 sur des URLs produit. Les pages produits étaient toujours visibles pour les humains, mais Google a commencé à les supprimer. Le trafic organique a chuté, le trafic payant continuait à convertir, et le CEO a découvert le rapport de couverture d’index.

L’hypothèse erronée : « Si la page se charge, le statut doit être 200 et c’est bon. » Le thème affichait un template « produit non disponible » lorsque le stock était nul — mais renvoyait 200 et définissait le canonique sur la page catégorie. Ce n’était pas une page produit ; c’était une page déguisée en manquante.

Ils ont corrigé cela en ne renvoyant 200 pour les produits en rupture de stock que si la page contenait de vraies informations produit et des alternatives. Les produits définitivement supprimés renvoyaient 410 avec des redirections pertinentes quand possible. Ils ont aussi corrigé les balises canoniques pour que les vrais produits se référencent eux-mêmes. L’indexation a progressivement récupéré à mesure que Google recrawlait ; la clé a été la cohérence et l’absence de comportements oscillants.

Mini-récit n°2 : L’optimisation qui a mal tourné

Un site média voulait réduire la charge sur l’origine. Ils ont poussé une mise en cache agressive au CDN et ajouté une règle : mettre en cache le HTML 24 heures, y compris les « pages d’erreur », car cela améliorait le taux de hit et rendait les dashboards plus calmes.

Puis WordPress a eu un bref incident de base de données. Pendant quelques minutes, de nombreuses pages ont rendu un template minimal disant « Aucun article trouvé » (car les requêtes échouaient). L’origine renvoyait toujours 200 puisque la couche PHP n’a pas généré d’erreur dure. Le CDN a mis en cache ces réponses pendant une journée.

Les humains se sont plaints d’abord, mais le vrai dommage a été plus discret : Googlebot a crawlé pendant la fenêtre dégradée, a vu beaucoup de pages presque vides en 200, et les a marquées soft 404. Même après la récupération de la base, Google continuait de voir l’état vide en cache.

La correction fut peu glamour : arrêter de mettre en cache les réponses HTML qui correspondent à des motifs d’erreur, mettre un TTL bref pour les 5xx, et donner aux 404 un TTL raisonnable. Ils ont aussi ajouté une barrière d’état applicative : si WordPress ne peut pas interroger le contenu, retourner 503, pas une page vide « réussie ». Les métriques de perf ont légèrement souffert ; l’indexation et la confiance des utilisateurs se sont améliorées. Choisissez votre poison avec soin.

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise B2B SaaS régulée utilisait WordPress pour la documentation et les landing pages. Leur équipe SRE insistait sur une chose qui faisait bureaucratique : un job hebdomadaire de crawl-et-vérification qui échantillonnait des URLs du sitemap et vérifiait statut, canonique et taille du contenu.

Cela n’était pas spectaculaire. Ça tournait depuis un runner CI avec curl et exportait les résultats dans un tableur et un canal d’alerte. Le marketing levait parfois les yeux au ciel. Le SRE les rabaissait parfois. La paix régnait.

Pendant une mise à jour de plugin, un plugin de cache a commencé à servir le template 404 pour certains archives paginées à cause d’un bug de coin. Les pages renvoyaient 200 avec « Nothing Found ». Le job hebdomadaire a détecté l’anomalie en quelques heures, pas en quelques semaines, et ils ont rollbacké avant que Google ne retrait un volume significatif du site.

La pratique n’a pas gagné d’awards. Elle a évité un désordre d’indexation, ce qui est la chose la plus proche d’un award pour les ops.

Blague #2 : Le moyen le plus rapide de créer des soft 404 est de « simplifier les redirections » juste avant un week-end prolongé. Le second le plus rapide est de le dire à voix haute.

Erreurs courantes : symptôme → cause racine → correction

1) « Soft 404 » sur des URLs qui affichent un message 404 aux utilisateurs

Symptôme : La page dit « Not Found », mais le serveur renvoie 200.

Cause racine : Le thème rend le template 404 tandis que le statut serveur reste 200, ou Nginx/Apache réécrit les 404 vers index.

Correction : Assurez-vous que la réponse HTTP est 404. Supprimez les patterns error_page 404 =200. Vérifiez avec curl -I et avec un user agent Googlebot.

2) Pages manquantes redirigées vers la page d’accueil

Symptôme : Beaucoup d’anciennes URLs redirigent vers / ; Search Console signale des soft 404.

Cause racine : Plugin de redirection « utile » envoyant tous les 404 vers la home, ou règles de rewrite globales.

Correction : Remplacez les redirections globales par des 301 spécifiques vers des remplacements pertinents. S’il n’y a pas de remplacement, retournez 404 ou 410.

3) Pages d’archives signalées comme soft 404

Symptôme : URLs de tag, author, date ou pagination listées comme soft 404.

Cause racine : Archives vides ou pages ultra-maigres principalement boilerplate.

Correction : Décidez : soit les rendre utiles (contenu d’intro soigné, curation, maillage interne réel), soit mettre noindex et les retirer des sitemaps.

4) Pics de soft 404 après activation du cache CDN

Symptôme : Search Console signale beaucoup d’URLs peu après des changements de cache.

Cause racine : Le cache a stocké des réponses vides/d’erreur en 200 et les a servies longuement à Googlebot.

Correction : Ajustez les règles de cache : ne mettez pas en cache les templates d’erreur, gardez un TTL conservateur pour 404/5xx, purgez après correctifs et évitez de cacher des réponses personnalisées ou challengées pour les bots.

5) Google voit « Accès refusé » ou des interstitiels

Symptôme : Soft 404 ou « Crawled – currently not indexed » pour des URLs importantes ; fetch-as-bot montre une page de blocage.

Cause racine : WAF, protection bot, règles géo ou murs de consentement servis à Googlebot.

Correction : Autorisez Googlebot (vérifiez par reverse DNS si vous êtes strict), ou servez des 403/401 et acceptez la non-indexation. Ne servez pas des pages de blocage en 200.

6) Balises canoniques qui regroupent beaucoup de pages en une seule

Symptôme : Beaucoup d’URLs ont un canonique pointant vers la page d’accueil ou une catégorie ; l’indexation chute.

Cause racine : Mauvaise configuration du plugin SEO, bug de thème ou hack anti-duplicates mal orienté.

Correction : Mettez le canonique vers soi pour les vraies pages. Utilisez la canonicalisation intentionnellement, pas comme bouton panique.

7) Endpoints JSON/REST ou URLs paramétrées indexés et signalés

Symptôme : Search Console montre des soft 404 pour des URLs étranges comme des chaînes de requête ou des endpoints API.

Cause racine : Liens de recherche internes exposés, pages paramétrées crawlables ou plugin générant des URLs poubelles.

Correction : Cessez de générer des chemins crawlables : restreignez les liens internes, envisagez noindex pour les résultats de recherche, et assurez-vous que les endpoints non-HTML ne figurent pas dans les sitemaps.

Listes de contrôle / plan étape par étape

Étape 1 : Trier les URLs

• Bucket A : Doit exister et être indexé (pages monétaires, docs clés).
• Bucket B : Doit exister mais ne pas être indexé (recherche interne, certaines archives).
• Bucket C : Ne doit pas exister (campagnes supprimées, fautes de frappe, URLs spam).

N’utilisez pas un comportement global pour tous les buckets. C’est comme ça qu’on obtient des soft 404 — et des réunions.

Étape 2 : Pour le Bucket A, rendez la page indiscutablement réelle

• Retournez 200 avec un contenu principal substantiel.
• Assurez-vous que le canonique se réfère à elle-même.
• Évitez les pages « aucun résultat » déguisées en pages de contenu.
• Corrigez les différences de rendu pour Googlebot.
• Assurez-vous que la page n’est pas bloquée par un WAF, auth ou directives robots.

Étape 3 : Pour le Bucket B, restez honnête et intentionnel

• Retournez 200 mais ajoutez noindex via meta robots (ou X-Robots-Tag si vous contrôlez les headers).
• Retirez-les des sitemaps XML.
• Réduisez les liens internes qui les présentent comme importants.

Étape 4 : Pour le Bucket C, faites disparaître proprement

• Retournez 404 pour les URLs inconnues/typos.
• Retournez 410 pour les contenus supprimés intentionnellement que vous ne remplacez pas.
• Ne redirigez que lorsqu’il existe un remplaçant pertinent. Rediriger vers la home est rarement pertinent.

Étape 5 : Corrigez les comportements de plateforme qui créent des soft 404 à grande échelle

• Thème : Vérifiez que les templates 404 n’écrasent pas les codes de statut.
• Plugins : Auditez les plugins de redirection et SEO pour les règles globales et le comportement des canoniques.
• Config serveur : Supprimez les réécritures 404→200 et les hacks « catch-all ».
• CDN : Ne mettez pas en cache les réponses vides/transitoires sous forme HTML longue durée.
• Monitoring : Ajoutez un crawl programmé qui échantillonne les URLs importantes et vérifie statut et taille du contenu.

Étape 6 : Validez puis demandez à Google de réévaluer

• Retestez avec curl -I et l’UA Googlebot.
• Purgez les caches après la correction.
• Dans Search Console, demandez la réindexation des URLs les plus impactées. Ne perdez pas de temps sur des milliers d’URLs ; corrigez les problèmes systémiques et laissez le crawl rattraper le reste.

Faits et contexte historique (utile, pas trivia)

• Fait 1 : « Soft 404 » n’est pas un statut HTTP. C’est une classification par le moteur de recherche superposée à votre réponse réelle.
• Fait 2 : Les premiers serveurs web servaient souvent des pages d’erreur personnalisées, mais le code de statut HTTP comptait toujours ; les moteurs ont appris à se méfier des « jolies erreurs » en 200.
• Fait 3 : La flexibilité des permalinks et des rewrites de WordPress est une arme à double tranchant : elle fait « résoudre » beaucoup d’URLs même lorsqu’il n’y a pas de contenu.
• Fait 4 : La tendance vers les SPA et les thèmes lourds en JS a augmenté les cas où les crawlers reçoivent des « coques vides », ressemblant à des soft 404 quand le rendu échoue.
• Fait 5 : L’adoption des CDN a amélioré la performance mais amplifié les bugs : une mauvaise réponse mise en cache globalement peut changer ce que les crawlers voient pendant des jours.
• Fait 6 : Les moteurs traitent les redirections massives vers la page d’accueil comme un problème de qualité ; cela ressemble à des « redirections trompeuses » ou à un comportement de faible valeur.
• Fait 7 : 410 Gone existe depuis des décennies mais est sous-utilisé ; il peut accélérer la suppression quand vous signifiez « définitivement parti ».
• Fait 8 : Les paramètres et la navigation facettée ont explosé avec l’e‑commerce et les tags CMS ; les moteurs ont commencé à classer beaucoup de combinaisons quasi-vides comme de faible valeur ou proches des soft 404.
• Fait 9 : La gestion des bots est devenue une catégorie produit ; challenger ou bloquer accidentellement Googlebot est désormais une cause courante d’anomalies d’indexation.

FAQ

1) Un soft 404 est‑il toujours mauvais ?

C’est mauvais s’il concerne des URLs que vous voulez indexer. Si Google signale une URL poubelle comme soft 404, c’est en quelque sorte un nettoyage gratuit. Le problème survient lorsque vos pages importantes sont mal classées.

2) Dois‑je rediriger tous les 404 vers la page d’accueil pour « sauver le SEO » ?

Non. C’est un déclencheur classique de soft 404. Redirigez uniquement lorsqu’il existe un remplaçant pertinent. Sinon, retournez 404 ou 410.

3) Qu’est‑ce qui est préférable : 404 ou 410 ?

404 signifie « non trouvé (peut être temporaire) ». 410 signifie « disparu (intentionnel) ». Utilisez 410 pour les suppressions volontaires que vous ne prévoyez pas de restaurer, surtout si elles sont souvent crawlées.

4) Le contenu maigre seul peut‑il provoquer un soft 404 ?

Oui. Si une page est surtout boilerplate avec peu de contenu principal unique, Google peut la considérer comme effectivement manquante. C’est fréquent sur les archives vides, les pages de résultats et les profondes paginations.

5) Ma page 404 WordPress a l’air correcte — pourquoi Google s’en plaint encore ?

Parce que Google regarde le code de statut et l’intention. Si vous retournez 200 avec un message type 404, ou que vous canonicalisez tout vers la home, Google le qualifiera de ce que c’est : pas une vraie page.

6) Le cache peut‑il causer des soft 404 même si l’origine est maintenant correcte ?

Absolument. Un CDN peut mettre en cache une réponse vide transitoire en 200. Googlebot touche la version en cache, pas votre origine fraîchement corrigée, jusqu’à expiration du TTL ou purge.

7) Dois‑je mettre en noindex les pages qui sont soft 404 ?

Si la page doit exister et être indexée, corrigez‑la plutôt que de la noindexer. Si elle doit exister mais pas être indexée (comme la recherche interne), le noindex est approprié — à condition qu’elle reste utile pour les utilisateurs.

8) Combien de temps faut‑il à Google pour récupérer après des corrections ?

Ça dépend de la fréquence de crawl et de la taille du site. Les pages importantes peuvent se mettre à jour en quelques jours ; les pages long‑tail peuvent prendre des semaines. Le chemin le plus rapide : corriger les problèmes systémiques, purger les caches, puis demander la réindexation des URLs prioritaires.

9) Dois‑je modifier le core WordPress pour résoudre ça ?

Généralement non. La plupart des causes sont le comportement du thème, des plugins de redirection/canonical, la config serveur (réécritures 404→200) et les règles de cache/WAF. Commencez par là.

10) Pourquoi Google marquerait‑il une vraie page comme soft 404 lors d’une migration ?

Les migrations créent souvent des chaînes de redirections, des canoniques incohérents, des pages placeholder maigres ou des réponses de maintenance temporaires servies en 200. Google voit l’incohérence et classe défensivement.

Conclusion : prochaines étapes qui font vraiment la différence

Les soft 404 ne sont pas mystiques. Ce sont des décalages entre ce que votre serveur affirme (200) et ce que votre contenu communique (« rien ici »), souvent amplifiés par redirections et caches. Corrigez le décalage, et Google se calmera généralement.

1. Choisissez 10 URLs signalées et appliquez le guide de diagnostic rapide : statut, redirections, vue bot, comportement du cache.
2. Retirez les redirections globales 404→home. Remplacez par des mappings spécifiques et pertinents ou retournez 404/410.
3. Faites des 404 de vrais 404. Auditez les règles Nginx/Apache et le comportement du thème qui forcent le 200.
4. Décidez ce qui mérite l’indexation. Si les archives/recherches sont maigres, enrichissez‑les ou mettez‑les en noindex et retirez‑les des sitemaps.
5. Corrigez la politique de cache pour que le vide transitoire ne devienne pas une vérité globale de 24 heures.
6. Ajoutez un crawl hebdomadaire ennuyeux. L’ennui est fiable. Le fiable est rentable.

Si vous faites ce qui précède, Search Console arrêtera de vous dénoncer, Googlebot cessera de se méfier de votre site, et vous recevrez moins d’alertes d’urgence sur la « chute mystérieuse du trafic ». Ce sont les vrais KPI.