GEO et SEO technique : pourquoi ce n'est pas un remplacement
Le GEO (Generative Engine Optimization) ne remplace pas le SEO technique : il ajoute une cible. Le SEO technique vise à être indexé et classé par Google, le GEO vise à être cité dans une réponse générée par ChatGPT, Perplexity ou Gemini. Les deux s'appuient sur la même plomberie : un contenu accessible, structuré, rapide et non dupliqué.
La différence tient aux contraintes d'accès. Les crawlers IA exécutent peu ou pas JavaScript, disposent d'un budget de crawl limité et réinterrogent rarement un site instable. Là où Googlebot sait attendre le rendu d'une application cliente, GPTBot récupère le HTML brut et repart avec ce qu'il a trouvé. Un site parfaitement optimisé pour Google peut donc être totalement invisible pour les moteurs de réponse, sans qu'aucune alerte ne se déclenche dans Search Console.
Cette asymétrie est une bonne nouvelle pour les équipes SEO existantes. Les correctifs qui débloquent les crawlers IA sont, presque toujours, des correctifs qui améliorent aussi l'indexation Google, la vitesse de crawl et la qualité des signaux envoyés. Il n'y a pas d'arbitrage à faire entre les deux canaux, seulement un ordre de priorité à définir.
Cet article détaille sept correctifs à double effet. Pour chacun, l'effet mesuré côté Google et l'effet mesuré côté LLM, avec les vérifications concrètes à lancer. Les constats s'appuient sur les audits réalisés par Mirok sur des sites SaaS B2B, dont la synthèse est disponible dans ce que 500 audits Mirok révèlent sur les sites SaaS B2B.
Correctif 1 : les données structurées, socle commun du GEO et du SEO
Le balisage schema.org reste le levier le plus rentable des deux côtés, parce qu'il transforme une page en ensemble de faits lisibles par une machine. Organization, Article, FAQPage, Product, HowTo : chaque type déclare explicitement ce que la page contient, qui l'a publiée et à quoi elle répond.
Côté Google, l'effet est direct et mesurable : éligibilité aux rich results, meilleure compréhension de l'entité, alimentation du Knowledge Graph. Une page Article correctement balisée avec author, datePublished et publisher donne à Google les éléments nécessaires pour rattacher le contenu à une entité identifiable. Côté LLM, l'effet est moins visible mais plus déterminant : le balisage fournit des faits attribuables, extraits sans ambiguïté, ce qui réduit le risque que le modèle reformule votre contenu sans vous citer, ou pire, qu'il hallucine une information voisine.
Les erreurs fréquentes coûtent cher. Un balisage présent mais incohérent avec le contenu visible (une date de publication différente, un auteur qui n'apparaît nulle part sur la page) envoie un signal contradictoire. Un JSON-LD dupliqué entre templates, hérité d'un thème ou d'un plugin, produit plusieurs déclarations Organization concurrentes sur le même site. La vérification tient en une passe : valider chaque type avec le Rich Results Test, puis comparer champ par champ avec ce que voit l'utilisateur. Pour aller plus loin sur la structure des pages, voir structurer ses pages pour les citations LLM : 8 correctifs GEO.
Correctif 2 : le rendu côté serveur, condition d'accès des crawlers IA
La plupart des crawlers IA n'exécutent pas ou très peu JavaScript. Ce n'est pas une limite temporaire, c'est un choix d'architecture : exécuter du JS coûte cher en calcul et en temps, pour un bénéfice incertain. Googlebot, lui, rend les pages depuis des années. Résultat : un contenu injecté côté client, invisible dans le HTML brut, reste invisible pour ChatGPT, Perplexity et Gemini.
Côté Google, le rendu côté serveur (SSR) ou la génération statique améliorent la fiabilité de l'indexation et réduisent la consommation de budget de crawl. Une page qui n'a pas besoin d'être rendue est indexée plus vite et plus souvent. Côté LLM, c'est une condition d'existence : sans texte dans la réponse HTML, il n'y a rien à citer.
Les vérifications sont simples et se font en cinq minutes. Récupérer la page avec curl et lire le HTML brut : si le contenu principal n'y apparaît pas, le problème est confirmé. Comparer ensuite avec la version rendue dans le navigateur pour mesurer l'écart. Tester les pages clés (accueil, pages produit, articles de blog, pages tarifaires) une par une, car les templates ne se comportent pas tous de la même façon. Un site qui affiche ses prix ou ses fonctionnalités uniquement via un composant client perd, pour les moteurs de réponse, l'essentiel de son argumentaire commercial.
Correctif 3 : la vitesse et la stabilité du serveur, du budget de crawl au budget de contexte
Core Web Vitals et temps de réponse serveur pèsent sur les deux canaux, pour des raisons différentes. Côté Google, LCP, INP et CLS sont des signaux d'expérience utilisateur, et un temps de réponse dégradé réduit la fréquence de crawl : Google revient moins souvent sur un site lent. Côté LLM, la logique est plus brutale encore : un site lent ou instable est moins souvent réinterrogé par les agents de réponse, et un timeout fait échouer purement et simplement la récupération de la page. Le contenu n'est pas mal classé, il n'est pas lu.
Les leviers sont connus et ne demandent pas de refonte. Mise en cache des pages et des requêtes coûteuses, CDN pour rapprocher le contenu des crawlers, compression Brotli ou gzip, suppression des redirections en chaîne qui multiplient les allers-retours. Chaque redirection supplémentaire est un coût de crawl payé pour rien, et un risque de timeout supplémentaire côté agent.
La méthode de mesure consiste à suivre le TTFB sur les pages stratégiques, pas seulement sur l'accueil, et à surveiller les erreurs 5xx dans les logs serveur. Un pic d'erreurs pendant une fenêtre de crawl se traduit par une perte d'indexation silencieuse, souvent attribuée à tort à un problème de contenu.
Correctif 4 : le maillage interne, ou comment rendre une page citable
Le maillage interne sert deux fonctions distinctes selon le canal. Pour Google, il distribue le PageRank interne, contrôle la profondeur de clic et évite les pages orphelines. Pour un LLM, il signale qu'une page appartient à un cluster thématique cohérent, ce qui augmente sa probabilité d'être retenue comme source autoritaire sur un sujet donné. Un modèle qui doit choisir entre deux pages traitant du même thème privilégie celle qui est reliée à un ensemble structuré de contenus connexes.
La méthode tient en trois règles. Utiliser des ancres descriptives plutôt que « cliquez ici » ou « en savoir plus », car l'ancre est un signal de sujet pour les deux canaux. Créer des liens contextuels depuis les pages fortes du site vers les pages à faire découvrir, en plaçant le lien dans le corps du texte et non dans un bloc de bas de page. Supprimer les liens morts et les liens vers des redirections, qui gaspillent du budget de crawl et brouillent la lecture du graphe.
Un audit de maillage se fait en croisant un crawl complet avec les données de Search Console. Les pages à zéro lien interne entrant sont prioritaires : elles existent, elles sont parfois indexées, mais elles n'ont aucune chance d'être sélectionnées comme source. Le rapport hebdomadaire de suivi des concurrents permet de comparer la densité de maillage sur les clusters où vos concurrents sont cités et pas vous, comme expliqué dans suivi des concurrents dans les LLM : le rapport hebdo en 5 minutes.
Correctif 5 : sitemap et robots.txt, ouvrir la porte aux crawlers IA
C'est le correctif le plus souvent manqué, parce qu'il ne se voit pas dans un dashboard. La question n'est pas technique mais stratégique : quels user-agents IA autoriser, et pour quel contenu. GPTBot (OpenAI), PerplexityBot, ClaudeBot (Anthropic) et Google-Extended (usage de contenu pour l'entraînement et les produits génératifs Google) se traitent indépendamment dans le robots.txt. Bloquer par défaut, par héritage d'un ancien site ou par réflexe de protection, exclut le site des réponses génératives sans que l'équipe le sache.
Côté Google, l'attention porte sur le sitemap : un fichier propre, sans URL en 404 ni en redirection, avec un lastmod fiable et non généré automatiquement à chaque déploiement. Un lastmod qui change tous les jours sans modification réelle finit par être ignoré. Vérifier aussi l'absence de noindex accidentel, souvent laissé par un environnement de préproduction mal cloisonné.
Côté LLM, la vérification se fait user-agent par user-agent. Tester l'accès de chaque crawler aux pages stratégiques, contrôler les règles héritées (un Disallow: / oublié dans un fichier de staging, une règle copiée d'un ancien domaine), et documenter la décision : autoriser pour la visibilité, bloquer pour la protection du contenu payant. Les deux choix sont défendables, l'absence de choix ne l'est pas.
Correctif 6 : canonical et duplication, une seule vérité par contenu
La duplication dilue les deux canaux, pour des raisons qui se ressemblent. Côté Google, elle disperse les signaux entre plusieurs URL, crée du cannibalisme entre versions et complique la consolidation des backlinks. Côté LLM, elle produit un effet plus insidieux : un contenu présent en plusieurs versions génère des citations contradictoires, ou conduit le modèle à écarter la source jugée peu fiable parce qu'il ne sait pas laquelle fait autorité.
Les cas classiques sont bien identifiés. Paramètres d'URL de tracking qui créent des variantes indexables, pagination mal déclarée, versions www et non-www servies toutes les deux en 200, contenu syndiqué repris sans canonical pointant vers l'original, pages de tags et d'archives qui dupliquent les extraits d'articles. Chacun de ces cas produit le même symptôme : plusieurs URL pour un seul contenu, et aucune réponse claire à la question « quelle page est la référence ».
La correction passe par une règle simple : une intention, une URL, un canonical auto-référent. Vérifier ensuite que le canonical déclaré correspond bien à l'URL servie, et non à une version redirigée. Un canonical qui pointe vers une 301 est un signal perdu pour Google et une ambiguïté de plus pour les moteurs de réponse.
Correctif 7 : l'accessibilité technique, le correctif que personne ne mesure
L'accessibilité technique est le parent pauvre des audits, alors qu'elle conditionne directement l'extractibilité. Hiérarchie de titres propre (un H1, des H2 qui structurent réellement le propos), HTML sémantique (article, section, nav, main plutôt que des div empilées), textes alternatifs descriptifs, contrastes suffisants, formulaires avec labels associés : chaque élément rend le contenu plus lisible par une machine.
Côté Google, l'effet est double : meilleure compréhension structurelle de la page et signaux d'expérience utilisateur positifs. Côté LLM, l'effet est plus direct encore. Un contenu organisé en titres et en listes se découpe naturellement en passages citables. Un modèle qui doit extraire une réponse à une question précise trouve dans une structure claire le fragment exact à reprendre, avec son contexte. Un pavé de texte sans hiérarchie oblige le modèle à deviner les frontières, ce qu'il fait mal.
Ce correctif est presque toujours détecté par un audit automatisé, et presque jamais priorisé, parce qu'il n'a pas d'indicateur de performance associé. C'est précisément ce qui en fait un avantage compétitif : les sites qui le traitent se distinguent sur un critère que leurs concurrents ignorent. Les formats de contenu les plus cités par les LLM reposent largement sur cette structure, comme le montrent les 500 audits sur les formats de contenu que les LLM citent vraiment.
Comment prioriser ces 7 correctifs sans refaire tout le site
L'ordre d'exécution suit une logique d'accès avant de suivre une logique de qualité. Premier bloc, ce qui débloque : rendu côté serveur, robots.txt, sitemap. Sans accès, aucune autre optimisation ne produit d'effet mesurable, ni sur Google ni sur les moteurs de réponse. Deuxième bloc, ce qui améliore la compréhension : données structurées, canonical. Le contenu devient lisible et non ambigu. Troisième bloc, ce qui renforce la citabilité : maillage interne, accessibilité, vitesse. Le site ne se contente plus d'être lu, il devient sélectionnable comme source.
La mesure doit se faire sur les deux canaux en parallèle, avec le même échantillon. Choisir dix à vingt requêtes témoins représentatives de l'intention d'achat, puis suivre pour chacune : position et impressions dans Search Console, et présence ou absence de citation dans ChatGPT, Perplexity et Gemini. Un correctif qui améliore l'un sans toucher l'autre mérite d'être documenté, car c'est souvent le signe d'un problème adjacent.
C'est exactement le rôle que joue Mirok dans une stack existante : détecter les opportunités sur ces sept axes, les auditer, les sourcer, puis proposer un correctif soumis à validation humaine avant exécution. Rien ne part en production sans accord, et chaque action est traçable. Le protocole est détaillé dans automatiser sans perdre le contrôle : le protocole de validation humaine, et le branchement aux outils déjà en place (Search Console, GA4, GitHub, CMS) prend une trentaine de minutes, comme expliqué dans brancher sa stack marketing à Mirok en 30 minutes.
FAQ
Le GEO remplace-t-il le SEO technique ?
Non. Le GEO ajoute une cible, être cité dans une réponse générée, mais il repose sur les mêmes fondations techniques que le SEO : contenu accessible, structuré, rapide et non dupliqué. Un site mal rendu ou mal balisé est invisible pour Google comme pour les moteurs de réponse. Les deux disciplines se renforcent au lieu de s'opposer.
Quels crawlers IA faut-il autoriser dans son robots.txt ?
Les principaux à considérer sont GPTBot (OpenAI), PerplexityBot, ClaudeBot (Anthropic) et Google-Extended. Un robots.txt qui bloque par défaut exclut le site des réponses génératives, souvent sans que l'équipe en ait conscience. Le choix dépend de votre stratégie de contenu et de votre modèle économique : autoriser pour gagner en visibilité, bloquer pour protéger un contenu payant.
Les données structurées ont-elles un effet sur les réponses de ChatGPT ou Perplexity ?
Oui, indirectement mais réellement. Elles facilitent l'extraction de faits attribuables et réduisent l'ambiguïté sur l'entité concernée. Un modèle qui identifie clairement l'auteur, la date et le sujet d'une page a plus de chances de la reprendre comme source citée plutôt que de paraphraser son contenu sans attribution.
Comment savoir si mon site est lisible par les moteurs de réponse IA ?
Comparez le HTML brut servi au crawler avec la version rendue dans le navigateur : si le contenu principal n'apparaît pas dans le HTML brut, il est invisible pour les crawlers IA. Vérifiez ensuite votre robots.txt user-agent par user-agent, puis testez la récupération de vos pages clés sans exécution JavaScript. Ces trois vérifications suffisent à établir un diagnostic de base.
Par quel correctif commencer quand on a peu de ressources ?
Commencez par ce qui débloque l'accès : rendu côté serveur, robots.txt et sitemap. Sans accès, les autres optimisations n'ont aucun effet mesurable, ni sur Google ni sur les moteurs de réponse. Une fois l'accès confirmé, enchaînez sur les données structurées et le canonical, qui améliorent la compréhension du contenu par les deux canaux.