Un curl contre trois crawlers, trois plateformes d'avis.

Nous voulions savoir ce qu'un crawler IA voit réellement sur une page produit Shopify. Pas ce qu'une présentation commerciale prétend qu'il voit, ni ce qu'une page SEO d'un éditeur de Widget affirme, mais ce qui revient quand on pose la question directement, avec un terminal et une seule requête HTTP.

La façon de poser la question consiste à faire semblant, un instant, d'être le crawler. Définissez votre user agent sur GPTBot, lancez un curl vers l'URL du produit, enregistrez le HTML sur disque, ouvrez-le dans n'importe quel éditeur capable de faire une recherche de chaîne. Cherchez la phrase la plus distinctive de l'avis le mieux noté de la boutique, le genre de phrase qui n'apparaît nulle part ailleurs sur la page ni dans les contenus marketing de l'éditeur. Si la phrase se trouve dans le fichier, le crawler l'a vue. Si elle n'y est pas, le crawler ne l'a pas vue, et ce qui arrive au langage du client en aval de cette requête se passe sans que cette phrase soit dans le tableau.

Il y a quelques semaines, nous avons effectué ce test sur trois boutiques, avec trois crawlers chacune. Neuf requêtes au total, contre trois des plateformes d'avis les plus populaires sur le Shopify App Store (une boutique Yotpo, une Okendo, une Loox), toutes dans leurs installations par défaut de l'App Store. Le résultat est une grille trois fois trois que cet essai parcourt cellule par cellule. La plupart des cellules sont vides. Celles qui ne le sont pas ne contiennent qu'une note globale, sans aucun texte.

Les boutiques resteront anonymes (Boutique A, Boutique B, Boutique C) car ce sont les plateformes qui sont en cause, pas les marchands. Le même test sur n'importe quelle boutique Shopify utilisant n'importe quel Widget donnerait, selon nous, le même résultat. Vingt minutes, un terminal, une recherche de chaîne.

Les URL de boutiques ont été choisies comme le ferait un acheteur. Chacune était le premier résultat organique pour une requête produit non brandée (un sérum, une bougie, un complément pour animaux). Chacune avait entre trois cents et trois mille avis sur la page produit, selon le propre tableau de bord du marchand. Chacune utilisait son logiciel d'avis dans une installation neuve, non modifiée, sans niveau de rendu côté serveur personnalisé ni fonctionnalité enterprise.

La Boutique A utilisait Yotpo, dans la configuration Widget standard disponible sur le Shopify App Store.

La Boutique B utilisait Okendo, dans la même configuration standard.

La Boutique C utilisait Loox, la plateforme d'avis photo et vidéo, également dans la configuration par défaut de l'App Store.

Nous avons effectué les requêtes depuis une adresse IP résidentielle unique, en mai 2026, avec chaque chaîne de user agent définie verbatim depuis les pages publiées par les plateformes pour les opérateurs de crawlers. Nous n'avons pas interagi avec les pages. Nous n'avons pas exécuté JavaScript. Nous n'avons pas suivi les iframes. Nous avons demandé le HTML de la même façon que le font les crawlers eux-mêmes : une requête GET, l'en-tête user agent approprié, pas de cookies, pas de préférence Accept-Language autre que la valeur par défaut.

La documentation publiée pour les trois bots est sans ambiguïté. GPTBot d'OpenAI, selon la page pour les opérateurs de crawlers d'OpenAI (consultée en mai 2026), récupère et analyse le HTML ; il n'exécute pas JavaScript. ClaudeBot d'Anthropic, selon la documentation publiée sur les bots d'Anthropic, récupère et analyse le HTML ; il n'exécute pas JavaScript. PerplexityBot de Perplexity, le crawler d'indexation distinct de l'agent PerplexityUser qui se déclenche lors de requêtes en temps réel, se comporte de la même façon : HTML uniquement.

Tel est l'univers de l'expérience. Trois pages, trois crawlers, neuf requêtes, une question par cellule : le HTML brut retourné par le serveur contient-il le texte de l'avis que l'acheteur voit dans son navigateur ?

