Checklist de gestion du crawl budget

Le crawl budget est la limite pratique du nombre de pages qu’un moteur de recherche est prêt et capable d’explorer sur un site au fil du temps. Le gérer consiste à réduire les requêtes qui ne peuvent pas améliorer la découverte ou l’indexation, puis à rendre les URL importantes plus faciles à trouver et moins coûteuses à récupérer.

Checklist : gestion du crawl budget. Durée : 1 à 2 jours ouvrés pour le diagnostic, puis 1 à 3 sprints d’ingénierie pour les correctifs approuvés. Responsable : responsable SEO technique. Contributeurs : ingénieur plateforme, propriétaire CDN ou infrastructure, ingénieur analytics, et responsable merchandising ou contenu pour tout espace d’URL concerné. Autorité de publication : responsable SEO technique et responsable ingénierie conjointement.

Soyez clair sur le périmètre : un site sain de 2 000 ou 8 000 pages canoniques n’a presque jamais besoin d’un projet de crawl budget. Il a un problème de priorisation, de liens, de qualité ou d’indexabilité. Lancez cette checklist lorsqu’un site vaste ou en évolution rapide présente des preuves de gaspillage de crawl, de découverte retardée, de crawl répété d’URL de faible valeur ou de tension sur l’hébergement — pas simplement parce qu’un rapport de crawl contient un grand nombre.

Pourquoi cette phase, et pourquoi ici

Bien qu’il s’agisse d’une checklist autonome plutôt que d’une phase numérotée, elle consomme l’audit technique de base : règles canoniques, résultats des codes de statut, comportement de rendu, architecture du site, inventaire des sitemaps et couverture d’index. Elle nécessite également un inventaire de contenu approuvé, car le « gaspillage » ne peut être défini tant que l’entreprise n’a pas indiqué quelles URL doivent être trouvées, mises à jour et indexées.

Exécutez-la après que l’équipe a appris à distinguer les pages canoniques de valeur des filtres, doublons, inventaire expiré, recherche interne et routes administratives. L’exécuter plus tôt encourage le blocage aveugle. L’exécuter après un déploiement programmatique massif, une migration ou une version de navigation à facettes est trop tard : les robots peuvent déjà être piégés dans un espace d’URL effectivement illimité.

Si elle est ignorée sur un site véritablement vaste, les nouvelles URL prioritaires et celles modifiées peuvent attendre derrière d’innombrables combinaisons de paramètres, pages d’erreur, chaînes de redirection et doublons. Si elle est exécutée sur un petit site sain, elle consomme du temps d’ingénierie sans résoudre la véritable contrainte. L’argument de dépendance est simple : la classification vient avant le contrôle, et les preuves viennent avant les règles.

Entrées et sorties

Les sorties sont le contrat avec l’ingénierie et le prochain cycle de mesure. « Améliorer l’efficacité du crawl » n’est pas un livrable.

La checklist

Enregistrez RÉUSSI, ÉCHEC ou N/A et joignez les preuves pour chaque élément. Chaque élément est complet uniquement lorsque sa condition « Fait quand » peut être observée.

1. Prouver que le crawl budget est la contrainte

Quoi : décider si ce travail mérite un projet. Pourquoi : le crawl budget est souvent accusé alors qu’une page est en réalité de faible qualité, orpheline, non canonique, bloquée ou intentionnellement exclue. Comment : comparez le nombre d’URL canoniques, la création quotidienne d’URL, la santé du serveur, les dates de dernier crawl, le délai de découverte, les raisons de couverture et la part des requêtes de bots vérifiées passées en dehors de l’inventaire canonique. Segmentez par répertoire et template ; une moyenne à l’échelle du site cache une section problématique. Outil : pipeline de logs, robot d’exploration, rapports de couverture des moteurs de recherche, exports de sitemaps et calendrier des publications. Fait quand : un diagnostic signé nomme au moins une contrainte mesurée ou ferme la checklist avec la mention « non significatif », accompagné des preuves et d’une action plus appropriée recommandée.

2. Construire un ensemble de données fiable des requêtes de bots

