Crawl budget Shopify : ce que Google ignore vraiment en 2026

Le 31 mars 2026, le blog officiel Google Search Central publie un article signé Gary Illyes intitulé Inside Googlebot: demystifying crawling, fetching, and the bytes we process. Trois confirmations brutales y figurent. La limite HTML par URL est désormais de 2 Mo (contre 15 Mo de référence depuis 2022), soit une division par 7,5. La latence base de données pèse plus lourd que la taille du site sur la capacité de crawl allouée. Et le Crawl Rate Limiter Tool dans Search Console est mort depuis novembre 2023, donc plus aucun levier direct pour caper Googlebot. (developers.google.com)

Cette doctrine 2026 change tout pour Shopify. La plateforme a une architecture par défaut qui multiplie les URLs (collections, tags, variants, sort, filtres), un écosystème d’apps qui alourdit le serveur en injectant du JavaScript bloquant, et un robots.txt.liquid ouvert depuis juin 2021 que la grande majorité des stores n’a jamais customisé. Résultat observé sur la majorité des audits techniques : 50 à 90 % du crawl budget brûlé sur des URLs sans intention de recherche, pendant que les nouvelles fiches produit attendent dix jours pour être indexées.

Trois ruptures supplémentaires aggravent le tableau en 2026. Shopify a changé le format des URLs de filtres en deux temps : le 16 mars 2026, ?filter.v.option.color=Blue est devenu ?filter.v.option.color=gid://shopify/FilterSettingGroup/123 (passage à des identifiants opaques stables), puis le 24 avril 2026, les anciennes URLs text-based ont cessé d’appliquer le filtre tout en continuant à renvoyer 200 OK (Shopify Changelog, Pavel Ungr). Soit des soft 404 en masse, sans 301 automatique. Les AI crawlers (GPTBot, ClaudeBot, PerplexityBot) n’exécutent pas le JavaScript et peuvent peser jusqu’à 30-40 % de la bande passante sur une boutique de 5 000 pages selon les études 2026. Et Bing France pèse 5,39 % du marché search, alimentant ChatGPT Search dont 87 % des citations matchent les top résultats Bing (Statcounter avril 2026, Seer Interactive janvier 2025).

Voici la nouvelle doctrine 2026 sur Shopify, les 7 sources de gaspillage typiques, le diagnostic en 4 étapes avec ses vraies limites techniques, et le plan d’action en 3 niveaux qui marche sur le terrain. Avec un template robots.txt.liquid complet et 5 cas terrain publics chiffrés.

La doctrine crawl budget 2026 : ce qui a changé depuis l’an dernier

En 2026, le crawl budget n’est plus une notion réservée aux sites de 500 000 pages. La combinaison de la limite 2 Mo HTML, de la priorité donnée à la latence base de données et du nouveau format Shopify GID transforme tout store de 1 000 SKUs ou plus en candidat à risque. La doctrine de 2024 ne s’applique plus.

La limite 2 Mo de Google (mars 2026)

Le 31 mars 2026, Gary Illyes détaille la mécanique de fetch en 2026 : Googlebot s’arrête exactement à 2 Mo par URL HTML, headers HTTP inclus. Tout ce qui dépasse n’est ni fetché, ni rendu, ni indexé. Pas de rejet, juste un cutoff brutal. Les ressources externes (JavaScript, CSS, requêtes XHR) ont chacune leur propre limite 2 Mo et ne comptent pas dans le 2 Mo de la page parente, ce qui sauve les Shopify modernes pour les assets. Mais pour le HTML, le couperet est net.

Cette limite descend de 15 Mo (la référence historique encore citée par la plupart des guides SEO francophones) à 2 Mo. Soit une division par 7,5. Conséquence pratique : si le HTML brut d’une fiche produit dépasse 2 Mo (ce qui arrive sur les Shopify avec apps de reviews qui injectent des centaines de commentaires inline + descriptions enrichies + variants illimités), le balisage Schema.org, les canonicals, les liens de navigation finaux peuvent passer sous le cutoff. Illyes recommande explicitement : placez les éléments critiques (meta tags, title, canonicals, structured data) en haut du HTML.

La latence base de données prime sur la taille du site

C’est la phrase qui résume le mieux la doctrine 2026. Gary Illyes, podcast officiel Google Search Off the Record :

“If you are making expensive database calls, that’s going to cost the server a lot. It’s not crawling that is eating up the resources, it’s indexing and what you are doing with the data.”

Le seuil historique du million d’URLs reste valide (“1 million is okay probably”), mais la priorité a explicitement basculé : infrastructure speed > site scale. Pour Shopify, ça signifie que le poids du theme.liquid, le nombre d’apps actives et la qualité du cache CDN comptent davantage que le nombre de produits dans le catalogue.

Concrètement, le TTFB cible que Googlebot tolère sans back-off est inférieur à 200 ms selon la doc officielle Google. Les benchmarks 2026 sur log file analysis (étude Managed Server) confirment l’ampleur : un passage de 160 ms à 663 ms (×4) peut faire chuter le volume de crawl de ~30 à ~10 requêtes/jour, soit environ 66 % de perte. À 1 550 ms, on tombe à 5 requêtes/jour. L’heuristique opérationnelle observée par plusieurs praticiens : chaque 100 ms d’amélioration TTFB représente environ +10 % de volume de crawl : ordre de grandeur, pas loi universelle Google.

Le Crawl Rate Limiter Tool est mort depuis novembre 2023

Dernier point souvent ignoré : depuis novembre 2023, le Crawl Rate Limiter Tool dans Search Console est officiellement deprecated. Il n’y a plus de bouton “force crawl plus” ou “calme-toi un peu”. Seule l’architecture du site, la propreté du robots.txt et la vitesse du serveur influencent la fréquence de Googlebot.

Quand un e-commerçant demande comment “forcer Google à venir plus souvent”, la réponse honnête est : vous ne pouvez pas le forcer, vous pouvez seulement arrêter de le décourager. C’est précisément le sujet de cet article. Pour creuser comment Google interprète les fichiers volumineux, ce que Google dit vraiment sur la taille des pages web complète bien ce point.

Breaking change Shopify : GID dans les filter URLs (mars-avril 2026)

Le calendrier précis est en deux temps. Le 16 mars 2026, Shopify déploie le nouveau format des URLs de filtres : les valeurs texte sont remplacées par des identifiants opaques GID. Le format ?filter.v.option.color=Blue devient ?filter.v.option.color=gid://shopify/FilterSettingGroup/123. Le 24 avril 2026, fin du fallback : les anciennes URLs text-based n’appliquent plus le filtre tout en continuant à renvoyer 200 OK. Soit des soft 404 en masse sans redirection 301 automatique (Shopify Changelog, Pavel Ungr).

