Hier matin, j'ai lancé un audit de mekaa.co sur isitagentready.com. Score : 4 sur 12. Ridicule pour une agence qui vend du GEO. En une heure, j'ai tout corrigé. Et au passage, j'ai compris pourquoi 99 % des sites français vont être complètement invisibles pour les agents IA dans les 18 prochains mois.
Le problème, ce n'est pas le contenu. C'est que les sites web ont été construits pour des humains qui cliquent et lisent. Pas pour des agents qui exécutent des actions. Quand Claude, ChatGPT Agent ou Comet visitent une page, ils ne cherchent pas un menu, ils cherchent des outils exposés, des skills déclarés, et des headers HTTP qui leur disent où aller.
Cet article est le retour d'expérience exact de ce que j'ai mis en place sur mekaa.co, avec le code, les commandes terminal et les pièges à éviter. Si tu lis ça en 2026 et que tu n'as encore rien implémenté, tu as encore une fenêtre pour être en avance. En 2027, ça sera juste le minimum syndical.
Ce que veut dire agent ready concrètement
Un site agent ready, ce n'est pas un site avec du bon contenu SEO. C'est un site qui implémente un stack technique précis pour qu'un agent IA puisse :
- Découvrir ce que le site propose sans le crawler page par page
- Lire des instructions structurées sur comment l'utiliser
- Exécuter des actions concrètes via des tools déclarés en JavaScript
Concrètement, ça se traduit par cinq couches techniques empilées :
En résumé : un site agent ready combine cinq standards (Link headers RFC 8288, llms.txt, Agent Skills Discovery, WebMCP, Content-Signal) qui permettent aux agents IA de découvrir, lire et exécuter des actions sur le site sans intervention humaine.
La plupart des sites ont déjà un sitemap.xml et un robots.txt. C'est le strict minimum. Le vrai delta, c'est de monter dans la pile : Link headers, Agent Skills, WebMCP. C'est là que ça devient intéressant et c'est là que personne n'est encore positionné.
Étape 1 : ajouter les link headers RFC 8288
Quand un agent IA fait une requête HTTP sur ta homepage, il regarde d'abord les en-têtes de réponse. Le header Link (défini par la RFC 8288) permet d'annoncer des ressources liées sans même renvoyer de HTML. C'est la couche de discovery la plus rapide pour un crawler.
Voici à quoi ça ressemble une fois implémenté :
link: </llms.txt>; rel="describedby"; type="text/plain", </sitemap.xml>; rel="sitemap"; type="application/xml", </robots.txt>; rel="describedby"; type="text/plain", </.well-known/agent-skills/index.json>; rel="agent-skills-index"; type="application/json"Implémentation via cloudflare transform rules
Si ton site est derrière Cloudflare (ce que je recommande pour 100 % des projets Webflow sérieux), tu n'as pas besoin de toucher à ton hébergement. Tout se passe dans Rules puis Transform Rules puis Modify Response Header.
Voici la procédure exacte :
- Sélectionner ton domaine dans le dashboard Cloudflare
- Aller dans Rules puis Transform Rules puis onglet Modify Response Header
- Cliquer sur Create rule
- Nommer la règle Add Link headers for agent discovery
- En filtre, choisir Custom filter expression et coller :
(http.host eq "www.mekaa.co"
and http.request.uri.path eq "/") or(http.host eq "mekaa.co"
and http.request.uri.path eq "/")- Comme action, sélectionner Set static, puis pour le header Link, coller la valeur :
</llms.txt>; rel="describedby"; type="text/plain", </sitemap.xml>; rel="sitemap"; type="application/xml", </robots.txt>; rel="describedby"; type="text/plain"- Déployer. La règle est active immédiatement.
Vérifier que ça fonctionne
curl -I https://www.mekaa.co/ | grep -i linkTu dois voir le header Link: avec toutes tes ressources. Si ce n'est pas le cas, vérifie l'expression du filtre. L'erreur la plus courante, c'est de cibler une route qui ne correspond pas exactement à la homepage.
En résumé : les Link headers RFC 8288 permettent d'annoncer en HTTP des ressources comme llms.txt ou sitemap.xml. Sur Cloudflare, ça se configure en 2 minutes via les Response Header Transform Rules, sans toucher à l'hébergement.
Étape 2 : publier un index agent skills
L'Agent Skills Discovery RFC v0.2.0 (publiée par Cloudflare en mars 2026) définit un standard pour exposer les compétences qu'un site web propose aux agents IA. Concrètement, c'est un fichier JSON publié à /.well-known/agent-skills/index.json qui liste les skills disponibles, avec un schéma précis.
Voici la structure attendue :
{
"$schema": "https://schemas.agentskills.io/discovery/0.2.0/schema.json",
"skills": [
{
"name": "mekaa-geo-services",
"type": "skill-md",
"description": "Get information about Mekaa's GEO services...",
"url": "/.well-known/agent-skills/mekaa-geo-services/SKILL.md",
"digest": "sha256:6d39397bd30e3022b00995fa93b32d8c0f93ee0dc0b069c98f575391abea10f5"
}
]
}Le challenge avec Webflow, c'est qu'on ne peut pas servir des fichiers sur des chemins /.well-known/.... La solution propre, c'est un Cloudflare Worker.
Le worker cloudflare qui gère l'index
<script>
const SKILL_MD = `---name: mekaa-geo-servicesdescription: Get information about Mekaa's GEO services and how to request a GEO audit. Use when a user asks about AI search visibility, GEO consulting, or wants to work with a French GEO agency.---# Mekaa GEO ServicesMekaa is a French digital agency specialized in Generative Engine Optimization (GEO).[contenu complet du skill...]`;
async function sha256(text) {
const buffer = new TextEncoder().encode(text);
const hash = await crypto.subtle.digest('SHA-256', buffer);
const hashArray = Array.from(new Uint8Array(hash));
return hashArray.map((b) => b.toString(16).padStart(2, '0')).join('');
}
export default {
async fetch(request) {
const url = new URL(request.url);
if (url.pathname === '/.well-known/agent-skills/index.json') {
const skillDigest = await sha256(SKILL_MD);
const index = {
$schema: 'https://schemas.agentskills.io/discovery/0.2.0/schema.json',
skills: [{
name: 'mekaa-geo-services',
type: 'skill-md',
description: "Get information about Mekaa's GEO services...",
url: '/.well-known/agent-skills/mekaa-geo-services/SKILL.md',
digest: `sha256:${skillDigest}`
}]
};
return new Response(JSON.stringify(index, null, 2), {
headers: {
'Content-Type': 'application/json',
'Cache-Control': 'public, max-age=3600',
'Access-Control-Allow-Origin': '*'
}
});
}
if (url.pathname === '/.well-known/agent-skills/mekaa-geo-services/SKILL.md') {
return new Response(SKILL_MD, {
headers: {
'Content-Type': 'text/markdown; charset=utf-8',
'Cache-Control': 'public, max-age=3600'
}
});
}
return fetch(request);
},
};
</script>L'élégance de cette approche, c'est que le SHA-256 du SKILL.md est calculé automatiquement à chaque requête. Pas besoin de le maintenir à la main, pas de risque d'oubli quand tu modifies le contenu.
Le piège des routes cloudflare
Voici une erreur que j'ai faite et qui m'a fait perdre 20 minutes : configurer la route avec un wildcard de sous-domaine. J'avais mis *.mekaa.co/.well-known/agent-skills/* en pensant que ça matcherait tout. C'est faux. Le pattern *.mekaa.co ne matche que les sous-domaines (blog.mekaa.co, app.mekaa.co), pas le domaine racine.
La bonne config, c'est deux routes séparées :
- mekaa.co/.well-known/agent-skills/*
- www.mekaa.co/.well-known/agent-skills/*
Une fois le Worker déployé et les routes correctement configurées, tu peux tester :
curl https://www.mekaa.co/.well-known/agent-skills/index.jsonLe JSON doit s'afficher avec un digest SHA-256 calculé. Si tu vois une page d'erreur HTML de Webflow ("Invalid .well-known request"), c'est que le Worker n'intercepte pas la requête. Vérifie tes routes.
En résumé : un index Agent Skills se publie à /.well-known/agent-skills/index.json avec un schéma JSON précis. Sur Webflow, le seul moyen propre est un Cloudflare Worker qui calcule automatiquement le SHA-256 et sert le JSON et le SKILL.md sur les bonnes routes.
Étape 3 : implémenter webmcp pour exposer des tools exécutables
C'est la couche la plus puissante et la plus excitante. WebMCP est une API JavaScript en cours de standardisation au W3C qui permet à un site web d'exposer des tools exécutables directement dans le navigateur de l'utilisateur. Quand un agent IA visite la page (via Claude in Chrome, Comet, ou Chrome avec les flags expérimentaux), il détecte ces tools et peut les exécuter en discutant avec l'utilisateur.
C'est exactement le même paradigme que le Model Context Protocol côté serveur, mais transposé dans le navigateur. D'où le nom : WebMCP.
Un exemple concret : déclencher un audit geo depuis chatgpt
Voici un des trois tools que j'ai exposés sur mekaa.co :
<script>
navigator.modelContext.registerTool({
name: 'run_geo_audit',
description: 'Run an instant free GEO audit on any website. Returns visibility analysis across AI search engines like ChatGPT, Perplexity, Claude, and Gemini.',
inputSchema: { type: 'object', properties: { website_url: { type: 'string', description: 'The full website URL to audit (must include https://)' } }, required: ['website_url'] },
execute: async function (input) {
let url = input.website_url.trim();
if (!url.startsWith('http://') && !url.startsWith('https://')) {
url = 'https://' + url;
}
const auditUrl = '/services/audit/audit?url=' + encodeURIComponent(url) + '&utm_source=webmcp&utm_medium=agent';
window.location.href = auditUrl;
return { status: 'audit_started', message: 'GEO audit launched for ' + url };
},
});
</script>Concrètement, voici le scénario que ça débloque : un utilisateur ouvre Claude in Chrome, navigue sur mekaa.co, et dit à Claude "audite la visibilité GEO de stripe.com". Claude détecte le tool run_geo_audit, l'exécute avec l'URL fournie, et l'utilisateur arrive sur la page d'audit Mekaa avec les résultats. Sans cliquer une seule fois sur le site.
C'est exactement ce que Cloudflare décrit dans son blog WebMCP : transformer un site web en serveur MCP côté client.
Installation dans webflow
C'est presque trivial. Dans Project Settings puis onglet Custom Code, section Footer Code, tu colles ton script entre balises <script>. Le script doit commencer par une vérification de la disponibilité de l'API :
<script> if (!('modelContext' in navigator)) { return;}</script>Cette ligne est cruciale. Aujourd'hui, l'API n'est disponible que dans des navigateurs spécifiques (Chrome avec flags, Comet, Claude in Chrome). Sur Chrome standard, navigator.modelContext n'existe pas. Sans cette vérification, ton script throw une erreur sur 99 % des visiteurs.
Une fois le code en place et publié, vérifie qu'il est bien chargé :
curl -s https://www.mekaa.co/ | grep -c "registerTool"Doit retourner le nombre de tools enregistrés (3 dans mon cas).
En résumé : WebMCP permet d'exposer des tools JavaScript exécutables par les agents IA directement dans le navigateur. Sur Webflow, ça s'installe en quelques minutes via le Custom Code Footer, à condition de toujours vérifier la disponibilité de l'API avant d'appeler registerTool.
Étape 4 : configurer le content-signal stratégiquement
Le Content-Signal est une proposition de Cloudflare lancée en septembre 2025. Elle permet de donner aux IA trois types d'autorisations granulaires sur ton contenu :
- search : autoriser ou non l'indexation classique (Google, Bing)
- ai-input : autoriser ou non l'usage en temps réel dans les réponses IA (ChatGPT Search, Perplexity, AI Overviews)
- ai-train : autoriser ou non l'utilisation pour entraîner des modèles
Beaucoup d'éditeurs paniquent et configurent ai-train=no, ai-input=no pour protéger leur contenu. C'est une erreur stratégique massive quand tu vends du GEO.
Pourquoi tout mettre en yes quand on fait du geo
Si tu interdis ai-input, tu te retires volontairement des réponses ChatGPT, Claude, Perplexity. Tu te tires une balle dans le pied. Pour une agence GEO, c'est l'équivalent d'un consultant SEO qui mettrait noindex sur sa homepage.
Pour ai-train, le débat est plus nuancé. L'argument pour yes : ton contenu entre dans les poids du modèle, et la marque devient un knowledge baseline. Quand quelqu'un demande "quelles agences GEO en France", ton nom peut sortir spontanément sans même que le modèle fasse une recherche web. C'est le Saint Graal du GEO long-terme.
L'argument pour no : ton contenu est utilisé sans compensation ni attribution. Mais soyons honnêtes, un no dans le Content-Signal est aujourd'hui largement ignoré par les crawlers, donc c'est plus un signal de principe qu'une vraie protection.
Ma reco pour Mekaa et pour la majorité des marques B2B :
Content-Signal: ai-train=yes, search=yes, ai-input=yesEn résumé : pour une stratégie GEO sérieuse, tout mettre en yes dans le Content-Signal est la seule option cohérente. Bloquer ai-input revient à se retirer volontairement des réponses générées par les moteurs IA, ce qui est exactement l'inverse de ce qu'on cherche à faire.
Le stack complet en une heure : bilan concret
Voici le récap de ce que j'ai mis en place sur mekaa.co, avec le temps réel passé sur chaque étape :
Une heure pile. C'est tout. Et pourtant, mekaa.co est aujourd'hui techniquement plus avancé que probablement 99 % des sites web français en matière de conformité agent-discovery. Si tu trouves ça difficile à croire, lance toi-même un audit isitagentready.com sur 10 sites d'agences digitales françaises et regarde les scores.
Ce que cette implémentation va vraiment changer (et ce qu'elle ne va pas changer)
Je vais être direct : à court terme, ces implémentations ne vont rien changer à ton trafic ou tes conversions. Les agents IA qui les exploitent réellement représentent encore une fraction négligeable des visiteurs en avril 2026. Si tu lis cet article en espérant un boost de leads immédiat, tu seras déçu.
Ce qui change, c'est ton positionnement à 18-24 mois. Voici pourquoi.
D'abord, les agents IA grand public arrivent vite. Claude in Chrome est déjà en bêta. Comet (Perplexity) est en accès limité. ChatGPT Agent existe. Google a annoncé un agent intégré à Chrome pour 2026. Quand ces produits sortiront en GA et que des dizaines de millions d'utilisateurs s'en serviront pour naviguer, les sites qui n'auront pas de WebMCP, pas d'Agent Skills, pas de Link headers, seront invisibles dans ce nouveau canal.
Ensuite, et c'est plus subtil, les moteurs de recherche IA actuels (Perplexity, ChatGPT Search, Google AI Overviews) commencent déjà à intégrer la lecture du llms.txt et l'inspection des agent-skills. Ce n'est pas encore documenté publiquement, mais les premiers signaux remontent dans la communauté GEO.
Enfin, il y a un argument que peu de gens voient : ces implémentations sont un signal de qualité technique pour les agents IA. Un site qui prend la peine de publier un Agent Skills index propre signale qu'il prend les agents au sérieux. Les modèles, à terme, vont privilégier ces sites dans leurs réponses. C'est exactement la même logique que le PageRank original : Google a privilégié les sites avec une structure de liens propre, parce que c'était un proxy de qualité éditoriale.
En résumé : implémenter le stack agent-ready aujourd'hui n'a quasi aucun impact business immédiat, mais positionne le site comme prioritaire dans les futures réponses des agents IA. C'est un investissement qui paiera vraiment en 2027, pas avant. Ceux qui attendront pour avoir des preuves de ROI arriveront avec deux ans de retard.
Les erreurs que j'ai faites et que tu peux éviter
Trois pièges concrets que j'ai rencontrés et que personne ne mentionne dans les docs officielles.
Le wildcard de route Cloudflare. Comme dit plus haut, *.mekaa.co/... ne match pas mekaa.co. Toujours créer deux routes séparées : une avec www., une sans.
Le ai-train=no réflexe. Beaucoup de gens (moi y compris au départ) bloquent l'entraînement par principe. Pour une marque qui vend du GEO, c'est suicidaire. Pour une marque qui publie des données propriétaires uniques, ça peut se discuter. Pour 95 % des cas, mettre yes est la bonne réponse.
L'oubli de la vérification d'API dans WebMCP. Si tu ne vérifies pas 'modelContext' in navigator avant d'appeler registerTool, ton script throw une erreur sur Chrome standard. Pas grave en soi, mais ça pollue ta console et peut casser d'autres scripts qui se chargent après.
Conclusion : le vrai coût d'attendre
Le piège classique avec ce genre d'implémentation, c'est de se dire "je le ferai quand ça aura un vrai impact business". Sauf que quand l'impact business sera mesurable, tout le monde l'aura déjà fait. La fenêtre d'opportunité, c'est précisément maintenant, en avril 2026, alors que personne ne l'a encore fait sérieusement en France.
Pour reprendre l'analogie SEO : ceux qui ont implémenté le HTTPS en 2014 (avant l'annonce de Google) ont gagné des positions gratuitement. Ceux qui l'ont fait en 2018 ont juste évité une pénalité. C'est exactement le même cycle qui se joue aujourd'hui avec l'agent-discovery.
Si tu fais du GEO, du SEO ou du contenu sérieux, rendre ton site agent ready n'est pas une option pour 2027. C'est un prérequis. Mieux vaut une heure aujourd'hui qu'un retard impossible à rattraper dans 18 mois. Tu peux suivre la démarche complète décrite dans cet article, ou tu peux nous demander un audit GEO complet sur mekaa.co qui inclut l'analyse de ta conformité agent-discovery.