La page que la Boutique A retourne à GPTBot fait cinquante kilo-octets. Elle contient le thème rendu en Shopify Liquid : l'en-tête, le titre du produit, le prix, le sélecteur de variante, le bouton d'achat, la description du produit, le guide des tailles, l'extrait de politique d'expédition, le pied de page. Elle contient des données structurées pour le produit, un schema Product avec nom, prix, image et un nœud AggregateRating unique citant le nombre d'avis et la note moyenne (l'AggregateRating est côté serveur, seule preuve en forme d'avis dans le HTML).

Ce qu'elle ne contient pas : le texte d'aucun des 812 avis que Yotpo détient pour ce produit. La section d'avis est un div avec la classe `yotpo-main-widget`, quelques attributs de données (identifiant produit, nom, URL image, prix, devise) et une balise script asynchrone pointant vers le CDN statique de Yotpo. Le div est vide dans la réponse, et le script n'a pas été exécuté.

Nous avons cherché dans le fichier la phrase la plus distinctive de l'avis le mieux noté : une phrase spécifique sur la texture et la façon dont le produit se sent sous le maquillage. La phrase n'apparaissait pas, et les correspondances partielles ne donnaient rien. Nous avons cherché le mot "avis" partout en dehors de la note globale et des données structurées : une demi-douzaine de correspondances dans des libellés de navigation et des attributs ARIA. Aucun d'eux n'était un avis.

Le crawler revenu de cette page aurait emporté la description du produit par le marchand, le prix, la note globale et la connaissance qu'il existe 812 avis quelque part qu'il ne peut pas lire. Il n'aurait emporté aucune phrase.

La page que la Boutique A retourne à ClaudeBot est, octet pour octet, identique à la page retournée à GPTBot. L'origine Shopify ne fait pas varier sa réponse en fonction du user agent ; elle sert le même thème rendu en Liquid à n'importe quel client. Le Widget d'avis est le même div vide, la balise script est le même fetch asynchrone, et le crawler d'Anthropic, tout comme celui d'OpenAI, n'exécute pas le script.

L'index de ClaudeBot pour cette page est le même que celui de GPTBot : note globale, nombre d'avis, aucun avis, même lacune.

Nous avons confirmé cela en cherchant la même phrase distinctive. Absente.

Même réponse. Même div vide. Même balise script. Même absence de la phrase de l'avis.

PerplexityBot, dans notre test, s'est comporté de la même façon que GPTBot et ClaudeBot. L'agent PerplexityUser, qui se déclenche quand un utilisateur pose une question à Perplexity et que Perplexity va chercher un petit nombre de pages en temps réel, se comporte davantage comme un navigateur et peut dans certains cas rendre du JavaScript simple. Mais PerplexityUser n'est pas l'indexeur. L'indexeur est PerplexityBot, et PerplexityBot n'exécute pas JavaScript.

La première ligne de la grille est donc vide dans les trois cellules. Yotpo, dans son installation standard, est invisible pour tous les crawlers IA que nous avons testés.

Okendo est l'option premium-DTC sur le Shopify App Store. Il se positionne comme une alternative plus respectueuse du design et plus fidèle à la marque que Yotpo. L'esthétique du Widget est différente ; le mécanisme est le même.

La page que la Boutique B retourne est, mécaniquement, de la même forme. Un div conteneur Okendo, préfixé par `okeReviews`, un ensemble d'attributs de données (identifiant d'abonné, identifiant produit, locale) et une balise script pointant vers la distribution d3hw6dc1ow8pp2.cloudfront.net d'Okendo. Aucun avis dans la réponse. Aucun paragraphe. Un nœud AggregateRating dans les données structurées, puisqu'Okendo, comme Yotpo, inscrit la note globale dans la page côté serveur pour des raisons SEO. Aucune citation.

GPTBot, ClaudeBot et PerplexityBot retournent tous le même résultat sur cette page : note globale, nombre d'avis, aucun avis.

La deuxième ligne de la grille est donc vide dans les trois cellules.

Loox est la plateforme d'avis photo et vidéo. Son différenciateur est visuel : chaque avis comporte, dans la plupart des installations, une image soumise par le client. La page que la Boutique C retourne est, mécaniquement, la plus chargée en JavaScript des trois : le carrousel de photos, la lightbox, le chargement différé des images. Presque tout ce que l'acheteur voit dans son navigateur est rendu après le chargement de la page.