Quoi : créer une table de requêtes normalisée pour la fenêtre d’analyse. Pourquoi : les chaînes user-agent peuvent être usurpées, les analytics échantillonnés omettent les bots, et les logs CDN peuvent différer des logs d’origine. L’analyse des fichiers journaux consiste à examiner les enregistrements d’accès serveur pour voir ce que les robots ont réellement demandé. Comment : combinez les données CDN et d’origine si nécessaire, normalisez l’hôte et l’encodage des URL, supprimez les assets statiques sauf si le rendu est dans le périmètre, vérifiez les principaux bots de recherche avec la méthode de vérification publiée par le fournisseur, et conservez le statut, les octets, le temps de réponse et le résultat du cache. Outil : logs CDN ou serveur web, vérification DNS, SQL ou un analyseur de logs. Fait quand : la plage de dates et la rétention sont documentées, les bots connus sont séparés des agents non vérifiés, les totaux correspondent aux enregistrements bruts, et la même requête peut reproduire chaque graphique du diagnostic.

3. Mesurer où les requêtes sont gaspillées

Quoi : classer chaque requête de robot en : canonique utile, duplicata, redirection, erreur, bloquée, paramètre, facette, recherche interne, soft-404, asset ou inconnue. Une soft-404 est une page qui renvoie 200 OK mais se comporte comme un résultat manquant ou vide. Pourquoi : le volume total de crawl ne peut pas montrer si les robots actualisent l’inventaire ou tournent en boucle sur des états sans valeur. Comment : joignez les requêtes à l’inventaire de crawl et canonique, regroupez par chemin normalisé et signature de paramètre, puis classez les modèles par nombre de requêtes et coût serveur. Conciliez ces modèles avec les raisons de couverture telles que découvert mais non indexé, exploré mais non indexé, duplicata, bloqué et soft-404 ; la couverture explique le résultat rapporté par un moteur de recherche, tandis que les logs prouvent les requêtes. Inspectez manuellement le groupe inconnu plutôt que de le forcer dans une étiquette commode. Outil : logs vérifiés, export de couverture, robot de site, export canonique et profileur de réponses. Fait quand : au moins 95 % des requêtes de robots dans le périmètre ont une classification vérifiée, le reste inconnu est listé, et les principaux modèles de gaspillage ont des exemples d’URL, des résultats de couverture et des propriétaires.

4. Contenir les facettes et paramètres à la source

Quoi : gouverner les paramètres de filtre, tri, pagination, suivi, session et recherche. La navigation à facettes permet aux utilisateurs de combiner des filtres tels que la marque, la couleur et la taille ; des combinaisons non contrôlées peuvent créer un espace de crawl potentiellement infini. Pourquoi : bloquer un robot après que les templates ont généré des millions de liens traite le symptôme tout en laissant la découverte, le comportement des utilisateurs, les analytics et les autres bots exposés. Comment : attribuez à chaque paramètre une fonction et une politique : page de destination indexable, duplicata canonique, page noindex, redirection, état sans lien ou modèle bloqué. Utilisez un ordre de paramètres stable, empêchez les combinaisons vides et contradictoires, et supprimez les paramètres de suivi ou de session des liens internes. Ne canonicalisez pas une page vers une cible dont le contenu est significativement différent simplement pour la supprimer. Outil : registre des paramètres, source du template, robot avec rapports de modèles d’URL, logs et tests d’URL automatisés. Fait quand : chaque paramètre observé a une politique approuvée, les templates explorables n’émettent que les combinaisons autorisées, les combinaisons interdites ont une couverture de test, et le volume de logs pour les modèles ciblés diminue au point de contrôle convenu.

5. Éliminer les espaces infinis et les pièges de crawl

Quoi : fermer les routes qui peuvent générer des dates, calendriers, paginations, IDs, variantes de casse, segments de chemin ou filtres récursifs illimités. Pourquoi : un robot peut continuer à découvrir syntaxiquement de nouvelles URL même si chaque page contient le même résultat vide ou dupliqué. Comment : fixez des limites finies, renvoyez 404 ou 410 pour les états impossibles, liez uniquement aux plages valides, normalisez les règles de casse et de barre oblique, redirigez les doublons exacts une seule fois, et cessez de générer des liens vers la page suivante au-delà de l’ensemble final de résultats. Testez les valeurs malformées et extrêmes, pas seulement le cas nominal. Outil : générateur d’URL synthétiques, robot, logs, tests de routage et tests de règles périphériques. Fait quand : chaque générateur a un maximum documenté, les états hors limites renvoient la réponse prévue, aucune route testée ne crée une nouvelle séquence illimitée, et les modèles de requêtes affectés diminuent sans bloquer les pages de valeur.

6. Corriger les soft-404, les erreurs et le gaspillage par redirections

