Écrire pour l'IA search : playbook technique du contenu machine-readable

En mars 2026, les AI Overviews de Google apparaissent sur plus de 30% des requêtes informationnelles en anglais. Perplexity traite des centaines de millions de requêtes par mois. ChatGPT Search indexe le web en continu. Le problème : ces systèmes ne « lisent » pas votre contenu — ils le parsent, le chunkerize, et décident en quelques millisecondes s'il mérite d'être cité ou ignoré. Si votre contenu n'est pas structuré pour cette extraction, vous êtes invisible dans la couche qui capte désormais une part croissante des clics.

Cet article est un playbook technique. Pas de principes vagues sur « écrire du contenu de qualité ». Du code, des patterns de structuration, et des mécanismes concrets pour rendre votre contenu extractible par les LLMs.

La mécanique d'extraction des LLMs : comprendre ce que vous optimisez

Avant de modifier une ligne de HTML, il faut comprendre comment un LLM consomme du contenu web. Le pipeline est fondamentalement différent de celui de Googlebot classique.

Du crawl au chunk : le parcours de votre contenu

Un moteur AI search (Google AI Overviews, Perplexity, ChatGPT Search) suit un pipeline en 4 étapes :

Crawl / retrieval : le bot récupère la page (ou un snapshot existant). Les user-agents varient — GoogleOther, PerplexityBot, ChatGPT-User, OAI-SearchBot, etc.
Extraction du contenu principal : suppression du boilerplate (nav, footer, sidebar). Algorithmes de type readability/trafilatura.
Chunking : découpe du contenu en segments de 256-512 tokens (variable selon le système). C'est le chunk, pas la page, qui est l'unité de citation.
Embedding + ranking : chaque chunk est vectorisé, comparé à la requête, et classé pour inclusion potentielle dans la réponse synthétisée.

L'implication directe : un article de 3000 mots parfaitement rédigé mais mal structuré produira des chunks ambigus. Le LLM ne pourra pas isoler la réponse à une question spécifique, et préférera citer un concurrent dont le contenu est plus granulaire.

Ce que les LLMs « voient » vs ce qu'ils ignorent

Les LLMs en mode search ne traitent pas le JavaScript côté client. Si votre contenu dépend d'un framework SPA sans SSR, il est tout simplement absent du pipeline. C'est un problème bien documenté pour les Single Page Applications, mais il prend une dimension nouvelle : là où Google finit par exécuter le JS (avec du délai), certains bots AI ne le font jamais.

Les éléments visuels (images sans alt, infographies sans texte alternatif, tableaux rendus en image) sont des trous noirs pour l'extraction. Un tableau HTML natif est parsable ; un screenshot de tableau dans un <img> ne l'est pas.

Structurer le HTML pour l'extraction par chunk

Le HTML sémantique n'est pas un nice-to-have esthétique. C'est le signal principal qui permet aux systèmes d'extraction de découper votre contenu en chunks cohérents.

La hiérarchie headings comme marqueur de segmentation

Les algorithmes de chunking utilisent massivement les headings (<h2>, <h3>) comme délimiteurs de segments. Un heading suivi de 2-3 paragraphes = un chunk propre avec un sujet identifiable. Un mur de texte sans heading = un chunk dont le sujet est ambigu.

Pattern recommandé : chaque <h2> couvre un sous-thème autonome. Chaque <h3> répond à une question spécifique. Le premier paragraphe après le heading contient la réponse directe (pattern « inverted pyramid »).

<article>
  <h1>Migrer de React SPA vers Next.js SSR : guide technique</h1>
  
  <h2>Pourquoi le SSR est critique pour le crawl AI</h2>
  <p>Les bots AI search (PerplexityBot, ChatGPT-User) n'exécutent pas 
  le JavaScript côté client. Sans SSR, votre contenu est invisible pour 
  ces systèmes. Le passage au SSR rend chaque page immédiatement 
  extractible au premier crawl.</p>
  
  <h3>Impact mesuré sur l'indexation AI</h3>
  <p>Après migration SSR, le taux d'inclusion dans les réponses 
  Perplexity passe typiquement de 0% à 12-18% pour les requêtes 
  informationnelles ciblées, sur la base de suivis manuels 
  sur des panels de 50-100 requêtes.</p>
  
  <h3>Configurations SSR minimales pour Next.js</h3>
  <!-- Contenu technique spécifique -->
</article>