Le HTML que le serveur retourne est, en conséquence, le plus dépouillé. Il y a un div avec la classe `loox-reviews-default` et quelques attributs de données, suivi d'une balise script. Il n'y a aucune image dans le HTML initial, aucun texte d'avis, et, dans le cas de Loox, pas même de nœud AggregateRating dans les données structurées de la page par défaut (le marchand peut configurer cela, mais l'installation par défaut ne l'inclut pas).

GPTBot, ClaudeBot et PerplexityBot ont tous retourné le même résultat : aucun avis. La troisième ligne de la grille est vide dans les trois cellules.

Trois lignes. Trois colonnes. Neuf cellules. Zéro cellule contient le texte des avis.

Nous le répétons, parce que c'est le résultat et la raison de cet essai. Sur trois des plateformes d'avis les plus populaires sur le Shopify App Store, sur trois des quatre crawlers IA les plus utilisés dans l'économie de la citation (Googlebot étant le quatrième, et nous y reviendrons), le texte des avis se trouve dans zéro des neuf cellules. Les crawlers reviennent avec une note globale dans six des cellules et rien dans trois des cellules. Ils ne reviennent avec aucune phrase d'avis dans l'une quelconque des neuf.

Le marchand qui utilise un Widget JavaScript publie, dans l'économie de la citation, des notes globales. Il ne publie pas des avis.

Trois plateformes d'avis populaires. Trois crawlers IA populaires. Neuf requêtes. Zéro phrase d'avis. La grille est la preuve. La grille est aussi le problème.

Un lecteur raisonnable se demandera : et Googlebot ? Google exécute JavaScript, alors Googlebot ne résout-il pas ce problème ?

Nous avons réalisé la même expérience avec Googlebot, sur les trois mêmes pages, la même semaine. Le résultat est plus complexe et mérite son propre paragraphe.

Le moteur de rendu de Googlebot est réel. Il est aussi, comme la propre documentation de Google l'a explicitement indiqué depuis au moins 2018 et comme John Mueller l'a répété dans ses Office Hours tout au long de 2024 et 2025, sur un pipeline en deux étapes. La première étape récupère le HTML initial, tout comme le font les crawlers IA. La deuxième étape met la page en file d'attente pour le rendu, exécute un Chrome sans interface graphique, exécute JavaScript et indexe le DOM rendu. La deuxième étape est retardée : des heures dans le meilleur des cas, souvent des jours, des semaines pour les pages à faible priorité.

Lorsque nous avons récupéré les trois mêmes pages via l'outil d'inspection d'URL de Google, toutes trois ont retourné le DOM rendu avec les avis présents. Donc en théorie, Googlebot voit bien les avis. En pratique, le délai entre la récupération initiale et l'index rendu signifie que la fraîcheur du corpus d'avis, dans l'index de Google, est structurellement en retard sur le corpus réel du marchand. L'acheteur qui a rédigé un avis sur un sérum hier ne figure pas dans l'index de Google aujourd'hui.

Et cela, c'est Google. Google-Extended, le signal de routage qui détermine si une page est utilisée pour entraîner Gemini, dépend du crawl de Googlebot. ChatGPT, Claude et Perplexity n'ont pas une telle relation. Ils n'ont pas de moteur de rendu en deuxième étape. La note globale est le maximum qu'ils emporteront jamais d'un Widget JavaScript.

Nous avons écrit séparément au sujet de the engine the answer engine reads, sur ce qu'un moteur de réponse consomme réellement quand il lit une page produit. Cet essai en est la version empirique : le moteur lit du HTML, le HTML ne contient pas les avis, la grille est vide.

Une deuxième objection raisonnable : les trois boutiques que nous avons échantillonnées utilisaient les installations par défaut, au niveau de l'App Store, de leurs plateformes d'avis. Chacune de ces plateformes dispose d'un niveau enterprise (Yotpo Enterprise, Okendo Plus, Loox Scale) avec des modules optionnels de rendu côté serveur. Le marchand qui paie le tarif supérieur peut, en principe, opter pour des extraits d'avis rendus côté serveur.

C'est exact. Cela ne change pas le résultat.

Nous avons examiné la documentation technique publiée pour les offres SSR de chacune des trois plateformes. Dans tous les cas, le rendu côté serveur inclut un petit bloc d'avis dans le HTML initial : généralement trois à dix, souvent les plus récents ou les mieux notés. Le reste du corpus est toujours côté client. Un marchand avec 800 avis qui active le SSR en publie dix aux crawlers IA. Les 790 autres sont toujours dans le Widget.

