Sous-domaine ou sous-répertoire : ce que le choix change pour les moteurs IA

Le débat sous-domaine ou sous-répertoire est un classique du SEO français. Faut-il publier son blog sur blog.monsite.fr ou sur monsite.fr/blog ? La question traîne depuis quinze ans, elle a ses camps, ses arguments de transmission d'autorité, et une réponse officielle qui devrait l'avoir close depuis longtemps. Le SEO du sous-domaine est d'ailleurs un dossier clos : sur le classement, l'affaire est réglée depuis des années. Le GEO du sous-domaine ne l'est pas, et il vient de se rouvrir par une porte que personne ne surveillait, celle des autorisations d'accès.

Google range la question dans une liste intitulée « Things we believe you shouldn't focus on », neuf entrées de son guide de démarrage SEO. C'est la même liste qui contient le bourrage de mots-clés, le PageRank et la prétendue pénalité de contenu dupliqué, et dont j'ai déjà tiré l'entrée sur le nombre et l'ordre des titres. L'entrée qui nous occupe s'appelle « Subdomains versus subdirectories » et la réponse tient en une phrase : « From a business point of view, do whatever makes sense for your business. » La suite explique qu'il peut être plus simple de gérer un site segmenté en sous-répertoires, ou plus logique de partitionner des thématiques en sous-domaines, selon le secteur. Rien sur le classement. Google renvoie la décision à l'exploitation.

Cette réponse est solide, et elle reste vraie pour le classement. Mais les deux mots qu'elle déclare indifférents apparaissent ailleurs dans la documentation de Google, dans un texte où ils décident de tout.

Les mêmes deux mots, dans la spécification robots.txt

La page qui spécifie le format robots.txt contient un tableau de portée. Il indique à quels contenus s'applique un fichier donné, et voici ce qu'il dit du cas général, https://example.com/robots.txt :

« It's not valid for other subdomains, protocols, or port numbers. It's valid for all files in all subdirectories on the same host, protocol, and port number. »

La phrase oppose littéralement les deux termes du débat. Les sous-répertoires sont couverts, tous, sans exception, sans qu'on ait rien à faire. Les sous-domaines ne le sont pas. La colonne « Not valid for » du tableau liste d'ailleurs https://other.example.com/, mais aussi https://www.example.com/, ce qui rappelle une chose qu'on oublie : www est un sous-domaine comme un autre.

Voilà la vraie ligne de partage. Le sous-répertoire est une portion d'un site. Le sous-domaine est un hôte, et l'hôte est l'unité dans laquelle se déclarent les autorisations. C'est dans ce fichier que se joue l'essentiel de l'accès des moteurs génératifs, et quels user-agents d'IA autoriser est une décision que le SEO technique classique n'avait jamais eu à prendre. Tant qu'on parlait de classement, la différence n'avait pas de conséquence pratique : Google savait rattacher les deux à la même marque. Depuis que l'accès des robots d'IA se négocie fichier par fichier, elle en a une, et elle est mécanique.

J'ai voulu savoir ce que ça donne en vrai.

Treize paires de sites, treize fichiers différents

J'ai pris treize couples hôte racine / sous-domaine chez des éditeurs qui ont les moyens de tenir une politique cohérente : HubSpot, Stripe, GitHub, OpenAI, Anthropic, Notion, Atlassian, Salesforce, Mozilla, Cloudflare (deux couples), le New York Times et Le Figaro. Pour chaque hôte, j'ai récupéré robots.txt et comparé les empreintes.

Treize paires, treize fichiers différents. Pas une seule marque de cet échantillon ne sert le même robots.txt sur ses deux hôtes. Ce résultat n'est pas anormal en soi : un sous-domaine de documentation n'a pas les mêmes chemins à protéger qu'un site vitrine, et il est légitime que les règles de chemin diffèrent. Ce qui compte, c'est ce que devient la politique d'IA au passage.

