Pages orphelines et budget de crawl : comment l’analyse de logs SEO révèle ce que Google voit vraiment de votre site

La théorie du crawl budget ne suffit plus : ce que Google dit contre ce qu’il fait

Quand tu cherches de l’information sur le crawl budget SEO, tu tombes presque toujours sur le même schéma. Une définition, le crawl rate limit, la crawl demand, un paragraphe sur le robots.txt, puis 3 conseils génériques. C’est exact, mais ce n’est pas exploitable. Google ne crawle jamais 100% des pages d’un site : il subsiste toujours un écart entre le nombre de pages en ligne et le nombre de pages réellement connues du moteur. Personne ne te dit combien de pages de ton site Googlebot a vraiment explorées cette semaine.

Les outils de simulation, autrement dit un crawler SEO, te montrent ce qu’un robot simulé voit depuis l’extérieur. Ils ne te disent ni ce que Googlebot a réellement exploré, ni à quelle fréquence, ni quelles URLs il a laissées de côté. C’est exactement le vide que comble l’analyse de logs, seule méthode pour observer le comportement réel de Google, et elle devient indispensable au-delà de 1 000 pages. La logique à garder en tête est celle de la pyramide SEO crawl-centric :

• Le potentiel du site : tout le contenu que tu pourrais publier.
• Les pages en ligne : ce que tu as réellement mis en production.
• Les pages crawlées par Google : celles que Googlebot a visitées au moins une fois.
• Les pages indexées : celles retenues dans l’index.
• Les pages actives : celles qui génèrent au moins une visite sur la période.
• Les pages efficaces : celles qui déclenchent une conversion.

Budget de crawl, capacité de crawl, demande de crawl : le vocabulaire à maîtriser

Google dispose de ressources limitées pour explorer l’ensemble du web. Il alloue donc un temps limité par site : c’est le crawl budget. Ce n’est pas une punition, c’est une contrainte de capacité. Des pages inutiles consomment ce crawl budget au détriment des pages à fort potentiel. Plusieurs facteurs l’influencent directement :

• Le pagerank interne, donc la structure de ton maillage.
• La popularité du site et ses backlinks.
• La fraîcheur du contenu et sa fréquence de mise à jour.
• La vitesse du serveur et ses temps de réponse.
• La profondeur du site, c’est-à-dire le nombre de clics pour atteindre une page.

Ne confonds pas la limite de capacité de crawl et la demande de crawl, c’est l’erreur la plus fréquente sur ce sujet. La capacité est ce que Google accepte de t’accorder, la demande est ce que ton site donne envie d’explorer. Un catalogue e-commerce de 50 000 références, un site média à forte rotation ou une boutique qui expire des centaines de produits chaque semaine vivent ces mécanismes au quotidien, et c’est là que ton crawl budget se joue.

Limite de capacité de crawl : tous les sites démarrent au même niveau

Google a officialisé en juillet 2026 que chaque site démarre avec la même limite de capacité de crawl par défaut, volontairement conservatrice. Autrement dit, un site récent n’est pas bridé par une pénalité : il est bridé par un réglage de sécurité. Si la demande de crawl augmente et que le site reste sain sur le plan technique, Google relève automatiquement cette limite au fil du temps. La capacité ne se réclame pas, elle se mérite par la santé technique, et c’est une bonne nouvelle pour qui travaille sérieusement ses performances Serveur.

Demande de crawl : taille du site, fraîcheur et qualité des pages

La demande de crawl dépend de la taille du site, de la fréquence de mise à jour, de la qualité des pages et de leur pertinence comparée aux autres sites du même sujet. C’est pourquoi 2 sites de taille identique n’obtiennent pas le même volume de crawl : Google arbitre en permanence entre les milliards d’URLs qu’il connaît. Demande et capacité évoluent séparément, ce qui explique pourquoi certains sites correctement crawlés stagnent malgré un contenu neuf.