C'est mieux que zéro. Ce n'est pas la parité.

Et c'est conditionné à un niveau tarifaire plus élevé que le marchand par défaut de l'App Store, qui est l'utilisateur médian de Shopify, ne paie pas. Dans la longue traîne des boutiques Shopify en 2026, l'installation par défaut est l'installation standard. L'installation par défaut est invisible.

Il y a un deuxième détail mécanique qui mérite d'être mentionné. Les extraits rendus côté serveur que chaque plateforme livre sont eux-mêmes sélectionnés, dans la plupart des cas, pour favoriser les avis positifs en haut, les avis récents en haut, ou les avis courts qui tiennent dans un bloc visuel fixe. Les avis qui sont rendus côté serveur ne sont pas un échantillon aléatoire du corpus. Ce sont les dix avis acceptables pour le marketing. Les crawlers, là où ils obtiennent des avis, obtiennent les plus beaux. Les avis complexes (le quatre étoiles "je l'adore mais le bouchon est difficile à ouvrir", le trois étoiles "bien pour la journée, pas pour la nuit"), les avis longs, les avis qui contiennent un mot-clé spécifique de longue traîne que l'acheteur va rechercher, sont toujours dans le Widget JavaScript, toujours invisibles. Le problème de sélection aggrave le problème de rendu. Le crawler ne voit pas seulement peu d'avis ; il en voit peu d'un type particulier, et rate entièrement la longue traîne.

Nous avons soutenu dans the end of the review widget que la forme du Widget est structurellement inadaptée au travail que le langage des acheteurs est censé accomplir. Cet essai en est la confirmation en forme de curl. Le Widget se rend pour l'acheteur. Il ne se rend pas pour le crawler. Le marchand paie pour les deux audiences et n'en atteint qu'une seule.

Une troisième objection, parfois formulée dans les documents marketing des plateformes d'avis : les crawlers IA ne représentent qu'une petite fraction du trafic. Pourquoi les optimiser quand Googlebot porte encore l'index ?

Nous laisserons de côté le problème de fraîcheur avec Googlebot, que nous avons abordé ci-dessus. La réponse plus profonde est que les crawlers IA ne sont pas la source du trafic ; ils sont la source de la conversion. Un acheteur qui demande à ChatGPT le meilleur sérum pour les peaux sensibles est en aval d'une réponse qui a déjà cité les avis d'une boutique. L'acheteur qui arrive à la boutique depuis cette réponse arrive avec une intention que la recherche organique conventionnelle n'égale pas. Adobe Analytics, dans son rapport de commerce de fin d'année 2025, a observé que les visiteurs arrivant via des sources d'IA générative avaient un taux de conversion 9,4 % plus élevé que les visiteurs arrivant via la recherche traditionnelle, et une durée de session sur le site 12 % plus longue.

Les cellules de la grille ne sont pas abstraites. Chaque cellule vide est une conversion en aval que le marchand n'obtient pas. L'auteur de l'avis a écrit la phrase qui aurait produit la citation. Le marchand a collecté la phrase, le crawler ne l'a pas vue, et le moteur de réponse a cité quelqu'un d'autre.

Dans the citation economy, on n'a pas une deuxième chance d'être la source. La marque qui possède la citation possède l'acheteur. Celle qui ne la possède pas apparaît dans la réponse de quelqu'un d'autre, comme un concurrent mentionné en passant ou pas mentionné du tout.

Une courte liste, dans la même forme que l'expérience.

Choisissez la page de votre produit le plus vendu et copiez l'URL.

Ouvrez un terminal, lancez un curl avec votre user agent défini sur GPTBot, enregistrez la sortie et ouvrez-la dans n'importe quel éditeur de texte. Cherchez la phrase la plus distinctive de votre meilleur avis. Si la phrase n'est pas dans le fichier, vos avis ne figurent pas dans l'index que le pipeline d'entraînement et de récupération de ChatGPT utilise. Faites de même avec ClaudeBot, puis avec PerplexityBot.

