Sous-domaine ou sous-dossier : qu'est-ce qui est le mieux pour le SEO ?

Si tu veux créer une nouvelle section sur ton site web, la question se pose souvent : le contenu doit-il se trouver sous un sous-domaine ou dans un sous-répertoire ?

Les deux variantes sont techniquement possibles et peuvent être indexées par les moteurs de recherche. La décision ne devrait donc pas reposer sur l'hypothèse générale qu'un sous-domaine ou un sous-dossier se positionne fondamentalement mieux sur Google.

Plus importantes sont l'architecture technique de votre site web, la pertinence du contenu, le maillage interne, la navigation des utilisateurs et la question de savoir si une section doit être exploitée de manière consciemment indépendante.

En bref : Un sous-répertoire tel que example.ch/blog/ est une section au sein du même site Web ou du même nom d'hôte. Un sous-domaine tel que blog.example.ch est en revanche un nom d'hôte distinct. En matière de référencement (SEO), il n'y a pas de règle simple „ sous-dossier bon, sous-domaine mauvais “.

Qu'est-ce qu'un sous-répertoire ? #

Un sous-répertoire se trouve dans la structure d'URL d'un site Web existant.

Exemples :

https://example.ch/blog/
https://example.ch/hilfe/
https://example.ch/shop/

Le domaine principal ou le nom d'hôte reste le même :

example.ch

Seul le chemin après le nom de domaine change.

Chez CURIAWEB, par exemple, la base de connaissances est également construite sur ce principe :

https://www.curiaweb.ch/hilfe

La base de connaissances fait ainsi partie intégrante du site Web existant et ne constitue pas un nom d'hôte distinct.

Qu'est-ce qu'un sous-domaine ? #

Un sous-domaine se place avant le nom de domaine principal.

Exemples :

blog.example.ch
shop.example.ch
support.example.ch
my.example.ch

Une sous-domaine est techniquement un nom d'hôte distinct et peut pointer vers une autre infrastructure indépendamment du site Web principal.

Par exemple, peuvent

example.ch
shop.example.ch

être hébergés sur des serveurs différents.

Quelle est la différence technique ? #

Dans le cas d'un sous-répertoire, le nom d'hôte reste le même :

example.ch/blog/
example.ch/boutique/
example.ch/aide/

En revanche, un sous-domaine crée un nom d'hôte supplémentaire :

blog.example.ch
shop.example.ch
hilfe.example.ch

Cette distinction a des conséquences techniques. Par exemple, un sous-domaine peut nécessiter ses propres enregistrements DNS, sa propre configuration d'hébergement et son propre certificat SSL/TLS ou une couverture de certificat correspondante.

Nous expliquons quel rôle jouent les enregistrements DNS à ce sujet sous Enregistrements DNS expliqués : A, AAAA, CNAME, MX, TXT et CAA.

Est-ce qu'un sous-domaine est un domaine propre ? #

Non.

Chez

blog.example.ch

est example.ch toujours le domaine enregistré. blogue est un sous-domaine ou un nom d'hôte configuré en dessous.

Par conséquent, vous n'avez normalement pas besoin d'enregistrer un nouveau domaine pour chaque sous-domaine.

Nous expliquons les différences entre un domaine et une URL sous Site Web, Domaine et URL : quelle est la différence ?.

Un sous-répertoire est-il meilleur pour le référencement naturel ? #

Pas nécessairement.

Les sous-répertoires présentent toutefois un avantage structurel important : ils permettent d'organiser très facilement au sein d'une structure d'URL commune les contenus qui font clairement partie du même site Web.

Un blog d'entreprise pourrait par exemple se trouver sous

example.ch/blog/

se trouvent et la base de connaissances sous

example.ch/aide/.

Cela permet aux utilisateurs de voir immédiatement que ces contenus font partie du site principal.

