Pourquoi Google continue-t-il à crawler des URLs 404 vieilles de plusieurs années ?

Quelle est la durée de vie réelle d'une URL dans la mémoire de Google ?

John Mueller révèle que Google conserve une trace des URLs crawlées pendant au moins 7 à 8 ans, même si elles n'existent plus. Cette durée dépasse largement ce que la plupart des praticiens imaginent. Concrètement, une page supprimée en 2016 peut encore recevoir des tentatives de crawl sporadiques.

Ces URLs rejoignent une file d'attente de faible priorité où Google tente occasionnellement de vérifier si le contenu est revenu. Le moteur n'abandonne pas une URL au premier 404 — il la marque comme inactive mais ne l'oublie pas complètement. Cette persistance s'explique par le fonctionnement historique de l'index : Google préfère garder une trace plutôt que supprimer définitivement.

Comment cette file d'attente de faible priorité fonctionne-t-elle ?

Le mécanisme exact reste flou, mais les observations terrain confirment que Google espace progressivement ses tentatives de crawl sur les URLs qui retournent systématiquement 404 ou 410. Une URL peut être tentée une fois par semaine au début, puis une fois par mois, puis tous les trimestres.

Cette file de faible priorité ne consomme qu'une fraction marginale du crawl budget total. Pour autant, sur un site avec un historique lourd (refonte, migrations multiples, suppressions massives), le volume cumulé peut devenir visible dans les logs. Ces tentatives de crawl ne pénalisent pas directement le référencement, mais elles révèlent la mémoire longue de Google.

Pourquoi Google maintient-il cette persistance sur des URLs mortes ?

Le moteur de recherche ne veut pas manquer une résurrection de contenu. Si une URL historique avec un bon profil de backlinks revient en ligne, Google souhaite la détecter rapidement. Cette logique s'applique surtout aux URLs ayant eu de la visibilité, des liens entrants ou un trafic significatif dans le passé.

De plus, Google sait que certains sites pratiquent des mises hors ligne temporaires ou des migrations mal gérées où des URLs 404 reviennent parfois des mois plus tard. Plutôt que d'effacer toute trace, le moteur préfère conserver une liste d'URLs « à surveiller ». C'est une assurance contre les faux négatifs.

• Google garde en mémoire les URLs pendant 7-8 ans minimum, même après suppression définitive
• Les URLs mortes rejoignent une file d'attente de faible priorité avec tentatives de crawl espacées
• Cette persistance vise à détecter d'éventuelles résurrections de contenu, surtout si l'URL avait du poids
• Le volume de crawl consommé reste marginal mais peut être visible sur des sites avec un lourd historique
• Les codes 410 (Gone) et 404 (Not Found) sont traités de manière similaire sur le long terme

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

Totalement. Les logs serveur de sites ayant subi plusieurs refontes confirment que Googlebot tente régulièrement de crawler des URLs supprimées depuis des années. On observe fréquemment des hits sur des chemins datant de 2015-2017, avec une fréquence faible mais régulière. Mueller ne fait que confirmer officiellement ce que les SEO techniques voient dans leurs logs depuis longtemps.

En revanche, la durée exacte de 7-8 ans reste un ordre de grandeur, pas une règle stricte. Certains sites rapportent des tentatives sur des URLs encore plus anciennes, d'autres voient les tentatives s'arrêter après 3-4 ans. La priorité initiale de l'URL, son profil de liens et son historique de trafic jouent probablement un rôle dans cette durée de rétention. [A vérifier] : aucune donnée officielle ne précise les critères exacts de priorisation dans cette file d'attente.

Faut-il traiter différemment les 404 et les 410 pour accélérer l'oubli ?

Soyons honnêtes : la distinction entre 404 (Not Found) et 410 (Gone) est théoriquement claire, mais en pratique Google les traite de manière très similaire sur le long terme. Le 410 est censé signaler une suppression définitive, mais Mueller précise que même ces URLs restent en file d'attente de faible priorité.

Utiliser un 410 peut légèrement accélérer la désindexation initiale, mais cela ne garantit pas que Google cesse complètement ses tentatives de crawl. La différence se joue surtout dans les premières semaines après la suppression. Passé ce délai, les deux codes convergent vers le même traitement : maintien en mémoire avec tentatives espacées. Ne compte pas sur le 410 comme un bouton magique d'effacement.