Effet collatéral inattendu mais utile : les URLs filtrées perdent leur valeur lexicale SEO. Le keyword color=blue devient un GID opaque, donc l’obfuscation des facettes devient quasi gratuite côté SEO puisque les URLs n’ont plus de sémantique à préserver. Les boutiques qui voulaient garder leurs filtres indexables pour capter des requêtes longue traîne du type “robes bleues” doivent désormais créer des collections statiques dédiées.

Shopify : pourquoi c’est un cas particulier

Shopify est livré avec une architecture URL qui multiplie les pages crawlables par défaut. Combinée à l’écosystème d’apps qui injecte du JavaScript bloquant et au robots.txt.liquid sous-utilisé par 70 % des stores observés, la plateforme transforme la chasse au crawl budget en un problème spécifique. Aucun WordPress ou Magento n’a exactement le même profil.

Architecture par défaut : la combinatoire explosive

Une boutique Shopify de 2 000 SKUs génère, sans rien faire, des dizaines de milliers d’URLs crawlables. Voici la combinatoire typique :

• Une collection × 5 tags × 3 sort_by × 4 filtres × 8 variants = potentiellement 480 URLs uniques par collection
• Multiplié par 20 collections principales = près de 10 000 URLs pour ce qui devrait être 20 destinations
• Sans compter les pages search interne /search?q=, les permutations devise (?currency=), tracking IDs marketing (?utm_*, ?fbclid=), apps qui rajoutent leurs propres paramètres

Le robots.txt Shopify par défaut bloque une partie (?variant=, ?q=, ?sort_by=, ?filter.*=), mais ne couvre pas les paramètres encodés (%2B, %20), les tagged/, les paramètres injectés par les apps, ni les paramètres marketing.

Les mega menus : la dilution silencieuse

Les mega menus Shopify exposent souvent 100 à 300 liens internes par page. Une analyse documentée par l’équipe Performance de Shopify montre une boutique avec 2 868 nœuds DOM dans le mega menu mobile + 2 223 desktop, soit ~5 000 nœuds nav sur 6 800 totaux sur la page d’accueil (performance.shopify.com).

Conséquence : le PageRank interne se dilue mécaniquement. Avec un mega menu de 120 liens + 15 liens body + 10 footer = 145 liens, chaque destination ne reçoit que 0,7 % de l’équité de la page source. Une architecture Hub & Spoke avec 40 liens totaux fait monter chaque destination à 2,5 %, soit 3,5 fois moins de dilution.

Les benchmarks 2026 placent les zones critiques à <40 liens (OK), 40-100 (zone risque), >100 (dilution quasi-certaine). Shopify Performance recommande explicitement : “keep at least one menu rendered on the server to help with web search bots”. Si le mega menu ne se rend qu’au hover/clic JS, Googlebot peut ne pas le découvrir lors du crawl initial.

Les apps qui sabotent silencieusement

L’écosystème d’apps Shopify est l’angle mort le plus coûteux. Sur la majorité des boutiques observées :

• Judge.me injecte ~77,9 Ko compressés (210 Ko bruts) de JavaScript en App Embed pour afficher les étoiles. Rendu CSR (client-side), donc invisible aux AI bots zero-JS.
• Loox charge son CDN async post-onload, photos reviews injectées en JavaScript.
• Klaviyo, Stamped, Reconvert, popup managers : chacun ajoute son script en </head> ou </body>.

Le benchmark officiel Shopify cible <10 Ko d’entry point JavaScript par asset, <16 Ko bundle minifié (shopify.dev theme-check). Quatre apps qui injectent 40 Ko chacune en CSR explosent ce budget, ralentissent le TTFB, provoquent un back-off Googlebot, et masquent le contenu critique aux AI bots.

robots.txt.liquid : un levier ouvert depuis 2021 mais négligé

Depuis juin 2021, Shopify permet de customiser entièrement le robots.txt via un fichier robots.txt.liquid (Online Store 2.0). On va dans Online Store > Themes > Edit Code > Add a new template et on le crée. C’est documenté chez Shopify Help Center.

Sur les boutiques observées, moins d’un tiers des Shopify ont touché à ce fichier. La plupart laissent le robots.txt par défaut, alors que c’est le levier le plus rapide pour réduire le gaspillage crawl. Et ce sont précisément les boutiques avec apps les plus actives qui souffrent le plus du gaspillage combinatoire.

Note technique : il n’existe pas de sitemap.xml.liquid équivalent. L’objet Liquid sitemap ne sert qu’à émettre la directive Sitemap: dans le robots.txt, pas à éditer le sitemap lui-même. Même sur Shopify Plus, le sitemap reste auto-généré et non-customisable. Seul Hydrogen (headless) ouvre une vraie main sur le sitemap via la Storefront API.

AI bots en 2026 : la cascade qui ruine votre crawl Googlebot

En 2026, les AI crawlers représentent la moitié de la pression sur les serveurs Shopify, alimentent les nouvelles surfaces de search (ChatGPT, Perplexity, Claude, Bing/Copilot) et n’exécutent pas le JavaScript. Trois conséquences pratiques : il faut connaître leurs user-agents, comprendre l’effet de cascade sur le crawl Googlebot, et injecter du JSON-LD Product en SSR pour exister dans l’AI search.

Inventaire des AI bots actifs en 2026

Sources officielles : platform.openai.com, privacy.claude.com, docs.perplexity.ai.

À ne pas confondre : GPTBot ≠ OAI-SearchBot. GPTBot sert au training des modèles OpenAI (apprentissage sur un corpus de pages). OAI-SearchBot sert au search index qui alimente ChatGPT Search en temps réel. Bloquer GPTBot ne retire pas vos pages de ChatGPT Search. Bloquer OAI-SearchBot oui. Idem côté Anthropic : ClaudeBot (training) vs Claude-SearchBot (index). La règle pratique : bloquer les training bots, laisser passer les search bots, c’est précisément ce que fait le template robots.txt.liquid plus bas.

Les ordres de grandeur observés en 2026 (étude 30 jours sur trafic e-commerce, Digital Applied) : les AI bots peuvent peser jusqu’à 30-40 % de la bande passante totale avant rate limiting sur une boutique de 5 000 pages. Un crawler agressif seul consomme plusieurs centaines de Go par mois. GPTBot domine en volume (étude Digital Applied : ~4 200 req/jour sur le site testé), suivi de ClaudeBot et PerplexityBot. Bytespider ignore une partie des directives Disallow selon les rapports d’incident 2024 (Cloudflare blog). ByteDance a publié des correctifs fin 2024, mais la conformité reste irrégulière.