Retiens surtout cette asymétrie des délais, elle est contre-intuitive. La découverte d’une URL nouvelle prend environ 20 heures en typique. Le rafraîchissement d’une URL connue prend environ 30 jours. Traduit en clair : une nouvelle page est vue vite, une page existante que tu modifies est relue lentement. Beaucoup de SEO concluent à tort à un mauvais crawl alors qu’ils sont simplement dans la constante de temps normale du rafraîchissement.

Ce que Google a officialisé en 2026 sur le crawl budget SEO

Le 22 juillet 2026, Google a publié une refonte de son document Optimize your crawl budget, présentée comme un travail de clarté. Elle contient pourtant des affirmations directement exploitables, dont cette phrase : « Every site starts with the same default, conservative crawl capacity limit. » Les recoupements avec la conférence Search Central Live de Milan en juin 2026 donnent la même tonalité : Google explique son fonctionnement réel plutôt que de dispenser des conseils génériques sur le crawl budget.

Autre donnée à retenir : 15% des recherches quotidiennes traitées par Google sont totalement inédites. Ce chiffre rappelle que le moteur doit en permanence arbitrer entre découvrir du contenu neuf et rafraîchir du contenu ancien. Et selon Google, les inefficacités de crawl viennent presque toujours d’un désalignement des phases du pipeline d’une URL, souvent aggravé par des directives robots.txt incorrectes. Ton crawl budget dépend donc d’abord de la cohérence de tes signaux.

La capacité de crawl est partagée entre tous les crawlers Google

Voici le point que presque aucun article français n’aborde. La limite de capacité de crawl est partagée entre tous les crawlers Google, alors que chacun a sa propre demande. Une forte demande d’un crawler réduit donc la capacité disponible pour les autres. Concrètement en 2026, les crawlers dédiés à l’IA, dont Google-Extended, et Googlebot puisent dans la même enveloppe.

C’est une piste d’analyse très concrète pour ton tableau de bord : corrèle les pics d’autres user-agents Google repérés dans tes logs à la chute de fréquence de Googlebot sur tes pages. Si les 2 courbes se croisent, tu as identifié l’un des mécanismes les plus opaques du crawl moderne, et une explication factuelle à une baisse de crawl que tu attribuais à tort à une pénalité.

Le 304 conditionnel et la vitesse serveur comme leviers officiels

Google recommande explicitement une chose simple et souvent ignorée : activer le HTTP caching et supporter le code 304 (Not Modified). Si une page n’a pas changé depuis le dernier passage de Googlebot, ton serveur doit répondre 304. Google réutilise alors sa version en cache, ce qui économise de la bande passante et des ressources serveur, donc du crawl budget. C’est un gain net sur les performances de ton hébergement.

Le second levier officiel est la vitesse du serveur : temps de réponse, poids des ressources, vitesse de chargement globale. Et là se cache l’asymétrie la plus piégeuse. La capacité de crawl peut chuter en quelques secondes quand Google se retire, par exemple parce que ton serveur souffre, mais mettre jusqu’à 1 à 3 semaines à remonter. Un incident de 10 minutes peut coûter un mois de crawl. Alerte donc sur le temps de réponse serveur, qui est la cause, pas sur le volume de crawl, qui n’est que la conséquence.

L’analyse de logs SEO : la seule méthode pour voir ce que Googlebot fait vraiment

Les logs sont des fichiers hébergés sur ton serveur web qui enregistrent chaque passage, humain ou bot, avec son horodatage. L’analyse de logs SEO consiste à les exploiter pour reconstituer ce que Googlebot a réellement fait sur ton site. C’est la seule méthode qui donne cette information : un crawler simule, les logs constatent. L’analyse manuelle sur Excel reste possible, mais elle est chronophage et n’historise rien. Plusieurs familles d’outils existent :

• Les analyseurs de logs et les commandes Linux pour les gros volumes.
• Les crawlers SaaS qui combinent crawl et ingestion de logs, comme Botify ou OnCrawl.
• Les crawlers locaux comme Screaming Frog ou Xenu.
• Les solutions open source comme Logz.io, Graylog ou Kibana, qui demandent des compétences Linux.

