Soft 404 et codes HTTP : renvoyer la bonne réponse

Un soft 404 est une page qui annonce au visiteur qu’elle est introuvable tout en disant au robot que tout va bien. Google le définit comme une réponse 2xx dont le contenu est une erreur, et la Search Console signale ceux qu’elle détecte. Dans un navigateur, la page paraît correcte : seule la ligne de statut la trahit.

Quel statut pour quelle situation

La documentation de Google attache à chaque famille de statuts une conséquence différente, et un robot lit le statut avant le premier mot de votre page. Le tableau s’en tient à ce que cette documentation énonce et ajoute, dans la dernière colonne, notre propre usage.

Deux détails méritent d’être retenus. Google suit jusqu’à 10 redirections successives, mais chaque saut est une requête de plus : nous visons exactement un saut. Il traite le 301 comme un signal fort et le 302 comme un signal faible, le 308 et le 307 se comportant comme leurs équivalents 301 et 302 : un déplacement définitif doit donc se déclarer comme tel. La façon dont les redirections nourrissent le choix d’une adresse canonique est expliquée dans notre guide sur les balises canoniques.

Google met le 404 et le 410 sur un pied d’égalité pour le retrait de l’index. Notre convention, qui n’est pas une distinction de Google : 410 pour les pages que nous avons retirées exprès et que nous ne comptons pas remettre, 404 pour tout le reste.

Comment naissent les soft 404

Les soft 404 sont presque toujours un accident de construction du site. Quatre schémas méritent d’être vérifiés, dans cet ordre.

Le premier est la route fourre-tout. Une application monopage, ou une règle de serveur écrite pour en servir une, répond à tout chemin inconnu avec la même coquille HTML et un 200, puis l’application affiche « page introuvable » en JavaScript. Le robot voit un 200 pour /n-importe-quoi. La bonne correction se fait côté serveur : les routes connues reçoivent la coquille, tout le reste reçoit un statut 404. Si le routage est purement côté client et que vous ne pouvez pas toucher au serveur, nous recommandons en solution de repli que l’application ajoute une balise meta robots noindex quand la route est inconnue, ou qu’elle renvoie le visiteur vers une URL que le serveur traite par un 404.

Le deuxième est la page d’erreur « sympathique » avec le mauvais statut. Dans nginx, error_page 404 =200 /404.html; réécrit le statut en 200. Dans Apache, ErrorDocument 404 https://example.com/404.html avec une URL complète fait envoyer une redirection au lieu de servir la page : le visiteur arrive sur une URL qui répond 200. La documentation d’Apache le dit : avec une URL absolue, le client ne voit plus le statut d’erreur d’origine.

Le troisième est la liste vide : une page de recherche sans résultat, une page d’étiquette sans article, une catégorie qui ne contient rien. Elles répondent 200 et affichent « aucun résultat ». Ce sont aussi des pages minces selon la logique de la politique de Google sur le contenu de faible valeur ajoutée. Si un ensemble vide est légitime, renvoyez-lui un 404, ou gardez-le hors du sitemap et ajoutez noindex.

Le quatrième est la redirection bien rangée : toutes les URL supprimées envoyées vers l’accueil. Le visiteur qui voulait un article atterrit sur une autre page, et la Search Console peut aussi signaler ces redirections comme des soft 404. Ne redirigez que vers une page qui remplace l’ancienne. Quand rien ne la remplace, répondez 404 ou 410.

Testez votre site en trois commandes

Utilisez une adresse qui ne peut pas exister, par exemple avec un suffixe aléatoire. curl -sI envoie une requête HEAD et n’affiche que les en-têtes, et head -n 1 ne garde que la ligne de statut. Dans Windows PowerShell 5.1, tapez curl.exe, car curl seul y est un alias de Invoke-WebRequest.

# 1. Une URL qui ne peut pas exister doit répondre 404 (ou 410)
curl -sI https://example.com/no-such-page-7f3k2x | head -n 1

# 2. Une page supprimée exprès doit répondre 404, 410 ou un 301 vers un vrai remplaçant
curl -sI https://example.com/a-page-you-deleted | head -n 1