Quelles sont les implications cachées pour la gestion du crawl budget ?

Sur un site de taille moyenne avec un crawl budget confortable, cette persistance n'a aucun impact mesurable. Googlebot consacre l'essentiel de ses ressources aux URLs actives et fraîches. Les tentatives sur les anciennes URLs mortes représentent une portion négligeable, souvent moins de 1% du crawl total.

Le problème émerge sur les sites massifs avec un historique de migrations multiples ou des milliers d'URLs supprimées. Si ton crawl budget est déjà tendu (fréquence de crawl faible, pages importantes mises à jour lentement), chaque hit sur une URL morte est un hit qui ne va pas vers du contenu actif. Dans ces cas spécifiques, surveiller les logs et identifier les anciennes URLs encore crawlées peut aider à diagnostiquer des inefficacités. Mais restons pragmatiques : optimiser la structure actuelle du site aura 100 fois plus d'impact que tenter d'effacer la mémoire de Google.

Que faire avec les anciennes URLs qui traînent dans les logs ?

Première étape : identifier le volume réel de crawl consommé par ces URLs mortes. Parse tes logs serveur (Screaming Frog Log Analyzer, Botify, OnCrawl, ou un script custom) et filtre les hits Googlebot sur des URLs retournant 404 ou 410. Si le volume est inférieur à 2-3% du crawl total, ignore-les — ce n'est pas là que se joue ta performance SEO.

Si le volume est significatif (>5% du crawl), creuse. Ces URLs ont-elles encore des backlinks actifs ? Si oui, redirige-les en 301 vers la page la plus pertinente. Si non, laisse le 404 en place et concentre-toi sur l'optimisation du contenu actif. Ne perds pas de temps à nettoyer des URLs qui ne consomment qu'une fraction marginale du budget.

Faut-il bloquer ces URLs dans le robots.txt pour forcer l'oubli ?

Non. Bloquer des URLs 404 dans le robots.txt est une erreur classique qui empire la situation. Si Googlebot ne peut plus crawler l'URL, il ne peut pas confirmer qu'elle retourne bien 404 — donc il la garde en mémoire indéfiniment, en statut « bloqué ». Tu remplaces un crawl occasionnel par une incertitude permanente.

La seule exception concerne les URLs sensibles que tu veux absolument faire disparaître de l'index. Dans ce cas, laisse-les accessibles en 404/410 le temps que Google les désindexe, puis éventuellement bloque-les. Mais pour des URLs mortes ordinaires, le robots.txt n'apporte rien. Laisse Google constater le 404 et espacer naturellement ses tentatives.

Comment gérer les migrations et refontes pour limiter cet effet sur le long terme ?

Lors d'une refonte, mappe proprement toutes les anciennes URLs vers leurs équivalents via des 301. Même si certaines pages n'ont plus d'équivalent direct, redirige vers la catégorie ou la page parent la plus proche. Une 301 bien pensée est toujours préférable à un 404, surtout si l'ancienne URL avait des backlinks ou du trafic.

Pour les URLs vraiment obsolètes (produits discontinués sans remplacement, sections fermées), assume le 404. Mais documente ces choix : garde une liste des URLs supprimées volontairement pour pouvoir justifier plus tard pourquoi elles ne sont pas redirigées. Cela évite les mauvaises surprises quand, trois ans après, on te demande pourquoi telle URL crawlée fréquemment retourne 404.

• Analyse tes logs serveur pour quantifier le crawl réel sur les URLs mortes (si < 3%, ignore)
• Identifie les anciennes URLs avec backlinks actifs et redirige-les en 301 vers du contenu pertinent
• Ne bloque jamais des URLs 404 dans le robots.txt — cela empêche Google de confirmer leur statut
• Lors d'une refonte, mappe systématiquement les anciennes URLs vers leurs équivalents ou pages parentes
• Documente les URLs volontairement laissées en 404 pour justifier ces choix à long terme
• Surveille les logs après migration pour détecter d'éventuels patterns de crawl anormaux