AEO Edge : appliquer vos optimisations AEO sur n'importe quel site avec un Cloudflare Worker

L'application server-side des optimisations AEO n'est plus réservée à WordPress. AEO Edge (bêta) injecte llms.txt, robots.txt IA, JSON-LD et meta via un Cloudflare Worker, avec fail-open, mode bot-boost et preuve avant/après. Installation en 5 minutes environ.

Jusqu'à présent, appliquer des optimisations AEO directement côté serveur supposait soit de modifier le code du site, soit d'utiliser un CMS supporté comme WordPress. Cette limite tombe. AEO Tool lance AEO Edge (bêta, 4 juillet 2026), un Cloudflare Worker qui applique vos optimisations à l'edge, devant n'importe quelle stack : llms.txt, robots.txt adapté aux bots IA, JSON-LD et balises meta, sans toucher au code d'origine. Installation en 5 minutes environ, avec une clé de site et un déploiement wrangler.

Pourquoi l'injection server-side est décisive pour l'AEO

Le point technique fondamental, encore largement sous-estimé : les crawlers des moteurs IA n'exécutent pas le JavaScript. GPTBot, le robot d'OpenAI documenté sur platform.openai.com, récupère le HTML brut renvoyé par votre serveur et s'arrête là. ClaudeBot, PerplexityBot et la grande majorité des robots IA fonctionnent de la même manière. Pas de rendu, pas d'hydratation React, pas d'exécution de scripts tiers.

La conséquence est directe : toute optimisation injectée côté client est invisible pour ces robots. Un JSON-LD ajouté par Google Tag Manager, une meta description posée par un framework après hydratation, une FAQ générée dynamiquement en JavaScript : rien de tout cela n'existe aux yeux d'un bot IA. Vous pouvez le vérifier vous-même en observant quels robots visitent réellement vos pages avec l'outil de tracking des bots IA, puis en comparant le HTML brut servi par votre serveur avec ce qu'affiche un navigateur.

Le SEO classique a mis des années à digérer cette contrainte, et Google a fini par exécuter le JavaScript. Les moteurs IA, eux, crawlent à une échelle qui rend le rendu JS économiquement improbable à court terme. Pour l'AEO, la règle de travail est simple : ce qui n'est pas dans le HTML servi par le serveur n'existe pas.

Le problème d'accès : chaque stack est un cas particulier

Si l'injection server-side est la bonne approche, encore faut-il pouvoir la mettre en oeuvre. Sur WordPress, le plugin AEO Tool Connect règle la question : il applique les optimisations validées directement dans le HTML servi, sans modification du thème. Mais WordPress ne représente qu'une partie du web.

Un site Shopify, un site Webflow, une application headless, un site vitrine développé sur mesure il y a huit ans, un intranet Jamstack : chaque stack demande une intégration spécifique, un développeur disponible et un cycle de déploiement. Pour une agence qui gère un portefeuille de sites hétérogènes, multiplier les intégrations sur mesure n'est pas tenable.

Il existe pourtant un dénominateur commun à tous ces sites : le réseau. Une part considérable du web passe déjà par Cloudflare comme proxy DNS. Et Cloudflare permet d'exécuter du code à l'edge, entre le visiteur et le serveur d'origine, via les Workers. C'est exactement le point d'insertion qu'exploite AEO Edge : au lieu de s'intégrer dans la stack, il se place devant elle.

Ce qu'AEO Edge injecte concrètement

AEO Edge est un Worker Cloudflare qui intercepte les requêtes entrantes et enrichit les réponses de votre serveur d'origine avec les optimisations validées dans votre compte AEO Tool. Le contrat fonctionnel est le même que celui du plugin WordPress AEO Tool Connect : les optimisations de niveau 1, réversibles, appliquées automatiquement. Quatre couches sont couvertes.

Un llms.txt servi à la racine

Le fichier llms.txt, dont la spécification est publiée sur llmstxt.org, donne aux modèles de langage un sommaire structuré de votre site : qui vous êtes, quelles sont vos pages importantes, comment vous contacter. AEO Edge le sert directement à l'URL /llms.txt, même si votre serveur d'origine n'en a jamais entendu parler. Le contenu est dérivé de votre audit et reste éditable depuis le dashboard. Pour comprendre ce que contient un bon fichier, le générateur de llms.txt permet d'en produire un et d'en vérifier la structure.

