Vers 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. Rien ne progressait. 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.
Ce projet a changé ma façon de penser le crawl budget entièrement. 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 savoir et gérer réellement à grande échelle, c'est 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 statistiques de crawl dans Google Search Console et senti mon estomac se serrer.
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.
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ée par la popularité de vos URLs et leur fréquence de changement. Multipliez ces deux leviers ensemble et vous avez une idée approximative de l'attention de crawl que votre site reçoit.
Pour la plupart des sites sous 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 hiérarchiser. Il va ignorer. Et si vous ne l'avez pas configuré pour hiérarchiser les bonnes choses, il va joyeusement passer son temps à crawler vos URLs avec session-ID et vos pages de facettes filtrées pendant que vos nouveaux 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 gestion de paramètres d'URL configurée. Chaque combinaison de filtre générait une URL unique. Vous pouviez sélectionner « bleu », « moyen », « coton » et « MarqueX » et obtenir /shop?colour=blue&size=medium&material=cotton&brand=brandx. Puis quelqu'un changeait l'ordre et obtenait /shop?size=medium&colour=blue&brand=brandx&material=cotton. URL différente, contenu identique.
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 d'URL dans Google Search Console, en marquant 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 canonique appropriée, pointant toutes les combinaisons de filtres vers la page de catégorie de base. Nous avons aussi ajouté noindex aux pages filtrées de faible valeur qui ne pouvaient pas être pratiquement canonisées.
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. Un pic soudain de pages indexées peut parfois déclencher une réévaluation de Google plutôt qu'une victoire nette.
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é.
Le rapport Crawl Stats vous montre les demandes de crawl moyennes par jour, le temps de réponse moyen, et, de façon cruciale, ce que Googlebot crawle réellement en fonction de son objectif (découverte vs. rafraîchissement). Si vos crawls de « rafraîchissement » dominent et que les crawls de découverte sont minimaux, Google passe son temps à revérifier les pages qu'il connaît déjà. Pas à en trouver de nouvelles. C'est un signal que votre linking interne est probablement superficiel ou que votre sitemap XML n'est d'aucune utilité.
Sur le projet de 91 000 pages, nous nous situions à environ 2 400 demandes de crawl par jour. Pour un site de cette taille, cela signifie que Google mettrait théoriquement environ 38 jours pour tout crawler une fois, en supposant que chaque demande atteigne une page unique et utile. Ce n'était pas le cas. Environ 40 % des demandes de crawl touchaient des chaînes de redirections ou des doublons gonflés par des 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 mauvais. Pas dramatiquement mauvais, juste tranquillement, inutilement mauvais.
Les problèmes courants que je vois :
- Des pages dans le sitemap qui retournent des 404 ou des redirections 301
- Pages noindexées incluses dans le sitemap (cela confond Googlebot, vous dites simultanément « crawlez ceci » et « n'indexez pas ceci »)
- Dates <lastmod> statiques ou simplement incorrectes
- 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 URLs dans un seul fichier. Il incluait également chaque URL filtrée qui avait jamais été générée, dont plus de 40 000 étaient noindexées. Googlebot traitait ce fichier énorme et découvrait ensuite que la plupart des URLs ne devaient pas être crawlées de toute façon. Signal gaspillé 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.
Les données de Bing Webmaster Tools (oui, ça vaut le coup de vérifier, Bing vous montrera parfois des modèles de comportement de crawl qui suggèrent des problèmes structurels que Google connaît aussi) ont montré que le temps de traitement du sitemap a baissé de plus de 60 %.
Liens Internes : Le Levier Que Vous Contrôlez Réellement
Voici quelque chose que je n'ai vraiment pas apprécié jusqu'à ce que Seahawk reprenne un grand site de contenu, environ 65 000 articles, pour un client médias en 2020. Le site avait des problèmes de crawl budget malgré un sitemap bien formé et une structure d'URL propre. Le problème était la profondeur des liens internes. Des milliers d'articles étaient effectivement orphelins, sans liens internes les pointant depuis aucune 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.
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.
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
- Recoupez avec les pages qui sont bien liées, trouvez des clusters thématiques
- Construire des liens internes contextuels depuis les pages à fort trafic vers les pages peu liées
- Validez dans l'outil Inspection d'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 indicateur d'alerte. 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 le résoudre.
Analyse des fichiers journaux : inconfortable mais nécessaire
Je vais être honnête, l'analyse des 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 déduisez qu'il a fait à 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 les URLs adjacentes à /wp-admin/ et les assets côté admin qui auraient dû être bloqués dans robots.txt. Personne n'avait configuré cela correctement. Les pages de documentation n'avaient pas été crawlées depuis quatre mois.
Screaming Frog's Log File Analyser est l'outil que j'utilise. Ce n'est pas glamour mais c'est fiable. Importez vos journaux serveur, filtrez par agent utilisateur Googlebot, et triez par fréquence de frappe d'URL. Les modèles qui émergent sont presque toujours révélateurs, et incluent presque toujours quelque chose qui crawle et qui ne devrait pas.
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écouverte, actuellement non indexée » ou « Analysée, actuellement non indexée »
Ce second statut, « Analysée, actuellement non indexée », est différent et mérite d'être traité séparément. 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 mince ou de problèmes de quasi-duplication. Aucune optimisation du budget de crawl ne peut corriger 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 se charge rapidement, Google analysera presque certainement tout, quel qu'en soit le coût. Le budget de crawl devient une véritable préoccupation à grande échelle, généralement à partir 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 indique à Google que ces URL existent. Mais si votre site présente des problèmes structurels (spam de navigation à facettes, réponse serveur lente, maillage interne peu profond), un sitemap ne contournera pas ces signaux. Pensez au sitemap comme une suggestion, pas une commande.
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. Disallow dans robots.txt empêche Googlebot de récupérer la page, économisant le budget de crawl mais signifiant 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 de crawl spécifiquement, disallow est plus efficace sur les URLs 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 canonical est généralement le bon choix.
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 de crawl. Sur le projet de 91 000 pages, un mouvement significatif dans les chiffres de pages indexées a pris environ six à huit semaines après le déploiement des corrections majeures. Ne vous attendez pas à des changements du jour au lendemain, Googlebot doit réanalyser, 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 en cinq mois. Pas parfait, il y avait vraiment des pages produits minces 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é de contempler un changement de carrière autour de la page 47 000 des rapports de crawl. Presque.
Lectures connexes : Recherche de mots-clés par IA en 2026 : ce que c'est, pourquoi traditio, Redirections 301 vs 302 : Laquelle compte vraiment pour le SEO, et Mots-clés LSI en 2026 : ce qu'ils sont, ce qu'ils ne sont pas, ce.