Ce qu’un fichier de log contient réellement

Un fichier de log brut est plus riche qu’on ne le croit. Chaque ligne contient des champs qui, croisés, racontent l’histoire complète d’un passage de robot :

• L’URL de la page visitée.
• L’URL source, autrement dit le referrer.
• Le code réponse : 200, 404, 301 ou 304.
• Le poids de la page servie.
• La date et l’heure exactes du passage.
• Le user agent, qui permet d’identifier Googlebot, un visiteur humain ou un autre bot.

Depuis le passage au Mobile First Index, filtre impérativement sur Googlebot mobile : raisonner sur les logs desktop revient à analyser un robot qui ne décide plus grand-chose. Avec les logs seuls, tu peux déjà savoir quelles pages Google connaît, lesquelles il ignore, à quelle fréquence il explore chaque page, et comment cette fréquence influence les visites issues de la recherche. C’est la base de tout diagnostic de crawl budget.

Logs seuls contre croisement logs plus crawler SEO

Les logs seuls ont une limite structurelle : ils ne parlent que des pages que Google connaît déjà. Une page que Googlebot n’a jamais visitée n’apparaît nulle part dans tes fichiers, donc tu ne peux pas la compter comme manquante. C’est le croisement avec un crawler SEO qui fait apparaître le reste, et personne d’autre ne te le montrera :

• Les pages orphelines, connues de Google mais absentes de ta structure.
• Les pages non crawlées, présentes dans ta structure mais ignorées de Googlebot.
• Le taux de crawl, le taux de pages actives et l’efficacité visites/crawl par catégorie.
• La part du crawl qu’une catégorie représente sur l’ensemble du site.
• Le PRic, le pagerank interne recalculé uniquement sur les pages réellement crawlées.

Détecter les pages orphelines en croisant logs et crawler

Une page orpheline, parfois appelée nomatch, est une page vue par Google mais inaccessible depuis la structure de ton site : aucun lien du maillage n’y pointe. Elle existe pour le moteur, elle n’existe plus pour tes visiteurs. Tu la détectes uniquement par le croisement : présente dans les logs, absente de la liste d’URLs produite par ton crawler. Aucun outil ne te le signalera spontanément.

La double conséquence est brutale. D’abord, la page ne bénéficie plus du pagerank interne, donc son potentiel de trafic s’effondre. Ensuite, elle gaspille du crawl budget au détriment des pages bien maillées. Et le constat est systématique : le taux de pages actives des orphelines est toujours inférieur à celui des URLs présentes dans la structure. Si tes orphelines accaparent une part importante du crawl, tu as une priorité d’optimisation, pas un détail. Le cas typique est le catalogue e-commerce avec forte rotation de produits expirés ou hors stock, qui restent accessibles en 200 alors qu’ils n’ont plus aucune valeur.

Les trois groupes d’URLs à distinguer dans ta fusion de données

La fusion de tes 2 sources de données doit produire 3 groupes d’URLs bien distincts, et c’est le socle de toute l’analyse. La méthode Excel est simple : une feuille urls structure extraite du crawler, une feuille urls logs extraite des logs filtrés sur Googlebot mobile, une RechercheV pour identifier les 3 groupes, puis une feuille all urls qui fusionne la structure et les orphelines avec toutes les données associées.

1. Structure inter Logs : les pages présentes dans ta structure et connues de Google. C’est ton crawl utile.
2. Structure moins Logs : les pages dans ta structure que Google n’a jamais crawlées. C’est ton potentiel non exploité.
3. Logs moins Structure : les pages connues de Google mais absentes de ta structure. Ce sont tes pages orphelines.

Les causes fréquentes de pages orphelines

Les causes de pages orphelines sont peu nombreuses et toujours les mêmes. Si tu en trouves, tu remontes souvent à un événement précis de l’histoire du site :

• Des pages d’une ancienne version du site jamais redirigées après une migration.
• Des pages expirées qui répondent encore en 200 au lieu d’un 404 ou d’un 410 clair.
• Des URLs mal générées dans le sitemap XML, qui poussent Google vers des adresses fantômes.