Un robots.txt qui connaît les bots IA

La plupart des robots.txt en production ignorent l'existence de GPTBot, ClaudeBot, PerplexityBot ou Google-Extended. AEO Edge réécrit le robots.txt servi pour y ajouter des règles explicites destinées aux crawlers IA que vous souhaitez accueillir, tout en préservant vos directives existantes. L'outil robots.txt pour bots IA détaille les directives recommandées moteur par moteur.

Un JSON-LD au format @graph injecté dans le head

Le Worker injecte un bloc de données structurées consolidé au format @graph : Organization, WebSite, WebPage, et les types spécifiques pertinents par page comme FAQPage ou BreadcrumbList. Le @graph relie les entités entre elles par des identifiants, ce qui aide les moteurs à comprendre qui publie quoi, sur quel site, avec quelle autorité. C'est l'un des signaux les plus directs pour améliorer la lecture de votre site par les LLMs. Une garde anti-doublon évite d'injecter un schema déjà présent dans la page d'origine.

Des balises meta et Open Graph réécrites via HTMLRewriter

Pour modifier le HTML à la volée sans le charger entièrement en mémoire, AEO Edge s'appuie sur HTMLRewriter, l'API de réécriture en streaming de Cloudflare Workers. Elle permet de cibler des sélecteurs précis (title, meta description, balises Open Graph) et de les réécrire pendant que la réponse transite par l'edge, avec un surcoût de latence négligeable. Les titres et descriptions optimisés dans votre audit sont ainsi appliqués sans jamais toucher au serveur d'origine.

Fail-open : la garantie de ne jamais dégrader le site

Placer du code entre vos visiteurs et votre serveur impose une exigence absolue de robustesse. AEO Edge applique un principe de fail-open systématique : si quoi que ce soit se passe mal, le Worker laisse passer la réponse d'origine telle quelle.

• Si l'API AEO Tool est injoignable ou trop lente, la page d'origine est servie sans modification.
• Si la configuration est invalide ou la clé de site révoquée, la page d'origine est servie sans modification.
• Si une exception survient pendant la réécriture, la page d'origine est servie sans modification.

Dans le pire des cas, votre site se comporte exactement comme avant l'installation. Le seul risque réel est de perdre temporairement les optimisations, jamais de casser une page. C'est la condition pour déployer ce type d'outil sur un site de production sans supervision permanente, et c'est le même contrat de sécurité que celui du plugin WordPress.

Le mode bot-boost : le JSON-LD servi aux crawlers IA sur toutes les pages

AEO Edge propose un mode optionnel appelé bot-boost. Son principe : lorsque la requête provient d'un crawler IA identifié par son user-agent, le Worker sert le JSON-LD sur toutes les pages du site, y compris celles pour lesquelles la version destinée aux visiteurs humains n'a pas été réécrite.

L'intérêt est d'assurer une couverture complète de la couche sémantique côté moteurs IA sans multiplier les réécritures sur le trafic humain. Le contenu visible reste strictement identique pour tous les visiteurs : seules des métadonnées descriptives et factuelles, qui décrivent la page telle qu'elle est, sont ajoutées pour les robots. Il ne s'agit pas de servir un contenu différent, mais de garantir que les données structurées sont présentes partout où un moteur IA les cherche.

La boucle de preuve : re-scan à J+3 et email avant/après

Appliquer des optimisations sans en mesurer l'effet revient à travailler à l'aveugle. AEO Edge reprend la boucle de preuve du plugin WordPress : trois jours après l'activation, un re-scan automatique de votre site est déclenché, et vous recevez un email avant/après qui compare les deux audits, critère par critère.

Vous voyez précisément quels points ont été corrigés par l'injection edge (llms.txt présent, robots.txt conforme, JSON-LD détecté, meta conformes) et ce qui relève encore d'un travail de fond sur le contenu. Pour aller plus loin, un test de citation IA vérifie si les moteurs commencent à vous citer sur vos requêtes cibles, et le monitoring de citations IA suit l'évolution dans le temps.