Quoi : faire en sorte que les codes de réponse décrivent le résultat réel. Pourquoi : une page vide avec un 200 demande aux robots d’analyser et d’évaluer un contenu qui aurait dû être déclaré manquant ; des réponses 5xx répétées consomment de la capacité et peuvent faire paraître un hôte peu fiable ; les chaînes de redirection nécessitent plusieurs requêtes pour atteindre une seule destination. Comment : renvoyez 404 pour les URL manquantes, 410 pour les ressources intentionnellement supprimées le cas échéant, 200 uniquement pour les pages substantielles, et une seule redirection vers la destination canonique finale pour les URL déplacées. Réparez les liens internes qui pointent vers des redirections ou des erreurs. Outil : logs, robot, suite de tests HTTP, monitoring et inventaire des routes. Fait quand : les résultats vides échantillonnés ne renvoient plus 200, les routes prioritaires n’ont pas de chaîne de redirection, les liens internes aboutissent directement, et le seuil de taux d’erreur défini dans les règles de décision est respecté pendant deux fenêtres de mesure consécutives.

7. Assurer la cohérence des contrôles canoniques et d’indexation

Quoi : aligner la réponse, l’URL canonique , les meta robots, les en-têtes HTTP robots, les liens internes et l’appartenance au sitemap. Pourquoi : des signaux contradictoires entraînent des visites répétées : une URL peut être soumise dans un sitemap, canonicalisée ailleurs, liée dans toute la navigation et bloquée par la directive qui explique son statut. Comment : créez une matrice de règles pour chaque classe d’URL et testez la réponse de production rendue. Utilisez robots.txt pour gérer l’accès des robots, pas comme un mécanisme de suppression fiable ; une URL bloquée ne peut pas révéler une directive noindex au niveau de la page à un robot qui ne la récupère jamais. Outil : robot, HTML brut et rendu, inspecteur d’en-têtes, testeur robots et inspection d’URL. Fait quand : 100 % des échantillons prioritaires et tous les cas de test de template correspondent à une règle cohérente, sans aucune URL canonique indexable bloquée et sans motif exclu promu via les sitemaps ou la navigation principale.

8. Nettoyer les sitemaps XML pour en faire un flux prioritaire

Quoi : publier uniquement des URL canoniques, indexables, avec code 200 et des dates de modification véridiques dans chaque sitemap XML . Pourquoi : un sitemap est un signal de découverte, pas une archive de chaque URL que le CMS a produite. Les redirections, doublons, erreurs et horodatages lastmod inchangés diluent ce signal et obscurcissent les comparaisons de couverture. Comment : conciliez les URL du sitemap avec l’inventaire canonique, fractionnez les fichiers par unités de diagnostic stables comme le type de contenu ou le répertoire, supprimez les URL exclues et mettez à jour lastmod uniquement pour les changements substantiels de page. Soumettez les sitemaps modifiés et enregistrez le téléchargement, les avertissements et les erreurs. Outil : analyseur de sitemap, export CMS, logs et rapports de sitemap des moteurs de recherche. Fait quand : chaque URL soumise renvoie 200, est auto-canonique et indexable, les exclusions sont à zéro, lastmod passe une vérification de changement de contenu échantillonnée, et les comptes soumis correspondent à l’inventaire approuvé.

9. Utiliser les liens internes pour rapprocher les pages prioritaires

Quoi : réparer les pages orphelines et réduire la distance en clics vers les URL à forte valeur ajoutée grâce à des liens internes utiles. La profondeur de crawl est le nombre d’étapes de liens dont un robot a besoin pour atteindre une page à partir d’une page de départ choisie. Pourquoi : bloquer le gaspillage ne dit pas à un robot quoi visiter ensuite ; les liens HTML stables provenant de pages fortes et fréquemment visitées le font. Comment : calculez la profondeur et les liens entrants depuis la page d’accueil et les hubs pertinents, ajoutez des liens contextuels ou de navigation là où les utilisateurs en bénéficient, remplacez les liens vers des URL redirigées et assurez-vous que la pagination expose l’inventaire plus profond. N’aplatissez pas tout dans un pied de page. Outil : robot de graphe de liens, templates, logs et performance de recherche par répertoire. Fait quand : chaque URL prioritaire a au moins un lien entrant explorable, aucune prioritaire orpheline ne subsiste, les templates prioritaires convenus sont à moins de trois étapes de lien d’un hub pertinent, et les logs confirment que les échantillons nouvellement liés sont découverts ou revisités.