# 3. Une ancienne URL doit atteindre sa cible en un saut : statut et Location de chaque étape
curl -sIL http://example.com/old-url | grep -iE '^(HTTP|location)'

Les deux premières doivent afficher quelque chose comme HTTP/2 404. La troisième affiche une ligne de statut et une ligne Location pour chaque saut : comptez les paires, vous voulez un seul 301, puis un 200. Certaines applications répondent différemment à HEAD et à GET ; si un résultat paraît faux, recommencez avec curl -s -o /dev/null -w '%{http_code}\n' URL. Dans un navigateur, l’onglet Réseau des outils de développement affiche le statut de la requête du document : une page dont le texte dit « introuvable » à côté d’un 200 est un soft 404 pris sur le fait.

Servir une vraie page 404

Dans nginx, le comportement par défaut convient tant que vous ne modifiez pas le statut. Le fichier ci-dessous est servi avec un statut 404 parce que error_page n’a pas de code précédé de = devant le chemin.

server {
    listen 443 ssl;
    server_name example.com;
    root /var/www/example.com;
    # ssl_certificate et ssl_certificate_key omis par souci de brièveté

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

    error_page 404 410 /404.html;
    location = /404.html {
        internal;
    }

    # Une page retirée exprès
    location = /old-guide/ {
        return 410;
    }
}

La version qui crée des soft 404 a l’air innocente, et c’est pourquoi elle se propage de tutoriel en tutoriel :

# À ne pas copier : toute URL inconnue reçoit la coquille de l'application et un 200
location / {
    try_files $uri /index.html;
}
error_page 404 =200 /404.html;

Dans Apache, donnez à ErrorDocument un chemin local, jamais une URL complète. Dans un .htaccess, la directive demande AllowOverride FileInfo.

ErrorDocument 404 /404.html

# Une page retirée exprès
Redirect gone /old-guide/

La page 404 elle-même doit garder l’en-tête du site, dire clairement qu’il n’y a rien à cette adresse et proposer deux ou trois destinations utiles. Ne la faites pas rediriger automatiquement vers l’accueil, ce qui revient à une redirection déguisée, et n’y mettez pas d’annonces : la politique de Google sur les écrans sans contenu éditeur cite les pages d’erreur parmi les endroits où ses annonces sont interdites.

Notre sonde, nos journaux, et que faire quand la Search Console signale une URL

Notre vérificateur AdSense comprend un test de gestion correcte des 404. Il demande un chemin inventé sous votre domaine. Un 404 ou un 410 réussit. Un 200 dont le texte dit que la page n’existe pas déclenche une alerte de soft 404, et un 200 au contenu ordinaire échoue. Ce site est fait de fichiers statiques servis par nginx avec try_files $uri $uri/ =404; et error_page 404 /404.html;, sur le même modèle que le premier extrait, et il réussit sa propre sonde.

Les journaux montrent pourquoi cette habitude compte. Entre le 23 septembre et le 7 octobre 2026, 3 317 de nos 5 213 requêtes ont reçu une réponse 404, soit 63,6 % du total, surtout des scanners à la recherche de fichiers .env et de chemins WordPress (le détail complet figure dans notre étude des journaux serveur). Chacune de ces réponses portait un vrai statut 404 : un robot qui tombe sur l’une d’elles apprend en une seule requête que l’adresse est une impasse. Si nous avions répondu par une page 200 accueillante, chaque adresse de ce type atteinte par un robot aurait pu rejoindre la liste des soft 404 de la Search Console.

Quand la Search Console classe une URL en soft 404, décidez au cas par cas. Si la page ne doit pas exister, renvoyez 404 ou 410 et retirez-la de votre sitemap. Si elle doit exister mais reste mince, enrichissez-la ou fusionnez-la dans une meilleure page. Si c’est une vraie page signalée à tort, vérifiez que son contenu principal figure dans le HTML envoyé par le serveur et que rien ne se casse pendant le chargement, puis demandez à la Search Console de valider la correction. Notre vérificateur SEO teste une page pour l’indexabilité, la présence dans le sitemap et les chaînes de redirections, ce qui couvre les suspects habituels.