Ce pattern semble basique. Il ne l'est pas. Analysez les 10 premiers résultats sur n'importe quelle requête technique : la majorité utilise des headings comme décoration (« Introduction », « Partie 1 ») au lieu de les utiliser comme résumés sémantiques du contenu qui suit.

Les éléments HTML que les LLMs exploitent réellement

Au-delà des headings, certains éléments HTML facilitent considérablement l'extraction :

<table> : les données tabulaires natives sont parsées et peuvent être citées sous forme structurée. Les LLMs excellent à synthétiser des tableaux comparatifs.
<dl> (definition list) : idéal pour les glossaires, les spécifications techniques. Le couple <dt>/<dd> est un signal sémantique fort de type « terme → définition ».
<code> et <pre> : les blocs de code sont identifiés comme tels et préservés dans les citations. Un snippet dans un <pre><code> a plus de chances d'être cité qu'un snippet dans un <p>.
<time datetime=""> : le signal de fraîcheur est extrait directement de l'attribut datetime, pas parsé depuis le texte visible.

<table>
  <caption>Comparatif des bots AI search (mars 2026)</caption>
  <thead>
    <tr>
      <th>Bot</th>
      <th>User-Agent</th>
      <th>Exécution JS</th>
      <th>Respect robots.txt</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Google AI Overviews</td>
      <td>GoogleOther / Google-Extended</td>
      <td>Partielle (via WRS)</td>
      <td>Oui</td>
    </tr>
    <tr>
      <td>Perplexity</td>
      <td>PerplexityBot</td>
      <td>Non</td>
      <td>Partiellement (controversé)</td>
    </tr>
    <tr>
      <td>ChatGPT Search</td>
      <td>OAI-SearchBot / ChatGPT-User</td>
      <td>Non</td>
      <td>Oui</td>
    </tr>
    <tr>
      <td>Anthropic (Claude)</td>
      <td>ClaudeBot</td>
      <td>Non</td>
      <td>Oui</td>
    </tr>
  </tbody>
</table>

Ce tableau, servi en HTML natif, sera extrait et cité tel quel par un LLM qui doit comparer les bots AI. Le même contenu en prose serait dilué sur 4 paragraphes et probablement mal chunké.

Structured data : du schema classique au schema pour LLMs

Le Schema.org classique (Article, Product, FAQPage) reste pertinent, mais la logique évolue. Les LLMs n'utilisent pas le Schema de la même manière que le moteur de recherche traditionnel.

Ce que les LLMs extraient du JSON-LD

Les systèmes RAG (Retrieval-Augmented Generation) qui alimentent les réponses AI utilisent le JSON-LD comme source de métadonnées structurées pour enrichir le contexte du chunk extrait. Les propriétés les plus exploitées :

author + author.sameAs : lien vers les profils d'autorité (LinkedIn, profil Google Scholar). C'est directement lié à la notion d'entity authority qui fonde la visibilité AI.
datePublished / dateModified : signal de fraîcheur algorithmique.
speakable : propriété Schema.org encore sous-utilisée, qui indique explicitement les sections les plus pertinentes pour une lecture/citation vocale ou synthétisée.
about / mentions : liens vers des entités Wikidata/Wikipedia, qui ancrent le contenu dans le knowledge graph.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Migrer de React SPA vers Next.js SSR pour le SEO AI",
  "datePublished": "2026-03-20",
  "dateModified": "2026-03-25",
  "author": {
    "@type": "Person",
    "name": "Marie Dupont",
    "url": "https://mariesdupont.dev",
    "sameAs": [
      "https://www.linkedin.com/in/mariedupont",
      "https://twitter.com/mariedupont_dev"
    ],
    "jobTitle": "Lead SEO Technique",
    "worksFor": {
      "@type": "Organization",
      "name": "TechCommerce SAS"
    }
  },
  "about": [
    {
      "@type": "Thing",
      "name": "Server-side rendering",
      "sameAs": "https://www.wikidata.org/wiki/Q28865452"
    },
    {
      "@type": "Thing",
      "name": "Next.js",
      "sameAs": "https://www.wikidata.org/wiki/Q56062622"
    }
  ],
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": ["h2", ".key-takeaway"]
  }
}
</script>

Le speakable est un signal direct aux systèmes de synthèse. Documenté par Google dans la spécification Speakable, il reste peu adopté. C'est une opportunité pour les early adopters.

FAQ et HowTo : structurer pour la citation directe