Cependant, cela ne garantit pas à lui seul de meilleurs classements. La qualité du contenu, l'intention de recherche, le maillage interne, la crawlabilité, la qualité technique et bien d'autres facteurs restent déterminants.

Important : Un sous-répertoire n'obtient pas automatiquement de bons classements simplement parce que le domaine principal est déjà établi. Le contenu d'un sous-répertoire doit également être pertinent, explorable et d'une qualité convaincante.

Un sous-domaine est-il mauvais pour le référencement naturel (SEO) ? #

Non.

Les sous-domaines peuvent être explorés et indexés par les moteurs de recherche et peuvent également obtenir de bons classements.

Une sous-domaine n'est donc pas automatiquement une erreur SEO.

Ce qui importe bien davantage, c'est de savoir si la structure choisie a du sens pour la section concernée du site web et si elle est mise en œuvre techniquement de manière propre.

Est-ce que Google traite un sous-domaine comme un site web distinct ? #

Une affirmation globale telle que „ Google traite chaque sous-domaine entièrement comme un site web tiers “ est trop simpliste.

Techniquement, il s'agit d'un nom d'hôte distinct pour un sous-domaine. Google fait également la distinction entre les domaines, les sous-domaines et les répertoires dans ses différentes fonctions et systèmes.

Cependant, cela ne signifie pas que cela entraîne automatiquement un désavantage général en matière de référencement.

Remarque : „ Nom d'hôte propre “ et „ moins bons classements “ sont deux affirmations totalement différentes. De l'indépendance technique d'un sous-domaine, il n'est pas possible de déduire un désavantage automatique en matière de classement.

Quand un sous-répertoire est-il judicieux ? #

Un sous-répertoire s'avère souvent judicieux lorsque la nouvelle section fait clairement partie du site Web existant.

Des exemples typiques sont :

example.ch/blog/
example.ch/conseils/
example.ch/aide/
example.ch/references/
example.ch/produits/

Les contenus peuvent ainsi être intégrés dans une navigation commune, un maillage interne et une architecture de l'information.

Pour un blog d'entreprise ou une base de connaissances, un sous-répertoire est donc souvent une solution très naturelle.

Quand est-ce qu'un sous-domaine est utile ? #

Un sous-domaine peut être utile si une section doit être techniquement ou fonctionnellement clairement séparée du site principal.

Des exemples peuvent être :

my.example.ch
app.example.ch
status.example.ch
dev.example.ch

Un portail client, une application web ou un système de suivi de l'état peuvent par exemple utiliser un logiciel et une infrastructure totalement différents de ceux du site Web public de l'entreprise.

Dans de tels cas, la séparation technique peut être plus importante que le désir de faire fonctionner l'ensemble des contenus sous un chemin de répertoire commun.

Un sous-domaine peut-il se trouver sur un autre serveur ? #

Oui.

C'est l'un des grands avantages techniques des sous-domaines.

Le domaine principal peut par exemple pointer vers un serveur web :

example.ch

pendant

app.example.ch

pointe vers une autre infrastructure via son propre enregistrement DNS.

Cela permet une séparation claire des différentes applications et systèmes.

Un sous-répertoire peut-il se trouver sur un autre serveur ? #

C'est également possible techniquement, mais c'est généralement plus complexe.

Au revoir

example.ch/app/

le même nom d'hôte est utilisé que pour le site Web principal, la séparation ne s'effectue pas simplement via un enregistrement DNS distinct pour le répertoire.

Des règles correspondantes de proxy inverse, de serveur Web ou d'application seraient par exemple nécessaires à la place.

Le DNS fonctionne avec des noms d'hôtes et non avec des chemins d'URL comme /app/.

En bref : DNS peut app.example.ch taxer séparément, mais pas directement example.ch/app/. Le chemin n'intervient qu'après la connexion au serveur web.

Qu'est-ce qui est mieux pour un blog ? #

Si le blog fait partie intégrante du site web de l'entreprise, un sous-répertoire constitue souvent la structure la plus simple et la plus logique :

