La pile technique derrière le SEO, l'AEO et le GEO, Partie 1 : plans de site, JavaScript et CSS

La plupart des discussions sur la visibilité de recherche commencent par le contenu : mots-clés, titres, liens retour — les éléments qu'un marketeur peut pointer du doigt en disant « voici la stratégie ». Mais sous chacune de ces stratégies se trouve une couche beaucoup moins glamour — la plomberie technique qui détermine si un moteur de recherche, un robot d'indexation IA, ou un modèle de langage peut réellement voir, analyser et faire confiance à votre site en premier lieu.

Cette couche est composée d'éléments auxquels la plupart des propriétaires d'entreprise ne pensent jamais : votre plan de site, la structure de votre JavaScript et de votre CSS, ce que votre fichier robots.txt permet et bloque, si vos pages portent un balisage de schéma, si vous avez seulement un fichier llms.txt, et — de plus en plus pertinent, et de plus en plus mal compris — comment votre configuration de cookies et de consentement se comporte quand c'est un robot, et non un humain, qui charge la page. Ceci est la Partie 1 d'une analyse en trois volets de cette couche. Ici, on couvre le plan de site, le JavaScript et le CSS — la fondation qui détermine si une page peut être atteinte et rendue correctement. La Partie 2 couvre robots.txt, le balisage de schéma et llms.txt. La Partie 3 couvre les cookies, et réunit les six éléments dans une seule liste de vérification.

Si cette couche est mal gérée, peu importe la qualité de votre contenu. Un moteur de recherche ne peut pas classer une page qu'il ne peut pas explorer. Un moteur de réponse IA ne peut pas citer un fait qu'il ne peut pas extraire. Un moteur génératif ne peut pas recommander une entreprise dont la fondation technique cache activement l'information. C'est la différence entre le SEO (être classé par la recherche traditionnelle), l'AEO (être cité par des moteurs de réponse comme ChatGPT, Gemini et les aperçus IA de Google), et le GEO (optimisation pour moteurs génératifs — être présenté, résumé et recommandé dans des réponses générées par IA plus largement) — tous reposant sur la même fondation peu glamour.

Trois jeux différents, une seule fondation partagée

Le SEO, l'AEO et le GEO sont souvent décrits comme des disciplines distinctes, et en termes de ce à quoi ressemble le « succès », elles le sont. Le succès en SEO est une position de classement. Le succès en AEO, c'est être la source qu'une IA cite mot pour mot. Le succès en GEO, c'est être tissé dans une réponse générée, une liste de recommandations, ou la suggestion d'un assistant d'achat IA — parfois sans clic ni citation du tout.

Mais les trois dépendent du même prérequis : quelque chose doit pouvoir accéder à votre contenu avant de pouvoir le classer, le citer ou le synthétiser. Cet accès est entièrement régi par la couche technique. Une stratégie de contenu sans fondation technique est une lettre magnifiquement écrite sans adresse sur l'enveloppe.

Le plan de site : comment la découverte commence vraiment

Un plan de site est l'expression la plus littérale de « voici ce qui existe sur mon site ». C'est une liste d'URL, remise directement aux moteurs de recherche, qui dit : explorez celles-ci, voici quand chacune a changé pour la dernière fois, voici approximativement l'importance de chacune par rapport aux autres.

Un plan de site automatisé et auto-actualisé — qui lit la vraie date de dernière modification de chaque page directement sur le système de fichiers plutôt que de dépendre de quelqu'un qui se souvient de mettre à jour un fichier XML à la main — a un effet cumulatif dans le temps :

• Découverte plus rapide du contenu nouveau et mis à jour. Au moment où une page change, sa date lastmod change avec elle. Les moteurs de recherche utilisent ce signal pour prioriser la réexploration, alors les mises à jour se reflètent plus rapidement dans l'index au lieu de rester périmées pendant des semaines.
• Aucune URL orpheline ou manquante. Un plan de site maintenu à la main dérive et se désynchronise du vrai site — des pages sont ajoutées, oubliées ou supprimées, et le plan de site ne le remarque pas. Un plan automatisé est généré à partir de la même source de vérité que le site lui-même, alors ce qui est listé et ce qui existe ne divergent jamais.
• Mise à l'échelle multilingue et multi-gabarit sans duplication manuelle. Sur un site avec plusieurs versions linguistiques de chaque page, un plan de site piloté par une liste de slugs partagée signifie qu'ajouter une nouvelle page produit automatiquement cinq entrées correctes dans le plan de site — une par langue — au lieu de cinq occasions de faire une faute de frappe ou d'en oublier une.
• Efficacité du budget d'exploration. Les moteurs de recherche allouent une attention d'exploration limitée à n'importe quel site donné. Un plan de site propre et précis indique exactement aux robots où se trouve le vrai contenu, alors ce budget est dirigé vers les pages qui méritent d'être indexées au lieu d'être dépensé à redécouvrir la même structure encore et encore.