À côté des orphelines, d’autres gisements de crawl gaspillé méritent un audit :

• Les spider traps : calendriers, URLs infinies, navigations à facettes, identifiants uniques ajoutés à chaque visite.
• Les soft 404, qui renvoient un code 200 pour une page vide de sens.
• Les contenus dupliqués, qui diluent le budget sur plusieurs exemplaires du même sujet.
• Les redirections en chaîne, qui multiplient les passages de robot pour rien.

Calculer ton taux de crawl, ton taux de pages actives et ta fenêtre de crawl

Trois indicateurs structurent le diagnostic, et il faut lever une ambiguïté avant de les calculer. Le taux de crawl est le ratio entre les URLs uniques crawlées par Google et les URLs présentes dans ta structure. Le taux de pages actives est le ratio entre les pages ayant généré au moins une visite sur la période et l’ensemble des URLs connues. La fenêtre de crawl, elle, mesure la fréquence de passage nécessaire pour que ton site génère 90% de son audience.

Sépare bien 3 choses que tout le monde mélange : crawl, indexation et activité. Crawler une page ne veut pas dire l’indexer, et l’indexer ne veut pas dire générer du trafic. Ton objectif opérationnel est ensuite simple à formuler : concentrer tes efforts sur les catégories qui cumulent un faible taux de pages actives, un grand nombre de pages et une bonne efficacité visites/crawl. Ce sont les gisements sous-exploités de ton crawl budget.

Fréquence de crawl : jusqu’à 50 passages par jour sur une page

La fréquence de crawl est le nombre de fois que Googlebot passe sur une page sur une période donnée. Sur une page très populaire, comme ta page d’accueil, Google peut crawler jusqu’à 50 fois la même page par jour. Ce chiffre donne l’échelle : le crawl n’est pas binaire, il est profondément inégal selon les pages, et cette inégalité explique une grande partie de tes écarts de visites.

Une faible fréquence sur une page importante est un symptôme, jamais une fatalité. Elle signale en général un mauvais maillage interne, du contenu dupliqué ou une qualité de contenu insuffisante. Dernier piège de calcul : n’établis jamais une fréquence moyenne au niveau du site entier. La page d’accueil fausse toute la moyenne vers le haut. Calcule par catégorie, et compare au sein d’une même catégorie.

Fenêtre de crawl : 7 à 15 jours en général, jusqu’à 3 mois en longue traîne

La fenêtre de crawl a une définition opérationnelle précise : c’est la fréquence de crawl nécessaire pour qu’un site génère 90% de son audience. Si 90% des visites viennent de pages crawlées dans les 7 derniers jours, ta fenêtre de crawl est de 7 jours. Ce n’est pas une notion abstraite, c’est un objectif mesurable.

Les ordres de grandeur : 7 à 15 jours sur la plupart des sites, jusqu’à 3 mois sur les sites très longue traîne comme les forums. Ton objectif est clair : que toutes les pages génératrices de trafic soient crawlées à l’intérieur de cette fenêtre. Une page qui sort de la fenêtre est une page dont les mises à jour arrivent trop tard pour compter, quel que soit le travail fourni dessus.

Efficacité visites/crawl : le KPI que personne ne calcule

L’efficacité visites/crawl est le KPI que personne ne calcule, et c’est probablement le plus utile. Formule : volume de visites divisé par volume de crawl Googlebot. Il se lit par catégorie, jamais au niveau global, sinon la moyenne lisse tout et tu ne vois plus rien.

Valeur élevée : Google crawle peu mais la catégorie convertit bien, tu dois augmenter le crawl via le maillage. Valeur faible : Google crawle beaucoup pour peu de visites, signe d’un problème de contenu, de ciblage sémantique ou de duplication. Compare aussi ce ratio entre tes pages en structure et tes pages orphelines : l’efficacité des orphelines est toujours moindre. Cet indicateur est absent des outils du marché, et pourtant il est central pour prioriser tes optimisations.

