Guide expérimental d'AEO technique

Environ 68 % des recherches Google se sont terminées sans clic au début de 2026. Le trafic de référence provenant de l'IA vers les sites majeurs a augmenté de 357 % en un an en 2025. Quand quelqu'un demande à ChatGPT ou Perplexity « quelle est la meilleure plateforme d'hébergement canadien », la réponse peut venir de ce que le modèle connaît déjà ou de ce qu'il peut récupérer en temps réel.

Cela change le rôle d'un site marketing. Il doit encore bien se classer, charger rapidement et convertir les humains. Mais il doit aussi être facile à lire, à résumer et à citer correctement par les systèmes IA.

C'est la version pratique de l'optimisation pour moteurs de réponses (AEO). Pas de magie. Pas de canal de trafic garanti. Juste du contenu plus facile à comprendre pour les moteurs de réponses.

Il s'agit uniquement du côté technique de la livraison : format du contenu, routage et métadonnées. La stratégie de contenu, la recherche de mots-clés et ce que vous écrivez sont des problèmes distincts.

Avertissement : les standards présentés ici sont encore expérimentaux. llms.txt et les brouillons IETF sur les préférences IA sont encore des propositions, et je ne peux pas encore mesurer une hausse directe des citations IA. J'ai quand même essayé parce que la direction semble réelle, et parce que ces changements ont aussi rendu le site plus facile à maintenir.

Ce que j'ai changé

J'ai reconstruit le pipeline de contenu autour de quatre idées :

1. Garder le contenu source en markdown.
2. Publier un index llms.txt.
3. Servir le markdown quand un client le demande explicitement.
4. Ajouter assez de métadonnées pour que les systèmes IA identifient l'entreprise et citent les pages correctement.

Vous n'avez pas besoin de copier chaque détail d'implémentation. Le modèle utile est plus simple : rendez le contenu faisant autorité disponible en texte propre, puis indiquez aux agents où le trouver.

Garder le contenu source en markdown

Un navigateur peut gérer une page React profondément imbriquée. Un moteur de réponses cherche souvent le texte, les titres, les liens et les faits de la façon la plus directe possible.

Déplacer le contenu des pages en markdown donne cette source propre. Votre site rendu peut toujours utiliser des composants React, des sections personnalisées, des grilles de fonctionnalités et des appels à l'action. Le fichier source devient simplement plus facile à inspecter pour les humains et les outils.

Pour MapleDeploy, Markdoc convenait bien parce qu'il garde le markdown comme source tout en associant des balises personnalisées à des composants React au moment du rendu. MDX peut résoudre le même problème. L'outil précis importe moins que le résultat : le contenu de la page vit dans un format texte lisible avant que le navigateur rende quoi que ce soit.

Cela donne aussi une meilleure source de vérité interne. Les articles de blogue, les pages de comparaison, les docs et les pages d'atterrissage peuvent tous être indexés, transformés et servis depuis le même répertoire de contenu.

Ajouter llms.txt

La convention llms.txt place un fichier texte à /llms.txt pour donner aux systèmes IA une carte organisée de votre site.

Voyez-le comme une table des matières pour les modèles de langage. Un plan du site dit « ces URL existent ». Un fichier llms.txt dit « voici qui nous sommes, voici les pages importantes, et voici où aller pour plus de détails ».

Un bon llms.txt inclut :

• Une courte description du site.
• Les pages produit importantes.
• Les pages de comparaison importantes.
• Les articles de blogue qui valent la peine d'être cités.
• Un lien vers le contenu markdown complet si vous en publiez un.

Nous publions aussi /llms-full.txt, qui combine le corps markdown du contenu publié dans une seule réponse. Cela donne aux agents de recherche un seul endroit où récupérer le contexte complet du site.

Générez ces deux fichiers à partir de votre source de contenu. Filtrez les articles non publiés et mettez le résultat en cache pour le servir sans coût inutile.

Servir le markdown sur demande explicite

Une fois la source en markdown, donnez aux clients une manière prévisible de la demander.

Deux déclencheurs sont utiles :

• Accept: text/markdown
• Une version .md de l'URL, par exemple /canadian-hosting.md