example.ch/blog/

Le blog peut ainsi être intégré directement dans la navigation, le maillage interne et le reste de la structure du site web.

Une sous-domaine telle que

blog.example.ch

peut néanmoins s'avérer judicieux si des raisons techniques ou organisationnelles plaident en faveur d'une séparation.

Seuleument pour des raisons de référencement, une structure de blog existante et fonctionnelle ne devrait pas être modifiée sans nécessité absolue.

Qu'est-ce qui est mieux pour une base de connaissances ? #

Ici aussi, la décision dépend de la structure technique et organisationnelle.

Si la base de connaissances fait partie intégrante du site web principal, il est par exemple possible de :

example.ch/aide/

Si, en revanche, un système de support entièrement autonome ou une application externe est utilisé, une structure telle que

support.example.ch

être techniquement plus judicieux.

Ce qui compte, ce n'est pas d'affirmer qu'une variante est fondamentalement plus performante en matière de référencement (SEO), mais de déterminer quelle architecture pour les contenus et le système est judicieuse à long terme.

Qu'est-ce qui est mieux pour une boutique en ligne ? #

Si la boutique et le site principal sont étroitement liés et utilisent le même système de gestion de contenu, un sous-répertoire peut s'avérer judicieux :

example.ch/shop/

En revanche, un système de boutique en ligne techniquement complètement séparé pourrait

shop.example.ch

être exploités.

Ici aussi, la décision doit être prise en fonction des exigences techniques, de la maintenabilité, de l'expérience utilisateur et de la structure des URL à long terme.

Qu'est-ce qui est mieux pour un espace client ? #

Pour un espace client, un sous-domaine est souvent une solution très judicieuse.

Par exemple :

my.example.ch

L'espace client peut ainsi être exploité techniquement indépendamment du site web public.

C'est particulièrement pratique lorsque différentes applications sont utilisées.

De plus, un portail client ne doit pas nécessairement répondre aux mêmes exigences en matière de référencement (SEO) que des pages d'information ou de produits indexables publiquement.

Qu'en est-il des liens internes ? #

Indépendamment de la structure choisie, le maillage interne doit être construit de manière judicieuse.

Un blog, un guide ou une section d'aide ne devrait pas exister de manière isolée si son contenu est pertinent pour les visiteurs du site principal.

Reliez entre eux les contenus thématiquement liés là où le lien aide réellement l'utilisateur.

Une navigation claire et une architecture de l'information sont plus importantes que d'essayer de générer des classements par la seule structure des URL.

Que deviennent les backlinks ? #

Les backlinks renvoient à des URL spécifiques.

Un lien externe vers

https://example.ch/blog/artikel

n'est par conséquent pas le même lien que celui sur

https://blog.example.ch/artikel/.

Lorsque des contenus existants sont déplacés d'une structure à une autre, les URL changent et les anciennes adresses doivent être redirigées en conséquence vers les nouvelles destinations.

Devrais-je passer d'un sous-domaine à un sous-dossier pour des raisons de SEO ? #

Pas seulement en raison de l'affirmation globale selon laquelle les sous-dossiers sont toujours meilleurs.

Un changement de

blog.example.ch

à

example.ch/blog/

modifie les URL de toute la zone.

Cela entraîne une migration de site web. Les URL existantes doivent être redirigées vers leurs nouvelles destinations et les liens internes, les balises canonical, les sitemaps ainsi que d'autres signaux techniques doivent être mis à jour en conséquence.

Une structure fonctionnelle et établie ne devrait donc pas être migrée sans raison technique, organisationnelle ou stratégique concrète.

Attention : Une migration d'URL motivée uniquement par un prétendu „ désavantage SEO des sous-domaines “ peut engendrer plus d'efforts et de risques que de bénéfices.

Quels sont les points à prendre en compte lors d'une migration ? #