Pour l'AEO et le GEO en particulier, le plan de site compte encore plus qu'avant, parce que les robots d'indexation IA (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, et autres) explorent maintenant les sites indépendamment de l'indexation de recherche traditionnelle. Un plan de site précis et à jour est l'un des moyens les plus rapides de mettre du nouveau contenu devant ces systèmes sans attendre une réexploration organique.

JavaScript : le tueur silencieux du SEO, de l'AEO et du GEO

Les sites web modernes s'appuient fortement sur le JavaScript pour l'interactivité, mais c'est là qu'une grande part des échecs invisibles en SEO et en AEO se produisent. Le problème central : de nombreux robots d'indexation — et presque tous les robots IA — n'exécutent pas du tout le JavaScript, ou l'exécutent avec une patience et un budget limités. Si votre contenu clé, vos titres, ou vos réponses n'apparaissent qu'après l'exécution d'un script, une grande part des systèmes qui essaient de lire votre page pourraient bien ne jamais voir ce contenu en premier lieu.

Cela compte différemment selon les trois disciplines :

• Impact SEO : Google peut rendre le JavaScript, mais il le fait en second passage, avec un délai, et avec un budget de rendu limité. Les pages lourdes et dépendantes du rendu sont indexées plus lentement et moins fiablement que les pages dont le contenu est présent dans le HTML initial.
• Impact AEO : les moteurs de réponse doivent extraire un fait précis et citable. Si ce fait est injecté côté client après le chargement de la page, de nombreux robots IA ne le rencontreront tout simplement jamais — ce qui signifie qu'un contenu parfaitement visible pour un visiteur humain est fonctionnellement invisible pour le système qui essaie de le citer.
• Impact GEO : les moteurs génératifs qui construisent une compréhension plus large de « ce que cette entreprise offre » ou « de quoi parle cette page » travaillent souvent à partir d'une récupération légère, sans JavaScript, de la page. Si votre proposition de valeur vit à l'intérieur d'un composant rendu par JS, elle pourrait être entièrement absente de la version de votre page que ces systèmes traitent réellement.

La solution pratique n'est pas « évitez le JavaScript » — c'est de s'assurer que le contenu qui compte pour la recherche, les réponses et le résumé par IA existe dans le HTML rendu côté serveur, avec le JavaScript en couche par-dessus pour l'interactivité plutôt que comme mécanisme de livraison du fond de la page.

CSS : plus que l'apparence — Core Web Vitals et efficacité d'exploration

Le CSS est rarement blâmé pour les problèmes de visibilité de recherche, mais il joue deux rôles distincts qui touchent les trois disciplines. Premièrement, le CSS bloquant le rendu ralentit la rapidité à laquelle une page devient utilisable, ce qui affecte directement les Core Web Vitals — un facteur de classement pour le SEO et un signal de confiance qui alimente la façon dont les systèmes IA pèsent favorablement une source quand plusieurs candidats sont autrement similaires.

Deuxièmement, et moins évident : un CSS et une livraison d'actifs mal optimisés et boursouflés ralentissent chaque exploration, humaine ou automatisée. Un robot qui parcourt un grand site avec un budget de temps limité par page traversera moins de pages, moins souvent, si chaque page est plus lourde que nécessaire. Multipliez cela sur un site multilingue avec des centaines d'URL, et un CSS non optimisé plafonne silencieusement la quantité de votre site jamais vue du tout.

Priorités pratiques : minimiser les feuilles de style bloquant le rendu, charger le CSS critique en ligne pour le contenu au-dessus de la ligne de flottaison, différer le reste, et mettre en cache agressivement pour que les explorations répétées (qui se produisent constamment) ne récupèrent pas inutilement les mêmes octets.

À venir dans la Partie 2

Le plan de site, le JavaScript et le CSS amènent un système jusqu'à votre contenu et lui permettent de le rendre correctement. Ils ne lui disent pas ce que ça signifie, ni s'il est même autorisé à l'utiliser. La Partie 2 couvre robots.txt — et pourquoi ce fichier doit maintenant penser spécifiquement aux robots IA — le balisage de schéma, et llms.txt, le fichier le plus récent de cette pile, conçu pour la façon dont les modèles de langage s'orientent autour d'un site.