Sous-domaine et SEO : sous-domaine ou sous-dossier, simplement

Qu’est-ce qu’un sous-domaine ?

En SEO, le sous-domaine se résume à un seul choix. Placez-vous une partie de votre site sur blog.example.com ou sur example.com/blog/ ? Le premier est un sous-domaine. Le second, en revanche, est un sous-répertoire, que beaucoup appellent sous-dossier.

Un sous-domaine est la partie placée devant votre domaine principal. Dans shop.example.com, le mot « shop » est le sous-domaine. De plus, votre DNS le pointe où vous voulez. Ainsi, il peut tourner sur un autre serveur, un autre CMS ou la plateforme d’une autre société.

Un sous-dossier, en revanche, n’est qu’un chemin sur le même hôte. Il partage le serveur, le robots.txt et souvent le CMS. Donc, pour un robot, il fait clairement partie du site principal.

Ce guide explique d’abord comment les moteurs traitent chaque option. Ensuite, il montre quand un sous-domaine a du sens et comment le passer dans un dossier. Notre SEO Checker gratuit signale les pages sur un sous-domaine, c’est pourquoi nous expliquons aussi cette alerte.

Comment Google traite un sous-domaine

Google dit qu’il explore, indexe et classe bien les deux options. Son équipe l’a souvent répété. Cependant, « peut se classer » ne veut pas dire « se classe pareil dès le premier jour ».

En pratique, Google apprend le sujet d’un hôte à partir de ses propres pages et de ses liens. C’est pourquoi un nouveau sous-domaine démarre souvent avec moins de confiance qu’un dossier sur un domaine fort. Il doit bâtir ses propres signaux, et cela prend du temps. En effet, cet écart résume tout le débat.

Ce qu’un sous-domaine partage, et ce qu’il ne partage pas

• Séparé : le robots.txt, le serveur, le certificat TLS (sauf certificat générique) et souvent le CMS et son sitemap.
• Séparé dans les rapports : une propriété préfixe d’URL dans la Search Console ne couvre qu’un hôte.
• Partagé : le nom de la marque et une propriété de domaine dans la Search Console, qui couvre tous les sous-domaines à la fois.
• Relié, pas fusionné : les liens entre le site principal et le sous-domaine aident, mais comptent comme des liens entre deux hôtes.

Le guide de Google sur la structure des URL demande des adresses simples et logiques. Aucune des deux options n’enfreint cette règle. La vraie différence porte donc sur la part de force du site principal que chacune peut utiliser.

Sous-domaine ou sous-répertoire

Voici la réponse courte. Pour la plupart des petits et moyens sites, un sous-répertoire est le choix le plus sûr pour le SEO. Cependant, un sous-domaine est meilleur quand la section est vraiment un autre produit, une autre équipe ou une autre plateforme.

Sous-domaine ou sous-dossier en un coup d’œil

• Liens : un dossier profite tout de suite des liens du domaine principal. Un sous-domaine gagne presque tous les siens.
• Mise en place : un dossier demande le même serveur ou un proxy inverse. Un sous-domaine ne demande qu’un enregistrement DNS.
• Outils : un sous-domaine peut utiliser n’importe quel CMS ou SaaS. Un dossier tourne souvent sur la technique du site principal.
• Mesure : un dossier partage cookies et statistiques sans effort. Un sous-domaine demande des réglages inter-domaines dans certains outils.
• Risque : un sous-domaine faible ou plein de spam reste un peu à part. Un dossier, en revanche, partage le sort du site principal.

Choisir entre sous-domaine et sous-répertoire est donc un échange. Vous cédez un peu de force commune contre la liberté de construire la section. Beaucoup de marques l’acceptent. Pourtant, d’autres le regrettent quand leur blog en sous-domaine met des années à rattraper son retard.

Quand un sous-domaine est le bon choix

Les sous-domaines ne sont pas une erreur. En effet, certains des plus grands sites du monde les utilisent exprès. Ils conviennent surtout quand la section mène sa propre vie.

• Une appli ou un tableau de bord, comme app.example.com, que les moteurs ne doivent pas indexer de toute façon.
• Une plateforme hébergée, comme un centre d’aide, une page d’état ou une boutique qui ne tourne que sur son propre hôte.
• Une autre langue ou un autre pays, quand une équipe locale le gère. Les dossiers marchent aussi ici, cela dit.
• Un produit distinct, avec son public, sa marque et sa propre stratégie de liens.
• Un outil, comme un pastebin ou un hébergeur de fichiers, qui ralentirait le site principal ou exige d’autres règles de sécurité.

Notre propre pastebin en est un bon exemple. Il tourne sur paste.denwix.com, car il a besoin de ses propres en-têtes de sécurité stricts et de son propre stockage. Donc notre checker le signale, et c’est normal. L’alerte rappelle l’échange ; ce n’est pas un verdict.

Quand ça ne vaut pas le coup

Le blog est le cas classique. Beaucoup mettent le blog sur un sous-domaine parce que WordPress s’y installait plus facilement. Puis le blog grandit et gagne des liens, mais cette force n’atteint pas les pages produits. C’est le coût du sous-domaine que presque personne n’avait prévu.

Quand un sous-dossier gagne

Un sous-dossier gagne chaque fois que le contenu sert à faire ranker le site principal. Blogs, guides, études de cas, glossaires et documentation en font partie. Ainsi, chaque nouvel article dans un dossier renforce le même hôte, et tout le site se renforce.