Les types FAQPage et HowTo produisent des paires question/réponse et des séquences d'étapes qui sont idéales pour le chunking LLM. Chaque paire Q/A = un chunk autonome et citable.

Attention au trade-off : Google a réduit l'affichage des rich results FAQ dans les SERPs classiques depuis 2023, mais les LLMs continuent d'exploiter le schema sous-jacent pour identifier les réponses directes. Le fait que le rich result ne s'affiche plus ne signifie pas que le structured data est inutile — son rôle a migré vers l'extraction AI.

Scénario concret : un e-commerce média de 12 000 pages face à l'AI search

Prenons le cas d'un site e-commerce spécialisé en matériel photo, 12 000 pages (3 000 fiches produit, 800 pages catégorie, 400 articles de blog, le reste en pages techniques/support). Trafic organique : 180 000 sessions/mois. Après l'activation élargie des AI Overviews en France, le CTR organique sur les requêtes informationnelles chute de manière significative — l'équipe mesure une baisse de 35% du trafic sur le blog en 8 semaines.

Audit de la machine-readability existante

L'équipe lance un crawl Screaming Frog sur les 400 articles du blog avec extraction custom :

Configuration Screaming Frog > Custom Extraction :
- XPath 1 : //article//h2 (comptage)
- XPath 2 : //article//table (comptage)  
- XPath 3 : //script[@type='application/ld+json'] (présence)
- XPath 4 : //article//pre/code (comptage)

Résultats :

62% des articles ont moins de 2 <h2> (structuration insuffisante pour un chunking propre)
91% n'ont aucun <table> HTML (les comparatifs sont en prose ou en images)
45% n'ont pas de JSON-LD Article (seulement un WebPage générique)
78% n'ont aucun bloc <code> (même les articles techniques sur les réglages photo)

L'analyse des logs serveur révèle que PerplexityBot et ChatGPT-User crawlent activement le site (2 300 requêtes/jour combinées), mais concentrent 80% de leurs requêtes sur seulement 15 articles — ceux qui ont déjà une structure H2/H3 dense et du JSON-LD complet.

Plan de restructuration

L'équipe priorise les 50 articles à plus fort potentiel (volume de recherche × qualité du contenu existant) et applique le playbook :

Restructuration sémantique : refonte des headings pour que chaque H2 soit une question ou un topic statement explicite. Ajout de H3 pour chaque sous-point.
Tableaux natifs : conversion de tous les comparatifs textuels en <table> HTML avec <caption>.
JSON-LD enrichi : ajout de TechArticle avec author.sameAs, about avec liens Wikidata, speakable sur les H2 et les paragraphes d'introduction.
Résumés extractibles : ajout d'un <div class="key-takeaway"> après chaque H2, contenant la réponse condensée en 1-2 phrases. Ce div est ciblé par le speakable.

Résultats après 6 semaines : les 50 articles restructurés voient leur présence dans les réponses Perplexity passer de 3 citations trackées à 19 (suivi manuel sur un panel de 200 requêtes), mesuré via un suivi de prompts dédié. Le trafic organique sur ces 50 pages se stabilise malgré la croissance continue des AI Overviews, tandis que les 350 articles non traités continuent de perdre du trafic.

Contrôler l'accès : robots.txt, AI bots et le dilemme du blocage

La tentation est forte de bloquer les bots AI dans robots.txt. C'est un choix légitime — mais ses conséquences sur la visibilité AI search sont radicales et souvent sous-estimées.

Configuration granulaire des accès

# robots.txt — stratégie sélective
# Autoriser les bots AI sur le blog (contenu informatif = visibilité)
# Bloquer sur les pages produit (protéger les données commerciales)

User-agent: GPTBot
Allow: /blog/
Disallow: /products/
Disallow: /account/

User-agent: ChatGPT-User
Allow: /blog/
Disallow: /products/

User-agent: PerplexityBot
Allow: /blog/
Disallow: /products/
Disallow: /api/

User-agent: ClaudeBot
Allow: /blog/
Disallow: /products/

User-agent: Google-Extended
Disallow: /products/pricing/
Allow: /

Ce découpage est un compromis pragmatique : le contenu éditorial (blog, guides) gagne en visibilité dans les réponses AI, tandis que les données produit/pricing restent protégées du scraping.

Le piège : Google-Extended contrôle l'utilisation de votre contenu par les produits Gemini, mais n'affecte pas les AI Overviews dans la Search. Bloquer Google-Extended ne vous exclut pas des AI Overviews — c'est une distinction documentée par Google dans leur documentation sur Google-Extended.