10. Protéger la capacité de l’hôte et les chemins de rendu

Quoi : maintenir les requêtes des robots rapides et réussies sans servir aux bots de recherche une page sensiblement différente. Pourquoi : la demande de crawl ne peut pas compenser un hôte qui expire, limite les robots légitimes de manière indistincte ou nécessite un rendu coûteux pour le contenu et les liens de base. Comment : comparez le temps de réponse et les erreurs par bot, route, état du cache et template ; mettez en cache les réponses sûres ; supprimez les chemins de requête coûteux ; préservez le HTML essentiel et les liens dans la réponse initiale ; et testez les règles du pare-feu et du CDN avec des bots vérifiés. Outil : surveillance des performances applicatives, analytics CDN, logs, tests de disponibilité et inspection des pages rendues. Fait quand : l’hôte respecte les seuils de réponse et d’erreur convenus sous charge attendue, les robots vérifiés ne sont pas accidentellement bloqués, et le contenu prioritaire ainsi que les liens sont présents sans interaction utilisateur.

11. Déployer par modèle et vérifier le compromis

Quoi : publier l’ensemble de règles cohérent le plus petit possible, puis comparer avant et après. Pourquoi : un changement global de robots, de canoniques, de routage ou de navigation peut supprimer des pages de longue traîne précieuses plus rapidement qu’il ne supprime le gaspillage. Comment : commencez avec un modèle d’URL ou un répertoire mesurable, préservez un groupe de contrôle lorsque c’est pratique, annotez la publication, et comparez les requêtes de bots, les erreurs, la latence de re-crawl prioritaire, la couverture, les impressions et la charge serveur après un cycle de crawl complet. Gardez les instructions de retour arrière à côté de la règle. Outil : journal de déploiement, logs serveur, rapports de couverture, rapports AmICited et monitoring. Fait quand : la mesure de gaspillage cible s’améliore, la découverte et l’indexation prioritaires ne régressent pas au-delà de la tolérance déclarée, le propriétaire signe le résultat, et la décision de prochain déploiement ou retour arrière est enregistrée.

Outils dans AmICited

AmICited fournit des preuves des moteurs de recherche et de performance pour le diagnostic. Les logs serveur bruts restent la source de vérité pour le comportement au niveau des requêtes entre les bots.

1. Ouvrez Bing Crawl sur le rapport Bing Crawl en direct pour examiner l’activité de crawl de Bing et les problèmes d’URL signalés. Capturez la plage, le type de problème, les exemples d’URL et l’heure d’exportation ; ne généralisez pas le comportement de Bing à tous les robots.

2. Utilisez Sitemaps et Indexation sur le rapport de sitemap pour comparer les comptes soumis, le dernier téléchargement, les avertissements et les erreurs, soumettre un sitemap nettoyé, ou demander l’indexation d’un lot limité d’URL prioritaires modifiées. Une demande accélère la reconsidération ; elle ne rend pas une page bloquée ou de faible qualité indexable.

3. Vérifiez les gagnants représentatifs, les modèles de gaspillage et les pages réparées dans Inspection d’URL sur le rapport d’inspection d’URL . Enregistrez la canonique déclarée et sélectionnée, le verdict de couverture, le dernier crawl et l’heure d’inspection. Sa vue de couverture est un échantillon croissant, pas un rapport complet de crawl budget.

4. Ouvrez Google Search Directories sur le rapport des répertoires pour comparer les clics et les impressions par section avant de restreindre un répertoire ou de modifier ses liens. Une section à faible trafic peut encore être stratégiquement nécessaire ; utilisez ce rapport pour dimensionner l’impact search, pas pour déclarer un gaspillage de crawl par lui-même.

Règles de décision : à quoi ressemble un problème en chiffres

Il s’agit de déclencheurs opérationnels pour cette checklist, pas de limites universelles des moteurs de recherche. Remplacez-les uniquement avec une base de référence documentée du site et une tolérance au risque approuvée.

N’ouvrez pas un projet de crawl budget uniquement parce que le site dépasse une ligne de comptage d’URL. Inversement, n’écartez pas un site de 20 000 pages dont le piège de calendrier génère des millions d’URL distinctes. La preuve d’une découverte contrainte ou d’un gaspillage est le facteur décisif.

Livrable

Remettez un package versionné, pas un diaporama indiquant « crawl optimisé » :

