Shopify, Wix, Webflow, Framer : ce que votre plateforme vous autorise face aux IA

Votre plateforme décide d'une partie de ce que les intelligences artificielles peuvent lire chez vous, parce qu'elle contrôle la racine de votre domaine. En 2026, Shopify, Wix, Webflow et Framer ont tous ouvert la publication d'un fichier llms.txt, un verrou qui tenait encore l'an dernier. La couche destinée aux agents, elle, reste inégale d'une plateforme à l'autre, et c'est désormais là que se joue l'écart.

Pourquoi votre plateforme change-t-elle ce que vous pouvez faire ?

Une partie des signaux que lisent les IA n'est pas dans vos pages, elle est dans des fichiers déposés à la racine du domaine : robots.txt, llms.txt, et le dossier .well-known qui héberge les fichiers destinés aux agents. Sur un site codé ou sur WordPress, vous êtes propriétaire de cette racine et vous y déposez ce que vous voulez. Sur une plateforme hébergée, cette racine appartient à l'éditeur du service, et vous ne pouvez y servir que ce qu'il a prévu de vous laisser servir.

C'est une contrainte technique, pas un défaut de votre part. Un dirigeant qui a choisi Shopify en 2022 n'a pas commis d'erreur de visibilité IA : la question ne se posait pas. Le sujet est de savoir ce que sa plateforme lui permet aujourd'hui.

Qu'est-ce qui a changé en 2026 sur les quatre grandes plateformes ?

Les quatre principaux constructeurs de sites ont livré, chacun à leur rythme, la possibilité de servir un fichier llms.txt à la racine du domaine. Ce fichier donne aux IA une vue résumée et hiérarchisée de ce que vous proposez. Le détail de ce qu'il contient, et pourquoi il compte commercialement, est traité dans notre article « llms.txt : la carte de visite que lisent les IA, et ce que ça change pour vos ventes ».

• Shopify sert désormais /llms.txt, /llms-full.txt et /agents.md nativement sur toutes les boutiques, avec un contenu généré par défaut. Depuis le 28 mai 2026, ces trois chemins peuvent être personnalisés par des gabarits Liquid ajoutés au thème.
• Wix génère et maintient automatiquement le fichier llms.txt de votre site, éditable depuis le tableau de bord SEO, avec une option pour le désactiver. Le service demande un site payant, un domaine personnalisé et l'indexation activée.
• Webflow propose un envoi de fichier llms.txt dans les réglages du site, servi sur le domaine personnalisé, en UTF-8 et sous 100 Ko. Il n'est pas publié sur le domaine de préproduction.
• Framer héberge des fichiers statiques à la racine ou dans un dossier .well-known depuis les réglages d'hébergement, sur les formules Pro et Enterprise.

L'enseignement pratique tient en une phrase : si vous avez renoncé à llms.txt en vous fiant à un article de 2025 qui vous disait que votre plateforme le rendait impossible, cette information est périmée. Vérifiez avant de conclure.

Qu'est-ce qui reste hors de portée aujourd'hui ?

L'ouverture porte sur llms.txt, pas sur tout le reste. La version Markdown page par page, que la spécification llms.txt propose sous la forme de variantes .md de chaque URL, n'est pas couverte par Webflow, qui écrit noir sur blanc que son implémentation est volontairement limitée au seul fichier llms.txt. Shopify, de son côté, sert trois chemins définis par Shopify, et rien d'autre : les fichiers destinés aux agents restent hors de portée d'une boutique, et le service documente que le robots.txt ne s'édite que via un gabarit Liquid non pris en charge par son support.

Le dossier .well-known, qui héberge la carte de capacités d'un serveur MCP, l'index de compétences agents et les métadonnées d'authentification, suit une logique de palier commercial. Webflow le réserve à son API Enterprise, avec une limite documentée de 30 fichiers de moins de 100 Ko. Framer l'ouvre à partir de la formule Pro. La couche agents n'est donc pas verrouillée par la technique seule : elle l'est par votre abonnement.

Comment un scan honnête traite-t-il un signal que votre plateforme interdit ?

Un signal que votre plateforme ne permet pas d'installer est marqué impossible, au lieu d'être compté contre votre site. Il disparaît du plan d'action, et il ne se transforme jamais en conseil que vous ne pourriez pas appliquer. Reprocher à une boutique Shopify de ne pas exposer de carte de capacités pour agents reviendrait à lui reprocher la météo, et surtout à lui vendre une prestation qui n'existe pas. C'est le principe exposé sur notre page méthode.

Le cas des sites multiples mérite une précision, parce qu'il est fréquent. Beaucoup d'entreprises font tourner une vitrine WordPress et une boutique Shopify sur le même domaine ou sur deux sous-domaines. Un signal n'est alors marqué impossible que s'il l'est sur toutes les plateformes concernées : une vitrine WordPress peut parfaitement servir le llms.txt que la boutique ne servirait pas. La contrainte se calcule sur l'ensemble réel, pas sur la plateforme la plus fermée.

Pourquoi un signal non mesuré ne doit-il pas se lire comme un échec ?

Un fichier injoignable, un délai dépassé ou une erreur serveur produisent une absence de mesure, pas un constat d'absence. Ces signaux sortent du calcul plutôt que de compter zéro, et chaque rapport indique combien de signaux ont réellement été vérifiés sur les 19 du référentiel. Un signal non mesuré ne peut pas non plus déclencher le verdict le plus sévère : un site n'est déclaré invisible que sur un échec réellement constaté, jamais sur un doute. La distinction entre ce qu'un scan constate et ce qu'il ignore est développée dans « Ce qu'un scan de visibilité IA mesure vraiment, et ce qu'il ne mesure pas ».

Cette nuance a une conséquence commerciale directe. Un outil qui compte zéro sur ce qu'il n'a pas su lire produit des scores bas, spectaculaires, et faux. Il vend de la peur au lieu de vendre une mesure.

Quand votre plateforme n'est-elle pas le problème ?

Le plus souvent, la plateforme n'est pas la cause principale d'invisibilité. Deux problèmes plus banals la précèdent. Le premier est l'absence de contenu à citer : une IA ne recommande pas une entreprise dont le site tient en cinq pages de slogans, quelle que soit la qualité de ses fichiers techniques. Le second est l'absence de notoriété : si personne ne parle de vous ailleurs sur le web, aucun fichier à la racine ne créera cette matière.

Une boutique Shopify avec de vraies fiches produit, des réponses aux questions que posent les acheteurs et des mentions dans la presse professionnelle sera citée avant un site codé sur mesure, techniquement irréprochable et vide. Dans ce cas, votre budget est mieux investi dans le contenu que dans une migration de plateforme. Une migration se justifie quand le contenu existe déjà et que la plateforme devient le facteur limitant, pas avant.

Que faut-il vérifier sur votre propre site cette semaine ?

Trois questions suffisent à situer votre site. Votre plateforme sert-elle un fichier llms.txt, et décrit-il votre activité ou récite-t-il un modèle générique fourni par l'éditeur ? Votre contenu est-il lisible directement dans le code de la page, ou faut-il exécuter du JavaScript pour le voir apparaître ? Votre robots.txt laisse-t-il entrer les robots des moteurs de réponse, ceux qui vont chercher une page pour répondre à une question posée maintenant ?

Aucune de ces trois vérifications ne garantit une citation. Elles conditionnent une éligibilité : sans elles, la citation est très improbable ; avec elles, elle devient possible. C'est la seule promesse honnête que l'on puisse faire aujourd'hui sur ce marché.