De plus, un dossier simplifie la vie. Il y a un seul robots.txt, un index de sitemaps, un certificat et une configuration de statistiques. Par ailleurs, les liens entre le blog et les pages produits restent des liens internes normaux, ce qui est exactement le but.

Et si le blog tourne sur une autre plateforme ?

Vous pouvez quand même le servir depuis un dossier. Un proxy inverse, réglé dans nginx, Apache ou un worker de CDN, envoie example.com/blog/ vers le vrai serveur du blog. Ainsi, visiteurs et robots ne voient que le domaine principal. La plupart des hébergeurs et des CDN ont un guide pour cela.

Un exemple rapide avec nginx

location /blog/ {
  proxy_pass https://blog-host.example.net/;
  proxy_set_header Host blog-host.example.net;
}

Ensuite, réglez l’adresse du blog sur https://example.com/blog/, pour que ses liens, ses canoniques et son sitemap utilisent l’adresse du dossier.

Pourquoi le SEO Checker signale un sous-domaine

Notre SEO Checker lit l’hôte de chaque page qu’il analyse. Si l’hôte porte autre chose que www devant le domaine principal, il affiche une alerte dans le groupe Adresse.

Des outils comme Seobility affichent la même alerte. Ils conseillent d’utiliser un domaine de premier niveau pour de meilleurs résultats. La formule est un peu forte. Pourtant, l’idée reste la même : une page sur un sous-domaine ne peut pas s’appuyer sur le domaine principal autant qu’une page dans un dossier.

L’alerte coûte très peu de points. Lisez-la donc comme une question. Cette section est-elle séparée exprès ? Si oui, gardez-la et suivez la liste ci-dessous. Sinon, prévoyez le passage dans un dossier.

La même ligne vérifie aussi un autre point. Elle s’assure que le domaine n’utilise que des lettres latines, car un nom dans une autre écriture s’affiche en punycode, par exemple xn--, dans de nombreux logiciels.

Liste de contrôle pour un sous-domaine

Garder un sous-domaine est souvent le bon choix. Dans ce cas, aidez les moteurs à le relier au site principal. Voici la liste que nous utilisons.

1. Donnez-lui son propre robots.txt, avec une ligne Sitemap. Un robot lit le robots.txt par hôte, donc celui du site principal ne le couvre pas.
2. Donnez-lui son propre sitemap XML et soumettez-le dans la Search Console.
3. Validez une propriété de domaine dans la Search Console, pour voir tous les hôtes dans un seul rapport.
4. Faites des liens dans les deux sens. Mettez le site principal dans l’en-tête et le pied du sous-domaine, et liez le sous-domaine depuis les pages principales utiles.
5. Gardez la même marque : logo, nom et design, pour que les gens et les machines voient une seule entreprise.
6. Ajoutez le schéma Organization avec le même nom, le même logo et les mêmes profils sameAs sur les deux hôtes.
7. Utilisez une seule adresse canonique par page, et ne publiez jamais le même article sur les deux hôtes.
8. Couvrez-le en HTTPS, avec un certificat générique ou son propre certificat.

Notre générateur de robots.txt et notre générateur de sitemap XML règlent les deux premières étapes en quelques minutes.

Comment passer d’un sous-domaine à un dossier

Passer une section d’un sous-domaine à un sous-dossier est une migration de site. Faites-le donc avec soin. Bien fait, le nouveau dossier se classe en général au moins aussi bien en quelques semaines. Mal fait, en revanche, le trafic baisse pendant des mois.

Étape 1 : listez chaque adresse

Explorez le sous-domaine et exportez chaque URL qui répond 200. Puis ajoutez les URL de son sitemap et de la Search Console, pour ne rien oublier.

Étape 2 : associez l’ancienne à la nouvelle

Écrivez une nouvelle adresse de dossier pour chaque ancienne. Gardez les slugs quand c’est possible. Par exemple, blog.example.com/seo-tips/ devient example.com/blog/seo-tips/.

Étape 3 : servez le contenu depuis le dossier

Installez la section sur le site principal, ou montez le proxy inverse vu plus haut. Ensuite, mettez à jour les canoniques, les liens internes, les images et le sitemap avec les nouvelles adresses.

Étape 4 : redirigez en 301

Envoyez chaque ancienne adresse vers la nouvelle avec une redirection permanente 301, une par une. N’envoyez jamais tout vers l’accueil. Notre vérificateur de chaînes de redirection montre si chaque saut arrive en une seule étape.

# On the old blog host (Apache)
RewriteEngine On
RewriteRule ^(.*)$ https://example.com/blog/$1 [R=301,L]

Étape 5 : surveillez et patientez

Soumettez le nouveau sitemap. Puis gardez les redirections au moins un an. Pendant ce temps, surveillez les 404 dans la Search Console et corrigez-les dès qu’ils apparaissent.

Erreurs fréquentes

• Mettre le blog sur un sous-domaine seulement parce que l’installation y était plus simple.
• Publier les mêmes articles sur le sous-domaine et sur le site principal, ce qui divise tous les signaux.
• Oublier le robots.txt du sous-domaine, si bien qu’un « Disallow: / » resté de la préproduction bloque tout.
• Laisser les sous-domaines de test ouverts aux robots. Protégez-les plutôt par un mot de passe.
• Passer un sous-domaine dans un dossier sans redirections 301.
• Ne lier le sous-domaine que depuis le pied de page, si bien qu’il semble secondaire.

Chacune de ces erreurs de sous-domaine s’évite facilement une fois connue. Par ailleurs, l’aide de la Search Console sur l’ajout d’une propriété explique la différence entre propriétés de domaine et de préfixe d’URL.

Questions et réponses