{"id":22789,"date":"2026-08-29T06:40:02","date_gmt":"2026-08-29T04:40:02","guid":{"rendered":"https:\/\/www.curiaweb.ch\/?post_type=docs&p=22789"},"modified":"2026-08-29T06:40:03","modified_gmt":"2026-08-29T04:40:03","password":"","slug":"sous-domaine-ou-sous-dossier-seo","status":"publish","type":"docs","link":"https:\/\/www.curiaweb.ch\/fr\/hilfe\/domains-dns\/subdomain-oder-unterverzeichnis-seo\/","title":{"rendered":"Sous-domaine ou sous-dossier : qu'est-ce qui est le mieux pour le SEO ?"},"content":{"rendered":"

Si tu veux cr\u00e9er 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\u00e9pertoire ?<\/p>\n\n\n\n

Les deux variantes sont techniquement possibles et peuvent \u00eatre index\u00e9es par les moteurs de recherche. La d\u00e9cision ne devrait donc pas reposer sur l'hypoth\u00e8se g\u00e9n\u00e9rale qu'un sous-domaine ou un sous-dossier se positionne fondamentalement mieux sur Google.<\/p>\n\n\n\n

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 \u00eatre exploit\u00e9e de mani\u00e8re consciemment ind\u00e9pendante.<\/p>\n\n\n\n

\n

En bref :<\/strong> Un sous-r\u00e9pertoire tel que example.ch\/blog\/<\/code> est une section au sein du m\u00eame site Web ou du m\u00eame nom d'h\u00f4te. Un sous-domaine tel que blog.example.ch<\/code> est en revanche un nom d'h\u00f4te distinct. En mati\u00e8re de r\u00e9f\u00e9rencement (SEO), il n'y a pas de r\u00e8gle simple \u201e sous-dossier bon, sous-domaine mauvais \u201c.<\/p>\n<\/blockquote>\n\n\n\n

Qu'est-ce qu'un sous-r\u00e9pertoire ?<\/h2>\n\n\n\n

Un sous-r\u00e9pertoire se trouve dans la structure d'URL d'un site Web existant.<\/p>\n\n\n\n

Exemples :<\/p>\n\n\n\n

https:\/\/example.ch\/blog\/\nhttps:\/\/example.ch\/hilfe\/\nhttps:\/\/example.ch\/shop\/<\/code><\/pre>\n\n\n\n
Le domaine principal ou le nom d'h\u00f4te reste le m\u00eame :<\/p>\n\n\n\n
example.ch<\/code><\/p>\n\n\n\n
Seul le chemin apr\u00e8s le nom de domaine change.<\/p>\n\n\n\n
Chez CURIAWEB, par exemple, la base de connaissances est \u00e9galement construite sur ce principe :<\/p>\n\n\n\n
\nhttps:\/\/www.curiaweb.ch\/hilfe\n<\/div><\/figure>\n\n\n\n
La base de connaissances fait ainsi partie int\u00e9grante du site Web existant et ne constitue pas un nom d'h\u00f4te distinct.<\/p>\n\n\n\n
Qu'est-ce qu'un sous-domaine ?<\/h2>\n\n\n\n
Un sous-domaine se place avant le nom de domaine principal.<\/p>\n\n\n\n
Exemples :<\/p>\n\n\n\n
blog.example.ch\nshop.example.ch\nsupport.example.ch\nmy.example.ch<\/code><\/pre>\n\n\n\n
Une sous-domaine est techniquement un nom d'h\u00f4te distinct et peut pointer vers une autre infrastructure ind\u00e9pendamment du site Web principal.<\/p>\n\n\n\n
Par exemple, peuvent<\/p>\n\n\n\n
example.ch\nshop.example.ch<\/code><\/pre>\n\n\n\n
\u00eatre h\u00e9berg\u00e9s sur des serveurs diff\u00e9rents.<\/p>\n\n\n\n
Quelle est la diff\u00e9rence technique ?<\/h2>\n\n\n\n
Dans le cas d'un sous-r\u00e9pertoire, le nom d'h\u00f4te reste le m\u00eame :<\/p>\n\n\n\n
example.ch\/blog\/\nexample.ch\/boutique\/\nexample.ch\/aide\/<\/code><\/pre>\n\n\n\n
En revanche, un sous-domaine cr\u00e9e un nom d'h\u00f4te suppl\u00e9mentaire :<\/p>\n\n\n\n
blog.example.ch\nshop.example.ch\nhilfe.example.ch<\/code><\/pre>\n\n\n\n
Cette distinction a des cons\u00e9quences techniques. Par exemple, un sous-domaine peut n\u00e9cessiter ses propres enregistrements DNS, sa propre configuration d'h\u00e9bergement et son propre certificat SSL\/TLS ou une couverture de certificat correspondante.<\/p>\n\n\n\n
Nous expliquons quel r\u00f4le jouent les enregistrements DNS \u00e0 ce sujet sous Enregistrements DNS expliqu\u00e9s : A, AAAA, CNAME, MX, TXT et CAA<\/a>.<\/p>\n\n\n\n
Est-ce qu'un sous-domaine est un domaine propre ?<\/h2>\n\n\n\n
Non.<\/p>\n\n\n\n
Chez<\/p>\n\n\n\n
blog.example.ch<\/code><\/p>\n\n\n\n
est example.ch<\/code> toujours le domaine enregistr\u00e9. blogue<\/code> est un sous-domaine ou un nom d'h\u00f4te configur\u00e9 en dessous.<\/p>\n\n\n\n
Par cons\u00e9quent, vous n'avez normalement pas besoin d'enregistrer un nouveau domaine pour chaque sous-domaine.<\/p>\n\n\n\n
Nous expliquons les diff\u00e9rences entre un domaine et une URL sous Site Web, Domaine et URL : quelle est la diff\u00e9rence ?<\/a>.<\/p>\n\n\n\n
Un sous-r\u00e9pertoire est-il meilleur pour le r\u00e9f\u00e9rencement naturel ?<\/h2>\n\n\n\n
Pas n\u00e9cessairement.<\/p>\n\n\n\n
Les sous-r\u00e9pertoires pr\u00e9sentent toutefois un avantage structurel important : ils permettent d'organiser tr\u00e8s facilement au sein d'une structure d'URL commune les contenus qui font clairement partie du m\u00eame site Web.<\/p>\n\n\n\n
Un blog d'entreprise pourrait par exemple se trouver sous<\/p>\n\n\n\n
example.ch\/blog\/<\/code><\/p>\n\n\n\n
se trouvent et la base de connaissances sous<\/p>\n\n\n\n
example.ch\/aide\/<\/code>.<\/p>\n\n\n\n
Cela permet aux utilisateurs de voir imm\u00e9diatement que ces contenus font partie du site principal.<\/p>\n\n\n\n
Cependant, cela ne garantit pas \u00e0 lui seul de meilleurs classements. La qualit\u00e9 du contenu, l'intention de recherche, le maillage interne, la crawlabilit\u00e9, la qualit\u00e9 technique et bien d'autres facteurs restent d\u00e9terminants.<\/p>\n\n\n\n
\n
Important :<\/strong> Un sous-r\u00e9pertoire n'obtient pas automatiquement de bons classements simplement parce que le domaine principal est d\u00e9j\u00e0 \u00e9tabli. Le contenu d'un sous-r\u00e9pertoire doit \u00e9galement \u00eatre pertinent, explorable et d'une qualit\u00e9 convaincante.<\/p>\n<\/blockquote>\n\n\n\n
Un sous-domaine est-il mauvais pour le r\u00e9f\u00e9rencement naturel (SEO) ?<\/h2>\n\n\n\n
Non.<\/p>\n\n\n\n
Les sous-domaines peuvent \u00eatre explor\u00e9s et index\u00e9s par les moteurs de recherche et peuvent \u00e9galement obtenir de bons classements.<\/p>\n\n\n\n
Une sous-domaine n'est donc pas automatiquement une erreur SEO.<\/p>\n\n\n\n
Ce qui importe bien davantage, c'est de savoir si la structure choisie a du sens pour la section concern\u00e9e du site web et si elle est mise en \u0153uvre techniquement de mani\u00e8re propre.<\/p>\n\n\n\n
Est-ce que Google traite un sous-domaine comme un site web distinct ?<\/h2>\n\n\n\n
Une affirmation globale telle que \u201e Google traite chaque sous-domaine enti\u00e8rement comme un site web tiers \u201c est trop simpliste.<\/p>\n\n\n\n
Techniquement, il s'agit d'un nom d'h\u00f4te distinct pour un sous-domaine. Google fait \u00e9galement la distinction entre les domaines, les sous-domaines et les r\u00e9pertoires dans ses diff\u00e9rentes fonctions et syst\u00e8mes.<\/p>\n\n\n\n
Cependant, cela ne signifie pas que cela entra\u00eene automatiquement un d\u00e9savantage g\u00e9n\u00e9ral en mati\u00e8re de r\u00e9f\u00e9rencement.<\/p>\n\n\n\n
\n
Remarque :<\/strong> \u201e Nom d'h\u00f4te propre \u201c et \u201e moins bons classements \u201c sont deux affirmations totalement diff\u00e9rentes. De l'ind\u00e9pendance technique d'un sous-domaine, il n'est pas possible de d\u00e9duire un d\u00e9savantage automatique en mati\u00e8re de classement.<\/p>\n<\/blockquote>\n\n\n\n
Quand un sous-r\u00e9pertoire est-il judicieux ?<\/h2>\n\n\n\n
Un sous-r\u00e9pertoire s'av\u00e8re souvent judicieux lorsque la nouvelle section fait clairement partie du site Web existant.<\/p>\n\n\n\n
Des exemples typiques sont :<\/p>\n\n\n\n
example.ch\/blog\/\nexample.ch\/conseils\/\nexample.ch\/aide\/\nexample.ch\/references\/\nexample.ch\/produits\/<\/code><\/pre>\n\n\n\n
Les contenus peuvent ainsi \u00eatre int\u00e9gr\u00e9s dans une navigation commune, un maillage interne et une architecture de l'information.<\/p>\n\n\n\n
Pour un blog d'entreprise ou une base de connaissances, un sous-r\u00e9pertoire est donc souvent une solution tr\u00e8s naturelle.<\/p>\n\n\n\n
Quand est-ce qu'un sous-domaine est utile ?<\/h2>\n\n\n\n
Un sous-domaine peut \u00eatre utile si une section doit \u00eatre techniquement ou fonctionnellement clairement s\u00e9par\u00e9e du site principal.<\/p>\n\n\n\n
Des exemples peuvent \u00eatre :<\/p>\n\n\n\n
my.example.ch\napp.example.ch\nstatus.example.ch\ndev.example.ch<\/code><\/pre>\n\n\n\n
Un portail client, une application web ou un syst\u00e8me de suivi de l'\u00e9tat peuvent par exemple utiliser un logiciel et une infrastructure totalement diff\u00e9rents de ceux du site Web public de l'entreprise.<\/p>\n\n\n\n
Dans de tels cas, la s\u00e9paration technique peut \u00eatre plus importante que le d\u00e9sir de faire fonctionner l'ensemble des contenus sous un chemin de r\u00e9pertoire commun.<\/p>\n\n\n\n
Un sous-domaine peut-il se trouver sur un autre serveur ?<\/h2>\n\n\n\n
Oui.<\/p>\n\n\n\n
C'est l'un des grands avantages techniques des sous-domaines.<\/p>\n\n\n\n
Le domaine principal peut par exemple pointer vers un serveur web :<\/p>\n\n\n\n
example.ch<\/code><\/p>\n\n\n\n
pendant<\/p>\n\n\n\n
app.example.ch<\/code><\/p>\n\n\n\n
pointe vers une autre infrastructure via son propre enregistrement DNS.<\/p>\n\n\n\n
Cela permet une s\u00e9paration claire des diff\u00e9rentes applications et syst\u00e8mes.<\/p>\n\n\n\n
Un sous-r\u00e9pertoire peut-il se trouver sur un autre serveur ?<\/h2>\n\n\n\n
C'est \u00e9galement possible techniquement, mais c'est g\u00e9n\u00e9ralement plus complexe.<\/p>\n\n\n\n
Au revoir<\/p>\n\n\n\n
example.ch\/app\/<\/code><\/p>\n\n\n\n
le m\u00eame nom d'h\u00f4te est utilis\u00e9 que pour le site Web principal, la s\u00e9paration ne s'effectue pas simplement via un enregistrement DNS distinct pour le r\u00e9pertoire.<\/p>\n\n\n\n
Des r\u00e8gles correspondantes de proxy inverse, de serveur Web ou d'application seraient par exemple n\u00e9cessaires \u00e0 la place.<\/p>\n\n\n\n
Le DNS fonctionne avec des noms d'h\u00f4tes et non avec des chemins d'URL comme \/app\/<\/code>.<\/p>\n\n\n\n
\n
En bref :<\/strong> DNS peut app.example.ch<\/code> taxer s\u00e9par\u00e9ment, mais pas directement example.ch\/app\/<\/code>. Le chemin n'intervient qu'apr\u00e8s la connexion au serveur web.<\/p>\n<\/blockquote>\n\n\n\n
Qu'est-ce qui est mieux pour un blog ?<\/h2>\n\n\n\n
Si le blog fait partie int\u00e9grante du site web de l'entreprise, un sous-r\u00e9pertoire constitue souvent la structure la plus simple et la plus logique :<\/p>\n\n\n\n
example.ch\/blog\/<\/code><\/p>\n\n\n\n
Le blog peut ainsi \u00eatre int\u00e9gr\u00e9 directement dans la navigation, le maillage interne et le reste de la structure du site web.<\/p>\n\n\n\n
Une sous-domaine telle que<\/p>\n\n\n\n
blog.example.ch<\/code><\/p>\n\n\n\n
peut n\u00e9anmoins s'av\u00e9rer judicieux si des raisons techniques ou organisationnelles plaident en faveur d'une s\u00e9paration.<\/p>\n\n\n\n
Seuleument pour des raisons de r\u00e9f\u00e9rencement, une structure de blog existante et fonctionnelle ne devrait pas \u00eatre modifi\u00e9e sans n\u00e9cessit\u00e9 absolue.<\/p>\n\n\n\n
Qu'est-ce qui est mieux pour une base de connaissances ?<\/h2>\n\n\n\n
Ici aussi, la d\u00e9cision d\u00e9pend de la structure technique et organisationnelle.<\/p>\n\n\n\n
Si la base de connaissances fait partie int\u00e9grante du site web principal, il est par exemple possible de :<\/p>\n\n\n\n
example.ch\/aide\/<\/code><\/p>\n\n\n\n
Si, en revanche, un syst\u00e8me de support enti\u00e8rement autonome ou une application externe est utilis\u00e9, une structure telle que<\/p>\n\n\n\n
support.example.ch<\/code><\/p>\n\n\n\n
\u00eatre techniquement plus judicieux.<\/p>\n\n\n\n
Ce qui compte, ce n'est pas d'affirmer qu'une variante est fondamentalement plus performante en mati\u00e8re de r\u00e9f\u00e9rencement (SEO), mais de d\u00e9terminer quelle architecture pour les contenus et le syst\u00e8me est judicieuse \u00e0 long terme.<\/p>\n\n\n\n
Qu'est-ce qui est mieux pour une boutique en ligne ?<\/h2>\n\n\n\n
Si la boutique et le site principal sont \u00e9troitement li\u00e9s et utilisent le m\u00eame syst\u00e8me de gestion de contenu, un sous-r\u00e9pertoire peut s'av\u00e9rer judicieux :<\/p>\n\n\n\n
example.ch\/shop\/<\/code><\/p>\n\n\n\n
En revanche, un syst\u00e8me de boutique en ligne techniquement compl\u00e8tement s\u00e9par\u00e9 pourrait<\/p>\n\n\n\n
shop.example.ch<\/code><\/p>\n\n\n\n
\u00eatre exploit\u00e9s.<\/p>\n\n\n\n
Ici aussi, la d\u00e9cision doit \u00eatre prise en fonction des exigences techniques, de la maintenabilit\u00e9, de l'exp\u00e9rience utilisateur et de la structure des URL \u00e0 long terme.<\/p>\n\n\n\n
Qu'est-ce qui est mieux pour un espace client ?<\/h2>\n\n\n\n
Pour un espace client, un sous-domaine est souvent une solution tr\u00e8s judicieuse.<\/p>\n\n\n\n
Par exemple :<\/p>\n\n\n\n
my.example.ch<\/code><\/p>\n\n\n\n
L'espace client peut ainsi \u00eatre exploit\u00e9 techniquement ind\u00e9pendamment du site web public.<\/p>\n\n\n\n
C'est particuli\u00e8rement pratique lorsque diff\u00e9rentes applications sont utilis\u00e9es.<\/p>\n\n\n\n
De plus, un portail client ne doit pas n\u00e9cessairement r\u00e9pondre aux m\u00eames exigences en mati\u00e8re de r\u00e9f\u00e9rencement (SEO) que des pages d'information ou de produits indexables publiquement.<\/p>\n\n\n\n
Qu'en est-il des liens internes ?<\/h2>\n\n\n\n
Ind\u00e9pendamment de la structure choisie, le maillage interne doit \u00eatre construit de mani\u00e8re judicieuse.<\/p>\n\n\n\n
Un blog, un guide ou une section d'aide ne devrait pas exister de mani\u00e8re isol\u00e9e si son contenu est pertinent pour les visiteurs du site principal.<\/p>\n\n\n\n
Reliez entre eux les contenus th\u00e9matiquement li\u00e9s l\u00e0 o\u00f9 le lien aide r\u00e9ellement l'utilisateur.<\/p>\n\n\n\n
Une navigation claire et une architecture de l'information sont plus importantes que d'essayer de g\u00e9n\u00e9rer des classements par la seule structure des URL.<\/p>\n\n\n\n
Que deviennent les backlinks ?<\/h2>\n\n\n\n
Les backlinks renvoient \u00e0 des URL sp\u00e9cifiques.<\/p>\n\n\n\n
Un lien externe vers<\/p>\n\n\n\n
\nhttps:\/\/example.ch\/blog\/artikel\n<\/div><\/figure>\n\n\n\n
n'est par cons\u00e9quent pas le m\u00eame lien que celui sur<\/p>\n\n\n\n
\nhttps:\/\/blog.example.ch\/artikel\/.\n<\/div><\/figure>\n\n\n\n
Lorsque des contenus existants sont d\u00e9plac\u00e9s d'une structure \u00e0 une autre, les URL changent et les anciennes adresses doivent \u00eatre redirig\u00e9es en cons\u00e9quence vers les nouvelles destinations.<\/p>\n\n\n\n
Devrais-je passer d'un sous-domaine \u00e0 un sous-dossier pour des raisons de SEO ?<\/h2>\n\n\n\n
Pas seulement en raison de l'affirmation globale selon laquelle les sous-dossiers sont toujours meilleurs.<\/p>\n\n\n\n
Un changement de<\/p>\n\n\n\n
blog.example.ch<\/code><\/p>\n\n\n\n
\u00e0<\/p>\n\n\n\n
example.ch\/blog\/<\/code><\/p>\n\n\n\n
modifie les URL de toute la zone.<\/p>\n\n\n\n
Cela entra\u00eene une migration de site web. Les URL existantes doivent \u00eatre redirig\u00e9es vers leurs nouvelles destinations et les liens internes, les balises canonical, les sitemaps ainsi que d'autres signaux techniques doivent \u00eatre mis \u00e0 jour en cons\u00e9quence.<\/p>\n\n\n\n
Une structure fonctionnelle et \u00e9tablie ne devrait donc pas \u00eatre migr\u00e9e sans raison technique, organisationnelle ou strat\u00e9gique concr\u00e8te.<\/p>\n\n\n\n
\n
Attention :<\/strong> Une migration d'URL motiv\u00e9e uniquement par un pr\u00e9tendu \u201e d\u00e9savantage SEO des sous-domaines \u201c peut engendrer plus d'efforts et de risques que de b\u00e9n\u00e9fices.<\/p>\n<\/blockquote>\n\n\n\n
Quels sont les points \u00e0 prendre en compte lors d'une migration ?<\/h2>\n\n\n\n
Lorsqu'un contenu est d\u00e9plac\u00e9 d'un sous-domaine vers un sous-dossier ou dans la direction inverse, une nouvelle destination appropri\u00e9e doit \u00eatre d\u00e9finie pour chaque ancienne URL pertinente.<\/p>\n\n\n\n
Par exemple :<\/p>\n\n\n\n
blog.example.ch\/artikel-a\/\n        \u2193\nexample.ch\/blog\/artikel-a\/\n\nblog.example.ch\/artikel-b\/\n        \u2193\nexample.ch\/blog\/artikel-b\/<\/code><\/pre>\n\n\n\n
Pour les contenus d\u00e9finitivement d\u00e9plac\u00e9s, des redirections permanentes c\u00f4t\u00e9 serveur appropri\u00e9es doivent \u00eatre utilis\u00e9es.<\/p>\n\n\n\n
Les liens internes, les sitemaps XML et les balises canoniques doivent \u00e9galement correspondre \u00e0 la nouvelle structure.<\/p>\n\n\n\n
Qu'en est-il du contenu dupliqu\u00e9 ?<\/h2>\n\n\n\n
Cela peut devenir probl\u00e9matique si des contenus identiques ou presque identiques restent accessibles simultan\u00e9ment sous plusieurs URL.<\/p>\n\n\n\n
Par exemple :<\/p>\n\n\n\n
blog.example.ch\/ratgeber\/\nexample.ch\/blog\/ratgeber\/<\/code><\/pre>\n\n\n\n
Si les deux versions fournissent durablement le m\u00eame contenu, il doit \u00eatre clair pour les moteurs de recherche quelle URL est la version pr\u00e9f\u00e9r\u00e9e ou canonique.<\/p>\n\n\n\n
Lors d'une v\u00e9ritable migration, il est g\u00e9n\u00e9ralement plus propre de rediriger d\u00e9finitivement l'ancienne URL vers la nouvelle URL plut\u00f4t que d'exploiter ind\u00e9finiment les deux structures en parall\u00e8le avec un contenu identique.<\/p>\n\n\n\n
Puis-je publier les m\u00eames contenus sur un sous-domaine et un sous-dossier ?<\/h2>\n\n\n\n
C'est techniquement possible, mais g\u00e9n\u00e9ralement peu judicieux pour le m\u00eame usage.<\/p>\n\n\n\n
Plusieurs URL identiques n'am\u00e9liorent pas automatiquement un contenu. Elles peuvent au contraire cr\u00e9er des doublons inutiles et compliquer l'analyse du site Web.<\/p>\n\n\n\n
S'il n'y a pas de raison objective \u00e0 l'existence de plusieurs versions, un contenu devrait poss\u00e9der une URL principale claire.<\/p>\n\n\n\n
Comment Google traite-t-il les URL canoniques ?<\/h2>\n\n\n\n
Lorsque Google trouve plusieurs pages identiques ou tr\u00e8s similaires, il les \u00e9value ensemble pour la canonisation.<\/p>\n\n\n\n
Les exploitants de sites Web peuvent, par exemple, avec des redirections, rel=\"canonical\"<\/code> et des indications coh\u00e9rentes dans le sitemap pour indiquer l'URL privil\u00e9gi\u00e9e.<\/p>\n\n\n\n
Cependant, Google peut finalement choisir une URL diff\u00e9rente comme canonique si les signaux existants l'indiquent.<\/p>\n\n\n\n
Une structure d'URL propre et coh\u00e9rente est donc pr\u00e9f\u00e9rable \u00e0 des signaux contradictoires entre plusieurs versions d'une m\u00eame page.<\/p>\n\n\n\n
Une sous-domaine a-t-elle besoin de ses propres enregistrements DNS ?<\/h2>\n\n\n\n
Un sous-domaine doit pouvoir \u00eatre r\u00e9solu en cons\u00e9quence via le DNS.<\/p>\n\n\n\n
Pour cela, il est possible d'utiliser par exemple un enregistrement A, AAAA ou CNAME.<\/p>\n\n\n\n
La variante correcte d\u00e9pend de l'infrastructure cible souhait\u00e9e.<\/p>\n\n\n\n
Avec le V\u00e9rification DNS CURIAWEB<\/a> Pouvez-vous v\u00e9rifier les informations DNS visibles publiquement ?.<\/p>\n\n\n\n
Un sous-r\u00e9pertoire a-t-il besoin de son propre enregistrement DNS ?<\/h2>\n\n\n\n
Non.<\/p>\n\n\n\n
Un chemin d'URL tel que<\/p>\n\n\n\n
example.ch\/blog\/<\/code><\/p>\n\n\n\n
n'est pas g\u00e9r\u00e9 via un enregistrement DNS propre.<\/p>\n\n\n\n
Le DNS r\u00e9sout le nom d'h\u00f4te example.ch<\/code> sur. Quel contenu ensuite sous \/blog\/<\/code> c'est le serveur web ou l'application qui y est ex\u00e9cut\u00e9e qui d\u00e9cide ce qui est livr\u00e9.<\/p>\n\n\n\n
Est-ce qu'un sous-domaine a besoin d'un certificat SSL ?<\/h2>\n\n\n\n
Si le sous-domaine doit \u00eatre accessible via HTTPS, il doit \u00eatre couvert par un certificat SSL\/TLS valide.<\/p>\n\n\n\n
Un certificat qui uniquement pour<\/p>\n\n\n\n
example.ch<\/code><\/p>\n\n\n\n
est valide, ne couvre pas automatiquement<\/p>\n\n\n\n
blog.example.ch<\/code><\/p>\n\n\n\n
ab.<\/p>\n\n\n\n
Selon le certificat, plusieurs noms d'h\u00f4tes ou sous-domaines peuvent y \u00eatre inclus. Des certificats g\u00e9n\u00e9riques (wildcard) peuvent \u00e9galement \u00eatre utilis\u00e9s pour certaines configurations de sous-domaines.<\/p>\n\n\n\n
Une sous-domaine peut-il avoir sa propre propri\u00e9t\u00e9 Search Console ?<\/h2>\n\n\n\n
Oui. Selon le type de propri\u00e9t\u00e9 utilis\u00e9, les sous-domaines ou les pr\u00e9fixes d'URL peuvent \u00eatre examin\u00e9s s\u00e9par\u00e9ment dans la Google Search Console.<\/p>\n\n\n\n
Cela peut s'av\u00e9rer utile dans le cas de zones plus vastes et techniquement s\u00e9par\u00e9es.<\/p>\n\n\n\n
En revanche, une propri\u00e9t\u00e9 de domaine peut regrouper des donn\u00e9es provenant de diff\u00e9rents protocoles et sous-domaines d'un domaine v\u00e9rifi\u00e9.<\/p>\n\n\n\n
Est-ce que Google peut traiter diff\u00e9remment les sous-domaines et les sous-dossiers ?<\/h2>\n\n\n\n
Oui, dans certaines fonctionnalit\u00e9s de Google, il existe des diff\u00e9rences techniques entre les noms d'h\u00f4tes et les r\u00e9pertoires.<\/p>\n\n\n\n
Par exemple, Google d\u00e9finit pour certaines fonctions de recherche un site web au niveau du nom d'h\u00f4te. Un sous-domaine peut donc y \u00eatre trait\u00e9 s\u00e9par\u00e9ment, tandis qu'un sous-dossier reste une composante du nom d'h\u00f4te existant.<\/p>\n\n\n\n
Cela ne doit cependant pas \u00eatre confondu avec une d\u00e9claration g\u00e9n\u00e9rale sur les classements.<\/p>\n\n\n\n
\n
Important :<\/strong> Les diff\u00e9rences techniques en mati\u00e8re de noms d'h\u00f4tes, de fonctionnalit\u00e9s de recherche ou de propri\u00e9t\u00e9s ne prouvent pas que Google classe fondamentalement moins bien les contenus sur les sous-domaines.<\/p>\n<\/blockquote>\n\n\n\n
Quelle variante est la plus facile \u00e0 g\u00e9rer ?<\/h2>\n\n\n\n
Lorsque l'ensemble des contenus est g\u00e9r\u00e9 par le m\u00eame site web ou le m\u00eame CMS, un sous-r\u00e9pertoire est souvent plus simple.<\/p>\n\n\n\n
Il ne n\u00e9cessite pas d'attribution DNS s\u00e9par\u00e9e pour la zone concern\u00e9e et peut g\u00e9n\u00e9ralement \u00eatre int\u00e9gr\u00e9 imm\u00e9diatement dans la navigation et la structure des URL.<\/p>\n\n\n\n
En revanche, lorsque diff\u00e9rentes applications, serveurs ou \u00e9quipes sont impliqu\u00e9s, un sous-domaine peut permettre une s\u00e9paration technique plus propre.<\/p>\n\n\n\n
Quelle variante choisirions-nous pour le contenu normal d'un site web ?<\/h2>\n\n\n\n
Pour les contenus qui font clairement partie du m\u00eame site Web \u2014 par exemple un blog, un guide, une base de connaissances ou des informations sur les services \u2014 un sous-r\u00e9pertoire est souvent une solution logique et facile \u00e0 maintenir.<\/p>\n\n\n\n
En revanche, pour des syst\u00e8mes techniquement autonomes tels que les portails clients, les applications web, les environnements de d\u00e9veloppement ou les pages de statut, un sous-domaine peut s'av\u00e9rer plus judicieux.<\/p>\n\n\n\n
Il s'agit d'une d\u00e9cision architecturale et non d'une r\u00e8gle SEO g\u00e9n\u00e9rale.<\/p>\n\n\n\n
Quelles questions devrais-je clarifier avant de prendre une d\u00e9cision ?<\/h2>\n\n\n\n
Au lieu de simplement demander \u201e Qu'est-ce qui est mieux pour le SEO ? \u201c, tu devrais v\u00e9rifier quel r\u00f4le la nouvelle section remplit r\u00e9ellement.<\/p>\n\n\n\n
Le contenu rel\u00e8ve-t-il, sur le plan technique et organisationnel, du site web principal ? Le m\u00eame CMS est-il utilis\u00e9 ? Cette section doit-elle utiliser la m\u00eame navigation et le m\u00eame parcours utilisateur ? Ou s'agit-il d'une application techniquement autonome qui doit \u00eatre exploit\u00e9e ind\u00e9pendamment ?<\/p>\n\n\n\n
Plus une zone est li\u00e9e au site Web principal, plus un sous-dossier peut \u00eatre naturel. Plus l'ind\u00e9pendance technique est mise en avant, plus un sous-domaine peut s'av\u00e9rer judicieux.<\/p>\n\n\n\n
R\u00e9sum\u00e9<\/h2>\n\n\n\n
Les sous-domaines et les sous-r\u00e9pertoires sont deux mani\u00e8res diff\u00e9rentes de structurer des contenus et des services sous un m\u00eame domaine.<\/p>\n\n\n\n
Un sous-r\u00e9pertoire tel que example.ch\/blog\/<\/code> reste une composante du m\u00eame nom d'h\u00f4te. Un sous-domaine tel que blog.example.ch<\/code> poss\u00e8de en revanche son propre nom d'h\u00f4te et peut techniquement fonctionner de mani\u00e8re ind\u00e9pendante sur une autre infrastructure.<\/p>\n\n\n\n
En mati\u00e8re de r\u00e9f\u00e9rencement, il n'existe pas de r\u00e8gle g\u00e9n\u00e9rale s\u00e9rieuse selon laquelle un sous-dossier serait automatiquement mieux positionn\u00e9 ou un sous-domaine serait fondamentalement moins bien class\u00e9.<\/p>\n\n\n\n
Pour les contenus \u00e9troitement li\u00e9s 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\u00e9pendantes, telles que des portails clients ou des syst\u00e8mes s\u00e9par\u00e9s, un sous-domaine peut repr\u00e9senter une meilleure architecture.<\/p>\n\n\n\n
Si une structure fonctionnelle existe d\u00e9j\u00e0, elle ne doit pas \u00eatre modifi\u00e9e uniquement en raison de pr\u00e9tendus avantages SEO. Un changement entre un sous-domaine et un sous-dossier modifie les URL et doit \u00eatre trait\u00e9 comme une migration avec des redirections correctes et d'autres ajustements techniques.<\/p>\n\n\n\n
Choisissez donc la structure en fonction du contenu, de la technique et de la maintenabilit\u00e9 \u00e0 long terme, et non en raison du mythe selon lequel Google privil\u00e9gierait fondamentalement l'une des deux variantes.<\/strong><\/p>","protected":false},"excerpt":{"rendered":"
Wenn du einen neuen Bereich deiner Website aufbauen m\u00f6chtest, stellt sich h\u00e4ufig die Frage: Soll der Inhalt unter einer Subdomain oder in einem Unterverzeichnis liegen? Beide Varianten sind technisch m\u00f6glich und k\u00f6nnen von Suchmaschinen indexiert werden. Die Entscheidung sollte deshalb nicht auf der pauschalen Annahme beruhen, dass eine Subdomain oder ein Unterverzeichnis grunds\u00e4tzlich besser bei […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_joinchat":[],"footnotes":""},"doc_category":[82],"doc_tag":[],"class_list":["post-22789","docs","type-docs","status-publish","hentry","doc_category-domains-dns"],"year_month":"2026-09","word_count":2457,"total_views":"6","reactions":{"happy":"0","normal":"0","sad":"0"},"author_info":{"name":"Silvio Mazenauer","author_nicename":"admin-curia","author_url":"https:\/\/www.curiaweb.ch\/fr\/author\/admin-curia\/"},"doc_category_info":[{"term_name":"Domains & DNS","term_url":"https:\/\/www.curiaweb.ch\/fr\/hilfe-kategorie\/domains-dns\/"}],"doc_tag_info":[],"knowledge_base_info":[],"knowledge_base_slug":[],"_links":{"self":[{"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/docs\/22789","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/types\/docs"}],"author":[{"embeddable":true,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/comments?post=22789"}],"version-history":[{"count":1,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/docs\/22789\/revisions"}],"predecessor-version":[{"id":22791,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/docs\/22789\/revisions\/22791"}],"wp:attachment":[{"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/media?parent=22789"}],"wp:term":[{"taxonomy":"doc_category","embeddable":true,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/doc_category?post=22789"},{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/doc_tag?post=22789"}],"curies":[{"name":"Bien jou\u00e9","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}