La cascade : pourquoi vos AI bots ruinent votre crawl Googlebot

Sur Shopify (infra mutualisée), quand les AI bots saturent l’origin :

1. Latence p95 explose, le CDN renvoie davantage de 5xx
2. Googlebot interprète “host overloaded” et réduit automatiquement son crawl rate (back-off documenté)
3. Le crawl budget Googlebot s’effondre, les nouveaux produits sont indexés en J+7 au lieu de J+1

Laisser Bytespider et GPTBot sans rate limit coûte directement du crawl budget Googlebot. La parade tient en deux gestes : autoriser les SearchBots (ChatGPT, Claude, Perplexity, OAI-SearchBot, Claude-SearchBot) qui apportent du trafic AI commerce, et bloquer les training bots (GPTBot, ClaudeBot training, CCBot, Google-Extended) qui mangent du crawl sans contrepartie. Bytespider mérite en plus un blocage au pare-feu Cloudflare puisque son compliance robots.txt est défaillante.

JSON-LD Product : ce que les AI bots zero-JS lisent vraiment

Les AI crawlers fetchent une part variable des fichiers JavaScript (environ 11-12 % des requêtes pour ChatGPT-User, 24 % pour ClaudeBot selon l’analyse Vercel sur la rise of the AI crawler) mais n’exécutent pas le code. Tout contenu injecté par App Embed (reviews Judge.me, étoiles Loox, widgets Stamped) est donc invisible pour Perplexity, ChatGPT Search et Claude. Seul Googlebot rend ces blocs.

Les données structurées comblent ce trou. Selon les analyses publiées en 2026, environ deux tiers des pages citées par Google AI Mode et près des trois quarts par ChatGPT contiennent du markup structuré, et la présence de schema augmente significativement le taux de citation AI Overview (analyse Alhena.ai, Searchless 2026). Pour exister dans une comparaison shopping AI, il faut au minimum : gtin, brand, availability, price, priceCurrency, aggregateRating, le tout rendu côté serveur en Liquid, pas injecté en JS.

Snippet à intégrer dans sections/main-product.liquid ou un snippet dédié :

{%- assign rating = product.metafields.reviews.rating.value -%}
{%- assign rating_count = product.metafields.reviews.rating_count -%}
{%- assign cv = product.selected_or_first_available_variant -%}
<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "Product",
  "@id": "{{ shop.url }}{{ product.url }}#product",
  "name": {{ product.title | json }},
  "description": {{ product.description | strip_html | truncatewords: 50 | json }},
  "image": [{%- for img in product.images limit: 5 -%}"https:{{ img | image_url: width: 1200 }}"{%- unless forloop.last -%},{%- endunless -%}{%- endfor -%}],
  "sku": {{ cv.sku | json }},
  {%- if cv.barcode != blank -%}"gtin13": {{ cv.barcode | json }},{%- endif -%}
  "brand": {"@type": "Brand", "name": {{ product.vendor | json }}},
  "offers": {
    "@type": "{% if product.variants.size > 1 %}AggregateOffer{% else %}Offer{% endif %}",
    "priceCurrency": {{ cart.currency.iso_code | json }},
    "availability": "https://schema.org/{% if cv.available %}InStock{% else %}OutOfStock{% endif %}",
    "url": "{{ shop.url }}{{ product.url }}"
  }{%- if rating_count and rating_count > 0 -%},
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "{{ rating }}",
    "reviewCount": "{{ rating_count }}"
  }{%- endif -%}
}
</script>

Judge.me expose nativement les metafields product.metafields.reviews.rating.value et rating_count. Loox idem depuis 2024 (activer Settings → Advanced → “Sync reviews to Shopify metafields”). Ne jamais inventer un aggregateRating : un faux rating déclenche une pénalité manuelle Google. Tester ensuite via curl -A "GPTBot" https://shop.com/products/x | grep '"@type"' pour valider le rendu zero-JS, plus le Rich Results Test pour la conformité Google.

Bing : le crawler oublié devenu critique en 2026

Bing France pèse 5,39 % du marché search (Statcounter, avril 2026), et sur e-commerce le ratio monte à 7-8 % avec une audience desktop Edge. Mais le vrai changement, c’est ChatGPT Search qui utilise l’index Bing : 87 % des citations SearchGPT matchent les top résultats Bing contre seulement 56 % pour Google. Si Bingbot ne crawle pas vos fiches produit, ChatGPT ne peut pas les citer.

Bingbot diffère de Googlebot sur plusieurs points qui importent en 2026 :

Shopify ne supporte pas IndexNow nativement, mais trois apps gèrent l’intégration : IndexNow: for Bing and Yandex (StoreSpark, 5/mois), InstaIndex: IndexNow for Bing (partenaire Microsoft Bing officiel), et la suite TinyIMG. L’impact mesuré : indexation Bing en 24-72 h vs 1-3 semaines en crawl naturel sur les petites boutiques. Pour 60 par an, c’est largement rentabilisé dès la première vague de produits.

Vitesse origin : le facteur que Google a remonté au top

La doctrine 2026 dit : infrastructure speed > site scale. Pour Shopify, ça se traduit par trois métriques à surveiller mensuellement et trois leviers d’action.

Les seuils chiffrés : Google cible un TTFB < 200 ms (doc officielle), le seuil “good” Core Web Vitals étant à 800 ms. La moyenne Shopify est annoncée à 0,51 s contre 1,4 s pour les concurrents Magento/Woo (Shopify Enterprise blog). L’heuristique observée par les praticiens log file analysis : environ +10 % de volume de crawl par tranche de 100 ms gagnés sur le TTFB. Ordre de grandeur, pas garantie Google.

Le cas Shopify spécifique : le fichier theme.liquid peut représenter jusqu’à 87 % du temps d’exécution Liquid total (omarweb.dev). Les apps tierces injectent leur JavaScript dans ce même contexte non-sandboxé, et leurs latences s’additionnent. Quatre apps qui ajoutent 100 ms chacune doublent le TTFB.

Trois outils pour mesurer : (1) Shopify Web Performance Dashboard (Online Store > Themes > Web performance) donne LCP/INP/CLS via RUM avec data CrUX, retard de ~36 h, mais ne mesure pas le TTFB directement. (2) GSC Crawl Stats > Average response time donne la métrique exacte que Googlebot voit. (3) Shopify Theme Inspector for Chrome affiche un flame graph par Liquid block, indispensable pour identifier les sections theme.liquid coûteuses ; couplé au query string ?debug pour activer le profilage.