Le résultat sera l'un des trois suivants. Si la phrase se trouve dans les trois fichiers, vous utilisez un système d'avis rendu côté serveur, ce que les applications dominantes du Shopify App Store en 2026 ne font pas, et vous faites partie d'une petite minorité chanceuse. Si la phrase se trouve dans certains fichiers et pas dans d'autres, vous utilisez une configuration inhabituelle (Judge.me avec le SSR partiel, ou l'un des niveaux SSR enterprise) et la lacune a la forme d'un gruyère. Si la phrase ne se trouve dans aucun des fichiers, vos avis ne sont pas sur Internet pour les crawlers IA, et vous êtes dans la même ligne de la grille que tout le monde.

Vous saurez, après le test, où vous vous situez dans la grille. Le test prend vingt minutes. La décision suivante est celle de savoir quoi faire de la cellule.

La réponse honnête est peu glamour : changer l'endroit où vit l'enregistrement canonique du corpus. En ce moment, il vit dans le JavaScript de l'éditeur de Widget, s'hydratant dans le DOM un instant après le premier rendu. Le navigateur de l'acheteur est assez patient pour attendre cette hydratation. Le crawler, en grande partie, ne l'est pas.

Le travail consiste donc à obtenir une copie du corpus hors du CDN du fournisseur et dans le HTML que Shopify livre dès le premier octet. Pas nécessairement tout le corpus ; les cent derniers avis feront la majeure partie du travail, particulièrement s'ils incluent les mieux notés et les plus récents ainsi qu'un échantillon sur la queue des quatre et trois étoiles. Le Widget peut rester sur la page si le marchand apprécie l'aspect visuel des étoiles et des photos (la plupart y tiennent). Ce qui compte, c'est que quelque part au-dessus ou en dessous du Widget, dans un balisage rendu côté serveur, il y a une liste sémantique d'articles, chacun avec une date, un pseudonyme d'auteur, une note et le paragraphe réel que le client a écrit.

Cet argument se trouve dans reviews are language not inventory dans l'abstrait. La grille ci-dessus en est la version concrète : la cellule est vide parce que le langage est dans JavaScript, et la cellule se remplit dès que le langage passe dans du HTML que le crawler peut lire dès le premier passage.

La mise en oeuvre technique est limitée. Chaque plateforme d'avis que nous avons examinée expose un endpoint JSON pour le corpus. Un thème Shopify peut appeler cet endpoint au moment de la requête, parcourir la réponse, rendre les articles dans le template produit. Un après-midi de travail sur le thème dans la plupart des cas, parfois moins, occasionnellement une journée si le marchand veut aussi pré-mettre en cache la réponse et la servir depuis la périphérie.

Dans un an, les marchands dont les grilles sont pleines ne seront pas ceux qui ont choisi un Widget plus joli. Ce seront ceux qui ont discrètement livré une page différente.

À vrai dire, nous ne blâmons pas vraiment les éditeurs de Widget d'être ce qu'ils sont. Ils livrent ce qu'ils ont été construits pour livrer : un élément d'interface utilisateur, des étoiles, un compteur, un carrousel de photos, un badge "acheteur vérifié". C'était le brief en 2015 et c'est encore le brief lors de la plupart des appels d'intégration avec les marchands en 2026. Le brief a été, selon ses propres termes, rempli.

Ce qui a changé depuis 2015 n'est pas le brief. C'est la deuxième audience pour laquelle personne n'a écrit de brief. Les crawlers sont arrivés discrètement au cours des deux dernières années et ils lisent le HTML que le serveur leur remet lors de la première requête, et ce qu'ils emportent est ce qui est ensuite cité dans la réponse d'un acheteur dans un contexte que le marchand ne voit jamais. Cette deuxième audience était toujours implicite dans le rôle du Widget. Désormais, c'est la plus importante des deux, et c'est celle que le Widget est le moins équipé pour servir.

Si vous n'avez pas encore lancé le curl contre votre propre boutique, vous ne savez pas vraiment de quel côté de cette équation vous vous situez. Faites-le donc. Une commande dans un terminal, l'URL de votre produit le plus vendu, trois crawlers l'un après l'autre. Cherchez dans la réponse la ligne la plus distinctive de votre avis le mieux noté. Si elle n'y est pas (et nous parierions qu'elle n'y est pas), vous venez de voir exactement ce qu'un moteur de réponse voit quand il vient lire votre boutique. Ce que vous décidez de faire ensuite vit dans l'écart entre ce résultat et ce que votre acheteur voit dans son navigateur.