Construire un tableau de bord SEO basé sur les logs, étape par étape

Le SEO est une science, pas un art, et l’analyse de logs est ta meilleure arme de conviction. Un comité de direction ne discute pas une opinion sur la navigation : il discute une courbe. Si tu prouves par les données que le mega-menu gaspille 30% du crawl budget pour quelques visites, la refonte devient une évidence chiffrée. C’est tout l’intérêt de la méthode.

La démarche complète tient en 10 étapes, et l’ordre compte. On commence toujours par la donnée brute, on la catégorise, on calcule, puis on alerte. Voici la progression :

• Croiser les URLs des logs et celles du crawler.
• Catégoriser les URLs avec des regex.
• Extraire les KPIs de base via un tableau croisé dynamique.
• Séparer structure et orphelines sur ces mêmes KPIs.
• Calculer l’efficacité visites/crawl.
• Calculer le taux de crawl et le taux de pages actives.
• Recalculer le pagerank interne des pages crawlées.
• Calculer la fréquence de crawl par catégorie.
• Comparer les ratios par catégorie à ceux du site entier.
• Enrichir avec Search Console, Analytics et les données de backlinks.

Catégoriser les URLs avec des regex avant tout calcul

Sans catégorisation, tu n’as que 2 niveaux d’information : le site entier, trop macro, ou l’URL seule, sans intérêt opérationnel. C’est la catégorie qui rend l’analyse utilisable. Elle se construit avec des expressions régulières, les regex, bien plus précises et sans erreur que les filtres avancés d’Excel sur un site complexe.

Le type d’insight que tu débloques : « la catégorie X est très crawlée mais génère peu de trafic qualifié, la catégorie Y est peu crawlée mais très efficace ». La conclusion est immédiate : mailler depuis X vers Y pour transférer du pagerank interne et du crawl vers les pages qui méritent. Ce raisonnement est impossible sans catégorisation, et c’est là que se joue l’optimisation réelle de ton crawl budget.

Volume de crawl, pages uniques, pages actives et PRic

Quatre KPIs de base se lisent dans un tableau croisé dynamique, avec les catégories en lignes :

• Volume de crawl, en somme.
• Volume de visites, en somme.
• Pages uniques crawlées, en nombre.
• Pages actives, en nombre.

Ajoute à cela la distinction entre PRi et PRic, que peu de praticiens maîtrisent. Le PRi est le pagerank interne calculé sur toute la structure : c’est une vue théorique, celle qu’aurait Google s’il crawlait tout. Le PRic est recalculé uniquement sur les pages vues par Googlebot : c’est la vue réelle. Aucun outil du marché ne le calcule nativement. Méthode : filtrer dans ton fichier les URLs à la fois présentes dans la structure et crawlées, puis recalculer le pagerank interne sur ce seul sous-ensemble, avec Botify, Netpeak Spider ou Screaming Frog couplé à un script R. Affiche ensuite par catégorie la part du crawl, la part des visites, la part du pagerank interne et la part des orphelines : les déséquilibres sautent aux yeux immédiatement.

Calibrer les seuils d’alerte sur les délais réels de Google

Un tableau de bord n’a de valeur que si ses alertes ne crient pas au loup. Le principe : ne pas alerter avant que le délai typique du processus concerné soit dépassé. Sinon tu noies ton utilisateur sous les faux positifs et il désactive tout au bout de 2 jours. Voici les seuils planchers que je pose, directement issus des délais officiels :

Le point le plus contre-intuitif concerne la capacité de crawl. Elle chute en quelques secondes quand Google se retire et met 1 à 3 semaines à remonter. Un tableau de bord qui alerte sur le volume de crawl alerte donc trop tard, systématiquement. Il faut alerter sur le temps de réponse serveur, qui est la cause, pas sur le volume, qui est la conséquence. Et n’oublie jamais que les délais s’empilent : un changement de canonique sur une page nouvellement découverte cumule la découverte, la file de rendu, surtout quand la page dépend du JavaScript, puis la canonicalisation.

