Gestion du budget de crawl

Le budget de crawl est la combinaison de deux facteurs : la limite de frequence 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 donnee.

Pour les petites boutiques avec moins de 5 000 pages, le budget de crawl est rarement un probleme. Google explorera regulierement 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 categorie 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 different. Google n'a pas besoin de toutes les explorer.

Les parametres de tri gaspillent le budget de crawl silencieusement. Des URLs comme /categorie?tri=prix-croissant, /categorie?tri=prix-decroissant, /categorie?tri=plus-recents et /categorie?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 modeles 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 regles comme Disallow: /*?sort=, Disallow: /*?filter=, Disallow: /search et Disallow: /cart. Ces regles 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 completement 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 specifiques 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 telecharger 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 apres 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 facon 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 telecharger 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 premiere requete, permettant a Googlebot de comprendre le contenu immediatement. Pour les sites e-commerce, le SSR ou la generation 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 implementation 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 necessite 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 frequemment et plus rapidement apres 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 categories, articles de blog cles 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 definir 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 completement 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.