Google traite les codes 404 et 410 différemment, et la différence compte quand vous retirez des URLs en masse. La version courte : 404 signifie « manquant, réessayez plus tard » ; 410 signifie « disparu, ne revient jamais ». Googlebot revisiste les 404 pendant des semaines avant de les supprimer de l'index. Il supprime les 410 en quelques jours. Si vous êtes en pleine migration et que vous regardez des milliers d'URLs qui doivent disparaître pour toujours, choisir le bon code réduit de plusieurs semaines le nettoyage.
Ce que chaque code signifie réellement
404 Not Found est la réponse par défaut quand une ressource n'existe pas à l'URL demandée. Le serveur dit « cette URL n'a pas de ressource en ce moment ». L'implication est permissive : peut-être que l'URL aura une ressource plus tard, peut-être que c'est une faute de frappe, peut-être que la ressource a été déplacée et quelqu'un a oublié de mettre une redirection en place. Le 404 est un filet très large.
410 Gone est le code de retrait explicite. Le serveur dit « cette URL avait une ressource, elle a été supprimée de façon permanente, ne demandez pas à nouveau ». C'est le signal de fermeture de porte. Google documente cela explicitement : 410 est interprété comme un signal plus fort pour supprimer l'URL de l'index que 404.
Comment Googlebot traite chacun
Comportement du 404. Googlebot rencontre un 404, marque l'URL comme manquante, mais la garde dans la queue de crawl. Le bot revisiste l'URL selon un calendrier ralentissant (24h, puis 7j, puis 30j, puis 90j). Si l'URL retourne finalement un 200, elle est réintégrée. Le cycle continue pendant des mois. L'URL reste dans le rapport Coverage de Search Console sous « Non trouvée (404) » pendant toute la durée.
Comportement 410. Googlebot rencontre un 410, marque l'URL comme définitivement retirée, la supprime de l'index en quelques jours. L'URL apparaît brièvement dans Search Console sous « Page supprimée en raison d'une réclamation légale » ou « Soft 404 » selon l'interprétation de Google, puis disparaît. La file d'attente de crawl cesse de la revisiter.
La différence fonctionnelle est quelques jours contre quelques mois de pollution d'index.
Quand choisir 410 plutôt que 404
- Nettoyage de migration : URLs qui n'existent plus sur le nouveau site et n'ont pas d'équivalent sémantique. Utilisez 410. Elles sont parties.
- Articles de blog supprimés : ancien contenu que vous avez volontairement retiré. 410 si vous êtes confiant ; 404 s'il y a une chance que l'article revienne sous le même slug.
- Pages produits décommissionnées : SKUs que vous ne vendez plus. 410 si le produit est définitivement retiré ; 404 s'il pourrait revenir.
- Abandon de motif d'URL : par ex. retirer /forum/* parce que le forum a été décommissionné. 410 sur l'ensemble du chemin.
- URLs de rebut provenant de piratages antérieurs ou d'erreurs CMS qui se sont retrouvées dans l'index. 410.
Quand 404 est le bon choix
- Fautes de frappe et URLs qui n'ont jamais existé : 404 est la réponse conventionnelle. 410 serait faux parce que l'URL n'a jamais eu de contenu pour commencer.
- Contenu en cours de révision pour republication : si l'URL pourrait réapparaître, 404 laisse la porte ouverte pour que Google la découvre à nouveau.
- Pages temporairement indisponibles : 404 est incorrect ici aussi — utilisez 503 avec un en-tête Retry-After. Mais en l'absence de celui-ci, 404 est le choix par défaut plus sûr pour les cas ambigus.
Comment configurer 410 sur les plateformes courantes
Vercel (vercel.json)
Ajoutez une règle de réécriture ou de code de statut. Le modèle le plus propre est de déployer un endpoint /410 et de réécrire les URLs retirées vers celui-ci avec statusCode 410. Notez que vercel.json supporte nativement les redirections, pas les réécritures de code de statut pour des URLs arbitraires ; le modèle consiste à utiliser un middleware Next.js qui retourne new Response(null, { status: 410 }) pour toute URL de votre liste de retraits.
Netlify (netlify.toml ou _redirects)
Utilisez la syntaxe _redirects : /retired-url 410! — le point d'exclamation à la fin est le flag force-status. Ou dans netlify.toml, utilisez un bloc [[redirects]] avec status = 410.
Apache (.htaccess)
Redirect gone /retired-url — ou utilisez RewriteRule avec le flag [G] : RewriteRule ^retired-url$ - [G,L].
Nginx
retourner 410 ; à l'intérieur d'un bloc location correspondant au pattern d'URL. Pour les patterns massifs : location ~ ^/old-pattern/ { return 410; }.
Pourquoi cela compte à l'échelle
Un site avec 10 000 URLs retraitées réparties 50/50 entre 404 et 410 verra la moitié en 410 disparaître du rapport Coverage en deux semaines, et la moitié en 404 dériver dans le rapport Coverage pendant trois à six mois. L'ensemble des 404 occupe le budget de crawl de Googlebot qui devrait aller aux URLs que vous voulez indexer. Sur les sites plus grands, l'impact sur le budget est mesurable : moins de budget pour la retraite signifie plus pour les nouveaux contenus.
Le pattern de migration
Trois étapes pour tout nettoyage de migration. Un : récupérer chaque URL depuis Search Console, Ahrefs, et l'ancien sitemap. Deux : catégoriser chaque URL dans l'un des quatre buckets : (a) correspond à une nouvelle URL → redirection 301, (b) renommée en nouveau slug → 301, (c) définitivement retraitée → 410, (d) statut ambigu → 404. Trois : déployer les règles de redirection/410/404 dans vercel.json ou .htaccess en même temps que le nouveau contenu, plus un linter SEO au moment du build qui arrête le déploiement si une URL de pré-migration manque dans l'ensemble des règles.
À savoir : le code 451
451 Unavailable For Legal Reasons existe pour le contenu que vous avez été légalement obligé de supprimer. C'est rare et spécifique — DMCA takedowns, RGPD droit à l'oubli quand l'URL est entièrement retraitée, ordonnances judiciaires. Google l'interprète de manière similaire à 410 (suppression de l'index) mais le signal légal est ce qui compte. N'utilisez-le que quand le contexte légal s'applique.
Le résumé
Utilisez 410 pour la retraite définitive. Utilisez 404 pour le contenu genuinely manquant ou ambigu. La différence d'index-cleanup de deux semaines vs six mois s'observe à chaque migration dépassant quelques milliers d'URLs. La solution est une règle dans vercel.json, netlify.toml, ou .htaccess. Faites-le correctement au moment du cutover et vous économisez le nettoyage post-launch que personne ne budgète.
Lectures adjacentes : 301 vs 302 vs 307 vs 308 est l'appel connexe pour les URLs qui ne sont pas retraitées mais déplacées. Le même nettoyage de migration qui a besoin de 410 a aussi besoin de la décision sur le code de redirection ; voir le post sur la stratégie de redirection pour ce cadre.