Headers HTTP pour le contrôle fin

Au-delà de robots.txt, les headers HTTP permettent un contrôle plus granulaire, notamment pour les sites où la logique varie par type de contenu servi dynamiquement :

# Configuration Nginx — header conditionnel
location /blog/ {
    # Autoriser l'indexation AI mais signaler la fraîcheur
    add_header X-Robots-Tag "max-snippet:-1, max-image-preview:large";
}

location /products/ {
    # Restreindre l'extraction AI
    add_header X-Robots-Tag "noai, noimageai" always;
}

Les directives noai et noimageai ne sont pas encore universellement supportées par tous les bots AI, mais elles font partie des propositions en cours de standardisation. Les implémenter dès maintenant prépare le terrain.

Écriture machine-readable : les patterns textuels qui favorisent l'extraction

La structure HTML est nécessaire mais pas suffisante. La manière dont le texte lui-même est rédigé a un impact direct sur la qualité du chunking et la probabilité de citation.

Le pattern « définition en premier paragraphe »

Les LLMs, lorsqu'ils synthétisent une réponse, cherchent des passages qui répondent directement à la requête. Un paragraphe qui commence par une définition ou une réponse factuelle est systématiquement mieux classé qu'un paragraphe qui « amène » progressivement le sujet.

Mauvais pattern (style éditorial classique) :

Depuis plusieurs années, les professionnels du e-commerce s'interrogent sur la meilleure façon de gérer les pages en rupture de stock. Cette question est d'autant plus pertinente que...

Bon pattern (machine-readable) :

Une page produit en rupture de stock doit rester indexée si le produit est susceptible de revenir, avec un schema Product dont la propriété availability est définie sur OutOfStock. Rediriger ou supprimer la page détruit les signaux SEO accumulés.

Le second pattern est un chunk autonome et citable. Il contient la réponse, la recommandation technique, et le contexte — en 2 phrases.

Entités explicites et désambiguïsation

Les LLMs résolvent les entités à partir du texte. Plus vous êtes explicite, plus la résolution est fiable :

Utilisez le nom complet la première fois : « Next.js (framework React de Vercel) » au lieu de « Next.js ».
Liez les acronymes à leurs expansions : « SSR (Server-Side Rendering) ».
Mentionnez les relations entre entités : « Googlebot, le crawler principal de Google Search » — ceci ancre l'entité dans le knowledge graph du LLM.

