Nom d’hôte placé sous un domaine parent, comme docs.example.com, qui peut remplir une fonction technique ou éditoriale distincte et doit être planifié dans l’architecture globale du site.
La décision et sa frontière
Un sous-domaine est un nom d’hôte situé sous un autre nom de domaine, par exemple docs.example.com sous example.com. Techniquement, il peut avoir sa propre application, son propre routage, ses cookies, sa configuration DNS et sa présence dans les moteurs de recherche. Cette souplesse ne tranche pas la question de l’architecture de l’information. Le choix entre sous-domaine et sous-répertoire doit reposer sur la gestion opérationnelle, les frontières produit, les besoins de localisation ou de plateforme et le parcours utilisateur, et non sur un gain SEO supposé.
Ce qu’il faut inspecter
Recensez chaque nom d’hôte, sa fonction, son responsable, son hôte canonique, l’état de son TLS, ses règles robots, son sitemap, son identifiant analytics et les chemins de liens internes. Crawlez des pages représentatives de part et d’autre de la frontière et vérifiez que les liens pointent directement vers les routes canoniques voulues. Pendant une migration, conservez une correspondance URL par URL et testez chaque destination, sans supposer qu’un routage au niveau de l’hôte suffit.
Une méthode de mise en œuvre
Utilisez un sous-domaine lorsqu’il crée une frontière stable et compréhensible, par exemple pour une documentation, une application ou une plateforme séparée par région. Donnez-lui une navigation et une politique d’indexation claires, tout en conservant des liens contextuels vers l’expérience parente. En cas de déplacement de contenu d’un nom d’hôte à un autre, configurez des redirections permanentes directes lorsque c’est pertinent, mettez à jour les références canonical et sitemap, puis validez le rendu et le suivi des deux côtés.
Erreurs et limites de mesure
Le raccourci risqué consiste à créer un sous-domaine pour isoler un travail SEO ou un contenu dupliqué. Cela peut fragmenter la responsabilité et compliquer les corrections à l’échelle du site. Ne dites pas qu’un sous-domaine hérite automatiquement de l’autorité ou la perd : évaluez les liens réels, le contenu, l’accessibilité et la mise en œuvre de la migration.
Exemple d’architecture. Une entreprise peut placer sa documentation produit sur docs.example.com parce qu’une équipe et une plateforme distinctes la gèrent, tandis qu’une application destinée aux clients vit sur app.example.com. Cette frontière est cohérente si la navigation, les attentes des comptes, la politique de recherche et la responsabilité sont clairs. Déplacer un dossier marketing vers un sous-domaine simplement parce qu’il utilise un gabarit différent est un motif bien plus faible. Documentez le parcours utilisateur à travers les hôtes avant de choisir le nom d’hôte.
Critères de contrôle. Tenez un inventaire des hôtes avec leur fonction, leur responsable principal, leur hôte public canonique, leur sitemap, leur politique robots, la couverture TLS, le périmètre analytics et les routes d’entrée clés. Crawlez des pages représentatives du parent vers le sous-domaine, et inversement, en contrôlant les liens internes directs, le comportement des redirections et les chemins de navigation ou de pied de page. Pour un déplacement, testez les paires d’URL anciennes et nouvelles, pas seulement la racine du nom d’hôte. Contrôlez les parcours sur navigateur et mobile si les cookies, la connexion ou le passage vers une application sont concernés.
Erreurs fréquentes. Ne dupliquez pas le même contenu sur un hôte racine et un sous-domaine sans décision canonique ou de migration explicite. Ne supposez pas que les moteurs de recherche traitent tous les noms d’hôte comme un seul site, ni comme des sites totalement sans lien : vérifiez la structure réelle des liens et des URL. Un changement de nom d’hôte touche aussi les opérations, les analytics et la confiance des utilisateurs, pas seulement le SEO. Il exige donc un plan de retour arrière par route.