Faut-il vraiment s'assurer que les pages supprimées renvoient le bon code HTTP ?

Qu'est-ce qu'un code HTTP approprié pour une page supprimée ?

Quand une page n'existe plus sur votre site, le serveur doit indiquer clairement cette absence au crawler. Le code HTTP 404 (Not Found) signale qu'une ressource n'existe pas temporairement, tandis que le code 410 (Gone) indique une suppression définitive.

Google préfère ces signaux clairs plutôt qu'une page qui renvoie un code 200 (OK) tout en affichant un message « page introuvable ». Ce dernier cas crée ce qu'on appelle des soft 404 : le serveur prétend que tout va bien alors que la page est vide ou inexistante.

Pourquoi la plupart des sites gèrent ça automatiquement ?

Les CMS modernes (WordPress, Shopify, Prestashop) retournent par défaut une 404 quand une URL n'existe pas dans leur base de données. C'est un comportement natif — aucune configuration supplémentaire nécessaire dans 90% des cas.

Le problème survient avec des configurations serveur personnalisées, des redirections mal paramétrées ou des pages générées dynamiquement qui affichent du contenu vide sans modifier le code de réponse. Certains sites e-commerce, par exemple, affichent une page catégorie vide avec un 200 au lieu de supprimer la catégorie complètement.

Que se passe-t-il si le code HTTP est incorrect ?

Google continue d'explorer et potentiellement d'indexer des pages fantômes. Votre budget crawl se disperse sur des URLs inutiles. Dans la Search Console, vous verrez des avertissements « Page indexée, bien que bloquée par robots.txt » ou « Explorée, actuellement non indexée » qui traduisent cette confusion.

Pire : si une page supprimée renvoie un 200 avec peu ou pas de contenu, Google peut la considérer comme du thin content et dégrader la perception de qualité globale du site.

• Une 404 dit à Google : « cette page n'existe pas, arrête de la crawler »
• Une 410 dit : « cette page a été supprimée définitivement, oublie-la »
• Un 200 sur une page vide crée une soft 404 qui gaspille le crawl budget
• Les CMS modernes gèrent les 404 nativement, mais vérifier reste indispensable sur des configs custom
• Les soft 404 peuvent dégrader la perception de qualité du site par Google

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et c'est même un classique des audits techniques. On tombe régulièrement sur des sites qui affichent « Désolé, cette page n'existe pas » avec un code 200. Google identifie ces soft 404 dans la Search Console, mais certains restent indexés pendant des mois avant d'être filtrés.

Ce qui coince souvent : les pages de paramètres URL dynamiques (filtres, facettes) qui génèrent des combinaisons vides. Un site e-commerce peut créer des milliers de pages produits filtrées qui affichent « 0 résultat » avec un 200. Google perd du temps à explorer tout ça.

Quelle nuance faut-il apporter sur le choix entre 404 et 410 ?

Mueller dit « code approprié » sans préciser lequel. Terrain : la 410 accélère effectivement le retrait de l'index, mais son impact reste marginal par rapport à une 404. Google traite les deux comme des signaux de suppression, la différence se joue sur quelques jours de désindexation.

Utiliser une 410 a du sens pour des pages définitivement supprimées (produit arrêté, contenu obsolète). Mais une 404 suffit dans 99% des cas. Ne vous compliquez pas la vie avec des règles serveur complexes pour distinguer les deux — concentrez-vous d'abord sur l'élimination des soft 404.

Dans quels cas cette règle ne s'applique-t-elle pas strictement ?

Quand vous utilisez une 301 pour rediriger une page supprimée vers une alternative pertinente. Si un produit n'existe plus mais qu'une version actualisée le remplace, une redirection 301 reste préférable à une 404 sèche. Google transfère une partie du jus SEO et l'utilisateur atterrit sur du contenu utile.

Autre exception : les pages paginées en fin de série. Si votre blog affiche « page 47 » vide parce que vous avez supprimé des articles, une 404 est correcte. Mais si cette page 47 existait et contenait du contenu indexé, une 301 vers la dernière page valide (ou vers l'archive principale) conserve mieux l'équité de liens. [À vérifier] : l'impact réel de cette pratique sur le classement reste difficile à mesurer de manière isolée.

Comment vérifier que votre site retourne les bons codes HTTP ?

Crawlez votre site avec Screaming Frog ou un équivalent. Filtrez les URLs par code de statut et identifiez celles qui renvoient un 200 avec peu ou pas de contenu. Exportez la liste et croisez avec la Search Console : section Couverture > Exclues > « Explorée, actuellement non indexée » ou « Soft 404 ».

Testez manuellement une URL inexistante (ex : votresite.com/page-qui-nexiste-pas-123456). Utilisez un outil en ligne comme httpstatus.io ou l'extension HTTP Header Live pour Firefox. Si vous voyez un 200 au lieu d'un 404, votre serveur ou CMS est mal configuré.

Quelles erreurs éviter lors de la gestion des pages supprimées ?

Ne redirigez pas systématiquement tout vers la homepage en 301. C'est du soft 404 déguisé : Google comprend que la page n'existe plus, mais vous gaspillez du crawl et créez une mauvaise expérience utilisateur. Une 404 propre avec une page d'erreur utile (suggestions de contenu, moteur de recherche interne) vaut mieux.

Évitez les pages 404 personnalisées qui chargent du JavaScript pour afficher du contenu. Si le code HTTP reste 404 mais que la page affiche des centaines de liens, Google peut la considérer comme indexable. Gardez vos pages d'erreur simples et légères.

Que faire concrètement pour nettoyer les soft 404 existantes ?

Corrigez le code serveur ou la configuration du CMS pour retourner une vraie 404. Supprimez les plugins ou règles .htaccess qui interceptent les erreurs et les transforment en 200. Sur WordPress, désactivez les thèmes qui affichent une page « article introuvable » sans modifier le header HTTP.

Pour les pages légitimement supprimées qui ont des backlinks ou du trafic résiduel, mettez en place des 301 ciblées vers des contenus équivalents. Ne laissez pas des 404 sur des URLs qui reçoivent encore des visites — vous perdez des opportunités de conversion.

• Crawler le site et identifier les pages avec code 200 et contenu vide ou minimal
• Vérifier la Search Console : sections « Soft 404 » et « Explorée, actuellement non indexée »
• Tester manuellement des URLs inexistantes pour confirmer le code HTTP retourné
• Corriger la config serveur ou CMS pour retourner des 404 propres sur les pages supprimées
• Mettre en place des 301 ciblées pour les pages supprimées avec backlinks ou trafic
• Simplifier les pages d'erreur 404 : contenu léger, pas de JavaScript lourd
• Éviter les redirections massives vers la homepage (soft 404 déguisé)