Gestion du budget de crawl

Le budget de crawl est la combinaison de deux facteurs : la limite de fréquence de crawl (combien de requetes par seconde Googlebot peut faire sans surcharger votre serveur) et la demande de crawl (a quel point Google veut explorer votre site en fonction de sa popularite et de sa fraicheur). Ensemble, ils determinent le nombre total de pages que Googlebot explorera sur une periode donnée.

Pour les petites boutiques avec moins de 5 000 pages, le budget de crawl est rarement un probleme. Google explorera régulièrement l'ensemble de votre site sans difficulte. Mais une fois que votre boutique depasse 10 000 URLs (y compris les variations de parametres, les pages de filtres et les listes paginees), le budget de crawl devient un veritable goulot d'etranglement.

Une boutique de mode de taille moyenne que nous avons auditee avait 8 000 produits reels mais plus de 340 000 URLs crawlables en raison de la navigation a facettes, des parametres de couleur/taille, des variations de tri et de la pagination. Googlebot consacrait 85 % de son budget de crawl a ces pages de parametres sans valeur, tandis que 30 % des pages produits reelles n'avaient pas ete re-explorees depuis plus de 90 jours.

Le gaspillage de crawl se produit quand Googlebot passe du temps a explorer des pages qui n'apportent aucune valeur SEO. En e-commerce, les principales sources de gaspillage sont les URLs de navigation a facettes, les pages de parametres, les pages de resultats de recherche interne et la pagination excessive.

La navigation a facettes est le pire coupable. Une page de catégorie avec des filtres pour marque, couleur, taille, prix et note peut generer des milliers de combinaisons d'URLs. Chaque combinaison (/chaussures?marque=nike&couleur=noir&taille=42) est une URL crawlable separee qui montre generalement les memes produits dans un arrangement legerement différent. Google n'a pas besoin de toutes les explorer.

Les parametres de tri gaspillent le budget de crawl silencieusement. Des URLs comme /catégorie?tri=prix-croissant, /catégorie?tri=prix-decroissant, /catégorie?tri=plus-recents et /catégorie?tri=meilleures-ventes montrent toutes les memes produits. Ces pages n'ajoutent aucun contenu unique mais peuvent tripler ou quadrupler votre nombre d'URLs crawlables.

Les identifiants de session et les parametres de tracking ajoutes aux URLs (/produit?utm_source=email&session=abc123) creent des versions crawlables en double de chaque page. Si votre plateforme ajoute ces parametres et ne les gere pas avec des balises canonical, vous multipliez inutilement votre surface de crawl.

L'outil principal pour prevenir le gaspillage de crawl est le robots.txt. En interdisant certains modèles d'URL, vous indiquez a Googlebot de ne pas explorer ces pages. Pour le e-commerce, cela signifie generalement bloquer les parametres de filtres a facettes, les ordres de tri, les resultats de recherche interne et les pages panier/paiement.

