Un client m'a appelé en octobre dernier, paniqué. Son site e-commerce recevait une tonne de trafic que ses analyses affichaient comme des visites « directes », mais les conversions avaient chuté. Après avoir fouillé les logs du serveur pendant environ une heure, j'ai réalisé qu'une partie importante de ce trafic n'était pas du tout des humains. C'étaient des agents IA, spécifiquement des assistants shopping et des outils de comparaison alimentés par LLM, qui parcouraient ses pages produits et repartaient parce qu'ils ne pouvaient pas analyser le contenu correctement. Les données structurées étaient un désastre. Les prix étaient enfouis dans du JavaScript. Les noms de produits vivaient dans des balises <h3> stylisées pour ressembler à des <h2>. Les agents arrivaient, trouvaient du bruit, et repartaient.
C'est où nous en sommes maintenant. Les agents IA ne viennent pas. Ils sont déjà là, lisent déjà vos sites, prennent déjà des décisions en fonction de ce qu'ils peuvent ou ne peuvent pas extraire. Et la plupart des plus de 12 000 sites que j'ai construits ou touchés au fil des années chez Seahawk Media n'ont pas été construits en gardant cela à l'esprit. Ni les vôtres, probablement.
Ce que « Lisible par les Agents » Signifie Réellement
Soyons direct sur un point. Lisible par les agents ne signifie pas « favorable à l'IA » au sens vague du marketing. Cela signifie qu'une machine peut arriver à une URL, analyser le contenu sans exécuter trois couches de JavaScript, extraire ce qu'elle cherche, et agir dessus. C'est tout.
Les humains sont indulgents. Nous balayons. Nous déduisons. Nous voyons un grand nombre sur une page de tarification et nous savons que c'est le prix même s'il est enrobé dans une <div class="fancy-number">. Un agent IA suivant un flux de travail structuré ? Pas aussi indulgent. Il a besoin de signaux, de hiérarchie et de prévisibilité.
Les agents qui effectuent ce travail en ce moment incluent l'outil de navigation d'OpenAI, le mode en ligne de Perplexity, et des dizaines d'agents personnalisés construits avec des frameworks comme LangChain et AutoGen. Ils partagent tous un besoin commun : du HTML propre, analysable, sémantiquement significatif avec des données structurées en support.
Le Vrai Problème : Architecture Basée sur JavaScript
C'est celui que je vois le plus souvent. Les agences et les freelancers construisent des sites sur React ou Next.js (ou Vue, ou Svelte, d'accord), ils font du rendu côté client, et ils considèrent le travail terminé. Le site est magnifique. Google peut l'explorer, plus ou moins, parce que Googlebot a maintenant un moteur de rendu headless Chrome intégré.
Mais la plupart des agents IA n'exécutent pas headless Chrome. Ils récupèrent du HTML brut via HTTP. Si votre contenu n'existe que après l'exécution de JavaScript, ces agents reçoivent une page vierge ou un spinner de chargement sérialisé en texte.
En 2022, Seahawk avait un client fintech qui avait construit toute sa section de taux et de comparaison de produits dans une SPA React. Pas de SSR, pas de secours statique. Nous avons lancé un simple curl contre leur URL et avons obtenu littéralement 14 lignes de HTML : une <div id="root"> et quelques balises script. C'est ce qu'un agent voit. Quatorze lignes.
La solution n'est pas nécessairement d'abandonner votre framework JS. C'est le rendu côté serveur (SSR) ou la génération de site statique (SSG). Next.js avec getServerSideProps ou getStaticProps. Nuxt pour Vue. SvelteKit. Ou même juste pré-rendre les pages clés avec quelque chose comme Prerender.io si vous êtes bloqué sur une configuration héritée. Le contenu doit être dans la charge utile HTML initiale.
Le HTML Sémantique N'est Plus Optionnel
Je sais. Vous entendez « utiliser du HTML sémantique » depuis 2009. Mais je ne le dis pas pour des raisons de SEO en ce moment. Je le dis parce que les agents utilisent les balises sémantiques pour comprendre quel type de chose ils regardent.
<article>, <nav>, <main>, <aside>, <header>, <footer>, ce ne sont pas des éléments de décoration. Ce sont des signaux. Un agent essayant d'extraire le contenu principal d'une page cherchera d'abord <main>. Si vous avez construit votre mise en page avec des <div> imbriquées et rien d'autre, l'agent doit deviner. Les agents qui devinent mal retournent des réponses incorrectes aux utilisateurs.
Voici ce que j'audit sur tous les sites maintenant :
- Y a-t-il exactement un élément <main> par page ?
- Les titres suivent-ils une hiérarchie logique (<h1> vers <h2> vers <h3>) sans sauter de niveaux ?
- Les menus de navigation sont-ils dans des éléments <nav> ?
- Le contenu supplémentaire (barres latérales, articles connexes) est-il dans des <aside> ?
- Les listes d'éléments sont-elles vraiment des <ul> ou <ol>, et non une succession de <div class="item"> ?
Ça semble basique. Et pourtant je dirais que 60 % des sites WordPress que je passe en revue échouent sur au moins trois de ces points. Celui de la hiérarchie des titres est presque universel : les designers stylisent les <h3> pour qu'ils paraissent gros et les <h2> pour qu'ils paraissent petits et personne ne corrige le balisage en dessous.
Schema Markup : Fais le Travail Réellement Ici
C'est là que la plupart des guides deviennent génériques. Je vais essayer de ne pas le faire.
Les données structurées Schema.org disent aux agents non pas seulement ce qui est sur la page, mais quel type de chose c'est. Un produit. Une recette. Une entreprise locale. Une FAQ. Un événement. Et ça lui donne ces données dans un format que les agents peuvent consommer sans analyser du texte brut.
Les types qui importent le plus en ce moment, selon mon expérience :
- Produit (avec offres, prix, disponibilité — tous les trois, toujours)
- LocalBusiness (avec openingHoursSpecification et coordonnées géographiques, pas juste une chaîne d'adresse)
- Article (avec datePublished, dateModified et author en tant que type Person, pas une simple chaîne)
- FAQPage (plus de détails ci-dessous)
- BreadcrumbList (sous-estimé, donne aux agents une carte de la hiérarchie de votre site)
- HowTo (si vous publiez des tutoriels ou de la documentation de processus)
Pour les sites WordPress, j'utilise Yoast SEO ou Rank Math pour les bases, puis j'étends manuellement avec du schema personnalisé dans un bloc <script type="application/ld+json"> pour tout ce qu'ils ne couvrent pas. JSON-LD est le format à utiliser. Pas RDFa, pas microdata. JSON-LD. Cela garde le balisage propre et les agents peuvent l'extraire sans toucher à votre couche de présentation.
Une erreur que j'ai commise en 2021 : j'ai mis du schema sur les pages produits d'un client mais j'ai laissé le champ price vide parce que leurs prix étaient « contactez pour un devis ». Le validateur de schema l'a accepté. Mais les agents extrayaient un prix vide et le renvoyaient aux utilisateurs comme « prix : inconnu », ce qui tuait la confiance. La solution était soit d'inclure une plage de prix réaliste avec minPrice / maxPrice, soit de supprimer entièrement le bloc offers. Les données partielles peuvent être pires que l'absence de données.
Structure du contenu : Écrire pour une extraction facile à scanner
Voici comment les agents lisent la prose. Ils ne la lisent pas comme vous le faites. Ils cherchent des réponses à des questions, des faits qu'on peut extraire, et des relations claires entre les affirmations.
Cela signifie que votre structure de contenu doit mettre la réponse en avant. Si quelqu'un (ou quelque chose) demande « combien de temps prend la livraison ? », votre page devrait avoir un titre qui dit quelque chose comme « Délais de livraison » et la première phrase sous celui-ci devrait indiquer le chiffre réel. Pas un paragraphe de contexte sur vos opérations d'entrepôt. Le chiffre d'abord, puis le contexte.
J'ai commencé à structurer le contenu comme ceci sur les sites clients, presque comme une pyramide inversée pour chaque sous-section :
- Énoncez le fait ou la réponse directement dans la première phrase sous le titre
- Ajoutez une ou deux phrases de contexte supplémentaire
- Créez un lien vers une ressource plus approfondie si le sujet le justifie
C'est tout. Pas de paragraphes d'introduction. Pas de « bonne question, explorons ensemble ce sujet ». Les agents ignorent ce bruit et identifient parfois mal l'endroit où commence la véritable réponse.
Sur un site de voyage que nous avons restructuré au printemps dernier, nous avons restructuré 80 articles de cette façon en environ six semaines. Les citations Perplexity pour ces pages ont augmenté notablement. Plus important encore, les réponses vers lesquelles ces citations pointaient étaient réellement exactes, parce que le fait pertinent était trouvable.
Robots.txt, llms.txt et contrôle d'accès
Celui-ci est plus récent. Il existe une convention croissante, pas encore un standard, pour un fichier appelé llms.txt placé à la racine de votre domaine. L'idée, proposée par Jeremy Howard, est de donner aux LLMs une carte en texte brut du contenu le plus important de votre site et toute préférence d'accès. Pensez-y comme un robots.txt mais écrit en anglais clair pour les agents de modèles de langage plutôt que pour les bots de crawl.
Devriez-vous l'implémenter ? Honnêtement, oui. Cela prend 20 minutes à écrire. Cela signale que votre site est conscient des agents, et à mesure que davantage d'agents seront formés pour le chercher, cela deviendra un signal significatif.
Sur robots.txt spécifiquement : soyez intentionnel. Certains propriétaires de sites bloquent réflexivement tous les crawlers d'IA maintenant. C'est votre choix, mais un blocage systématique signifie que votre contenu n'apparaîtra pas non plus dans les réponses générées par l'IA, ce qui est un canal de distribution auquel vous renoncez. Pensez-y de la même façon que vous aviez pensé à bloquer Googlebot en 2005. Probablement pas une très bonne idée.
Liaison Interne et Architecture de Crawl
Un agent qui suit un workflow ne se pose pas simplement sur une page. Il suit les liens. La qualité de votre structure de liaison interne détermine quelle part de votre site un agent peut réellement parcourir et comprendre.
Une mauvaise liaison interne signifie que les agents indexent une ou deux pages de votre site et s'arrêtent. Ils n'obtiennent pas la vue complète de ce que vous offrez.
Une bonne liaison interne signifie :
- Chaque page importante est accessible en trois clics maximum à partir de la page d'accueil
- Le texte d'ancrage est descriptif, pas « cliquez ici » ou « lire la suite »
- Le contenu connexe est lié contextuellement dans le corps du texte, pas seulement dans un widget de barre latérale
- Les pages orphelines n'existent pas (ou si elles existent, vous le savez et avez choisi intentionnellement de les laisser ainsi)
J'exécute des crawls Screaming Frog sur les sites clients avant tout travail de lisibilité pour les agents. Le rapport des pages orphelines seul révèle habituellement du contenu que les clients pensent publié et trouvable, mais qui ne l'est pas. Un client avait 34 pages orphelines, y compris leurs principales études de cas. Personne ne faisait de lien vers elles. Ni les agents, ni les humains.
FAQ
Dois-je restructurer mon site entier pour être lisible par les agents ?
Non. Commencez par vos pages avec le plus de trafic et vos pages critiques pour la conversion. Généralement, c'est votre page d'accueil, vos pages de services ou produits principales, et tout contenu qui se classe actuellement et génère des prospects. Commencez par bien faire cela. Un audit complet du site est utile à terme, mais ce n'est pas par là qu'on commence.
Le balisage de schéma aide-t-il réellement les réponses des agents IA ?
D'après ce que j'ai observé sur les sites de nos clients, oui. Les agents qui extraient des données structurées retournent des réponses plus précises et attribuent les sources de façon plus fiable quand le schéma est présent. Cela dit, ce n'est pas un bouton magique. Le contenu sous-jacent doit toujours être précis et bien structuré. Le schéma aide les agents à trouver et faire confiance aux données ; il ne corrige pas les mauvaises données.
Qu'en est-il des sites avec du contenu payant ?
Utilisez la propriété de schéma isAccessibleForFree sur votre type Article, et le motif hasPart / isPartOf pour marquer quelles sections sont payantes. Cela dit aux agents ce qu'ils peuvent utiliser. La documentation de Google sur le balisage structuré de contenu payant couvre cela clairement, et la même logique s'applique aux agents non-Google.
llms.txt est-il largement supporté pour le moment ?
Pas universellement. Mais cela coûte presque rien à implémenter, et l'adoption précoce de conventions comme celle-ci tend à être payante. J'ai l'ai ajouté aux sites clients de Seahawk depuis début 2024. C'est un petit signal pour l'instant. Cela aura plus d'importance dans 12 mois.
Comment puis-je tester si un agent peut lire mon site ?
Commencez par curl -A "Mozilla/5.0" [votre URL] dans un terminal et regardez ce qui revient. Si votre contenu principal n'y figure pas, vous avez un problème de rendu. Ensuite, passez vos pages par le test Rich Results de Google pour valider le schéma. Et vérifiez l'audit d'accessibilité Chrome Lighthouse, parce que la lisibilité pour les agents et l'accessibilité se chevauchent bien plus que la plupart des gens ne le réalisent.
---
Le web a été construit pour les humains, puis adapté à titre onéreux pour les moteurs de recherche. Maintenant, il a besoin d'une autre adaptation, cette fois pour les agents qui ne naviguent pas comme le ferait un humain. Ce n'est pas une crise. C'est juste le prochain tour de travail. Et honnêtement, la plupart de cela sont de bonnes pratiques qui améliorent les sites pour les humains aussi. Un balisage plus propre, un contenu plus clair, moins de débordement JavaScript. Vous auriez probablement dû le faire de toute façon.