Ce qu'un robot d'IA reçoit vraiment de votre site

L'avertissement habituel est que les robots d'IA n'exécutent pas JavaScript, donc qu'un site moderne leur est invisible. La première moitié est vraie et bien documentée. La seconde est un saut, et pour les plateformes sur lesquelles la plupart des sites vitrines sont construits, elle est fausse. Nous l'avons mesuré plutôt que supposé, car la mesure prend une minute et la supposition s'est répétée jusqu'au folklore.

La méthode

Un robot qui n'exécute pas JavaScript voit exactement les octets renvoyés par le serveur et rien d'autre. Demandez donc la page avec un user-agent de robot, retirez tout ce qui est dans script, style et noscript, supprimez les balises restantes et comptez les mots qui restent. C'est le contenu avec lequel le robot doit travailler. Tout le test tient en un curl et vingt lignes d'analyse, et chacun peut le relancer sur son propre site.

Chaque site testé sert son contenu dans le HTML initial. Le site client Framer renvoie 3 322 mots avec dix-neuf éléments h2 avant qu'une seule ligne de JavaScript ne s'exécute. Les sites Webflow renvoient leurs titres, leur navigation et leur corps de texte. Ce site en renvoie 2 763. Webflow publie du HTML statique et Framer effectue le rendu serveur de ses sites publiés : l'alarme ne décrit ni l'un ni l'autre.

L'avertissement reste valable pour le motif, pas pour la plateforme. Un contenu qui n'existe qu'après une requête est réellement invisible : un tableau tarifaire chargé depuis une API, un jeu de résultats filtré, un accordéon dont les panneaux sont injectés au clic, un widget d'avis, un embed tiers. Ces éléments apparaissent sur des sites Webflow et Framer aussi souvent qu'ailleurs, et c'est cela qu'il faut auditer. La plateforme n'est pas le risque. Le composant l'est.

Deux manques que le test révèle

La colonne JSON-LD est la vraie découverte. Deux des sites testés ne renvoient aucune donnée structurée : rien sur la page n'indique à une machine de quel type de chose il s'agit ni qui l'a publiée. C'est un problème bien moins coûteux à corriger qu'un problème de rendu, et c'est celui qui est réellement présent.

Le second est la colonne octets par mot, une façon de demander quelle part de ce que vous envoyez est du contenu. Ce site envoie 129 octets par mot visible. La page d'accueil de Framer en envoie 1,328, soit 2,2 Mo de HTML portant 1 661 mots. Rien n'est cassé là-dedans et le rendu est superbe pour un humain, mais un robot qui parcourt beaucoup de pages paie toute la charge utile pour atteindre le dixième de pour cent qui est du texte. C'est l'instinct qui préside à garder une page rapide pour les humains, exposé dans pourquoi un site Webflow ralentit, appliqué à un autre lecteur.

Quoi en faire

• Faites le test sur votre propre page d'accueil avant de croire quoi que ce soit, y compris ceci. Récupérez-la avec un user-agent de robot, retirez les scripts et lisez ce qui reste.
• Auditez les composants, pas les plateformes. Tout ce qui arrive après une requête est ce qui risque, quel que soit l'outil ayant produit la page.
• Ajoutez les données structurées avant d'optimiser autre chose. C'est le signal le moins cher de la liste et deux sites sur six ici ne l'ont pas.
• Vérifiez le fichier avant la page. Un robot interdit n'atteint jamais le HTML, et c'est un audit distinct : regardez quels agents votre robots.txt adresse réellement.

Le pendant de cet article est quels robots d'IA respectent vraiment robots.txt, qui traite de l'accès, et comment les moteurs de recherche IA décident quoi citer traite de ce qui se passe une fois la page à la fois accessible et lisible. Si vous hésitez encore entre les outils, la question du rendu ne doit pas trancher : voir Webflow ou Framer.