Un robots.txt pratique pour une boutique e-commerce pourrait inclure des règles comme Disallow: /*?sort=, Disallow: /*?filter=, Disallow: /search et Disallow: /cart. Ces règles empechent Googlebot de gaspiller du budget de crawl sur des pages qui ne devraient jamais apparaitre dans les resultats de recherche.

Soyez prudent avec le blocage robots.txt. Il empeche le crawl, pas l'indexation. Si d'autres pages lient vers une URL bloquee, Google peut quand meme l'indexer en se basant sur le texte d'ancrage et le contexte des liens, meme sans avoir explore la page. Pour les pages que vous voulez complètement exclues de l'index, combinez le blocage robots.txt avec des balises meta noindex ou des balises canonical.

Une autre approche est d'utiliser l'outil Parametres d'URL dans Google Search Console pour indiquer a Google comment des parametres spécifiques affectent le contenu de la page. Vous pouvez indiquer si un parametre comme "sort" modifie le contenu, et si Google doit explorer toutes, certaines ou aucune URL avec ce parametre.

Google Search Console fournit un rapport Statistiques de crawl sous Parametres qui montre comment Googlebot interagit avec votre site. Ce rapport revele le total des requetes de crawl, le temps de reponse moyen, la repartition des requetes par type de reponse et le but du crawl (decouverte vs. rafraichissement).

Faites attention a la repartition des codes de reponse. Si un pourcentage significatif des requetes de crawl retournent des redirections 301/302, des erreurs 404 ou des erreurs serveur 5xx, vous gaspillez du budget de crawl sur des URLs cassees ou redirigees. Un site e-commerce sain devrait voir 90 % ou plus des requetes de crawl retourner un code 200.

La repartition par type de fichier montre si Googlebot passe un temps disproportionne a télécharger des images, du CSS, du JavaScript ou d'autres ressources. Si les fichiers JavaScript dominent vos requetes de crawl, cela peut indiquer des problemes de rendu qui forcent Googlebot a faire des requetes supplementaires.

Comparez vos statistiques de crawl mois après mois. Une chute soudaine des requetes de crawl peut indiquer des problemes de performance serveur ou des modifications du robots.txt qui ont trop bloque. Un pic soudain pourrait signifier que Google a decouvert un nouveau lot d'URLs parametrees ou qu'un changement de sitemap a expose des pages precedemment cachees.

La façon dont votre boutique rend les pages impacte directement l'efficacite du crawl. Les pages rendues cote client (CSR) construites avec des frameworks JavaScript comme React ou Vue necessitent que Googlebot fasse plusieurs requetes : d'abord pour télécharger le squelette HTML, puis pour recuperer et executer le JavaScript, et enfin pour rendre le contenu de la page. Ce processus est plus lent et consomme plus de budget de crawl par page.

Le rendu cote serveur (SSR) fournit du HTML entierement rendu des la première requete, permettant a Googlebot de comprendre le contenu immediatement. Pour les sites e-commerce, le SSR ou la génération de sites statiques (SSG) resulte generalement en 40 % a 60 % de pages supplementaires explorees par session de crawl par rapport aux equivalents CSR.

Les boutiques Shopify sont rendues cote serveur par defaut, ce qui est rarement un probleme pour les marchands Shopify. Mais les boutiques construites sur des architectures headless avec React/Next.js ou Vue/Nuxt.js doivent s'assurer que leur implémentation SSR fonctionne correctement. Nous avons vu des boutiques headless ou une configuration SSR mal parametree faisait que Googlebot voyait des pages produits vides, entrainant une desindexation massive.

Testez comment Google voit vos pages avec l'outil d'inspection d'URL dans GSC. Cliquez sur "Voir la page testee" pour voir a la fois la reponse HTML brute et le HTML rendu. Si la version rendue manque d'informations produit, de prix ou d'avis, votre configuration de rendu nécessite attention.

Au-dela du blocage des pages sans valeur, vous pouvez activement diriger Googlebot vers votre contenu le plus important. Le maillage interne est le signal le plus fort pour la priorite de crawl. Les pages avec plus de liens internes sont explorees plus fréquemment et plus rapidement après les mises a jour.

Gardez votre sitemap XML legere et precise. N'incluez que les pages que vous voulez reellement indexer : pages produits, pages de catégories, articles de blog clés et pages d'information essentielles. Retirez les produits en rupture de stock (ou redirigez-les), les pages noindexees et les URLs parametrees de votre sitemap. Un sitemap de 5 000 URLs importantes bat un sitemap de 50 000 URLs dont 90 % sont inutiles.

Mettez a jour les dates lastmod de votre sitemap avec precision. Quand vous mettez a jour le prix, la description ou la disponibilite d'une page produit, la date lastmod doit refleter le changement. Googlebot utilise lastmod comme signal pour la priorite de re-crawl. Nous avons vu des boutiques définir toutes les dates lastmod a la meme valeur (ou utiliser la date du jour pour chaque page), ce qui detruit le signal et amene Google a ignorer complètement lastmod.

Pour les changements urgents comme les soldes, les baisses de prix ou les lancements de nouveaux produits, vous pouvez utiliser l'API d'indexation (pour les types de sites eligibles) ou demander manuellement l'indexation via l'outil d'inspection d'URL de GSC.

Le leak a nomme le système de crawl Trawler et a expose les entrees qui pilotent ses décisions de planification. Les URLs qui meritent des mises a jour frequentes a partir de signaux "dignes du crawl" - link equity, exactitude lastmod, profondeur de liens internes, changements de contenu recents - sont revisitees souvent. Les URLs qui ne le font pas glissent dans des paliers de crawl peu frequents independamment de leur importance commerciale.

Pour les gros catalogues, le comportement du scheduler explique pourquoi certaines PDP restent des semaines sans re-crawl. Le correctif est rarement "augmenter le crawl budget via robots.txt ou sitemaps" - c'est rendre les PDP importantes dignes du crawl. Les liens internes provenant de pages fréquemment crawlees (homepage, hubs de catégorie, posts de blog recents) tirent les PDP plus profondes dans des paliers plus frequents. Des valeurs lastmod exactes dans les sitemaps XML disent a Trawler quand un re-crawl est justifie.

L'inverse compte aussi. Les URLs de navigation a facettes et les doublons parametres brulent le crawl budget que Trawler alloue a votre domaine, laissant moins de cycles pour les URLs que vous voulez indexees. Une gestion agressive des parametres, rel=canonical et des règles disallow sur les URLs vraiment redondantes liberent des cycles Trawler pour les pages de revenu.