// guide
Comment faites-vous du GEO sur votre propre site en pratique ?
Mis à jour: 2026-08-03
// réponse courte
Le GEO technique, c'est de l'hygiène, pas de la magie. Sur get-geo.ai, une demi-journée de travail a fait pointer chaque signal vers un seul hôte, a donné aux fetchers d'IA le contenu dès la première requête, a basculé Search Console vers une propriété de domaine, et a placé le corpus complet des guides dans des fichiers llms-full par locale qui se mettent à jour depuis le même registre que les pages. Le contenu décide si l'on vous cite ; la technique décide si l'on lit assez loin pour vous citer.
Point de départ : un site qui a l'air correct
Nous vendons du GEO — notre propre site doit donc être l'implémentation de référence. Ce guide n'est pas de la théorie mais le protocole d'une vraie journée de travail : ce que nous avons trouvé, comment nous l'avons corrigé, ce que nous avons vérifié. Tous les exemples viennent de ce site même.
get-geo.ai a été construit « selon les règles de l'art » dès le premier jour : rendu côté serveur, 8 langues avec hreflang, JSON-LD Schema.org, structure answer-first, llms.txt. Que pourrait-il bien y avoir à corriger ? L'audit a trouvé un problème invisible à l'œil nu.
Découverte n°1 : le conflit apex / www
Le site vivait physiquement sur www.get-geo.ai, tandis que tous les signaux — canonical, sitemap, hreflang, JSON-LD, llms.txt — pointaient vers get-geo.ai (l'apex, le domaine sans sous-domaine). Et l'apex répondait par une redirection 308 vers www.
Résultat : une boucle. « La version canonique est l'apex » → l'apex redirige vers www → www déclare « la version canonique est l'apex ». Un crawler Google classique y survit, en brûlant du budget de crawl. Les fetchers d'IA, souvent, non : beaucoup disposent d'un budget d'une ou deux requêtes par page, et certains n'atteignent tout simplement jamais le contenu à travers une redirection. Pour le GEO, c'est critique : un fichier invisible pour le fetcher est un fichier qui n'existe pas.
Le correctif : l'apex est devenu le domaine principal chez l'hébergeur (Vercel), www renvoyant en 308 vers l'apex. Un seul commutateur — et tous les signaux sont devenus cohérents : adresse réelle, canonical, liens internes, sitemap et llms.txt pointent désormais au même endroit.
La leçon : le choix entre apex et www n'a pas d'importance. Ce qui compte, c'est que le site vive exactement sur l'un des deux et que l'autre redirige fermement. Tout écart entre « où vit le site » et « où pointent les signaux » est une taxe prélevée à chaque visite de crawler.
Découverte n°2 : le conseil périmé d'un agent IA
Le diagnostic était mené par un agent IA, et sa checklist comportait : « vérifiez que l'enregistrement A de l'apex pointe vers 76.76.21.21 ». La vérification du DNS réel a montré autre chose : le domaine résout vers 216.198.79.1 — la nouvelle infrastructure de Vercel, vers laquelle l'hébergeur a migré après la date de coupure des données d'entraînement du modèle.
Le conseil n'était pas nocif — juste périmé. Le modèle citait le passé avec assurance.
La leçon : un agent IA sans outils de vérification, c'est de la mémoire, pas de la connaissance. Confrontez toute recommandation technique d'un modèle à l'état réel du système : une requête DNS prend une seconde et tranche la question. C'est d'ailleurs le principe même du GEO : les modèles répondent à partir de ce qu'ils ont pu lire — et c'est exactement pour cela que nous rendons les contenus lisibles.
Étape 3 : Google Search Console — la propriété de domaine
Après le changement d'hôte principal, l'ancienne propriété GSC (préfixe d'URL sur https://www.get-geo.ai/) est devenue inutile : elle ne couvre que www, alors que les pages migraient vers l'apex.
La configuration correcte est une propriété de domaine (get-geo.ai, sans protocole ni sous-domaine) : elle couvre d'un coup apex, www, http, https et tous les sous-domaines. Elle ne se vérifie que par un enregistrement DNS TXT — avec un détail agréable : le jeton google-site-verification est lié au compte, pas à la méthode de vérification, si bien qu'un enregistrement ajouté au DNS auparavant a validé la propriété instantanément. Ensuite — soumission du sitemap à l'adresse apex : https://get-geo.ai/sitemap.xml.
La leçon : un sitemap fraîchement soumis dans GSC affiche souvent un statut rouge « Impossible de récupérer » avec zéro page. Ce n'est pas une erreur mais un espace réservé avant le premier traitement — asynchrone, il peut prendre jusqu'à deux jours. Avant de paniquer, vérifiez trois choses : le fichier s'ouvre à son URL directe, chaque <loc> pointe vers le bon hôte, et robots.txt contient une ligne Sitemap:. Si les trois tiennent — attendez, simplement.
Étape 4 : le sitemap comme instrument GEO, pas comme formalité
Notre sitemap ne contient pas que des pages. Il liste llms.txt, llms-full.txt et toutes les versions linguistiques llms-full/{locale} — avec dates lastmod et priorités.
Pourquoi : les crawlers d'IA (GPTBot, ClaudeBot, PerplexityBot) ont été observés en train de lire les sitemaps, et lister explicitement les fichiers LLM leur donne un itinéraire direct vers la version machine-lisible du site — sans compter sur le fait que le fetcher connaisse la convention /llms.txt.
La leçon : traitez le sitemap comme un menu pour machines, pas comme une case à cocher. Tout ce que vous voulez montrer aux systèmes d'IA doit y figurer, avec des dates lastmod honnêtes.
Étape 5 : llms-full — le contenu complet, pas la table des matières
La convention distingue deux fichiers : llms.txt est une table des matières avec des liens ; llms-full.txt est le contenu complet pour les systèmes qui ne suivent pas les liens. Notre version full ne contenait au départ que la page d'accueil : les guides — notre actif le plus citable — n'étaient accessibles que page par page.
Ce que nous avons changé :
- Des fichiers par locale. Les textes complets des guides sont partis dans llms-full/{locale}, chaque fichier entièrement dans sa langue. Entasser 8 langues dans un seul fichier, c'est diluer par huit la densité utile pour toute requête donnée.
- Une URL sous chaque titre. Dans le fichier, chaque guide s'ouvre sur son titre avec l'URL canonique juste en dessous — pour qu'un modèle qui reprend le texte puisse citer la page, et non le fichier txt lui-même.
- Génération automatique depuis un registre unique. Les fichiers sont construits à partir de la même source que les pages des guides. Un nouveau guide arrive sur le site, dans le sitemap et dans llms-full en une seule action. La synchronisation manuelle meurt en un mois — nous ne l'avons même pas commencée.
- Une limite avec dégradation honnête. Le fichier a un plafond de taille ; en cas de dépassement, au lieu d'une troncature silencieuse, il ajoute la liste des guides restés dehors, avec leurs liens.
- Une leçon venue d'un endroit inattendu : la première limite de 100 Ko a failli être cassée par un système d'écriture. Devanagari (hindi) occupe 3 octets par caractère en UTF-8 contre 1 pour le latin — le fichier hindi atteignait 85 Ko quand l'anglais en pesait moitié moins. Nous avons relevé la limite à 200 Ko. Si votre site est multilingue, budgétez en tenant compte de l'écriture : les systèmes CJK et indiens « pèsent » plusieurs fois plus.
Bilan de la journée
Une demi-journée de travail, pas une seule page de contenu nouvelle — et pourtant :
- chaque signal du site pointe vers un seul hôte, sans boucle ni redirection superflue ;
- un fetcher d'IA au budget d'une requête obtient le contenu du premier coup ;
- GSC collecte les données de tout le domaine, pas d'un seul sous-domaine ;
- le corpus complet des guides en 8 langues est accessible aux machines en un fichier par locale ;
- publier un nouveau guide met automatiquement à jour le site, le sitemap et llms-full.
De l'hygiène, pas de la magie
Voilà la partie technique du GEO : pas de la magie, de l'hygiène. Le contenu décide si l'on vous cite. La technique décide si l'on lit jusqu'à votre contenu.
Questions liées
Le choix apex vs www compte-t-il pour le GEO ?
Le choix en lui-même, non. Ce qui compte, c'est que le site vive exactement sur un seul hôte et que chaque signal — canonical, sitemap, hreflang, JSON-LD, llms.txt — y pointe, l'autre nom d'hôte redirigeant fermement. Une boucle entre apex et www brûle du budget de crawl et arrête souvent les fetchers d'IA qui ne font qu'une ou deux requêtes.
Faut-il utiliser une propriété de domaine dans Google Search Console ?
Oui, si apex et www (ou http et https) vous importent tous les deux. Une propriété de domaine les couvre d'un coup et se vérifie via DNS TXT. Une propriété préfixe d'URL sur www seul devient aveugle dès que l'hôte principal passe à l'apex.
Pourquoi lister llms.txt dans le sitemap ?
Les crawlers d'IA ont été observés en train de lire les sitemaps. Lister llms.txt et les fichiers llms-full par locale leur donne un itinéraire direct vers le corpus machine-lisible, sans compter sur le fait que chaque fetcher connaisse la convention /llms.txt.
Pourquoi des fichiers llms-full par locale plutôt qu'un dump multilingue ?
Un seul fichier avec huit langues dilue par huit la densité utile pour toute requête donnée. Un fichier par locale garde le corpus dense, place une URL canonique sous chaque titre de guide, et peut être généré depuis le même registre que les pages HTML.