Optimiser ton budget de crawl : le plan d’action priorisé

Optimiser ton crawl budget, ce n’est pas un levier unique, c’est une articulation. Quatre familles d’actions : réduire le crawl inutile, orienter Googlebot vers les pages stratégiques, accélérer le serveur et fiabiliser les directives. Dans cet ordre, tu récupères le maximum de budget sans réécrire tout ton site.

Distingue surtout les leviers rapides des leviers lents. Les 4 leviers rapides, qui s’appliquent en heures à 2 jours, sont le title, le snippet, le robots.txt et la suppression via Search Console. Tout le reste se compte en semaines : maillage, migration, canonique. Et comme ta fenêtre de crawl est longue, l’optimisation cible surtout la longue et la moyenne traîne. La short tail suit indirectement, sans que tu aies à la travailler en direct.

Réduire le crawl inutile : redirections, soft 404 et duplication

Commencer par supprimer, c’est souvent le gain le plus rapide. Chaque passage de robot sur une page inutile est un passage perdu pour une page utile :

• Traiter les redirections en chaîne, qui consomment du crawl sans rien apporter.
• Nettoyer les soft 404 en renvoyant un vrai code 404.
• Supprimer les contenus dupliqués et les pages à faible qualité.
• Régler les spider traps, en particulier les facettes et les calendriers.
• Détecter les serveurs qui renvoient systématiquement 200 sur des pages inchangées au lieu d’un 304. Ce contrôle est automatisable, autant en faire une alerte.

Orienter Googlebot vers les pages stratégiques

Réduire, c’est bien. Rediriger le crawl vers ce qui compte, c’est mieux. Garde en tête la frontière entre crawl et indexation : une page crawlée n’est pas forcément indexée, et une page indexée ne génère pas forcément de visites. L’optimisation du crawl sert la seconde étape, elle ne la remplace pas. Trois actions structurent cette orientation :

• Renforcer le maillage interne et revoir la navigation pour réduire la profondeur des pages à fort potentiel.
• Maintenir un sitemap XML exact et à jour : un sitemap sale envoie Google vers des erreurs et duplique la découverte des mêmes pages.
• Vérifier la précision du fichier robots.txt, pour bloquer ce qui n’a aucune valeur SEO sans créer d’incohérence avec le pipeline de crawl.

Les erreurs à éviter quand tu analyses tes logs

Les erreurs d’analyse de logs sont toujours les mêmes quand je reprends un rapport existant. Aucune ne coûte cher à corriger, mais chacune fausse une décision. Les voici, pour que tu ne les répètes pas :

• Calculer des moyennes au niveau du site entier alors que la page d’accueil fausse tout.
• Confondre taux de crawl, taux d’indexation, taux de pages actives et fréquence de crawl.
• Alerter sur le volume de crawl au lieu du temps de réponse serveur, donc toujours trop tard.
• Oublier de filtrer sur Googlebot mobile, ou mélanger les user-agents bots et humains.
• Réutiliser une analyse ponctuelle sans historisation : sans courbes d’évolution, impossible de distinguer un incident d’une saisonnalité.

De l’analyse manuelle Excel au monitoring continu

L’approche manuelle sur Excel a des limites structurelles. Tu extrais les logs, tu exportes le crawl, tu croises, tu recalculs : à chaque redémarrage, le travail est refait de zéro. Surtout, tu n’historises rien. Or sans courbes d’évolution, tu ne peux pas dire si une baisse de fréquence sur 30 jours est un incident ou une saisonnalité.

C’est là que l’automatisation change d’échelle. Un crawl hebdomadaire, une ingestion régulière des logs, une historisation des KPIs et des alertes calibrées sur les seuils officiels donnent un pilotage continu au lieu d’un diagnostic ponctuel. Tu ajoutes ensuite Google Search Console, Analytics et les données de backlinks dans le même tableau de bord, et tu passes d’une photo à un film. Suivre les performances de ton crawl budget dans la durée devient alors une routine, pas un projet.

