Pourquoi Googlebot continue-t-il d'explorer vos pages en erreur 404 et 410 ?

Google revisite-t-il vraiment toutes les pages en erreur ?

Oui, et c'est une mécanique de fond du crawler. Quand Googlebot rencontre une 404 ou une 410, il ne tire pas un trait définitif sur cette URL. Il la marque comme supprimée dans l'index, certes, mais la conserve dans son carnet d'adresses avec une fréquence de crawl réduite.

Cette logique répond à deux besoins opérationnels de Google. Premièrement, distinguer une erreur serveur ponctuelle d'une suppression réelle. Un site peut renvoyer une 404 temporaire à cause d'un bug de déploiement ou d'une surcharge. Deuxièmement, capturer les ressources qui reviennent en ligne après restauration, migration ou republication de contenu.

Quelle différence entre 404 et 410 du point de vue du crawler ?

Sur le papier, la 410 devrait signaler une suppression définitive, tandis que la 404 reste ambiguë (page introuvable, temporairement ou non). Google lui-même a longtemps encouragé l'usage de la 410 pour accélérer la désindexation.

Dans les faits, le comportement de crawl reste similaire. Les deux codes déclenchent des revisites intermittentes, avec peut-être une fréquence légèrement inférieure pour la 410. Mais Google ne fait pas confiance aveugle : il vérifie quand même. Un site qui restaure une page supprimée par erreur sera crawlé à nouveau, quel que soit le code retourné à l'origine.

Combien de temps Googlebot continue-t-il ces vérifications ?

Google ne communique pas de durée précise. L'observation terrain montre que des URLs peuvent être revisitées pendant des mois, voire des années, avec des intervalles qui s'allongent progressivement. Une page populaire avec un historique de liens entrants sera crawlée plus longtemps qu'une ressource marginale sans backlinks.

La fréquence décroît de manière exponentielle : plusieurs visites la première semaine, puis une par mois, puis tous les trimestres. Mais elle ne tombe jamais strictement à zéro tant que l'URL reste techniquement accessible (même en erreur) et qu'elle présente un intérêt historique pour Google.

• Les 404/410 restent crawlées de façon intermittente, souvent pendant des mois après la suppression
• La fréquence de revisit dépend du PageRank historique et du nombre de liens pointant vers la ressource
• Une 410 ne garantit pas un arrêt immédiat du crawl, contrairement à ce que suggère la RFC HTTP
• Les erreurs temporaires (surcharges, bugs) motivent cette logique de vérification répétée
• Le crawl budget consommé par ces URLs reste significatif sur des sites avec beaucoup d'erreurs historiques

Cette déclaration est-elle cohérente avec ce qu'on observe sur le terrain ?

Absolument. Les logs serveur confirment ce comportement depuis des années. On voit régulièrement Googlebot revenir sur des URLs supprimées, parfois avec des patterns prévisibles : pics de crawl après des opérations de netlinking externes, revisits mensuelles sur d'anciennes pages à fort trafic historique.

Le point intéressant, c'est que Google ne donne aucun délai précis ni critère d'arrêt. On sait que la fréquence baisse, mais pas à quel rythme ni quand elle cesse totalement. Les observations montrent une décroissance logarithmique plutôt qu'une extinction franche. [A vérifier] : est-ce que la fréquence atteint réellement zéro un jour, ou reste-t-elle à un plancher minimal ad vitam ?

Quelles conséquences concrètes pour le crawl budget ?

Sur un site de taille moyenne (moins de 50 000 pages), l'impact reste négligeable. Googlebot a largement la capacité de crawler ces erreurs sans pénaliser les pages actives. Mais sur les gros sites avec un historique chargé, la facture devient lourde.

Imaginons un site e-commerce qui a supprimé 200 000 références obsolètes au fil des années. Si Googlebot revisite ne serait-ce que 5 % de ces URLs chaque mois, ça représente 10 000 requêtes pour du contenu mort. C'est 10 000 hits qui ne servent pas à indexer du contenu frais. Et si ces pages retournent des 404 lentes (CMS mal optimisé, redirections internes avant l'erreur), le temps de crawl explose.

Faut-il vraiment s'en préoccuper ou est-ce du micro-management inutile ?

Ça dépend du contexte. Pour 90 % des sites, ignorer ces crawls est acceptable. Google gère correctement la priorisation et les pages importantes restent crawlées en priorité. Les 404 intermittentes ne causent pas de pénalité de ranking.

Par contre, trois situations exigent une gestion active. Un : sites avec crawl budget contraint (millions de pages, faible autorité). Deux : migrations ratées laissant des milliers d'URLs orphelines crawlées en boucle. Trois : erreurs 404 lentes techniquement (timeout, redirections en chaîne avant l'erreur). Dans ces cas, nettoyer activement via robots.txt ou répondre avec des 410 accélérées peut libérer du budget pour le contenu prioritaire.

Que faire avec les anciennes URLs en erreur qui drainent du crawl budget ?

Première étape : identifier les URLs 404/410 encore crawlées régulièrement. Google Search Console (rapport Couverture, section Exclues) donne une vue partielle, mais les logs serveur restent indispensables pour un diagnostic précis. Filtre les hits Googlebot sur les codes 4xx et trie par fréquence.

Ensuite, segmente ces URLs. Celles qui ont encore des backlinks actifs méritent une redirection 301 vers un contenu équivalent ou une catégorie parent. Celles sans liens ni intérêt historique peuvent rester en 404 rapide (temps de réponse < 100 ms). Si elles représentent un volume énorme, une 410 bien configurée peut accélérer la décroissance du crawl, sans garantie absolue.

Comment optimiser techniquement la réponse des pages en erreur ?

Beaucoup de sites servent des 404 lourdes : chargement complet du CMS, requêtes base de données, template complexe. Résultat : chaque crawl d'erreur coûte 500 ms à 2 secondes, alors qu'une 404 statique répond en 20 ms.

Configure ton serveur (Nginx, Apache, CDN) pour retourner une 404 minimaliste sans passer par l'applicatif. Capture les patterns d'URLs mortes (ex : /produit-*, /archive-*) au niveau du reverse proxy et renvoie une réponse HTTP directe avec un body HTML minimal. Googlebot s'en fiche du contenu de la page d'erreur, il ne lit que le code de statut.

Faut-il utiliser la 410 plutôt que la 404 pour accélérer l'oubli ?

Google a toujours dit que la 410 permet une désindexation plus rapide. C'est vrai pour la sortie de l'index, mais ça ne coupe pas net les crawls de vérification. La différence reste marginale dans la pratique.

Utilise la 410 si tu veux signaler explicitement une suppression définitive (contenu légalement retiré, produit discontinué sans équivalent). Mais ne t'attends pas à ce que Googlebot arrête immédiatement ses visites. La vraie économie vient de la vitesse de réponse, pas du code exact.

• Auditer les logs serveur pour repérer les 404/410 crawlées régulièrement par Googlebot
• Rediriger en 301 les URLs en erreur qui ont encore des backlinks actifs
• Implémenter des 404 ultra-rapides (< 100 ms) au niveau serveur, sans passer par le CMS
• Utiliser la 410 uniquement pour les suppressions définitives documentées, pas par défaut
• Ne pas bloquer les 404 dans robots.txt, ça empêche Google de confirmer la suppression
• Monitorer l'évolution du crawl budget avant/après optimisation via Search Console et logs