Un lecteur, Jérémie, m'avait écrit une question très simple : son site vendait trois catégories de produits, il y avait un blog dessus, et il se demandait s'il pouvait créer un sous-domaine par produit sans prendre de risque. Sous-entendu : est-ce que cela aiderait son référencement, ou le pénaliserait ? Je publie une réponse à cette question depuis 2018, je l'ai corrigée plusieurs fois, et je la corrige encore : ma position s'est nuancée avec les années, celle de Google n'a pas bougé.
Un rappel de vocabulaire d'abord. exemple.fr/blog/ est un sous-répertoire, aussi appelé sous-dossier : même hôte, donc même site au sens technique. blog.exemple.fr est un sous-domaine : un hôte différent, qui peut vivre sur un autre serveur, avec sa propre configuration. Le choix paraît cosmétique. Il ne l'est pas — mais pas exactement pour les raisons qu'on entend le plus souvent en réunion de projet.
Ce que Google dit aujourd'hui, et ce qu'il ne dit pas
La position publique de Google n'a pas varié depuis des années : les deux structures sont traitées de façon équivalente en recherche. Le sujet a donné lieu à un affrontement assez net entre Google et une partie de la profession en janvier 2018, quand John Mueller et Danny Sullivan ont dû défendre cette ligne publiquement. Mueller la résumait d'une phrase qui reste la meilleure synthèse du sujet : il y a de bonnes raisons d'aller dans les deux sens, mais il ne faut pas en choisir une à l'aveugle en espérant une prime au classement (Search Engine Roundtable, 24 janvier 2018).
Côté secteur, Patrick Stox a publié chez Ahrefs en mars 2021 un article qui qualifie la préférence des référenceurs pour les répertoires de mythe fondé sur d'anciennes études : dans les cas de migration souvent cités, d'autres facteurs — refonte, maillage interne accru, contenus ajoutés — expliquent mieux les écarts que la structure d'URL (Ahrefs, Subdomain vs Subfolder). Cet article m'avait fait réviser mon discours, et je le maintiens : le classement n'est pas le bon angle d'attaque.
Là où la documentation officielle est beaucoup plus concrète, c'est sur le plan de l'exploration. Google définit explicitement un site, pour son infrastructure de crawl, comme un nom d'hôte unique : https://www.example.com/ et https://code.example.com/ sont traités comme deux sites distincts, avec des budgets d'exploration séparés (Google Search Central, gestion du budget d'exploration, mise à jour du 22 juillet 2026). Ce n'est pas une question de « jus de liens », c'est une question de plomberie : chaque hôte a sa file d'attente et ses limites.
Ce qu'un sous-domaine change réellement
Voici ce qui bouge quand vous passez d'un répertoire à un sous-domaine. Aucun de ces points n'est rédhibitoire isolément ; additionnés, ils représentent du travail de configuration récurrent.
| Élément | Sous-répertoire | Sous-domaine |
|---|---|---|
| Exploration par Google | Budget partagé avec le site | Hôte distinct, budget distinct |
| Fichier robots.txt | Un seul fichier | Un fichier par hôte |
| Search Console | Couvert par la propriété du site | Propriété de domaine, ou propriété séparée |
| Nom du site dans les résultats | Non géré au niveau du répertoire | Nom de site possible |
| Certificat TLS | Rien à ajouter | Certificat ou wildcard à gérer |
| Cookies | Partagés par défaut | Dépend de l'attribut Domain |
| Analytics | Aucune configuration | Domaine de cookie à aligner |
Deux précisions utiles. Le robots.txt ne vaut que pour l'hôte, le protocole et le port où il est hébergé : celui de www.exemple.fr ne pilote pas boutique.exemple.fr (documentation robots.txt, mise à jour du 31 août 2026). Et dans Search Console, une propriété « préfixe d'URL » n'inclut pas les sous-domaines ; seule la propriété de domaine, validée par DNS, les couvre tous (aide Search Console).
Un avantage net du sous-domaine, côté affichage : Google ne gère les noms de site qu'au niveau du domaine et du sous-domaine, pas du répertoire. https://exemple.fr/news ne peut pas porter son propre nom de site, https://news.exemple.fr le peut (Search Central, noms de site, mise à jour du 10 décembre 2025). Marginal pour une TPE, réel pour un média à plusieurs marques.
Les cas concrets, un par un
Le blog
Répertoire, sans hésiter. Le blog sert à attirer une audience qu'on oriente ensuite vers les pages commerciales : le garder sur le même hôte simplifie le maillage interne, la mesure et la maintenance. Je n'ai jamais vu d'argument valable pour blog.exemple.fr chez une TPE ou une PME, sauf contrainte d'hébergement.
La boutique
Même réponse, et c'est le cas où j'ai vu le plus de dégâts. Dans mes cours et mes mini-conférences, je montrais régulièrement des boutiques logées sur un sous-domaine à côté d'un site éditorial : le contenu décollait avec les années, la boutique restait à l'arrêt. La cause n'est pas magique. Quand la boutique est ailleurs, personne ne pense à lui faire des liens depuis les contenus, les fiches produits ne sont jamais citées depuis la page d'accueil, et l'équipe finit par traiter les deux comme deux projets séparés. Un sous-domaine peut très bien fonctionner, à condition de lui offrir le même maillage interne qu'un répertoire. Plus de travail et une vigilance permanente pour arriver au même résultat : je préfère éviter.
Les versions linguistiques
C'est le seul cas où je ne tranche plus de façon aussi ferme qu'avant. J'ai longtemps écrit qu'il fallait bannir fr.site.com et de.site.com. La documentation de Google, elle, présente les trois structures — domaine national, sous-domaine, sous-répertoire — avec leurs avantages et inconvénients, sans en désigner une meilleure ; seuls les paramètres d'URL sont déconseillés (structures d'URL pour les sites multirégionaux, mise à jour du 10 décembre 2025). Le sous-domaine y est crédité d'un atout que le répertoire n'a pas : il autorise des serveurs différents par marché.
Ma recommandation pratique reste la même pour une PME : un site principal en .com ou .eu, puis des répertoires par langue ou par marché. J'ai vu plusieurs entreprises qui avaient ouvert un site par pays européen revenir à ce modèle, faute de pouvoir entretenir une notoriété correcte sur cinq domaines à la fois. J'ai traité le sujet en détail dans mon guide du SEO international.
Le site d'aide ou la documentation
Ici, le sous-domaine se défend. Les centres d'aide reposent souvent sur un outil externe hébergé par un prestataire, difficile à brancher sous un répertoire sans reverse proxy. Le contenu vise un public différent — vos clients existants — et ne cherche pas à se classer sur les requêtes commerciales. Si votre éditeur propose un répertoire via proxy, prenez-le. Sinon, aide.exemple.fr est un compromis acceptable.
L'environnement de test
Sous-domaine obligatoire, et protégé. Une préproduction sur preprod.exemple.fr doit être fermée par authentification HTTP, pas seulement par noindex ou robots.txt : j'ai récupéré assez de sites dont la préprod s'était retrouvée indexée pour insister. Attention à un détail technique : si votre domaine est inscrit sur la liste de préchargement HSTS, l'inscription impose la directive includeSubDomains et s'applique donc à tous les sous-domaines, y compris les sous-domaines internes non publics (hstspreload.org). Une préprod sans certificat valide devient alors inaccessible.
Le volet technique à anticiper
Les certificats, d'abord. Chaque sous-domaine a besoin du sien, ou d'un certificat wildcard *.exemple.fr qui ne couvre qu'un seul niveau. Chez Let's Encrypt, un wildcard exige une validation DNS-01, plus lourde à automatiser qu'une validation HTTP ; et la limite est de 50 certificats par domaine enregistré tous les 7 jours (limites de fréquence Let's Encrypt, mise à jour du 5 août 2026). Une architecture qui crée un sous-domaine par produit, comme l'envisageait Jérémie, atteint vite le plafond. Si vous vous interrogez sur le type de certificat à prendre, j'ai comparé les options dans mon article sur le certificat SSL gratuit ou payant.
Les cookies ensuite. Un cookie sans attribut Domain n'est renvoyé qu'à l'hôte qui l'a posé et n'est pas transmis aux sous-domaines ; il faut déclarer Domain=exemple.fr pour le partager. Et les cookies préfixés __Host-, utilisés pour les sessions sensibles, interdisent justement l'attribut Domain : ils restent liés à un seul hôte (MDN, Set-Cookie). Conséquence directe : un panier ou une session qui doit survivre au passage de www à boutique demande une configuration explicite.
La mesure, enfin. Google Analytics 4 recommande de configurer la mesure inter-domaines pour les sous-domaines et de vérifier que tous utilisent le même domaine de cookie, faute de quoi des auto-références apparaissent et les sessions sont coupées en deux (aide Google Analytics). C'est l'erreur la plus fréquente que je corrige sur ce type d'architecture.
Et si je veux changer ?
Une migration de sous-domaine vers répertoire est une migration d'URL classique : plan de correspondance page à page, redirections 301, mise à jour du maillage interne, nouveau sitemap, surveillance dans Search Console pendant plusieurs semaines. Ma méthode est détaillée dans mon article sur la redirection 301.
Un avertissement, en revanche, sur une pratique qu'on me propose parfois : déplacer des contenus douteux vers un sous-domaine ou un répertoire dédié pour « isoler le risque » ne fonctionne pas. Les règles anti-spam de Google visent explicitement le fait d'utiliser ou de créer des sous-domaines, des sous-répertoires ou des sites pour continuer à enfreindre les règles, et traitent cela comme un contournement (règles anti-spam Google, mise à jour du 28 août 2026). L'évaluation porte sur le contrôle éditorial, pas sur l'emplacement.
Ma règle de décision
Je choisis un répertoire par défaut. Je bascule sur un sous-domaine seulement si je réponds oui à l'une de ces trois questions : le contenu tourne-t-il sur une plateforme que je ne peux pas brancher sous un répertoire ? S'adresse-t-il à un public réellement différent, sans concurrence avec mes pages commerciales ? Doit-il être isolé pour des raisons de sécurité ou de charge, comme une préproduction ou une API ? Si la réponse est non partout, le sous-domaine n'apporte rien qu'un dossier ne ferait.
La réponse à Jérémie tient donc en une phrase : un sous-domaine par produit ne présente pas de « risque » au sens d'une sanction, mais c'est une multiplication de sites à faire vivre pour un bénéfice nul. Trois catégories de produits se rangent très bien dans trois répertoires du même site.
Questions fréquentes
Un sous-domaine est-il pénalisé par Google ?
Non, il n'existe aucune pénalité liée au fait d'utiliser un sous-domaine. Google traite les deux structures de façon équivalente dans son classement et l'a réaffirmé publiquement à plusieurs reprises. La différence se joue sur l'exploration, la configuration technique et le maillage interne, pas sur une sanction algorithmique.
Un sous-domaine hérite-t-il de l'autorité du domaine principal ?
Pas automatiquement, et la question est mal posée. Pour l'infrastructure d'exploration de Google, un nom d'hôte différent est un site différent, avec son propre budget de crawl. En pratique, ce qui compte est le nombre et la qualité des liens qui pointent vers les pages concernées, y compris les liens internes depuis le site principal.
Faut-il déclarer chaque sous-domaine dans Search Console ?
Cela dépend du type de propriété. Une propriété « préfixe d'URL » ne couvre pas les sous-domaines : il faut alors en créer une par sous-domaine. Une propriété de domaine, validée par un enregistrement DNS, couvre en une seule fois tous les sous-domaines et tous les protocoles.
Faut-il un certificat SSL séparé pour chaque sous-domaine ?
Oui, sauf si vous utilisez un certificat wildcard qui couvre tous les sous-domaines d'un même niveau. Chez Let's Encrypt, un wildcard impose une validation par enregistrement DNS, plus complexe à automatiser qu'une validation classique. Multiplier les sous-domaines revient donc à multiplier les renouvellements à surveiller.
Mes statistiques sont-elles affectées par un sous-domaine ?
Oui, si rien n'est configuré. Google Analytics 4 recommande d'activer la mesure inter-domaines pour les sous-domaines et de vérifier que tous partagent le même domaine de cookie. Sans cela, un visiteur qui passe du site principal au sous-domaine est compté deux fois et votre tunnel de conversion devient illisible.
Mon centre d'aide doit-il être sur un sous-domaine ?
C'est l'un des rares cas où le sous-domaine se justifie, parce que ces outils sont souvent hébergés par un prestataire externe. Si votre éditeur permet de le servir sous un répertoire via un reverse proxy, cette option reste préférable. Sinon, un sous-domaine bien relié au site principal fait très bien l'affaire.