Questions fréquentes sur le crawl budget seo et l’analyse de logs

Voici les questions qui reviennent le plus sur le crawl budget seo et l’analyse de logs, avec des réponses courtes. Chaque réponse reste autoportante et renvoie à la section détaillée correspondante.

Est-ce que tous les sites sont concernés par le budget de crawl ?

Tous les sites ont un budget de crawl, mais l’enjeu devient critique au-delà de quelques milliers d’URLs. En dessous, une mauvaise répartition coûte peu. Au-dessus, elle coûte des mois. Les praticiens considèrent que l’analyse devient indispensable au-delà de 1 000 pages, quand la simulation ne suffit plus à expliquer les écarts entre pages en ligne et pages connues.

Les signaux qui doivent t’alerter au quotidien :

• Des pages importantes sont peu crawlées malgré un fort potentiel de trafic.
• Une part importante du crawl est absorbée par des pages sans valeur.
• La fréquence de crawl de tes pages stratégiques baisse sans raison apparente pendant plusieurs jours.

Combien de temps Google met-il pour crawler et indexer une page ?

Voici les ordres de grandeur officiels, présentés par Gary Illyes lors du Google Search Central Live Deep Dive de Barcelone en octobre 2026. Garde en tête qu’ils s’empilent, du crawl au rendu puis à l’indexation, et qu’un tableau de bord qui attend un effet en 48 heures mesure du bruit :

• Découverte d’une URL nouvelle : environ 20 heures en typique, de semaines à jamais dans le pire cas.
• Rafraîchissement d’une URL connue : environ 30 jours.
• Traitement d’un sitemap : environ 24 heures, jusqu’à 14 jours, ou jamais si la qualité est insuffisante.
• Indexation bout en bout : environ 1,5 heure en typique.
• Mise à jour de la capacité de crawl : 4 heures à 1 à 2 semaines, jusqu’à 1 à 3 semaines en phase de récupération.

Peut-on optimiser son crawl budget sans accéder aux logs ?

Partiellement. Avec Google Search Console et un crawler SEO, tu accèdes au rapport de couverture et aux statistiques de crawl. C’est utile, mais tu n’as aucune preuve de ce que Googlebot fait réellement, page par page, jour après jour sur ton crawl budget.

Ce que Search Console ne te montrera jamais : tes pages orphelines, l’efficacité visites/crawl par catégorie ou ton PRic. La recommandation est donc simple : demande l’accès aux logs serveur, et si on te le refuse, obtiens au minimum une extraction régulière sur des périodes comparables. L’idée directrice reste de comparer ce qui est comparable, sinon tu analyses du bruit et tu prends de mauvaises décisions structurelles.

Ce qu’il faut retenir

Le budget de crawl n’est pas une notion abstraite, c’est une enveloppe mesurable dans tes logs. Voici ce qu’il faut retenir, et pourquoi je te recommande de mettre en place ton tableau de bord puis d’automatiser le suivi :

• Les logs seuls montrent ce que Google connaît ; le croisement avec un crawler révèle les pages orphelines et les pages non crawlées.
• Les pages orphelines gaspillent du crawl et leur taux de pages actives est toujours inférieur à celui de la structure.
• Le taux de crawl, le taux de pages actives, la fenêtre de crawl et l’efficacité visites/crawl se calculent par catégorie, jamais au niveau global.
• La capacité de crawl est partagée entre tous les crawlers Google, crawlers dédiés à l’IA compris.
• Les seuils d’alerte se calibrent sur les délais réels de Google : découverte 20 heures, indexation 1,5 heure, canonique 3 semaines, title 2 jours.
• On alerte sur le temps de réponse serveur avant le volume de crawl, parce que la capacité chute en secondes et remonte en 1 à 3 semaines.
• Le passage à l’automatisation et à l’historisation transforme un diagnostic ponctuel en pilotage continu de ton crawl budget.

Si tu veux suivre l’aventure, abonne-toi !