Installation : environ 5 minutes

Le déploiement suit le parcours standard des Workers Cloudflare :

1. Créez ou connectez votre compte AEO Tool et lancez un audit de votre site si ce n'est pas déjà fait.
2. Récupérez votre clé de site dans le dashboard : elle identifie le site et ses optimisations validées.
3. Clonez le template AEO Edge et renseignez la clé de site dans la configuration du Worker.
4. Déployez avec la commande wrangler deploy depuis votre terminal.
5. Ajoutez la route Cloudflare pour que le Worker s'exécute devant votre domaine, puis vérifiez le résultat en rechargeant /llms.txt et /robots.txt.

Comptez environ 5 minutes pour un domaine déjà proxifié par Cloudflare. Le Worker tourne ensuite sans maintenance : les optimisations sont tirées de votre compte AEO Tool, et toute mise à jour validée dans le dashboard est répercutée à l'edge au prochain rafraîchissement.

Pour qui est-ce pertinent

AEO Edge s'adresse d'abord aux sites qui ne sont pas sur WordPress : e-commerce SaaS, applications headless, stacks legacy sans développeur disponible. Il intéresse aussi les agences qui veulent standardiser l'application AEO sur un portefeuille de clients hétérogène, sans dépendre de la stack de chacun. La bêta est ouverte depuis le 4 juillet 2026 : le contrat fonctionnel est identique à celui du plugin WordPress AEO Tool Connect, seul le point d'injection change.

Questions fréquentes

AEO Edge fonctionne-t-il si mon site n'est pas derrière Cloudflare ?

Non, pas en l'état : le Worker s'exécute sur le réseau Cloudflare et doit donc se trouver sur le chemin des requêtes. Si votre domaine n'est pas encore proxifié par Cloudflare, la migration DNS est la première étape (le plan gratuit suffit pour ce cas d'usage). Pour un site WordPress, le plugin AEO Tool Connect reste l'option la plus directe, sans changement d'infrastructure.

Le Worker ralentit-il le site ?

Non, de manière mesurable. La réécriture s'appuie sur HTMLRewriter, qui traite la réponse en streaming pendant qu'elle transite par l'edge, sans mise en mémoire tampon complète. Les appels vers l'API AEO Tool sont assortis de délais courts et le principe de fail-open garantit qu'une lenteur côté API n'est jamais répercutée sur le visiteur : la page d'origine part sans attendre.

Que se passe-t-il si l'API AEO Tool est indisponible ?

Le Worker applique le fail-open : il sert la réponse de votre serveur d'origine sans aucune modification. Le site reste intégralement fonctionnel, seules les optimisations AEO sont temporairement absentes. Dès que l'API redevient joignable, l'injection reprend automatiquement, sans intervention.

Quelle est la différence avec le plugin WordPress AEO Tool Connect ?

Le contrat est identique : mêmes optimisations de niveau 1, même réversibilité, même boucle de preuve avec re-scan à J+3. Ce qui change est le point d'injection. Le plugin s'exécute en PHP à l'intérieur de WordPress ; AEO Edge s'exécute au niveau du réseau, devant n'importe quelle stack. Si votre site est sur WordPress, le plugin reste le chemin le plus simple ; pour tout le reste, le Worker prend le relais.

Le mode bot-boost est-il assimilable à du cloaking ?

Non. Le cloaking consiste à servir un contenu substantiellement différent aux robots pour tromper leur évaluation. Le mode bot-boost ajoute uniquement des données structurées factuelles qui décrivent la page telle que les visiteurs la voient : le texte, les prix, les informations restent identiques. Les métadonnées descriptives conformes au contenu réel relèvent de l'aide à la compréhension, pas de la dissimulation.

Comment vérifier que les optimisations sont bien appliquées ?

Trois vérifications rapides : recharger /llms.txt et /robots.txt pour constater l'injection, inspecter le HTML brut d'une page (et non le DOM du navigateur) pour y trouver le JSON-LD, et attendre le re-scan automatique à J+3 qui envoie un comparatif avant/après par email. Un test de citation IA sur vos requêtes cibles complète la mesure côté moteurs.