Le mot important est explicite. Je ne servirais pas du markdown en fonction du user-agent. Les outils IA, navigateurs, robots et clients d'aperçu changent leurs user-agents avec le temps. Si un client demande du HTML, servez du HTML. S'il demande du markdown, servez du markdown.

Vous pouvez vérifier le comportement avec de simples requêtes :

curl -H "Accept: text/markdown" https://votresite.com/une-page
curl https://votresite.com/une-page.md

Pour les URL .md, ajoutez un en-tête canonique Link qui pointe vers la page HTML. Cela indique aux moteurs de recherche quelle version fait autorité et évite que la copie markdown soit traitée comme une page concurrente.

Ajouter des métadonnées utiles

Le markdown est propre, mais une seule page markdown peut perdre son contexte. Une page HTML a des balises meta, des propriétés OpenGraph, des liens canoniques et des données structurées. Une réponse markdown devrait porter les mêmes faits de base.

Pour MapleDeploy, la réponse markdown inclut le frontmatter de la page et des métadonnées globales comme :

• Le nom du site
• La locale
• L'URL canonique
• L'auteur
• La région de l'entreprise
• Le résumé des prix
• Le lien vers /llms.txt

Le but n'est pas d'ajouter des mots clés partout. Le but est d'enlever l'ambiguïté. Si un moteur de réponses récupère une page et doit répondre à « que fait cette entreprise ? » ou « combien ça coûte ? », il ne devrait pas avoir à deviner.

Gardez ces métadonnées dans la réponse servie, pas nécessairement dans chaque fichier source brut. Le frontmatter propre à la page doit rester lisible pour les auteurs.

Du côté HTML, continuez d'utiliser les données structurées JSON-LD quand elles sont pertinentes : Organization, Article, FAQPage, BreadcrumbList ou un schéma propre au produit. La recherche traditionnelle et la récupération par IA profitent toutes les deux d'une structure claire.

Définir les permissions clairement

Rendre le contenu plus facile à récupérer est une décision. Dire ce que les systèmes peuvent en faire en est une autre.

Au minimum, gardez robots.txt intentionnel. Si vous acceptez l'indexation, une règle générique d'autorisation suffit. Si vous voulez bloquer certains robots, robots.txt est l'endroit où placer cette politique.

Pour des signaux plus granulaires, les brouillons IETF sur les préférences IA sont encore en évolution. Le brouillon d'attachement expiré utilisait des exemples Content-Usage comme :

Content-Usage: train-ai=n

L'adoption est encore précoce, donc traitez cela comme un signal, pas comme un mécanisme d'application. La valeur pratique est que votre intention est claire.

Ce que j'éviterais

J'éviterais tout ce qui dépend de l'identification approximative des robots. C'est fragile et facile à casser.

J'éviterais aussi de trop investir dans les métriques au début. Surveillez les journaux pour /llms.txt, /llms-full.txt, les URL .md et les requêtes Accept: text/markdown. Cela vous indique si des outils utilisent les chemins. Cela ne prouve pas que le travail améliore les citations ou les revenus.

Enfin, ne rendez pas la version markdown moins bonne pour les humains seulement pour satisfaire une théorie sur l'IA. Des titres clairs, des paragraphes courts, des liens exacts et du texte factuel aident les deux publics.

Conclusion

Le pipeline complet est simple : écrire le contenu en markdown, publier un index lisible par l'IA, servir le markdown sur demande et inclure assez de métadonnées pour garder les citations exactes.

Est-ce nécessaire ? Personne ne le sait encore. La frontière entre « site Web » et « document qu'une IA peut lire » devient plus mince, mais les standards gagnants ne sont pas encore établis.

Ce que je sais, c'est qu'un contenu markdown propre, des métadonnées utiles et des routes explicites forment une meilleure base que des faits importants enfouis dans des composants rendus. Si la découverte par IA continue de croître, le site est prêt. Sinon, le système de contenu reste plus clair qu'avant.

MapleDeploy est une plateforme d'hébergement Coolify gérée sur une infrastructure canadienne, avec des forfaits à partir de 45 $ CAD/mois et un essai gratuit de 30 jours. Si vous construisez quelque chose qui nécessite la résidence des données au Canada, jetez un coup d'œil.