Lorsqu'un contenu est déplacé d'un sous-domaine vers un sous-dossier ou dans la direction inverse, une nouvelle destination appropriée doit être définie pour chaque ancienne URL pertinente.

Par exemple :

blog.example.ch/artikel-a/
        ↓
example.ch/blog/artikel-a/

blog.example.ch/artikel-b/
        ↓
example.ch/blog/artikel-b/

Pour les contenus définitivement déplacés, des redirections permanentes côté serveur appropriées doivent être utilisées.

Les liens internes, les sitemaps XML et les balises canoniques doivent également correspondre à la nouvelle structure.

Qu'en est-il du contenu dupliqué ? #

Cela peut devenir problématique si des contenus identiques ou presque identiques restent accessibles simultanément sous plusieurs URL.

Par exemple :

blog.example.ch/ratgeber/
example.ch/blog/ratgeber/

Si les deux versions fournissent durablement le même contenu, il doit être clair pour les moteurs de recherche quelle URL est la version préférée ou canonique.

Lors d'une véritable migration, il est généralement plus propre de rediriger définitivement l'ancienne URL vers la nouvelle URL plutôt que d'exploiter indéfiniment les deux structures en parallèle avec un contenu identique.

Puis-je publier les mêmes contenus sur un sous-domaine et un sous-dossier ? #

C'est techniquement possible, mais généralement peu judicieux pour le même usage.

Plusieurs URL identiques n'améliorent pas automatiquement un contenu. Elles peuvent au contraire créer des doublons inutiles et compliquer l'analyse du site Web.

S'il n'y a pas de raison objective à l'existence de plusieurs versions, un contenu devrait posséder une URL principale claire.

Comment Google traite-t-il les URL canoniques ? #

Lorsque Google trouve plusieurs pages identiques ou très similaires, il les évalue ensemble pour la canonisation.

Les exploitants de sites Web peuvent, par exemple, avec des redirections, rel="canonical" et des indications cohérentes dans le sitemap pour indiquer l'URL privilégiée.

Cependant, Google peut finalement choisir une URL différente comme canonique si les signaux existants l'indiquent.

Une structure d'URL propre et cohérente est donc préférable à des signaux contradictoires entre plusieurs versions d'une même page.

Une sous-domaine a-t-elle besoin de ses propres enregistrements DNS ? #

Un sous-domaine doit pouvoir être résolu en conséquence via le DNS.

Pour cela, il est possible d'utiliser par exemple un enregistrement A, AAAA ou CNAME.

La variante correcte dépend de l'infrastructure cible souhaitée.

Avec le Vérification DNS CURIAWEB Pouvez-vous vérifier les informations DNS visibles publiquement ?.

Un sous-répertoire a-t-il besoin de son propre enregistrement DNS ? #

Non.

Un chemin d'URL tel que

example.ch/blog/

n'est pas géré via un enregistrement DNS propre.

Le DNS résout le nom d'hôte example.ch sur. Quel contenu ensuite sous /blog/ c'est le serveur web ou l'application qui y est exécutée qui décide ce qui est livré.

Est-ce qu'un sous-domaine a besoin d'un certificat SSL ? #

Si le sous-domaine doit être accessible via HTTPS, il doit être couvert par un certificat SSL/TLS valide.

Un certificat qui uniquement pour

example.ch

est valide, ne couvre pas automatiquement

blog.example.ch

ab.

Selon le certificat, plusieurs noms d'hôtes ou sous-domaines peuvent y être inclus. Des certificats génériques (wildcard) peuvent également être utilisés pour certaines configurations de sous-domaines.

Une sous-domaine peut-il avoir sa propre propriété Search Console ? #

Oui. Selon le type de propriété utilisé, les sous-domaines ou les préfixes d'URL peuvent être examinés séparément dans la Google Search Console.

Cela peut s'avérer utile dans le cas de zones plus vastes et techniquement séparées.