• crawl-budget-summary.md : périmètre, décision, méthode de vérification des bots, fenêtre d’analyse, résultats, traitements approuvés, risques, ordre de publication et déclencheurs de retour arrière.
• crawl-pattern-register.csv : modèle normalisé, exemple d’URL, objectif, nombre de requêtes, part, réponse, état canonique, état du sitemap, liens entrants, valeur métier, traitement, propriétaire et statut.
• priority-url-sample.csv : au moins 20 URL avec champs de base et de point de contrôle pour la découverte, dernier crawl, verdict d’index, profondeur, liens entrants, réponse et canonique sélectionnée.
• sitemap-reconciliation.csv : URL soumise, état dans l’inventaire, réponse, canonique, indexabilité, validation lastmod, action et preuve.
• monitoring-spec.md : requêtes, tableaux de bord, seuils, propriétaires, cadence, routes d’alerte, dates de point de contrôle et rétention.

Le responsable SEO technique possède le package ; l’ingénierie signe les modifications de routes et d’infrastructure ; le responsable du contenu ou du merchandising signe toute décision qui supprime un chemin utilisateur découvrable ou une page de destination indexable.

Ce qui peut mal tourner

L’équipe optimise un minuscule site. Les ingénieurs passent un sprint à bloquer des paramètres tandis que les pages importantes restent pauvres ou orphelines. Fermez la checklist comme non significative et redirigez le travail vers le contenu, les liens ou l’indexabilité.

Robots.txt devient un outil de suppression. Les URL bloquées peuvent rester connues, et les robots ne peuvent pas récupérer leurs directives au niveau de la page. Définissez d’abord le cycle de vie prévu, supprimez la génération interne et utilisez la réponse, la redirection, la canonique ou le comportement noindex qui correspond.

Chaque facette est traitée comme un duplicata. Une combinaison marque-et-catégorie avec une demande réelle peut être une page de destination utile ; un ordre de tri ne l’est généralement pas. Décidez au niveau du modèle en utilisant la demande et le caractère distinctif du contenu.

On s’attend à ce qu’une balise canonique arrête le crawl. Les canoniques expriment une version préférée, mais les doublons peuvent encore être récupérés pour évaluer la relation. Supprimez les liens et la génération inutiles plutôt que de compter sur un seul indice.

Les sitemaps deviennent des vidages de base de données. Les URL redirigées, expirées, bloquées et non canoniques obscurcissent l’inventaire que l’équipe souhaite réellement voir exploré. Conciliez l’appartenance au sitemap comme une étape de validation de publication.

Les analytics sont confondus avec les logs. Les analytics côté client enregistrent rarement les requêtes des robots de recherche. Sans logs d’accès vérifiés, l’équipe ne peut pas mesurer l’allocation des requêtes ni le coût des réponses.

Le déploiement bloque des pages de revenus. Une règle large sur les paramètres ou les chemins touche des catégories valides, des pages localisées, la pagination ou des destinations de campagne. Testez des exemples positifs et négatifs, déployez un modèle à la fois et gardez un retour arrière rapide.

Le succès signifie moins de requêtes. Le volume de crawl peut chuter parce que des pages de valeur ont disparu de la découverte. Un changement réussi réduit le gaspillage tandis que la découverte prioritaire, l’indexation et la demande search restent saines.

Phase suivante

Alimentez le registre des modèles, la réconciliation des sitemaps, l’échantillon prioritaire et les seuils de monitoring dans le rafraîchissement et itération continus . Cette phase a besoin de chemins de découverte stables et de signaux de changement fiables ; sinon, une page rafraîchie peut être publiée correctement mais attendre invisible derrière des pièges de crawl ou des liens internes faibles.

Rouvrez cette checklist après une migration, un changement de plateforme ou de routage, une version de navigation à facettes, une expansion majeure d’inventaire, un incident d’erreur soutenu ou un dépassement de seuil convenu. Ne réexécutez pas l’intégralité de l’exercice selon un calendrier lorsque la base de référence de monitoring reste propre.

FAQ

La FAQ ci-dessous couvre le périmètre, les règles robots, les paramètres, les sitemaps et la cadence de révision. Le principe directeur est cohérent : classifiez d’abord l’espace d’URL, utilisez les preuves de requêtes en second lieu, et modifiez les contrôles des robots uniquement lorsque le résultat souhaité pour l’utilisateur et l’indexation est explicite.