Le budget de crawl se gère-t-il vraiment au niveau du serveur et non du dossier ?

Qu'est-ce que Google entend par « capacité de charge à l'échelle du serveur hôte » ?

Quand Google parle de capacité de charge au niveau du serveur, il fait référence à la façon dont Googlebot évalue la santé technique d'une infrastructure. Plutôt que d'analyser dossier par dossier, Google mesure la réactivité globale du serveur — temps de réponse, latence, erreurs 5xx, timeouts.

Si votre serveur héberge plusieurs sites ou sous-domaines, Googlebot ne segmente pas son analyse. Une section lente ou mal configurée peut dégrader la perception globale de la fiabilité de votre infrastructure, même si d'autres zones sont parfaitement optimisées.

Pourquoi cette approche change-t-elle la donne pour les sites multi-dossiers ?

Beaucoup de SEO pensent encore qu'ils peuvent « isoler » des sections problématiques en optimisant uniquement les répertoires stratégiques. C'est une erreur. Si vous avez un répertoire /blog/ ultra-rapide mais un /archive/ bourré de pages lentes, Google voit la moyenne.

Pire encore : si vous partagez un serveur avec d'autres sites (hébergement mutualisé), les performances de vos voisins impactent potentiellement votre propre budget de crawl. Google n'a pas de visibilité directe sur votre arborescence interne — il voit une adresse IP, un serveur, une vitesse moyenne.

Cette logique s'applique-t-elle aussi aux CDN et aux architectures distribuées ?

Là, ça se complique. Google ne précise jamais clairement si un CDN comme Cloudflare ou Fastly est considéré comme un « serveur hôte » unique. Dans la pratique, les CDN modifient les en-têtes, anonymisent partiellement l'origine, et distribuent la charge sur plusieurs points de présence (PoP).

On observe que les sites sous CDN performant bénéficient généralement d'un meilleur budget de crawl, mais est-ce dû au cache, à la latence réduite, ou à la perception d'un « serveur » globalement plus stable ? Google reste flou. [A vérifier]

• Le budget de crawl se calcule au niveau du serveur hôte, pas dossier par dossier.
• Un répertoire lent ou mal configuré peut dégrader la perception globale de votre infrastructure.
• Les hébergements mutualisés sont particulièrement à risque, car vous partagez la réputation du serveur avec d'autres sites.
• Google ne documente pas clairement comment les CDN et les architectures distribuées entrent dans ce calcul.
• Optimiser un sous-dossier isolément ne suffit pas si le reste du serveur montre des faiblesses.

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