// guide
Comment faites-vous du GEO sur votre propre site en pratique ?
Auteur: Dmitry Filippov, Founder, GET-GEO.AI
Publié: 2026-08-03 · Mis à jour: 2026-09-22
// réponse courte
Sur get-geo.ai, une demi-journée de travail a permis d'aligner les signaux sur un seul domaine, de rendre les contenus accessibles dès la première requête et de configurer une propriété de domaine dans Search Console. Les guides alimentent aussi automatiquement un fichier llms-full par langue. Ces corrections facilitent l'accès aux contenus que les assistants pourraient citer.
- Faire du GEO sur notre propre site a pris une demi-journée et aucune page nouvelle : un seul hôte principal, une propriété de domaine dans Search Console et des exports llms-full reconstruits.
- Tous les signaux pointaient vers l'apex alors que l'apex répondait par une redirection 308 vers www : une boucle que les fetchers d'IA dotés d'un budget d'une requête ne franchissent jamais.
- La checklist d'un agent IA disait que l'enregistrement A de l'apex devait pointer vers 76.76.21.21 ; le DNS réel indiquait 216.198.79.1, la nouvelle infrastructure de Vercel : vérifiez les conseils d'un modèle sur le système réel.
- Un sitemap fraîchement soumis peut afficher « Impossible de récupérer » pendant un ou deux jours ; vérifiez trois choses : le fichier s'ouvre, chaque loc utilise le bon hôte, robots.txt le référence.
- llms-full livre désormais un fichier par locale pour 9 langues ; la devanagari prend 3 octets par caractère, le fichier hindi a donc atteint 85 Ko et le plafond est passé à 300 Ko.
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, 9 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
Les pages étaient servies sur www.get-geo.ai, alors que les balises canonical, le sitemap, hreflang, JSON-LD et llms.txt indiquaient get-geo.ai, le domaine sans sous-domaine, aussi appelé apex. Celui-ci renvoyait pourtant vers www avec une redirection 308.
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.
À retenir : vous pouvez choisir le domaine avec ou sans www. L'essentiel est de servir les pages sur une seule version, de rediriger l'autre vers celle-ci et d'y faire pointer tous les signaux techniques.
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.
Une propriété de domaine pour get-geo.ai couvre le domaine nu, www, HTTP, HTTPS et les autres sous-domaines. Sa validation passe par un enregistrement DNS TXT. Dans notre cas, l'enregistrement google-site-verification déjà présent a permis de la valider immédiatement. Nous avons ensuite envoyé le sitemap à l'adresse 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 : utiliser le sitemap pour faciliter la découverte
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.
Des robots IA comme GPTBot, ClaudeBot et PerplexityBot ont été observés en train de consulter des sitemaps. Y indiquer les fichiers destinés aux modèles leur fournit un chemin direct vers ces contenus, sans supposer qu'ils connaissent la convention /llms.txt.
À retenir : le sitemap doit recenser les ressources que vous souhaitez rendre accessibles aux robots, avec des dates lastmod qui correspondent à de véritables modifications.
É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é :
- Un fichier par langue. Les guides complets sont regroupés dans llms-full/{locale}. Cela évite de mêler 9 langues dans un fichier dont seule une partie serait pertinente pour une question 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.
- Une génération automatique à partir du même registre que les pages. L'ajout d'un guide met à jour le site, le sitemap et llms-full. Cette organisation évite de devoir synchroniser manuellement plusieurs versions.
- Une limite de taille explicite. Si le contenu dépasse le plafond du fichier, les guides non inclus restent indiqués sous forme de liens au lieu de disparaître sans explication.
- Une limite adaptée aux écritures. Le premier plafond de 100 Ko était presque atteint par le fichier hindi : le devanagari utilise 3 octets par caractère en UTF-8, contre 1 pour le latin de base. Le fichier hindi pesait 85 Ko, environ deux fois plus que l'anglais. Nous avons porté la limite à 300 Ko. Un site multilingue doit tenir compte de ces écarts, notamment pour les écritures CJK et indiennes.
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 9 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 fréquentes
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 vous souhaitez suivre le domaine avec et sans www, ou en HTTP et HTTPS. Une propriété de domaine couvre toutes ces variantes et se valide par un enregistrement DNS TXT. Une propriété limitée au préfixe www ne couvre pas les pages servies directement sur le domaine nu.
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 un fichier llms-full par langue plutôt qu'un fichier multilingue ?
Dans un fichier contenant neuf langues, une grande partie du texte ne correspond pas à la langue d'une question donnée. Un fichier par langue rassemble les contenus pertinents, associe chaque guide à son URL canonique et peut être généré à partir du même registre que les pages HTML.
Guides associés
Sources
// partager
Comment citer cette page
Vous pouvez citer et réutiliser ce contenu en mentionnant la source et en ajoutant un lien vers cette page.
“Comment faites-vous du GEO sur votre propre site en pratique ?” — GET-GEO.AI, 2026-09-22. https://get-geo.ai/fr/guides/how-we-do-geo-ourselves