En revanche, une propriété de domaine peut regrouper des données provenant de différents protocoles et sous-domaines d'un domaine vérifié.

Est-ce que Google peut traiter différemment les sous-domaines et les sous-dossiers ? #

Oui, dans certaines fonctionnalités de Google, il existe des différences techniques entre les noms d'hôtes et les répertoires.

Par exemple, Google définit pour certaines fonctions de recherche un site web au niveau du nom d'hôte. Un sous-domaine peut donc y être traité séparément, tandis qu'un sous-dossier reste une composante du nom d'hôte existant.

Cela ne doit cependant pas être confondu avec une déclaration générale sur les classements.

Important : Les différences techniques en matière de noms d'hôtes, de fonctionnalités de recherche ou de propriétés ne prouvent pas que Google classe fondamentalement moins bien les contenus sur les sous-domaines.

Quelle variante est la plus facile à gérer ? #

Lorsque l'ensemble des contenus est géré par le même site web ou le même CMS, un sous-répertoire est souvent plus simple.

Il ne nécessite pas d'attribution DNS séparée pour la zone concernée et peut généralement être intégré immédiatement dans la navigation et la structure des URL.

En revanche, lorsque différentes applications, serveurs ou équipes sont impliqués, un sous-domaine peut permettre une séparation technique plus propre.

Quelle variante choisirions-nous pour le contenu normal d'un site web ? #

Pour les contenus qui font clairement partie du même site Web — par exemple un blog, un guide, une base de connaissances ou des informations sur les services — un sous-répertoire est souvent une solution logique et facile à maintenir.

En revanche, pour des systèmes techniquement autonomes tels que les portails clients, les applications web, les environnements de développement ou les pages de statut, un sous-domaine peut s'avérer plus judicieux.

Il s'agit d'une décision architecturale et non d'une règle SEO générale.

Quelles questions devrais-je clarifier avant de prendre une décision ? #

Au lieu de simplement demander „ Qu'est-ce qui est mieux pour le SEO ? “, tu devrais vérifier quel rôle la nouvelle section remplit réellement.

Le contenu relève-t-il, sur le plan technique et organisationnel, du site web principal ? Le même CMS est-il utilisé ? Cette section doit-elle utiliser la même navigation et le même parcours utilisateur ? Ou s'agit-il d'une application techniquement autonome qui doit être exploitée indépendamment ?

Plus une zone est liée au site Web principal, plus un sous-dossier peut être naturel. Plus l'indépendance technique est mise en avant, plus un sous-domaine peut s'avérer judicieux.

Résumé #

Les sous-domaines et les sous-répertoires sont deux manières différentes de structurer des contenus et des services sous un même domaine.

Un sous-répertoire tel que example.ch/blog/ reste une composante du même nom d'hôte. Un sous-domaine tel que blog.example.ch possède en revanche son propre nom d'hôte et peut techniquement fonctionner de manière indépendante sur une autre infrastructure.

En matière de référencement, il n'existe pas de règle générale sérieuse selon laquelle un sous-dossier serait automatiquement mieux positionné ou un sous-domaine serait fondamentalement moins bien classé.

Pour les contenus étroitement liés au site principal, tels qu'un blog, un guide ou une base de connaissances, un sous-dossier constitue souvent une structure simple et logique. Pour des applications techniquement indépendantes, telles que des portails clients ou des systèmes séparés, un sous-domaine peut représenter une meilleure architecture.

Si une structure fonctionnelle existe déjà, elle ne doit pas être modifiée uniquement en raison de prétendus avantages SEO. Un changement entre un sous-domaine et un sous-dossier modifie les URL et doit être traité comme une migration avec des redirections correctes et d'autres ajustements techniques.

Choisissez donc la structure en fonction du contenu, de la technique et de la maintenabilité à long terme, et non en raison du mythe selon lequel Google privilégierait fondamentalement l'une des deux variantes.