Is it true that crawl budget is managed at the server level rather than the directory level?

What does Google mean by « host server load capacity »?

When Google talks about server load capacity, it refers to how Googlebot evaluates the technical health of an infrastructure. Instead of analyzing folder by folder, Google measures the overall responsiveness of the server — response time, latency, 5xx errors, timeouts.

If your server hosts multiple sites or subdomains, Googlebot does not segment its analysis. A slow or misconfigured section can degrade the overall perception of reliability of your infrastructure, even if other areas are perfectly optimized.

Why does this approach change the game for multi-folder sites?

Many SEOs still think they can

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

Oui et non. D'un côté, l'idée que Google évalue la santé globale d'un serveur correspond à ce qu'on observe sur des infrastructures complexes. Quand un serveur donne des signes de fatigue — erreurs 503, timeouts, latence élevée — Googlebot ralentit le rythme, même sur des sections du site techniquement irréprochables.

Mais cette logique montre vite ses limites. On a vu des sites hébergés sur le même serveur (même IP, même infra) avec des budgets de crawl très différents. Comment expliquer cet écart si Google ne juge qu'au niveau du serveur ? La popularité du site, la fraîcheur du contenu, et la profondeur de l'arborescence jouent aussi — Google ne le dit jamais explicitement.

Quelles nuances faut-il apporter à cette affirmation ?

Google parle ici de capacité de charge technique, pas de budget de crawl total. Ce sont deux choses distinctes. Le budget de crawl dépend aussi de l'intérêt que Google porte à votre contenu — un site avec 10 millions de pages obsolètes ne sera jamais crawlé intégralement, même si le serveur est une fusée.

Autre point flou : qu'entend Google par « serveur hôte » ? Une IP ? Un nom de domaine ? Un cluster ? Sur une architecture moderne avec load balancing, reverse proxy, et CDN, la notion de « serveur » devient abstraite. Google simplifie probablement pour éviter d'entrer dans des détails techniques qu'il ne veut pas documenter. [A vérifier]

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

Les sites qui utilisent des sous-domaines distincts sur des serveurs différents échappent en partie à cette logique. Si blog.example.com tourne sur un serveur A et shop.example.com sur un serveur B, chaque sous-domaine devrait bénéficier de son propre budget de crawl, indépendamment de l'autre.

Mais attention : Google ne garantit rien. On a vu des cas où des sous-domaines partageant la même infrastructure DNS ou le même certificat SSL étaient traités comme un ensemble. Là encore, Google ne documente jamais ces subtilités — il faut tester et mesurer sur le terrain.

Que faut-il faire concrètement pour optimiser le budget de crawl au niveau serveur ?

Première étape : mesurer la santé technique de votre serveur dans son ensemble. Google Search Console vous donne des indices (erreurs serveur, temps de réponse moyen), mais il faut aussi analyser les logs serveur bruts pour identifier les patterns de crawl et les zones de friction.

Ensuite, passez au crible tous les répertoires, même ceux que vous jugez secondaires. Un /wp-admin/ mal sécurisé qui génère des centaines de 404, un /medias/ avec des fichiers lourds qui saturent la bande passante, un /test/ oublié qui renvoie des erreurs 500 — tout ça dégrade la perception globale. Robots.txt et balises noindex ne suffisent pas si Googlebot tente quand même d'accéder.

Quelles erreurs éviter sur une infrastructure multi-sites ou multi-dossiers ?

Ne laissez jamais un site ou un répertoire orphelin sur votre serveur. Si vous n'utilisez plus une section, supprimez-la physiquement ou redirigez proprement. Un dossier abandonné qui génère des erreurs ou des timeouts peut polluer la perception de l'ensemble.

Autre erreur classique : croire qu'un CDN règle tout. Un CDN améliore la latence et absorbe les pics de trafic, mais si votre serveur origine est lent ou instable, Googlebot peut contourner le cache et taper directement à la source. Résultat : vous ne profitez pas du CDN pour le crawl.

Comment vérifier que mon serveur est perçu comme stable par Google ?

Google Search Console, onglet « Statistiques d'exploration ». Vous y trouverez trois graphiques : nombre total de demandes d'exploration, temps de téléchargement moyen, et taille moyenne des téléchargements. Si le temps de téléchargement monte ou si le nombre de requêtes chute sans raison éditoriale, c'est un signal d'alerte.

Mais ce n'est qu'un début. Les logs serveur vous en disent beaucoup plus : fréquence de passage de Googlebot, codes HTTP renvoyés, pages les plus crawlées, timeouts. Un outil comme Screaming Frog Log File Analyser ou Botify (pour les gros sites) devient indispensable.

• Analyser les logs serveur pour identifier les sections qui génèrent des erreurs ou des timeouts
• Supprimer ou rediriger les répertoires obsolètes ou inutilisés sur le serveur
• Vérifier que le CDN cache bien les ressources crawlées par Googlebot (User-Agent Googlebot dans les logs CDN)
• Surveiller les métriques de Search Console (temps de téléchargement, volume de crawl) sur la durée
• Éviter les hébergements mutualisés si votre site dépend fortement du crawl (e-commerce, actualité, marketplace)
• Tester la réactivité du serveur sous charge avec des outils comme LoadImpact ou Artillery