Trois leviers Shopify-specific :

1. Theme.liquid surgery : remplacer {% for product in collections.all.products %} (lourd au-delà de 50 items) par des {%- liquid -%} blocks ; sortir les renders inutilisés du header ; préférer {% render %} à {% include %} pour bénéficier du cache de variables.
2. App audit trimestriel : ouvrir Theme Inspector + Customize > Apps embeds. Désinstaller (pas seulement désactiver) les apps inactives : uninstall retire vraiment le code, disable laisse l’embed dans settings_data.json avec "disabled": true.
3. Cloudflare APO Shopify ($5/mois) : cache HTML côté edge → TTFB observé ~80 ms vs 400 ms origin. Compatible avec robots.txt.liquid custom.

Les 7 sources de gaspillage URL typiques sur Shopify

Sur les audits techniques croisés, les sept mêmes patterns reviennent. Filtres facettés, variants, search interne, sort_by, tags, pagination root et paramètres marketing. La grande majorité des boutiques ont au moins 50 % de leur crawl budget brûlé sur ces sept sources.

1. Filtres facettés et obfuscation post-2026

Les filtres de collection (?filter.v.option.color=..., ?filter.v.price.gte=50) sont le tueur de crawl numéro un. Chaque combinaison génère une URL unique, et la combinatoire explose : 5 couleurs × 4 tranches de prix × 3 tailles = 60 URLs pour une seule collection.