Le Figaro montre le cas propre. lefigaro.fr et madame.lefigaro.fr déclarent 245 lignes User-agent chacun, et les deux ensembles sont identiques au caractère près : même liste de robots d'IA, mêmes noms, même granularité. Les fichiers diffèrent par ailleurs (12 628 contre 12 121 octets), mais la politique d'agents, elle, a été répliquée. C'est faisable, quelqu'un le fait.

Le New York Times montre l'autre cas. nytimes.com nomme 68 agents distincts. cooking.nytimes.com en nomme 55. Treize agents sont donc nommés sur l'hôte principal et absents du sous-domaine, et aucun dans l'autre sens : l'ensemble du sous-domaine est un sous-ensemble strict de celui de l'hôte principal.

Parmi ces treize, sept portent un Disallow: / sur nytimes.com, c'est-à-dire une interdiction totale :

Brightbot
Diffbot-User
ExaBot
ExaSearchBot
FirecrawlAgent
ShapBot
meta-webindexer/1.1

Sur cooking.nytimes.com, ces sept noms n'apparaissent nulle part. Ils relèvent donc du bloc User-agent: *, dont les dix Disallow visent des chemins d'application (/search, /recipe-box, /guides/, l'édition de compte). Autrement dit : sept robots que le New York Times a explicitement chassés de son site d'information sont libres de parcourir ses recettes. Même marque, même rédaction, même politique éditoriale supposée, un nom d'hôte d'écart.

Je ne sais pas si c'est un choix ou un oubli, et je ne prétendrai pas le savoir. Ce que la mesure établit, c'est que la question se pose une fois par hôte, et qu'elle a reçu deux réponses différentes dans la même maison.

Le llms.txt ne s'hérite pas davantage

Le même test sur llms.txt, sur huit des paires, donne un résultat plus net encore. Deux paires n'ont de fichier sur aucun des deux hôtes (New York Times, Le Figaro). Deux paires divergent sur la présence même :

cloudflare.com/llms.txt              200   17 176 octets
blog.cloudflare.com/llms.txt         404
developers.cloudflare.com/llms.txt   200   15 906 octets

anthropic.com/llms.txt               404
docs.anthropic.com/llms.txt          200   73 393 octets

Anthropic est l'illustration parfaite du mécanisme. L'entreprise qui édite Claude publie un llms.txt sur son sous-domaine de documentation et n'en publie pas sur l'hôte de sa marque. Ce n'est pas une négligence, c'est la conséquence normale d'un fichier qui se déclare par hôte : les docs vivent ailleurs, le fichier suit les docs.

Les quatre paires restantes ont bien un fichier des deux côtés, et aucune ne sert le même. Stripe : 65 026 octets sur l'hôte racine, 90 052 sur docs.stripe.com, avec deux types MIME différents (text/plain contre text/markdown). Notion : 6 803 contre 37 145. HubSpot : 30 688 contre 952 767, soit un rapport de trente et un entre le fichier du site et celui du blog. Sur les six paires où au moins un hôte publie un llms.txt, il n'existe pas un seul cas de fichier partagé.

La spécification l'assume, et c'est là que la différence avec le sous-répertoire devient explicite. La version 2 du texte de Jeremy Howard, publiée le 3 septembre 2024 et révisée le 10 août 2026, écrit que le fichier « can be placed at the site root, or at any path within it, covering the pages under that path ». Le document explique même pourquoi il a écarté le préfixe /.well-known/ : parce que les URI bien connues n'existent qu'à la racine d'une origine, alors que beaucoup d'auteurs ne contrôlent qu'un chemin sur un hôte partagé.

Traduit dans les termes du débat : un sous-répertoire peut porter son propre llms.txt, ou se contenter de celui de la racine qui le couvre. Un sous-domaine est une origine, donc il doit republier le sien. La spécification a été écrite pour rendre le chemin autonome, et elle a laissé l'hôte indivisible. Le sujet du llms.txt et de son utilité réelle mérite son propre article, mais sa portée, elle, ne se discute pas.

Anthropic est du reste le seul des trois éditeurs de moteurs dont j'ai lu la documentation robots à écrire la consigne noir sur blanc : « Please do this for every subdomain that you wish to opt out from. » Le terme « subdomain » apparaît zéro fois dans la page bots d'OpenAI et zéro fois dans celle de Perplexity, contre une fois chez Anthropic. Ces zéros veulent bien dire quelque chose : sur les mêmes fichiers, « robots.txt » sort 11, 3 et 5 fois, et « crawl » 11, 7 et 20 fois. Les pages sont les bonnes, le silence est éditorial.

Le cas Cloudflare, ou trois hôtes et trois doctrines

Cloudflare vend du contrôle d'accès aux robots d'IA. C'est donc l'endroit où l'on s'attend à trouver la politique la mieux tenue du web. Ses trois hôtes publics servent trois fichiers robots.txt sans rapport les uns avec les autres.

Sur cloudflare.com, neuf blocs User-agent, dont huit nomment un agent d'IA pour l'autoriser explicitement, un en-tête Content-Signal: ai-train=yes, search=yes, ai-input=yes, et des commentaires qui pointent vers /llms.txt, /llms-full.txt, les versions Markdown des pages et un /.well-known/agents.json.

Sur blog.cloudflare.com, un seul bloc User-agent: *, trois Disallow d'interface, la longue préface juridique sur les signaux de contenu, et aucun agent d'IA nommé. Sur developers.cloudflare.com, un seul bloc également, quatre Disallow, et le Content-Signal placé cette fois à l'intérieur du bloc User-agent plutôt qu'au niveau du fichier.

Les trois hôtes autorisent l'usage par les IA, il n'y a pas de contradiction de fond. Mais ils l'autorisent par trois mécanismes différents, avec trois jeux de règles, et un seul des trois annonce les points d'entrée en Markdown. Un robot qui arrive sur le blog n'a aucun moyen d'apprendre que la marque publie un llms.txt, puisque le fichier qui le mentionne vit sur un autre hôte et que celui du blog répond 404.

Le fichier le plus élaboré des trois est d'ailleurs le plus daté. cloudflare.com autorise nommément Claude-Web. Or ce nom n'apparaît pas une seule fois dans la documentation actuelle d'Anthropic, qui nomme ClaudeBot cinq fois, Claude-User cinq fois et Claude-SearchBot trois fois. Aucun de ces trois noms n'est présent dans le robots.txt de Cloudflare. Pour vérifier que ce n'est pas une fatalité, j'ai pris un témoin : 20minutes.fr nomme les quatre, dont les trois en vigueur. Rester à jour est possible. Rester à jour sur trois fichiers l'est moins.

Comment les moteurs nomment la source

Reste la question qui intéresse vraiment quand on arbitre : est-ce qu'un moteur génératif voit blog.marque.com comme la marque, ou comme un tiers ? J'ai posé la même question en français à trois moteurs, avec recherche web activée, en leur demandant de lister les URL exactes de leurs sources. La question portait sur le blocage des robots d'IA chez Cloudflare, un sujet dont la matière est répartie sur les trois hôtes de la marque.

Les trois réponses ne se ressemblent pas.

ChatGPT (gpt-5.4) a émis deux requêtes de recherche, et les deux portent un opérateur site: :

site:developers.cloudflare.com block AI bots Cloudflare docs
site:blog.cloudflare.com Cloudflare block AI bots

La couche de récupération adresse donc l'hôte, pas le domaine. Elle a interrogé deux hôtes de la même marque comme deux terrains séparés, ce qui prolonge ce qu'on sait de l'éclatement d'une question en sous-requêtes. Les quatre URL finalement citées sont toutes sur developers.cloudflare.com : un hôte a raflé la réponse entière, l'autre est reparti bredouille.

Perplexity (sonar) a renvoyé vingt sources, réparties sur douze hôtes distincts et dix domaines enregistrables. Dix de ces vingt URL, soit la moitié, sont chez Cloudflare, réparties sur trois hôtes : cinq sur blog.cloudflare.com, trois sur developers.cloudflare.com, deux sur www.cloudflare.com. Cloudflare est le seul domaine de la liste présent par plusieurs hôtes. Dans le corps de la réponse, le moteur a cité trois URL, une par hôte.

Gemini (2.5 flash) a fait un troisième choix. Ses libellés de source nomment des domaines enregistrables et rien d'autre : cloudflare.com, developpez.com, solutions-numeriques.com, playwire.com. Les neuf liens qu'il fournit pointent tous vers vertexaisearch.cloud.google.com, et celui que j'ai testé répond 404 hors de la session de l'API. Chez lui, le sous-domaine n'existe pas à l'écran : trois hôtes Cloudflare, s'il y en avait trois, se seraient présentés au lecteur sous une étiquette unique.

Ce qu'un second hôte fait à l'identité de la marque

Les autorisations sont la partie mécanique du problème. Il en existe une seconde, plus lente à se manifester, et que les trois relevés ci-dessus éclairent par contraste : selon le moteur, un sous-domaine se présente au lecteur comme la marque, comme une source parmi d'autres, ou pas du tout.

Chez Gemini, l'étiquette de source est le domaine enregistrable. Trois hôtes d'une même maison se fondent en un seul nom, et le sous-domaine ne coûte donc rien en visibilité de marque. Chez ChatGPT et chez Perplexity, l'URL complète apparaît, et le lecteur voit blog.cloudflare.com. Il fait le rapprochement sans effort, parce que la marque est dans le nom d'hôte. La question devient nettement moins confortable quand elle ne l'est pas : un blog hébergé chez un prestataire, servi sous un nom d'hôte qui ne porte pas votre marque, n'a plus aucun signal de nom pour se rattacher à vous. C'est le même problème que celui de la cohérence d'entité entre homonymes, déplacé du nom de la marque vers le nom du serveur.

Il y a enfin une conséquence de structure que personne n'annonce en réunion d'arbitrage. Tout lien entre monsite.fr et blog.monsite.fr est un lien entre deux hôtes. Il reste un lien, il continue de guider un robot, mais il cesse d'être un lien interne au sens du maillage : les outils le comptent comme sortant d'un côté, entrant de l'autre, et vos rapports se mettent à décrire deux sites là où vous en gérez un. Le sous-répertoire garde un graphe unique. Le sous-domaine en crée deux, qu'il faut ensuite recoudre à la main.

Ce que la mesure retourne

La crainte classique du sous-domaine est qu'il dilue l'autorité de la marque. Sur le versant génératif, la mesure va dans l'autre sens. Chez Perplexity, une marque a occupé la moitié des sources d'une réponse parce qu'elle avait trois hôtes plutôt qu'un. Là où un domaine unique se serait vu attribuer une place, trois hôtes en ont pris trois. J'ai montré ailleurs qu'un domaine n'obtient qu'un emplacement et que deux pages du même site se disputent le droit de l'occuper : ce plafond se compte visiblement par hôte, pas par domaine, au moins chez ce moteur et sur cette requête.

Le vrai coût du sous-domaine est ailleurs, et il est administratif. Chaque hôte ouvre un dossier d'autorisations complet et indépendant : son robots.txt, son llms.txt, ses en-têtes, sa ligne dans vos journaux de crawl, sa colonne dans votre suivi de citations. Treize paires testées, treize fichiers robots.txt différents, et pas un seul llms.txt partagé : la duplication n'est pas une hypothèse théorique, c'est ce que font les éditeurs les mieux outillés du web, y compris ceux qui vendent l'outil.

Le sous-répertoire n'a pas ce problème, pour une raison écrite dans la spécification et non dans une croyance de métier : il hérite. Un fichier à la racine couvre tous les chemins, aujourd'hui et pour ceux que vous créerez demain.

La règle de décision

Publiez en sous-répertoire par défaut. En SEO, le sous-domaine se plaidait sur la transmission d'autorité, et ce terrain est aujourd'hui sans enjeu. En GEO il se plaide sur la surface à maintenir : un hôte, un jeu de fichiers, aucune dérive possible entre deux versions d'une même politique. C'est le seul critère qui ait changé de camp en dix ans.

Passez au sous-domaine quand une contrainte réelle l'impose. Il y en a de bonnes : une plateforme tierce qui ne sait pas servir sous un chemin, une équipe distincte avec son propre cycle de déploiement, une déclinaison par pays qui a déjà sa gouvernance, un besoin d'isolation de sécurité. Google le dit lui-même, la décision est d'exploitation. Prenez-la sur ce terrain, en connaissant la facture.

Si vous avez déjà un sous-domaine, la facture se règle en quatre gestes :

1. Servir le meme robots.txt sur tous les hotes, ou au
   minimum le meme bloc d'agents d'IA. Comparer les
   empreintes, pas les fichiers a l'oeil.
2. Publier un llms.txt par hote, chacun decrivant son
   propre perimetre.
3. Verifier que les noms d'agents cites sont ceux que
   les editeurs documentent aujourd'hui.
4. Segmenter logs et suivi de citations par hote, sinon
   un sous-domaine muet reste invisible.

Le premier point est celui qui rattrape le plus de dégâts, et c'est aussi celui qui coûte le moins cher : un fichier à copier au déploiement.

Rapatrier un blog d'un sous-domaine vers un sous-répertoire est en revanche une décision lourde, parce que c'est une migration d'adresses complète. Le SEO sait la mener, la doctrine est écrite et les redirections font le travail côté classement. Sur le versant génératif elle laisse une trace plus longue, pour une raison que j'ai mesurée à part : une redirection 301 ne rattrape pas la mémoire d'un modèle, elle rattrape seulement les robots qui repassent. Un déménagement d'hôte se décide donc une fois, tôt, et pas deux fois.

Ce que cette mesure ne dit pas

Elle porte sur un échantillon de treize paires choisies pour leur notoriété, ce qui n'en fait pas un échantillon représentatif du web français. Elle ne mesure pas de classement, seulement des déclarations d'accès et des citations : rien ici ne contredit la position de Google sur le SEO, et rien ne cherche à la contredire. Le relevé de citations vient d'une requête unique par moteur, sur un sujet où la marque interrogée était aussi le sujet de la question. Cette configuration gonfle mécaniquement sa part. Le relevé établit donc qu'un moteur est capable de citer trois hôtes d'une même marque dans une réponse, et il ne dit rien de la fréquence à laquelle il le fait.

Enfin, l'observation sur Gemini décrit ce que l'API renvoie, pas nécessairement ce que voit un utilisateur dans l'interface grand public.

La SERP française sur cette question donne huit résultats organiques : deux billets d'agence SEO dont le premier classé date de novembre 2022, un article de blog d'éditeur d'outil, une fiche de lexique, deux guides d'hébergeur de sites et deux fils Reddit. Quatre affichent une date, deux une ancienneté relative, deux n'en affichent aucune. Tous abordent la question par la définition du sous-domaine, par le classement ou par la transmission d'autorité. Aucun ne mentionne qu'un sous-domaine oblige à republier son robots.txt. C'est pourtant la seule conséquence du choix qui soit écrite dans une spécification plutôt que déduite d'une intuition.

Si vous voulez savoir ce que vos propres hôtes déclarent aujourd'hui, c'est le genre de relevé que couvre un audit GEO, et le vocabulaire employé ici est détaillé dans le glossaire.