Quelque part autour de la page 47 000 d'un rapport de crawl, j'ai sérieusement envisagé un changement de carrière. Le site -- un grand catalogue e-commerce basé au Royaume-Uni avec environ 91 000 URLs indexables -- stagnait à environ 34 000 pages indexées depuis six mois. Pas de croissance. Le client était convaincu que quelque chose était « cassé ». Je lui ai dit que rien n'était cassé. J'avais à moitié raison.
Point clé : Sur un site de 91 000 pages, Googlebot explore ce que votre architecture lui indique : la structure des liens internes, la rigueur du sitemap et l'élimination des pages inutiles déterminent quelles pages sont indexées.On a 91,000-page site Googlebot crawls what your architecture tells it to: internal linking, sitemap discipline, and killing waste decide which pages get indexed.
Ce projet a changé ma façon de penser le crawl budget dans son intégralité. Pas la théorie -- j'avais lu la documentation Google, j'avais regardé les vidéos Search Central, je savais ce qu'était le crawl budget. Mais connaître la théorie et la gérer réellement à grande échelle sont deux choses radicalement différentes. Ce qui suit est tout ce que je me dirais si je pouvais revenir à ce mardi matin de mars 2022 quand j'ai d'abord tiré les stats de crawl dans Google Search Console et senti mon estomac se serrer.was. But knowing it and actually managing it at scale are two wildly different things. What follows is everything I'd tell myself if I could go back to that Tuesday morning in March 2022 when I first pulled the crawl stats in Google Search Console and felt my stomach drop.
Ce que le budget de crawl signifie vraiment (Et ce qu'il ne signifie pas)
Voilà ce qui trompe constamment les gens : le crawl budget ne signifie pas « le nombre de pages que Google indexera jamais pour vous ». Cela signifie à peu près le nombre d'URLs que Googlebot va récupérer dans une fenêtre de crawl donnée, que Google définit lui-même comme une combinaison entre la limite de taux de crawl et la demande de crawl.fetch within a given crawl window, which Google itself defines as a combination of crawl rate limit and crawl demand.
Le crawl rate limit est la vitesse à laquelle Googlebot peut crawler sans surcharger votre serveur. Le crawl demand est la quantité que Google veut crawler -- déterminé par la popularité de vos URLs et la fréquence à laquelle elles changent. Multipliez ces deux leviers ensemble et vous avez une idée approximative de l'attention de crawl que votre site reçoit.wants to crawl -- driven by how popular your URLs are and how often they change. Multiply those two levers together and you have a rough sense of how much crawling attention your site gets.
Pour la plupart des sites de moins de 1 000 pages, c'est sans importance. Google crawlera tout. Mais une fois que vous êtes dans les dizaines de milliers -- et absolument une fois que vous dépassez les six chiffres -- Googlebot commence à faire des choix. Il va prioriser. Il va ignorer. Et si vous ne l'avez pas configuré pour prioriser le bon contenu, il dépensera joyeusement son temps à crawler vos URLs avec paramètre de session-ID et vos pages de facettes filtrées tandis que vos nouveaux lancements de produits passent inaperçus pendant des semaines.
Ce n'est pas hypothétique. C'est ce qui s'est passé sur le projet de 91 000 pages.
Le problème de navigation à facettes que personne ne m'avait averti
La navigation à facettes est le plus grand killer de budget de crawl que j'ai rencontré sur les gros sites. Régulièrement. À chaque fois.
Le site catalogue avait un système de filtre à facettes -- couleur, taille, matière, marque -- sans aucune configuration de gestion des paramètres URL nulle part. Chaque combinaison de filtre générait une URL unique. Vous pouviez sélectionner « bleu », « moyen », « coton » et « BrandX » et obtenir /shop?colour=blue&size=medium&material=cotton&brand=brandx. Puis quelqu'un a changé l'ordre et obtenu /shop?size=medium&colour=blue&brand=brandx&material=cotton. URL différente, contenu identique./shop?colour=blue&size=medium&material=cotton&brand=brandx. Then someone flipped the order and got/shop?size=medium&colour=blue&brand=brandx&material=cotton. Different URL, identical content.
J'ai lancé un crawl Screaming Frog (version 18, qui gère beaucoup mieux le rendu JavaScript que les versions antérieures) et trouvé plus de 200 000 URLs générées uniquement par le système de filtre. Googlebot visitait ces pages. Constamment. Pendant que des milliers de pages de produit légitimes restaient non indexées.
La solution qui a vraiment marché
Nous avons abordé cela en deux étapes. D'abord, j'ai configuré la gestion des paramètres URL dans Google Search Console -- en signalant les paramètres de filtre comme « Ne change pas le contenu de la page » pour signaler à Googlebot de les consolider. Deuxièmement, et plus important encore, l'équipe dev a implémenté une stratégie de canonical appropriée, pointant toutes les combinaisons de filtres vers la page de catégorie de base. Nous avons également ajouté noindex aux pages filtrées de faible valeur qui ne pouvaient pas être canonicalisées.noindex to low-value filtered pages that couldn't practically be canonicalised.
En environ huit semaines, le nombre de pages indexées a commencé à augmenter. Pas de façon explosive -- progressivement. Ce qui est en fait ce que vous voulez. Une augmentation soudaine des pages indexées peut parfois déclencher une réévaluation de Google plutôt qu'une victoire propre.
Statistiques de crawl dans Search Console : les données que la plupart des gens ignorent
J'ai audité près de 80 sites au cours des trois dernières années spécifiquement pour les problèmes de crawl. Peut-être 15% des personnes qui m'ont remis ces sites avaient déjà consulté le rapport Crawl Stats dans Search Console. Ce chiffre devrait être beaucoup plus élevé.Crawl Stats report in Search Console. That number should be much higher.
Le rapport Crawl Stats vous montre le nombre moyen de demandes de crawl par jour, le temps de réponse moyen, et -- de manière cruciale -- ce que Googlebot crawle réellement, ventilé par objectif (discovery vs. refresh). Si vos crawls « refresh » dominent et les crawls discovery sont minimaux, Google dépense son temps à revérifier les pages qu'il connaît déjà. À ne pas en trouver de nouvelles. C'est un signal que votre linking interne est probablement peu profond ou que votre sitemap XML ne fait rien d'utile.
Sur le projet de 91 000 pages, nous étions à environ 2 400 demandes de crawl par jour. Pour un site de cette taille, cela signifie que Google prendrait théoriquement environ 38 jours pour tout crawler une fois -- en supposant que chaque demande accède à une page unique et utile. Ce n'était pas le cas. Environ 40 % des demandes de crawl accédaient à des chaînes de redirection ou à des doublons gonflés par paramètres.
Le temps de réponse moyen est plus important que vous ne le pensez
Une chose que j'ai sous-estimée au début de ma carrière : Googlebot est véritablement sensible à la vitesse du serveur. Pas d'une manière qui affecte le classement (bon, pas directement), mais d'une manière qui affecte la volonté de crawl. Les serveurs lents font reculer Googlebot. Google réduira sa fréquence de crawl pour éviter de surcharger un serveur défaillant.
Le site catalogue avait un Time to First Byte autour de 1,8 secondes sur les pages de catégories pendant le trafic de pointe. Après que le client soit passé de l'hébergement mutualisé à un VPS dédié avec un bon cache (WP Rocket pour la mise en cache des pages, Redis pour la mise en cache des objets), le TTFB est tombé sous 400ms. Les requêtes de crawl par jour ont augmenté notablement au cours des six semaines suivantes. Corrélation, évidemment, mais j'ai vu ce schéma trop de fois pour le rejeter.
Sitemaps XML : cessez de les traiter comme une formalité
La plupart des sitemaps que j'hérite sont faux. Pas dramatiquement faux -- juste tranquillement, inutilement faux.
Les problèmes courants que je vois :
- Des pages dans le sitemap qui retournent des 404 ou des redirections 301
- Pages en noindex incluses dans le sitemap (cela confond Googlebot -- vous dites simultanément « crawlez ceci » et « n'indexez pas ceci »)
Dates <lastmod> statiques ou simplement incorrectesdates that are static or just wrong- Sitemaps avec 70 000+ URLs dans un seul fichier (la limite est 50 000 par fichier, et les fichiers volumineux ralentissent le traitement)
- Pas de fichier d'index de sitemap, juste un blob XML monolithique
Sur le projet de grand catalogue, le sitemap contenait 91 000 URL dans un seul fichier. Il incluait également chaque URL filtrée qui avait jamais été générée -- plus de 40 000 d'entre elles en noindex. Googlebot traitait ce fichier énorme et découvrait ensuite que la plupart des URL ne devaient pas être crawlées de toute façon. Signal perdu des deux côtés.
Nous avons reconstruit l'architecture du sitemap en tant qu'index de sitemap approprié pointant vers des sitemaps enfants segmentés : un pour les pages de catégorie principales, un pour les pages de produits (divisé en deux fichiers compte tenu du volume), un pour le contenu éditorial. Chaque fichier sous 40 000 URLs, les valeurs <lastmod> générées dynamiquement à partir de la véritable date de dernière modification dans la base de données. Pas de pages en noindex, pas de redirections.<lastmod>values dynamically generated from the actual last-modified date in the database. No noindexed pages, no redirects.
Les données de Bing Webmaster Tools (oui, ça vaut le coup de vérifier -- Bing vous montrera parfois des tendances de comportement de crawl qui révèlent des problèmes structurels que Google rencontre aussi) ont montré une baisse du temps de traitement du sitemap de plus de 60 %.
Liens Internes : Le Levier Que Vous Contrôlez Réellement
Voici quelque chose que je n'ai vraiment apprécié que lorsque Seahawk a repris un grand site de contenu -- environ 65 000 articles -- pour un client média en 2020. Le site avait des problèmes de budget de crawl malgré un sitemap bien formé et une structure URL propre. Le problème venait de la profondeur des liens internes. Des milliers d'articles étaient effectivement orphelins -- aucun lien interne ne pointait vers eux depuis une page crawlée.
Googlebot ne suit pas seulement les sitemaps. Il suit les liens. Si une page n'est découvrable que par une entrée sitemap et n'a aucun lien interne, elle est déprioritisée. Ce n'est pas officiellement documenté en termes clairs, mais les propres conseils de Google sur le linking interne montrent clairement que les liens crawlables depuis les pages importantes, c'est comme Googlebot priorise la découverte.only follow sitemaps. It follows links. If a page is only discoverable through a sitemap entry and has zero internal links, it gets deprioritised. That's not officially documented in crisp terms, but Google's own guidance on internal linking makes clear that crawlable links from important pages are how Googlebot prioritises discovery.
Pour ce client médias, nous avons audité les liens internes avec l'outil Site Audit d'Ahrefs et identifié environ 12 000 articles avec trois liens internes ou moins pointant vers eux. Nous avons intégré un bloc « articles connexes » automatisé dans le CMS (WordPress, bloc Gutenberg personnalisé) qui récupérait du contenu contextuel similaire. Au cours du trimestre suivant, les pages indexées sur ce site sont passées de 41 000 à plus de 58 000. Même domain authority. Même taux de production de contenu. Juste une meilleure liaison interne.WordPress, custom Gutenberg block) that pulled contextually similar content. Over the following quarter, indexed pages on that site climbed from 41,000 to over 58,000. Same domain authority. Same content production rate. Just better internal linking.
L'approche numérotée que j'utilise maintenant sur tout audit de grand site :
- Exécuter un crawl complet Screaming Frog et exporter les données de liens internes
- Identifier chaque page avec moins de trois liens internes entrants
- Comparez avec les pages qui sont bien liées -- trouvez des clusters thématiquesare well-linked -- find topical clusters
- Construire des liens internes contextuels depuis les pages à fort trafic vers les pages peu liées
- Validez dans l'outil Inspection des URL de Search Console que les pages nouvellement liées passent de « Découverte -- actuellement non indexée » à « Crawlée »
Ce statut « Découverte -- actuellement non indexée » dans Search Console est votre canari. Cela signifie que Google connaît l'existence de la page mais n'a pas priorisé sa récupération. Améliorer les liens internes est généralement le moyen le plus rapide de résoudre le problème.
Analyse des fichiers journaux : inconfortable mais nécessaire
Je vais être honnête -- l'analyse de fichiers journaux est quelque chose que j'ai évité pendant des années. Cela semblait être une profondeur inutile quand les outils de crawl vous donnaient la plupart de ce dont vous aviez besoin. J'avais tort.
Les fichiers journaux vous disent ce que Googlebot a réellement fait, pas ce que vous en déduisez à partir de votre sitemap ou de votre outil de crawl. Sur un projet -- une entreprise SaaS avec environ 8 000 pages de documentation produit -- l'analyse des journaux a révélé que Googlebot passait près de 30 % de son temps de crawl sur des URL adjacentes à /wp-admin/ et des ressources du côté admin qui auraient dû être bloquées dans robots.txt. Personne n'avait configuré cela correctement. Les pages de documentation n'avaient pas été crawlées depuis quatre mois.actually did, not what you infer it did from your sitemap or crawl tool. On one project -- a SaaS company with about 8,000 product documentation pages -- log analysis revealed Googlebot was spending nearly 30% of its crawl time on/wp-admin/adjacent URLs and admin-side assets that should have been blocked in robots.txt. Nobody had set that up properly. Documentation pages that hadn't been crawled in four months.
Screaming Frog's Log File Analyser est l'outil que j'utilise. Ce n'est pas spectaculaire mais c'est fiable. Importez vos journaux serveur, filtrez par l'agent utilisateur Googlebot, et triez par fréquence de visite d'URL. Les tendances qui émergent sont presque toujours révélatrices -- et incluent presque toujours quelque chose qui crawle mais ne devrait pas. is the tool I use. It's not glamorous but it's reliable. Import your server logs, filter by Googlebot user agent, and sort by URL hit frequency. The patterns that emerge are almost always illuminating -- and almost always include something crawling that shouldn't be.
Quand S'inquiéter et Quand Laisser Tomber
Tous les grands sites n'ont pas besoin d'une gestion agressive du budget d'exploration. Si vous avez 10 000 pages et que 9 800 sont indexées, ne commencez pas à actionner des leviers. Vous créerez des problèmes là où il n'y en a pas.
La gestion du budget d'exploration devient vraiment utile quand :
- Vous avez plus d'environ 15 000 pages indexables
- Votre nombre de pages indexées a plafonné malgré l'ajout de nouveau contenu
- Crawl Stats affiche une moyenne de demandes d'exploration bien inférieure à ce que vous attendriez pour votre volume de pages
- Vous voyez des milliers d'URL en statut « Découvertes -- actuellement non indexées » ou « Explorées -- actuellement non indexées »
Ce deuxième statut -- « Explorées -- actuellement non indexées » -- est différent et mérite d'être distingué. Il signifie que Google a récupéré la page et a décidé de ne pas l'indexer, généralement en raison d'un contenu léger ou de problèmes de quasi-duplication. Aucune optimisation du budget d'exploration ne résout un problème de qualité.
---
FAQ
Le budget de crawl affecte-t-il les petits sites ?
Rarement de manière significative. Si votre site compte moins de 1 000 pages et charge rapidement, Google explorera presque certainement tout indépendamment. Le budget d'exploration devient une préoccupation véritable à grande échelle -- généralement au-delà de 10 000 à 15 000 pages, ou sur les sites où une grande partie des URL sont générées dynamiquement.
Soumettre directement un sitemap résoudra-t-il les problèmes de budget de crawl ?
Non. Un sitemap aide à la découverte -- il dit à Google que ces URL existent. Mais si votre site présente des problèmes structurels (spam de navigation facettée, réponse serveur lente, maillage interne peu profond), un sitemap ne contrebalancera pas ces signaux. Pensez au sitemap comme une suggestion, pas comme un ordre.
Comment vérifier si Googlebot gaspille du crawl sur des URLs sans valeur ?
Commencez par le rapport Statistiques de crawl dans Google Search Console et regardez quels types d'URLs reçoivent le plus de demandes. Puis croisez les données avec un crawl Screaming Frog pour identifier les motifs d'URLs à haut volume qui sont des doublons, noindexés, ou peu pertinents. L'analyse des fichiers journaux vous donnera l'image la plus précise si vous avez accès aux logs serveur.
Dois-je utiliser `noindex` ou `robots.txt disallow` pour économiser le budget de crawl ?
Des outils différents pour des tâches différentes. L'interdiction dans robots.txt empêche Googlebot de récupérer la page du tout -- ce qui économise le budget d'exploration mais signifie que Google ne peut lire aucun signal sur cette page. Noindex permet à Google de récupérer la page mais lui dit de ne pas l'inclure dans les résultats de recherche. Pour le budget d'exploration spécifiquement, disallow est plus efficace sur les URL vraiment inutiles (chemins d'administration, résultats de recherche interne). Pour les pages de facettes filtrées où vous voulez que Google comprenne le contenu mais ne l'indexe pas, noindex avec une canonique est généralement le bon choix.Disallow in robots.txt prevents Googlebot from fetching the page at all -- saving crawl budget but meaning Google can't read any signals on that page.Noindex allows Google to fetch the page but tells it not to include the page in search results. For crawl budget specifically,disallow is more effective on truly junk URLs (admin paths, internal search results). For filtered facet pages where you want Google to understand the content but not index it,noindex with a canonical is usually the right call.
Quel délai réaliste faut-il prévoir pour voir des améliorations après correction des problèmes de budget de crawl ?
Honnêtement, cela dépend de votre taux d'exploration. Sur le projet de 91 000 pages, un mouvement significatif des comptages de pages indexées a pris environ six à huit semaines après le déploiement des correctifs majeurs. Ne vous attendez pas à des changements du jour au lendemain -- Googlebot doit ré-explorer, réévaluer, et le pipeline d'indexation a sa propre latence en plus de cela.
---
Le projet de 91 000 pages s'est bien terminé. Les pages indexées ont grimpé de 34 000 à un peu plus de 71 000 sur cinq mois. Pas parfait -- il y avait véritablement des pages produit peu fournies qui ne méritaient pas d'être indexées -- mais le contenu qui importait a été trouvé. Le client a arrêté de demander si quelque chose était cassé. Et j'ai arrêté d'envisager des changements de carrière vers la page 47 000 des rapports d'exploration. Presque.