Ce travail d'explicitation n'est pas de la pédagogie pour le lecteur humain (votre audience sait ce qu'est le SSR). C'est de la construction d'autorité d'entité pour les systèmes d'extraction.

Citations et sourcing : le signal de fiabilité

Les LLMs sont entraînés à identifier les contenus qui citent leurs sources comme plus fiables. Un article qui mentionne des sources vérifiables (liens vers la documentation officielle, référence à des études avec auteur et date) sera favorisé par rapport à un article qui affirme sans sourcer.

C'est un cercle vertueux : les moteurs AI citent les contenus qui citent eux-mêmes des sources fiables. La pratique, bien documentée dans le consensus layer du SEO AI, consiste à devenir une source secondaire fiable que les LLMs utilisent comme relais vers les sources primaires.

Monitoring : détecter les régressions de machine-readability

Restructurer 50 articles est un investissement. Il suffit d'un déploiement malheureux pour que le JSON-LD soit supprimé, les <table> convertis en <div>, ou les headings remplacés par des <span> stylés. Ce type de régression silencieuse post-déploiement est la première cause de perte de visibilité AI après une phase d'optimisation réussie.

Vérifications automatisées

Un script de CI/CD peut valider les invariants de machine-readability avant chaque mise en production :

// check-machine-readability.ts
// Script de validation CI/CD — exécuter avant chaque deploy

import { JSDOM } from 'jsdom';
import * as fs from 'fs';

interface ReadabilityReport {
  url: string;
  h2Count: number;
  tableCount: number;
  hasJsonLd: boolean;
  hasAuthorSameAs: boolean;
  hasSpeakable: boolean;
  errors: string[];
}

function checkPage(html: string, url: string): ReadabilityReport {
  const dom = new JSDOM(html);
  const doc = dom.window.document;
  const article = doc.querySelector('article') || doc.body;
  const errors: string[] = [];

  const h2Count = article.querySelectorAll('h2').length;
  if (h2Count < 3) {
    errors.push(`Seulement ${h2Count} H2 — minimum recommandé : 3`);
  }

  const tableCount = article.querySelectorAll('table').length;

  const jsonLdScripts = doc.querySelectorAll(
    'script[type="application/ld+json"]'
  );
  let hasJsonLd = false;
  let hasAuthorSameAs = false;
  let hasSpeakable = false;

  jsonLdScripts.forEach((script) => {
    try {
      const data = JSON.parse(script.textContent || '');
      if (data['@type']?.includes('Article') || 
          data['@type'] === 'TechArticle') {
        hasJsonLd = true;
        if (data.author?.sameAs?.length > 0) {
          hasAuthorSameAs = true;
        }
        if (data.speakable) {
          hasSpeakable = true;
        }
      }
    } catch (e) {
      errors.push('JSON-LD invalide (parse error)');
    }
  });

  if (!hasJsonLd) errors.push('Pas de JSON-LD Article/TechArticle');
  if (!hasAuthorSameAs) errors.push('Pas de author.sameAs dans le JSON-LD');

  return {
    url,
    h2Count,
    tableCount,
    hasJsonLd,
    hasAuthorSameAs,
    hasSpeakable,
    errors,
  };
}

// Usage dans un pipeline CI
const report = checkPage(
  fs.readFileSync('./dist/blog/migration-ssr.html', 'utf-8'),
  '/blog/migration-ssr'
);

if (report.errors.length > 0) {
  console.error(`❌ Machine-readability check failed for ${report.url}:`);
  report.errors.forEach((e) => console.error(`   - ${e}`));
  process.exit(1);
}

console.log(`✅ ${report.url} — ${report.h2Count} H2, ` +
  `${report.tableCount} tables, JSON-LD OK`);

Ce script, intégré à votre pipeline GitHub Actions ou GitLab CI, empêche le déploiement de pages qui régressent en dessous du seuil de machine-readability défini. C'est un filet de sécurité indispensable quand plusieurs développeurs touchent aux templates.

Pour un monitoring continu en production (et pas seulement pré-deploy), un outil comme Seogard détecte automatiquement la disparition d'un JSON-LD, le changement de structure de headings, ou la suppression d'éléments sémantiques — sans attendre le prochain crawl manuel.

Suivi de la visibilité AI

Le monitoring ne s'arrête pas à la structure technique. Il faut aussi tracker si vos pages sont effectivement citées dans les réponses AI. Le suivi de visibilité par prompts reste la méthode la plus fiable : constituer un panel de 100-200 requêtes représentatives, interroger périodiquement les moteurs AI, et tracker les citations de votre domaine.

Croisez ces données avec votre analyse de logs : si PerplexityBot crawle intensivement un article mais que cet article n'apparaît jamais dans les réponses Perplexity, c'est un signal que le contenu est crawlé mais mal extrait — typiquement un problème de structure, pas de qualité.

Le trade-off lisibilité humaine vs machine-readability

Un dernier point, rarement abordé : ces optimisations machine-readable peuvent-elles dégrader l'expérience de lecture humaine ?

La réponse courte : non, si c'est bien fait. Les patterns décrits ici (headings descriptifs, paragraphes d'introduction directs, tableaux natifs, définitions explicites) améliorent aussi la lisibilité humaine. Le style « inverted pyramid » est un standard journalistique éprouvé.

Le seul vrai trade-off concerne le style narratif. Un long format de type « story » — avec une montée en tension, des anecdotes, une structure non-linéaire — sera mal chunké par les LLMs. Si votre objectif est la visibilité AI, réservez le style narratif aux contenus de marque (brand storytelling) et privilégiez le style structuré/référence pour le contenu informationnel.

Ce n'est pas un appauvrissement. C'est une spécialisation : chaque format de contenu a son architecture optimale. Les sites qui performent en AI search sont ceux qui comprennent que l'optimisation pour les machines et l'optimisation pour les humains ne sont pas en opposition — elles convergent vers la même exigence : la clarté.

Le contenu machine-readable n'est pas un format mystérieux. C'est du HTML sémantique rigoureux, du JSON-LD complet, et un style rédactionnel qui met la réponse avant le contexte. Les sites qui adoptent ce playbook maintenant construisent l'avantage structurel qui comptera quand les bots dépasseront le trafic humain. Le plus grand risque n'est pas de sur-optimiser — c'est de déployer ces changements sans monitoring continu et de perdre silencieusement la structure qui vous rend citable.