Les erreurs 500 tuent-elles vraiment votre crawl budget ?

Pourquoi Google freine-t-il l'exploration face aux erreurs 500 ?

Les erreurs serveur 500 indiquent que quelque chose cloche côté hébergement, base de données ou configuration applicative. Google interprète cette situation comme un signal de détresse : le serveur est peut-être surchargé, en panne partielle ou incapable de traiter les requêtes correctement.

Plutôt que de persister et risquer d'aggraver la situation, Googlebot applique un principe de précaution. Il réduit progressivement la fréquence de crawl pour ne pas achever un serveur déjà affaibli. C'est une logique défensive qui vise à préserver la stabilité de votre infrastructure, mais qui a un coût : vos nouvelles pages ou mises à jour seront découvertes plus lentement.

Quelle différence entre un 500 et un 404 pour le crawl ?

Un code 404 indique clairement que la ressource n'existe plus et ne reviendra probablement jamais. Google enregistre cette information, retire l'URL de l'index et passe à autre chose sans hésitation. Le crawl budget n'est pas impacté durablement : le bot comprend qu'il n'y a rien à crawler ici.

Un 500, en revanche, est ambigu. Il peut signifier une panne temporaire, une surcharge ponctuelle ou un vrai problème structurel. Google ne peut pas décider si l'URL reviendra en ligne dans une heure ou si c'est foutu. Il va donc réessayer plusieurs fois, gaspiller du crawl budget à tenter de récupérer la page, et finalement réduire la cadence globale par sécurité.

Que se passe-t-il si les 500 augmentent brutalement ?

Une hausse soudaine des erreurs serveur déclenche une réaction immédiate chez Googlebot. Le bot détecte que quelque chose a changé : mise à jour serveur ratée, pic de trafic non géré, problème de base de données. Il ne connaît pas la cause, mais il voit les symptômes.

La réponse est mécanique : réduction du taux de crawl pour éviter d'être celui qui fait tomber définitivement le serveur. Cette baisse peut persister plusieurs jours, même après résolution du problème initial, le temps que Google réévalue la stabilité du site. Pendant ce temps, votre indexation ralentit, vos contenus frais stagnent et vos concurrents continuent de crawler normalement.

• Un 500 = signal d'alarme temporaire pour Google, qui ralentit par précaution
• Un 404 = fin de partie pour l'URL, le bot n'y revient plus
• Une montée brutale des 500 peut réduire le crawl budget pendant plusieurs jours, même après correction
• Remplacer des 500 chroniques par des 404 ou 410 rétablit un crawl normal plus rapidement
• La confusion 500/404 gaspille du crawl budget inutilement sur des pages mortes

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

Oui, et c'est même une des rares déclarations de Mueller qui correspond parfaitement à ce qu'on observe en production. Les sites qui connaissent des vagues d'erreurs 500 suite à une migration ratée ou un incident infrastructure voient leur fréquence de crawl chuter de 30 à 60 % en quelques jours. Le retour à la normale prend souvent plus de temps que la résolution technique elle-même.

Ce qui est moins évident, c'est la durée de la « punition ». Google ne réaccélère pas instantanément après correction des 500. Il y a une phase de test progressive où le bot vérifie que la stabilité est revenue. Cette inertie peut coûter cher sur des sites d'actualité ou e-commerce avec forte rotation de contenu.

Quelles nuances faut-il apporter à cette règle ?

La recommandation de basculer en 404 ou 410 suppose que vous ayez identifié que ces URL ne reviendront jamais. Or en pratique, beaucoup d'erreurs 500 sont intermittentes : un timeout base de données, une surcharge RAM momentanée, un bug applicatif qui se corrige au redémarrage. [A vérifier] : Mueller ne précise pas comment distinguer les 500 définitifs des temporaires avant de décider de les tuer en 404.

Autre angle mort : les sites à forte volumétrie (millions de pages) peuvent avoir un taux de 500 naturel lié à la complexité technique, sans que cela impacte massivement le crawl global. Un taux de 2-3 % de 500 sur un gros site n'est pas forcément alarmant si ces erreurs sont dispersées. C'est la concentration et la récurrence sur les mêmes URL qui posent problème.

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

Si vos erreurs 500 touchent des sections entières non prioritaires (archives anciennes, pages filtrées complexes, variantes paramétrées), l'impact sur le crawl des pages stratégiques peut rester limité. Google alloue du crawl budget différemment selon les sections d'un site. Un 500 massif sur /archives/ n'empêchera pas forcément le crawl de /produits/.

Par ailleurs, certains sites utilisent volontairement des 500 comme mécanisme de rate limiting côté API ou flux. C'est techniquement discutable, mais ça existe. Dans ce cas, basculer en 404 serait contre-productif : vous voulez que Google réessaie plus tard, pas qu'il abandonne définitivement l'URL.

Comment identifier les URL qui crachent des 500 à répétition ?

Commencez par la Search Console, onglet Couverture, filtre « Erreur serveur (5xx) ». Exportez la liste complète et croisez-la avec vos logs serveur pour identifier les URL qui génèrent des 500 de manière récurrente, pas juste ponctuelle. Un 500 unique lié à un timeout n'est pas le même problème qu'une URL qui renvoie systématiquement cette erreur.

Utilisez un crawler comme Screaming Frog ou Oncrawl en mode rapide pour tester toutes les URL suspectes et voir si les 500 sont reproductibles. Comparez avec les logs serveur : est-ce que ces erreurs touchent aussi les vrais utilisateurs, ou seulement Googlebot ? Si c'est bot-only, creusez côté config serveur (rate limiting agressif, blocage user-agent).

Que faire concrètement avec ces URL défaillantes ?

Si l'URL correspond à une page réellement supprimée ou obsolète, basculez proprement en 404 ou 410. Ne laissez pas traîner un 500 sur une ressource morte : vous gaspillez du crawl budget et entretenez la confusion. Un 410 est encore plus explicite qu'un 404 pour signaler une suppression définitive, mais les deux fonctionnent.

Si le 500 vient d'un bug applicatif ou d'une ressource manquante (image, script, dépendance), corrigez la cause racine. Parfois, une bibliothèque PHP ou Node manquante génère des 500 en cascade sur des centaines d'URL. Réglez le problème, puis surveillez la remontée du crawl dans les jours suivants via la Search Console et vos logs.

Comment surveiller l'évolution du crawl budget après correction ?

Suivez deux métriques principales : le nombre de pages crawlées par jour (disponible dans la Search Console, section Statistiques sur l'exploration) et le taux d'erreurs 5xx dans vos logs. Après correction des 500, vous devriez voir le crawl remonter progressivement sous 7 à 14 jours. Si ça stagne, vérifiez que de nouvelles erreurs ne sont pas apparues ailleurs.

Configurez des alertes automatiques (via Google Analytics, Datadog, New Relic ou un script maison) pour être notifié dès qu'un pic de 500 apparaît. Réagir en quelques heures plutôt qu'en quelques jours limite la casse sur le crawl budget. Un bon monitoring évite de découvrir le problème trois semaines plus tard dans la Search Console.

• Exporter les erreurs 5xx de la Search Console et croiser avec les logs serveur
• Crawler les URL suspectes pour vérifier la reproductibilité des 500
• Basculer en 404 ou 410 les pages définitivement supprimées qui renvoient des 500
• Corriger les bugs applicatifs ou dépendances manquantes qui génèrent des 500 en cascade
• Surveiller le crawl budget (pages crawlées/jour) pendant 14 jours après correction
• Mettre en place des alertes automatiques pour détecter les pics de 500 en temps réel