Avec le breaking change Shopify de mars 2026, ces URLs portent désormais des GID opaques (?filter.v.option.color=gid://shopify/FilterSettingGroup/123). Les anciennes URLs text restent crawlables et renvoient 200 OK sans appliquer le filtre : soit des soft 404 massifs sans 301 automatique. Sur une boutique fashion Shopify Plus de 8 000 SKUs, 12 000 URLs filtres se sont retrouvées indexées, faisant chuter le trafic organique collections de 34 % en six mois avant qu’on ne pose le diagnostic.

Trois techniques d’obfuscation existent quand on veut empêcher la création d’URLs crawlables sans casser l’UX :

• POST au lieu de GET : un formulaire en POST n’est pas crawlable, Googlebot ne soumet jamais de formulaires. Méthode radicale mais incompatible avec le storefront filtering natif Shopify qui exige GET.
• AJAX avec onclick sans <a href> : Googlebot exécute le JavaScript mais “likely won’t click on all JavaScript elements”. Un <button onclick="loadFiltered()"> sans lien sous-jacent n’est pas suivi de manière fiable. Attention : pushState/History API recrée des URLs crawlables, donc à éviter si l’objectif est l’obfuscation.
• Fragment URL #color=blue : Google ignore les fragments depuis l’abandon de l’AJAX crawling scheme en 2015. Limite : 100 % client-side, donc sans JavaScript le filtre ne fonctionne plus.

2. Variants : la duplication invisible

Shopify expose chaque variant produit avec son propre paramètre URL : /products/robe-rouge?variant=12345. Pour un produit avec 5 tailles × 3 couleurs, ça fait 15 variants donc 15 URLs par produit. Sur 2 000 SKUs, c’est près de 30 000 URLs variants crawlables.

Le robots.txt Shopify bloque ?variant= par défaut, ce qui est une bonne nouvelle. Mais les widgets “produits similaires” des apps de recommandations pointent souvent vers les URLs variants spécifiques plutôt que vers le produit maître, ce qui pousse Googlebot à les découvrir quand même. C’est le pattern décrit dans URLs Dupliquées en E-commerce : Pourquoi Google ne Vous Pénalise Pas : pas de pénalité, mais une dilution de signal qui finit par coûter en ranking.

3. Search interne : les pages générées par utilisateur

Les pages /search?q=... sont générées dynamiquement par les requêtes des utilisateurs. Plus le trafic est élevé, plus la boutique a de pages search interne dans la nature. Certaines, partagées sur réseaux sociaux ou indexées via backlinks externes, finissent dans Google.

Le robots.txt Shopify bloque /search?q=, mais pas toujours les variantes (/search?type=product&q=...) ni les URLs des apps de recherche tierces (Searchanise, Boost, Algolia) qui créent leur propre arborescence /search? parallèle. La règle : bloquer toutes les pages de search interne via robots.txt.liquid (Disallow: /search), ajouter un noindex sur les pages déjà indexées, surveiller via URL Inspection mensuel.

4. Sort_by : la combinatoire silencieuse

?sort_by=price-ascending, ?sort_by=price-descending, ?sort_by=manual, ?sort_by=created-descending, ?sort_by=best-selling. Chaque collection peut être triée de 5 manières, donc 5 URLs uniques. Pour 20 collections, c’est 100 URLs sort_by.

Le robots.txt Shopify bloque ?sort_by= par défaut, mais les apps de filtre avancé (Boost AI Search, Searchanise, Hulk Apps) génèrent des variantes (?sort=, ?orderby=, ?_sort=) que le robots.txt par défaut ne couvre pas. Angle mort le plus fréquent sur Shopify Plus avec apps premium.

5. Tags collections : le gaspillage oublié

Les tags Shopify (/collections/all/tagged/promotion, /collections/robes/tagged/rouge) sont le gaspillage le plus systématiquement oublié. Le robots.txt par défaut ne les bloque pas, et la plupart des thèmes Shopify les exposent comme URLs crawlables sans canonical propre.

Le pattern typique : un développeur crée des tags pour structurer le merch interne (promo, nouveauté, bestseller), ajoute un widget de navigation qui linke ces tags publiquement, et six mois plus tard, des centaines de URLs tagged vivent dans l’index sans direction stratégique. La règle absolue : Disallow: /collections/*/tagged/ dans le robots.txt.liquid.

6. Pagination root collection

Shopify expose ?page=2, ?page=3 via le tag Liquid {% paginate collection.products by N %}. Ces URLs sont crawlables et self-canonical par défaut (page 2 → canonical = page 2), ce qui est exactement la doctrine Google 2026.

Le piège est uniquement sur la root collection (/collections/?page=...), qui retourne souvent une liste générique non stratégique. Disallow: /collections/?page=* économise sans casser la pagination des sous-collections, qui restent indispensables pour que Googlebot suive les liens vers les produits situés au-delà de la première page.

7. Paramètres marketing : le gaspillage venu de l’externe

Les paramètres tracking ajoutés par les régies pub et les apps internes représentent un volume invisible mais massif d’URLs crawlables. Voici l’inventaire 2026 :

Comment ils se retrouvent crawlés : autotagging publicitaire (Google Ads, Meta, TikTok ajoutent leurs paramètres à la redirection finale), partages sociaux où les utilisateurs copient l’URL après clic ad, JavaScript des apps tierces qui réécrit les liens internes en runtime, cookies persistants qui sticky l’ID en query string, et backlinks externes mal formés (?_pos=3&_ss=r qui persistent dans Reddit ou newsletters cinq ans après).

Les URLs Shopify cachées qu’on ne voit pas

Au-delà des sept sources combinatoires, Shopify expose plusieurs paths systématiquement ignorés dans les audits crawl. Voici l’inventaire qu’il faut couvrir :

Cas particulier : sur Cloudflare, le path /cdn-cgi/ peut être indexé en parasite même après ajout du Disallow (Google Search Central community). Solution : Disallow + attendre 48 h, puis vérifier le rapport “Indexé bien que bloqué par robots.txt” dans GSC pour identifier les fuites résiduelles.

Pour les boutiques Hydrogen ou Oxygen (headless), le robots.txt et le canonical sont gérés en code applicatif, donc le défaut Shopify ne s’applique pas : il faut répliquer manuellement les Disallow via les loaders Remix/React Router.

Shopify Markets, Soft 404 et autres multiplicateurs

Markets : le multiplicateur crawl chiffré

Shopify Markets propose trois architectures URL pour les boutiques multi-pays : sous-dossiers (recommandé, example.com/fr-fr/), sous-domaines (ca.example.com) ou ccTLDs (example.ca). Sous-dossiers héritent de l’autorité du domaine principal et bénéficient de l’hreflang automatique, sous-domaines sont traités comme sites séparés par Google (Search Console séparée).

Le multiplicateur crawl devient lourd vite : un catalogue de 1 000 produits sur 8 marchés (US, CA, UK, FR, DE, IT, ES, NL) génère 8 000 URLs canoniques produits, plus 400 URLs collections (50 × 8), plus 160 URLs CMS (20 × 8). Au total, une boutique 1 000 SKUs gonfle à 15 000-25 000 URLs crawlables. Google alloue le crawl budget par hostname, donc avec sous-dossiers un seul budget se partage entre les 8 marchés.

Bugs hreflang documentés en 2025-2026 : balises manquantes sur templates custom qui overrident content_for_header, conflit canonical vs hreflang où le canonical pointe vers la version primaire au lieu de la locale courante, trailing slash inconsistency entre /fr-ca et /fr-ca/, duplicate content cross-domain quand deux marchés partagent la même langue (FR-FR et FR-BE en français non traduit) sans x-default cohérent.

Soft 404 : la limite Liquid à connaître

Shopify gère trois statuts produit avec des réponses HTTP distinctes : un produit Active + sold out retourne 200 OK avec le message “Sold out” (piège : Google peut le classer Soft 404 si la page ne porte aucune valeur ajoutée), un produit Archived retourne 404 Not Found natif, un produit Draft est invisible storefront et renvoie 404.

Limite critique : Shopify Liquid ne peut pas écrire de headers HTTP. Les snippets “fake 410” qui circulent avec {% capture %} de headers ne fonctionnent pas. Google ignore le body et lit le vrai header 200. La seule méthode native pour générer un 404 propre est d’archiver le produit depuis l’admin (Products → Status → Archived).

Gary Illyes l’a re-confirmé à Search Central Live APAC 2025 : “Soft 404s consume crawl budget despite 200 OK status”. Le 410 Gone n’est pas plus rapide que le 404 : mythe SEO démenti définitivement. Pour les sold-out temporaires qu’on veut garder indexés, le bon pattern est d’enrichir product.liquid avec un schema OutOfStock + un bloc “Notify me” + des produits liés :

{% if product.available == false %}
  <script type="application/ld+json">
  {
    "@context": "https://schema.org/",
    "@type": "Product",
    "name": {{ product.title | json }},
    "offers": {
      "@type": "Offer",
      "price": "{{ product.price | money_without_currency | strip_html }}",
      "priceCurrency": {{ cart.currency.iso_code | json }},
      "availability": "https://schema.org/OutOfStock",
      "url": {{ product.url | prepend: shop.url | json }}
    }
  }
  </script>
  <div class="restock-block">
    <button data-notify="{{ product.id }}">Me prévenir du retour</button>
    {% render 'related-products', collection: product.collections.first %}
  </div>
{% endif %}

Note importante : Google Rich Results exige price et priceCurrency même quand availability est OutOfStock. Sans ces deux champs, le schema est ignoré et la page n’apparaît pas dans le rich snippet produit (Google Product structured data).

Decision tree pour les saisonniers : revient en moins de 12 mois → garder l’URL active avec schema OutOfStock + Notify ; revient en plus de 12 mois ou incertain → archiver (404 natif) + 301 vers la collection parente ; remplacé par une nouvelle version → 301 vers la nouvelle URL produit ; supprimé sans remplaçant et faible valeur SEO → archiver simple (404 suffit).

Le diagnostic crawl budget en 4 étapes

Pour savoir si une boutique Shopify gaspille du crawl budget, il faut quatre sources de données croisées : les Crawl Stats de Search Console, une mesure de TTFB, l’inspection des structured data côté SSR, et une approche logs alternative puisque Shopify n’expose pas les logs serveur natifs.

Étape 1 : Search Console Crawl Stats

Direction Search Console > Paramètres > Statistiques sur l’exploration. Trois signaux à lire dans l’ordre :

1. Code de réponse : si le ratio 200-OK est sous 75 %, problème de URLs zombies (404 sur produits supprimés mal redirigés, 301 en cascade, 500 d’erreur serveur)
2. Type de fichier : si HTML représente moins de 60 % du crawl, Googlebot brûle son budget sur JS, CSS ou images. Sur les Shopify mal optimisés, HTML peut chuter à 30 % seulement
3. Host status : signaux Server connectivity, Robots.txt fetch, DNS resolution

Signaux spécifiques Shopify à surveiller :

• Un pic soudain de “Découverte” sans pic correspondant de “Mise à jour” indique souvent l’apparition d’une nouvelle source d’URLs (app installée, paramètre marketing déployé)
• Une chute du nombre total de requêtes journalières corrèle souvent avec un back-off Googlebot (le serveur a ralenti, vérifier les apps)
• Un ratio élevé de “Autre client” dans la catégorie agent indique que des bots tiers (AI crawlers, scrapers) consomment de la ressource serveur, ce qui ralentit Googlebot indirectement

Étape 2 : mesurer le TTFB

Trois outils complémentaires :

• Shopify Web Performance Dashboard (Online Store > Themes > Web performance) pour LCP/INP/CLS via RUM, data CrUX, retard ~36 h. Ne mesure pas le TTFB directement.
• GSC Crawl Stats > Average response time pour la métrique exacte vue par Googlebot. À comparer avant/après installation d’une nouvelle app.
• Shopify Theme Inspector for Chrome pour le flame graph par Liquid block. Indispensable pour identifier la section du theme.liquid qui coûte. Activer avec ?debug dans l’URL.

Un TTFB médian > 600 ms est un signal d’alerte immédiat. Au-delà de 1 000 ms, le back-off Googlebot est probable.

Étape 3 : valider le rendu SSR pour AI bots

Pour vérifier que les données critiques (prix, dispo, ratings) sont rendues côté serveur et donc visibles aux AI bots zero-JS, lancer en console :

curl -A "GPTBot" https://votre-shop.com/products/votre-produit \
  | grep -E '("@type"|aggregateRating|"price"|"availability")'

Si le grep renvoie vide ou que aggregateRating est absent, le schema JSON-LD n’est pas rendu en SSR. Doubler avec le Rich Results Test Google qui montre la sortie après rendu Googlebot.

Étape 4 : l’accès logs Shopify (et ses alternatives)

C’est le point où beaucoup d’articles SEO sont inexacts. Shopify n’expose pas les logs serveur, ni sur Basic, ni sur Standard, ni sur Advanced, ni sur Plus storefront classique. Le support ne les fournit pas sur demande. Officiellement pour des raisons de sécurité.

Trois exceptions :

• Shopify Plus + Hydrogen (headless) : log drains natifs vers Splunk, Datadog, New Relic ou endpoint HTTP générique. Capture request logs, runtime logs, exceptions. Voie officielle, zéro friction.
• Cloudflare Enterprise + Logpush : ~60 k/an Cloudflare + plan Plus + intégration Ahrefs Enterprise. Réservé aux gros e-commerce.
• Cloudflare Worker custom devant le storefront : ~5/mois Workers + infra à hoster (Wrangler, cloudflared, Node receiver). C’est la seule voie pour les plans non-Plus qui donne des logs riches (40+ champs : IP, UA, TTFB, cache status, ASN, geo). Setup 1-2 jours, maintenance continue.

Recommandation pratique selon le plan :

Le plan d’action en 3 niveaux + template robots.txt.liquid 2026

Trois niveaux d’intervention, dans l’ordre du ROI décroissant et du temps croissant : Niveau 1 (1 semaine, gain 30-50 % de crawl budget récupéré), Niveau 2 (2-4 semaines, +20-30 % supplémentaires), Niveau 3 (4-8 semaines, optimisation structurelle). Commencer par le Niveau 1.

Niveau 1 : robots.txt.liquid (1 semaine)

Ouvrir Online Store > Themes > Edit Code > Add a new template > robots.txt.liquid et coller le template 2026 ci-dessous, l’adapter aux paramètres custom, déployer.

{%- comment -%} VEC 2026 : robots.txt.liquid anti crawl waste e-commerce {%- endcomment -%}
{% for group in robots.default_groups %}
  {{- group.user_agent }}

  {%- for rule in group.rules -%}
    {{ rule }}
  {%- endfor -%}

  {%- if group.user_agent.value == '*' -%}
    Disallow: /collections/*+*
    Disallow: /collections/*%2B*
    Disallow: /collections/*%20*
    Disallow: /collections/*/tagged/
    Disallow: /collections/?page=*
    Disallow: /search
    Disallow: /cdn-cgi/
    Disallow: /account
    Disallow: /services/
    Disallow: /community/
    Disallow: /recommendations/
    Disallow: /*?*utm_
    Disallow: /*?*fbclid=
    Disallow: /*?*gclid=
    Disallow: /*?*msclkid=
    Disallow: /*?*ttclid=
    Disallow: /*?*_pos=
    Disallow: /*?*_ss=
    Disallow: /*?*_psq=
    Disallow: /*?*_fid=
    Disallow: /*?*pr_prod_
    Disallow: /*?*aff=
    Disallow: /*?*ref=
    Disallow: /collections/*?*pf_
    Disallow: /*%5B*
  {%- endif -%}

  {%- if group.sitemap != blank -%}
    {{ group.sitemap }}
  {%- endif -%}
{% endfor %}

{%- comment -%} Blocs AI bots HORS du for-loop pour éviter la duplication {%- endcomment -%}

User-agent: OAI-SearchBot
Disallow:

User-agent: Claude-SearchBot
Disallow:

User-agent: PerplexityBot
Disallow:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Crawl-delay: 10
Disallow: /checkout
Disallow: /cart

User-agent: Google-Extended
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: CCBot
Disallow: /

Ce template, ligne par ligne :

• Conserve les Disallow par défaut Shopify (?variant=, ?q=, ?sort_by=, ?filter.*=)
• Bloque les collections combinatoires (*+* et leurs versions encodées %2B, %20, %5B)
• Bloque la page tagged (gaspillage le plus souvent oublié)
• Bloque la pagination root (/collections/?page=*) sans casser les sous-collections paginées
• Bloque les paths cachés (/cdn-cgi/, /account, /services/, /community/, /recommendations/)
• Bloque tous les paramètres marketing (utm, fbclid, gclid, msclkid, ttclid, pos, ss, pr_prod, aff, ref, pf)
• Autorise les SearchBots AI (OAI-SearchBot, Claude-SearchBot, PerplexityBot)
• Bloque les training bots (GPTBot, ClaudeBot, Google-Extended, Bytespider, CCBot)
• Conserve l’émission du Sitemap directive natif Shopify

Garder ?currency= et ?country= hors du robots.txt : Shopify Markets gère via canonical + hreflang auto.

Vérification après déploiement : https://votre-boutique.com/robots.txt doit refléter ces règles. Attendre 48 h puis surveiller les Crawl Stats. Le ratio URLs uniques crawlées augmente généralement en 2-3 semaines.

Niveau 2 : canonicals, noindex, sitemap propre (2-4 semaines)

Le robots.txt empêche Googlebot de crawler les nouvelles URLs. Mais les URLs déjà indexées ne sont pas désindexées par un simple Disallow. Il faut un noindex accessible, donc autoriser temporairement le crawl pour ces URLs en signalant qu’elles ne doivent pas être indexées.

Trois actions clés en parallèle :

• Audit des canonicals : sur les collections, vérifier que <link rel="canonical"> pointe vers la version statique (jamais une URL filtrée). Sur les produits avec variants, le canonical doit pointer vers la fiche maître, pas vers ?variant=X. Patterns problématiques à corriger : canonical hardcodé en request.canonical_url ignorant les variants, canonical absent sur collections filtrées, canonical en boucle sur pages search d’apps tierces.
• Ajout de noindex sur URLs déjà indexées : via un snippet conditionnel dans theme.liquid. Exemple : {% if request.path contains 'tagged' %}<meta name="robots" content="noindex">{% endif %}. Garder le crawl ouvert temporairement le temps que Google retire l’URL de l’index, puis resserrer via robots.txt définitivement.
• Auto-unpublish des produits hors stock définitif via Shopify Flow (workflow Unpublish when inventory = 0). Les produits archivés sont retirés du sitemap automatiquement.

À ce stade, attaquer aussi le maillage interne. C’est précisément là que votre maillage interne devient le levier critique quand PageSpeed ne suffit plus : un Shopify avec un crawl budget propre mais un maillage déficient passe à côté de l’effet compounding.

Niveau 3 : architecture profonde (4-8 semaines)

Le Niveau 3 est structurel. Pas urgent, mais sans lui, le résultat ne tient pas dans le temps.

5 cas terrain publics chiffrés + 1 anecdote anonymisée

Voici des résultats publics documentés pour calibrer ce qui est réaliste sur Shopify. Trois cas sur cinq concernent le secteur mode (les études publiques chiffrées sur Shopify y sont sur-représentées), un cas headless et un cas plateforme custom comparable pour la magnitude. À compléter par une anecdote anonymisée en fin de section.

Cas 1 : Boutique Shopify mode + Fast Simon (Search Engine Journal) Page catégorie en CSR JavaScript invisible sans rendering + Fast Simon générait des URLs ?narrow consommant le crawl budget. Actions : prerendering SSR, Disallow: /collections/*narrow*, migration pagination de ?sort_by vers ?page. Keywords ranking page 1 passés de 4,4 % à 10 % des keywords trackés en 3 mois.

Cas 2 : Marque fashion Shopify, 200k URLs → cleanup (Ramkr Shukla) Index bloat massif (tags URLs auto, collection-variant combos, pages filtres, produits orphelins, URLs d’apps legacy), pages prioritaires enterrées à 5-6 clics. Actions : robots.txt bloquant tags/filtres, pagination standardisée, pruning low-value, collections prioritaires remontées à depth 1-2, canonicals corrigés, sitemap réduit aux URLs SEO-utiles. Résultat : 0 → 120 000 visiteurs organiques mensuels en 14 mois, >70 % du revenu organique sur collection pages.

Cas 3 : Mode masculine smart-casual Shopify (Ataullah Bokhari) URLs produits dupliquées par variants + pagination, paramètres ?variant=xyz enterrant les pages clés, sitemap manquant, LCP 4,8 s. Actions : sitemap XML propre, robots.txt corrigé, canonicals sur duplicates, lazy-loading + WebP, schema Product/FAQ/BreadcrumbList, internal linking structuré. Résultat : 1 200 → 5 400 sessions/mois (+350 %), +70 % keywords rankés, revenu organique 1 800 → 16 848 (+836 %) en 90 jours.

Cas 4 : Mid-size Shopify home & lifestyle (Xsquare SEO) Indexing issues, schema manquant produits, internal linking faible, bounce 72 %, mobile speed. Actions : réécriture titles/meta/descriptions, schema Product, compression images, internal linking renforcé, 42+ backlinks niche. Résultat : 4 000 → 60 500 visiteurs/mois (×15) en 8 mois, <10 → 470+ keywords page 1.

Cas 5 : Marketplace véhicules US (Botify, plateforme custom comparable) (Botify) Pattern de crawl budget identique aux gros Shopify Plus à catalogue 1M+ URLs : 99 % du site invisible Google, refinements URLs infinies. Actions : robots.txt anti-refinements, URLs connues réduites de 50 %, internal linking renforcé, sitemap nettoyé. Résultat : crawl Google 0,5 % → 9,5 % (×19), trafic 40 000 → 80 000 visites/semaine (×2) en moins de 3 mois.

Anecdote anonymisée : Shopify Plus mode, 8 000 SKUs (cas pratique observé en France) 9 collections principales × 4 filtres actifs en moyenne (couleur, taille, prix, matière) + 1 filtre supplémentaire de l’app de recherche tierce. La combinatoire a explosé à 12 000 URLs facettes indexées en six mois. Pages /collections/robes?filter.v.option.color=rouge cannibalisaient la collection statique /collections/robes-rouges, perte de 80 % du trafic sur les collections statiques. Actions : robots.txt.liquid customisé bloquant les patterns combinatoires, canonicals dynamiques propres, nettoyage Search Console des URLs déjà indexées via noindex temporaire. Récupération en 11 semaines sur le trafic baseline, puis +12 % sur les six mois suivants. Le directeur e-commerce ouvrait Search Console Crawl Stats pour la première fois lors du premier appel.

Patterns communs observés sur les cinq cas publics : (1) robots.txt = levier numéro un, quatre cas sur cinq commencent par là ; (2) pruning agressif des URLs indexées (réduction 50-99 %) corrèle systématiquement avec doublement+ du trafic ; (3) depth reduction des pages prioritaires à click depth 1-2 = signal de crawl priority pour Google ; (4) délais cohérents 90 jours pour premiers résultats, 8-14 mois pour effet plein.

6 mauvais conseils du marché à éviter en 2026

Le marché du SEO Shopify regorge de conseils qui sonnent vrais mais ne le sont plus en 2026. Voici les six qui reviennent encore presque chaque semaine sur LinkedIn, dans les forums, ou dans des audits venant d’ailleurs. Aucun ne tient face à la doctrine 2026.

“Bloquez TOUS les paramètres URL via robots.txt” : faux. Bloquer le pattern ?* empêche Googlebot d’accéder à toute URL paramétrée, y compris celles qui ont une vraie intention search. Le paramètre ?type=product peut avoir du sens si deux univers (produits/articles) coexistent sur le même domaine. La règle correcte vient des guidelines Google Search Central : selective indexing. On bloque les paramètres qui multiplient sans intention, on garde les paramètres qui correspondent à une vraie requête utilisateur. Opération de précision, pas une grenade.

“IndexNow va régler le problème de crawl Google” : faux. Google ne supporte pas IndexNow, malgré des tests passés. Le protocole fonctionne pour Bing, Yandex, Seznam, Naver, et 17 % des nouveaux clics Bing viennent d’URLs découvertes via IndexNow. Mais sur Google, pas de raccourci. Pour accélérer l’indexation Bing (donc ChatGPT Search), IndexNow est très utile via apps Shopify ($5/mois). Pour Google, le trio reste : sitemap propre + maillage interne + crawl non gaspillé.

“Augmentez le budget Google Ads pour que Google crawle plus” : aucun lien. Aucune corrélation officielle ou observable entre dépense Ads et fréquence Googlebot organique. Mythe persistant chez certains prestataires marketing. Ce qui peut donner l’illusion : une boutique qui scale ses Ads scale aussi son trafic, génère plus de backlinks externes, et bénéficie d’une perception “marque montante” qui se reflète aussi en Search. Mais la corrélation n’est pas la cause. On n’achète pas du crawl budget chez Google.

“Migrez vers Shopify Plus pour avoir plus de crawl” : non. Shopify Plus n’a pas plus de crawl budget que Shopify standard. L’architecture par défaut est exactement la même : mêmes patterns d’URLs, mêmes combinatoires, mêmes apps. Ce que Plus apporte, c’est la possibilité technique de customiser plus (checkout scripts, Hydrogen, log drains), pas une faveur de Googlebot. Migrer pour le crawl budget est un mauvais argument. Migrer pour la liberté de customisation ou pour les log drains Hydrogen est légitime.

“Le 410 Gone désindexe plus vite que le 404” : mythe démenti par Gary Illyes en 2025. Google traite tous les 4xx (sauf 429) de manière identique. La ressource est marquée inexistante et retirée de l’index au même rythme. Le 410 a un sens sémantique (signaler une suppression définitive volontaire) mais ne gagne pas de temps d’indexation. Sur Shopify, archiver le produit suffit (404 natif).

“Le JavaScript onclick suffit à obfusquer les facettes” : faux. Googlebot exécute le JavaScript mais ne déclenche pas systématiquement les handlers user-interaction (onclick, hover, scroll). En pratique, un <button onclick="loadFiltered()"> sans lien sous-jacent n’est pas suivi de manière fiable. Mais ce n’est plus une garantie absolue depuis 2024 : la doctrine 2026 dit “no <a href> = pas crawlé fiablement”, donc plus ferme. Pour obfusquer vraiment : POST (incompatible Shopify storefront filtering), fragment URL (# ignoré par Google), ou supprimer le <a href> au profit d’un <button>.

Foire aux questions

Combien de temps pour récupérer un crawl budget Shopify saturé ? Entre 8 et 14 semaines selon l’ampleur du gaspillage et l’âge des URLs déjà indexées. Les cas publics chiffrés montrent des premiers résultats dès 6-12 semaines après robots.txt.liquid corrigé + canonicals propres + nettoyage Search Console. L’effet plein s’observe à 8-14 mois.

Faut-il bloquer le search interne via robots.txt ou via noindex ? Les deux ont leur rôle. Le robots.txt empêche le crawl (gain immédiat), le noindex empêche l’indexation des URLs déjà crawlées (nettoyage de l’index existant). Sur Shopify, commencer toujours par robots.txt.liquid pour les nouvelles URLs et passer au noindex temporaire pour les URLs déjà indexées. Quand l’index est nettoyé, resserrer via robots.txt définitivement.

Les apps de reviews comme Judge.me ou Loox impactent-elles vraiment le crawl ? Oui, indirectement. Elles injectent du JavaScript qui ralentit le serveur (TTFB), ce qui pousse Googlebot à un back-off automatique selon Gary Illyes 2025. Et 100 ms de TTFB supplémentaire = environ 10 % de volume de crawl perdu. Le contenu reviews injecté en CSR est aussi invisible aux AI bots zero-JS : d’où l’importance de synchroniser les metafields ratings vers un JSON-LD AggregateRating rendu SSR.

Le 410 désindexe-t-il plus vite que le 404 ? Non. Gary Illyes l’a re-confirmé en 2025 : Google traite tous les 4xx (sauf 429) de manière identique. La ressource est marquée inexistante et retirée de l’index au même rythme.

Comment Shopify gère-t-il les logs serveur ? Aucun accès sur Shopify Basic, Standard, Advanced, ni Plus storefront classique. Seul Plus + Hydrogen propose des log drains natifs vers Splunk, Datadog ou New Relic. Pour les autres plans, il faut passer par Search Console Crawl Stats (Googlebot only), un Cloudflare Worker custom devant le domaine (5/mois, 1-2 jours setup), ou Logpush en Cloudflare Enterprise.

Quels signaux montrent que Googlebot fait du back-off sur ma boutique ? Trois signaux dans les Crawl Stats Search Console : le nombre total de requêtes journalières chute brutalement sans changement de volume de pages, le temps de réponse moyen monte au-dessus de 600 ms, le rapport “Host status” mentionne des problèmes de connectivité serveur. Si deux signaux sur trois en parallèle, c’est probablement un back-off. Agir sur la cause (apps, latence DB, TTFB) avant tout autre chantier.

Le sitemap_products doit-il être custom ou laisser le défaut Shopify ? Le défaut suffit pour la majorité des boutiques (< 5 000 SKUs), à condition de vérifier qu’il n’inclut pas les produits archivés ou en stock zéro définitif. Il n’existe pas de sitemap.xml.liquid : Shopify ne permet pas de customiser le sitemap, même sur Plus. La seule voie pour un sitemap vraiment custom est Hydrogen (headless) via la Storefront API.

Ce que je retiens, en clair

Trois choses à retenir pour 2026 sur un Shopify :

1. Le crawl budget n’est plus un sujet enterprise. Avec la limite 2 Mo HTML de mars 2026, la prime à la latence DB et les AI bots qui pèsent 40 % de la bande passante, c’est devenu opérationnel pour toute boutique de 1 000+ SKUs.
2. Sept patterns sur Shopify expliquent l’essentiel du gaspillage. Filtres facettés, variants, search interne, sort_by, tags, pagination root et paramètres marketing. Un robots.txt.liquid propre (Niveau 1 du plan) règle 30 à 50 % du problème en une semaine.
3. On ne peut pas forcer Google à venir plus souvent. On peut seulement arrêter de le décourager. C’est l’architecture, la vitesse serveur, le JSON-LD SSR pour les AI bots, et la propreté du robots.txt qui font le crawl. Pas le budget Ads, pas IndexNow (sur Google), pas la migration Plus.

L’inventaire complet en format actionnable est dans la grille d’audit en 30 points (Tech, Architecture, Apps, Tracking, Recovery) accompagnée du template robots.txt.liquid 2026 commenté ligne par ligne, téléchargeable juste en dessous.

Le SEO Shopify qui parle chiffre d’affaires, pas vanity metrics.