Sous-domaine ou nouveau domaine : les trois options pour un second site
Le choix entre un sous-domaine ou un nouveau domaine se pose dès qu’un second contenu s’ajoute au site principal : un blog, une boutique, un espace client, une version anglaise, une marque secondaire. Il existe en réalité trois options, et la première est souvent oubliée.
- Le sous-répertoire :
www.entreprise.fr/blog/. Le contenu vit dans un dossier du site existant. Même domaine, même certificat, même installation. - Le sous-domaine :
blog.entreprise.fr. Un nom placé sous votre domaine, gratuit, avec son propre dossier, ses propres enregistrements DNS et, si besoin, sa propre installation et sa propre version PHP. - Le nouveau domaine :
autre-marque.fr. Un nom distinct, enregistré et renouvelé séparément, qui ne porte rien de l’historique du premier.
Les trois sont possibles sur un même hébergement mutualisé. Le guide Héberger plusieurs sites sur un seul hébergement explique ce que partagent les sites d’un même abonnement Plesk. Ce guide traite la question d’avant : quelle adresse donner au second site.
Sous-domaine ou sous-répertoire : ce que dit Google sur le SEO
Les faits vérifiables d’abord : dans sa documentation sur les sites multirégionaux, Google Search Central présente sous-domaines et sous-répertoires comme deux structures d’URL acceptables pour des versions distinctes d’un site, à côté des domaines nationaux. Google explore et indexe un sous-domaine comme une partie du même site, pas comme un site étranger.
La documentation ne dit pas que les deux structures se valent dans tous les cas. L’expérience des référenceurs, prudente et non chiffrée :
- un sous-répertoire profite directement de l’historique, des liens entrants et de la navigation du site principal : un article dans
/blog/est lié depuis le menu, le pied de page, les pages voisines ; - un sous-domaine est rattaché au même domaine, mais il a sa propre page d’accueil et ses propres liens internes ; il reçoit moins naturellement les liens du site principal, sauf si vous les créez ;
- un nouveau domaine repart de zéro : aucun historique, aucun lien.
La différence vient donc du maillage, pas d’un traitement de faveur. Aucune structure ne garantit un classement ; seuls le contenu et les liens le font.
Blog en sous-domaine ou dans un dossier : la règle pratique
Si le contenu sert le même public et la même marque, mettez-le dans un dossier. Si c’est un produit à part, avec sa propre équipe, sa propre technique ou son propre public, le sous-domaine est défendable.
Marque et lisibilité : ce que lit un client
Un client lit une adresse et se demande si elle appartient bien à vous.
- Le sous-répertoire est le plus rassurant :
www.entreprise.fr/boutique/dit clairement que la boutique est celle de l’entreprise. - Le sous-domaine reste lisible avec un mot court et attendu :
boutique.,blog.,app.,compte.. Il est courant pour les espaces connectés, où l’utilisateur comprend qu’il quitte la vitrine pour entrer dans l’outil. - Le nouveau domaine est le seul choix cohérent quand la marque est différente : activité secondaire sous un autre nom, filiale, produit vendu à un autre public. Le guide Nom de domaine .fr ou .com détaille l’éligibilité AFNIC, la vérification de marque à l’INPI et le choix de l’extension.
Piège courant : un domaine par campagne ou par produit, et trois ans plus tard dix noms renouvelés dont la moitié ne servent plus. Règle simple : un domaine par marque, des sous-domaines ou des dossiers pour tout le reste.
Et le sous-domaine www ?
www.entreprise.fr est lui-même un sous-domaine de entreprise.fr. Choisissez une seule forme canonique, avec ou sans www, et redirigez l’autre en 301. Un second site en sous-domaine ne reçoit pas de www : www.blog.entreprise.fr n’a aucun intérêt et finit sans certificat valide.
E-mail : un sous-domaine peut avoir ses propres MX, SPF et DKIM
Un sous-domaine est un nom DNS complet : il peut recevoir ses propres enregistrements MX, donc des adresses du type contact@boutique.entreprise.fr, avec un SPF et un DKIM distincts de ceux du domaine principal. Un sous-répertoire n’existe pas pour le courrier : l’e-mail de www.entreprise.fr/boutique/ est celui d’entreprise.fr.
Deux usages concrets :
- séparer les envois automatiques : notifications, factures et relances de panier partent depuis
notifications.entreprise.fravec leur propre SPF et leur propre clé DKIM, ce qui isole leur réputation de celle des adresses humaines ; - confier un outil à un prestataire : un service d’e-mailing gère un sous-domaine réservé, sans toucher la zone d’
entreprise.fr.
À l’inverse, un nouveau domaine oblige à recréer toute la chaîne (boîtes, MX, SPF, DKIM, DMARC) et à attendre que les destinataires lui fassent confiance : un domaine neuf qui envoie des campagnes dès la première semaine finit souvent en indésirables. Le guide SPF, DKIM et DMARC donne la méthode, valable pour un domaine comme pour un sous-domaine.
Certificats SSL : un certificat par sous-domaine ou un wildcard
Chaque nom servi en HTTPS doit être couvert par un certificat :
- Sous-répertoire : rien à faire, le certificat du site principal couvre tout ce qui se trouve sous
www.entreprise.fr. - Sous-domaine : il faut un certificat qui nomme
blog.entreprise.fr. Plesk émet un Let’s Encrypt gratuit par sous-domaine et le renouvelle tous les 90 jours, à condition que le DNS pointe déjà vers le serveur. - Nouveau domaine : un certificat par domaine, Let’s Encrypt ou payant.
Quand le wildcard devient utile
Un certificat wildcard couvre *.entreprise.fr, c’est-à-dire tous les sous-domaines de premier niveau. Il devient pertinent à partir de plusieurs sous-domaines, ou quand ils sont créés à la volée (un sous-domaine par client d’une application). Let’s Encrypt délivre des wildcards uniquement par la validation DNS-01 : un enregistrement TXT _acme-challenge à publier dans la zone à chaque renouvellement. Plesk automatise cet échange quand la zone DNS est hébergée sur le même serveur ; sinon, le renouvellement demande une intervention. Un certificat SSL wildcard payant, valable un an, évite cette contrainte.
Le guide Let’s Encrypt ou certificat SSL payant compare les deux familles. En résumé : jusqu’à trois sous-domaines, un Let’s Encrypt par nom ; au-delà, un wildcard.
Isolation technique et coûts : ce que change chaque option
Dans Plesk, sous-domaine et domaine additionnel sont des objets très proches. Chacun peut avoir :
- son propre dossier racine, séparé de
httpdocs; - sa propre version de PHP et ses propres limites (
memory_limit,upload_max_filesize) ; - son propre certificat, ses journaux d’accès et d’erreurs, ses tâches planifiées ;
- un accès FTP additionnel limité à son dossier, pour confier le blog à une agence sans ouvrir le site principal.
Un sous-répertoire n’offre rien de tout cela : il partage installation, PHP, journaux et accès. C’est sa force (une seule chose à maintenir) et sa limite (une mise à jour ratée touche tout).
Ce que le sous-domaine n’isole pas : les ressources. Tous les sites d’un abonnement, sous-domaines compris, partagent les limites CloudLinux et l’espace disque de la formule. Si le second site doit être protégé du premier, il lui faut son propre abonnement, par exemple un second hébergement web.
Les coûts, poste par poste
- Sous-répertoire : aucun coût supplémentaire.
- Sous-domaine : gratuit et sans limite pratique dans Plesk, Let’s Encrypt inclus. Seul coût éventuel : un wildcard payant, à partir de 24,90 € HT par an.
- Nouveau domaine : un nom de domaine .fr commence à 9,90 € HT par an, puis se renouvelle chaque année, avec le temps de gestion qui va avec : contacts, verrouillage, DNS, échéance. Le vrai coût d’un domaine n’est pas son prix, c’est l’obligation de ne jamais l’oublier.
Tableau comparatif : sous-répertoire, sous-domaine ou nouveau domaine
| Critère | Sous-répertoire (site.fr/blog/) | Sous-domaine (blog.site.fr) | Nouveau domaine (autre-marque.fr) |
|---|---|---|---|
| Référencement | Hérite des liens et de l’historique du site | Même site pour Google, maillage à construire | Repart de zéro |
| Marque | Clairement le même site | Même marque, espace distinct | Indispensable pour une marque différente |
| Pas d’existence propre | MX, SPF, DKIM dédiés possibles | Chaîne complète à recréer, réputation à bâtir | |
| Certificat | Couvert par celui du site | Let’s Encrypt par nom, ou wildcard | Certificat propre |
| Isolation technique | Aucune | Dossier, PHP, journaux, FTP distincts ; ressources partagées | Idem, abonnement séparé possible |
| Coût | Nul | Nul (wildcard payant optionnel) | Enregistrement puis renouvellement annuel |
| Risque d’oubli | Faible | Moyen : sous-domaine abandonné | Élevé : échéance manquée |
Lecture rapide : même marque et même technique, sous-répertoire ; même marque et technique différente, sous-domaine ; marque différente, nouveau domaine. Les cas suivants nuancent cette grille.
Six cas concrets avec une recommandation
Blog d’entreprise
Le blog existe pour amener des visiteurs vers l’offre : sous-répertoire /blog/, sur la même installation si le site est déjà un WordPress. Le sous-domaine ne se justifie que si le blog tourne sur un autre logiciel ou est confié à une équipe qui ne doit pas accéder au site.
Boutique à côté d’un site vitrine
Module du même CMS (WooCommerce sur le WordPress existant) : /boutique/. Installation distincte (PrestaShop) : sous-domaine boutique.entreprise.fr, dossier et PHP séparés, certificat propre. Une boutique consomme plus qu’une vitrine et les deux partagent l’enveloppe de l’abonnement : dimensionnez pour la somme.
Application ou espace client
Sous-domaine, presque toujours : app.entreprise.fr ou compte.entreprise.fr. L’application a sa technique, ses sessions et cookies, ses envois d’e-mails, donc un SPF et un DKIM dédiés et un certificat distinct. Si des sous-domaines par client sont prévus, partez sur un wildcard dès le début.
Site multilingue : sous-répertoire /en/ ou domaine par pays
Google Search Central liste trois structures pour des versions localisées : domaine national (entreprise.de), sous-domaine (de.entreprise.fr) et sous-répertoire (entreprise.fr/de/) ; les paramètres d’URL sont déconseillés. Pour une PME qui traduit son site, le sous-répertoire est le plus simple : un domaine, un certificat, un CMS. Le domaine par pays se justifie quand chaque pays a son équipe et son offre. Dans tous les cas, déclarez les versions avec des balises hreflang réciproques et une version x-default.
Marque ou activité distincte
Nouveau domaine. Une adresse autre-marque.entreprise.fr affaiblit les deux marques. Réservez le nom de la marque, en .fr et .com si l’activité le mérite, après vérification à l’INPI.
Site événementiel temporaire
Le réflexe est le domaine dédié (salon-2027.fr). Préférez salon.entreprise.fr ou /salon-2027/ : gratuit, rattaché à la marque, facile à fermer par une redirection 301 vers la page bilan. Un domaine événementiel non renouvelé est souvent racheté par des tiers qui récupèrent son trafic.
Créer un sous-domaine dans Plesk : dossier, PHP, certificat et DNS
Depuis l’Espace client, ouvrez Plesk, puis :
- Dans Sites web & domaines, cliquez sur Ajouter un sous-domaine.
- Saisissez le nom (
blog) et le domaine parent. Gardez le dossier racine proposé, séparé dehttpdocs, pour que les deux sites n’exposent pas leurs fichiers l’un à l’autre. - Validez. Plesk crée le sous-domaine, son dossier et, si la zone DNS est gérée par Plesk, les enregistrements A et AAAA.
- Dans Paramètres PHP, choisissez la version et les limites adaptées au logiciel à installer ; elles sont indépendantes du site principal.
- Dans Certificats SSL/TLS, installez un certificat Let’s Encrypt, ou attribuez le wildcard existant, puis activez la redirection permanente de HTTP vers HTTPS.
- Installez le logiciel et testez l’adresse en HTTPS.
Si la zone DNS est gérée ailleurs
Plesk ne peut alors pas publier l’enregistrement à votre place. Ajoutez dans la zone :
- un enregistrement A
blogvers l’adresse IPv4 de l’hébergement (affichée dans Plesk), et un AAAA si une IPv6 est disponible ; - ou un CNAME
blogverswww.entreprise.fr, si le sous-domaine doit toujours suivre l’adresse du site principal. Un CNAME exclut tout autre enregistrement sur le même nom : pas de MX sur un sous-domaine en CNAME.
Attendez la propagation (de quelques minutes à quelques heures selon le TTL), puis émettez le certificat. Le guide Configurer les DNS d’un domaine détaille chaque type d’enregistrement et les vérifications avec dig. Pour un nouveau domaine, la procédure est celle d’un domaine additionnel : commande, serveurs DNS pointés vers l’hébergement, ajout dans Plesk, certificat.
Redirections et pièges : www, contenu dupliqué et sous-domaine oublié
Le contenu accessible à deux adresses
Après une création, le même blog répond parfois sur blog.entreprise.fr et sur www.entreprise.fr/blog/. Choisissez une adresse canonique, redirigez les autres en 301 et déclarez rel="canonical". Même règle pour un contenu déplacé d’un dossier vers un sous-domaine : chaque ancienne URL redirige vers son équivalent, pas vers la page d’accueil.
Le sous-domaine www et le certificat
Un visiteur qui tape www.blog.entreprise.fr obtient une erreur de certificat : ce nom n’est couvert ni par le certificat du sous-domaine ni par *.entreprise.fr, qui ne descend pas d’un niveau. Ne créez pas ce nom en DNS. Le guide Activer HTTPS et corriger un certificat SSL traite les autres erreurs.
Le sous-domaine oublié
C’est le piège le plus coûteux. Un site d’événement ou un espace de test reste en ligne sur old.entreprise.fr avec un WordPress jamais mis à jour, et devient la porte d’entrée d’un piratage de tout l’abonnement, puisque les sites partagent le même utilisateur système. Autre variante : un CNAME pointe encore vers un service tiers résilié, qu’un inconnu réserve pour servir son contenu sous votre nom.
Liste de contrôle avant de choisir entre sous-domaine et nouveau domaine
Passez ces points avant de créer quoi que ce soit.
- Marque : le second site porte-t-il le même nom que le premier ? Non : nouveau domaine. Oui : suite.
- Technique : même logiciel que le site principal ? Oui : sous-répertoire. Non : sous-domaine.
- Objectif : le contenu doit-il apporter du trafic au site principal ? Privilégiez le sous-répertoire et son maillage naturel.
- E-mail : envois automatiques en volume ? Sous-domaine avec SPF et DKIM dédiés, et vérification de la politique DMARC du domaine parent.
- Certificat : plus de trois sous-domaines dans un an, ou créés à la volée ? Wildcard.
- Ressources : le second site peut-il ralentir le premier ? Si c’est inacceptable, séparez les abonnements.
- Multilingue : une équipe et une offre, sous-répertoire par langue avec
hreflang; des entités par pays, domaines nationaux. - Durée de vie : site temporaire ? Sous-domaine ou dossier, avec date de fermeture et redirection prévues dès le départ.
- Adresse canonique et inventaire : une seule forme, redirections 301 sur les autres, et une liste à jour des noms avec un responsable et une échéance chacun.
Pour un nouveau domaine, ajoutez les vérifications du guide .fr ou .com : INPI, titulaire au nom de l’entreprise, verrouillage et renouvellement automatique.
Questions fréquentes
Sous-domaine ou sous-répertoire : lequel est le meilleur pour le SEO ?
Un sous-domaine est-il gratuit chez un hébergeur ?
Comment créer un sous-domaine dans Plesk ?
Peut-on avoir une boutique et un site vitrine sur le même domaine ?
Site multilingue : sous-domaine, sous-répertoire ou domaine par pays ?
Un sous-domaine peut-il avoir ses propres adresses e-mail ?
Faut-il un certificat SSL par sous-domaine ?
Que faire d’un ancien sous-domaine qui ne sert plus ?
Guides liés
Pour aller plus loin sur le même sujet, et sur ce qui l’entoure :
Sources techniques
[1] Google Search Central — Managing multi-regional and multilingual sites (structures d’URL : domaine national, sous-domaine, sous-répertoire) [2] Google Search Central — Tell Google about localized versions of your page (hreflang) [3] Google Search Central — URL structure best practices [4] Plesk — Customer Guide Obsidian : Adding Subdomains [5] Let’s Encrypt — Challenge Types (validation DNS-01 obligatoire pour les certificats wildcard) [6] Let’s Encrypt — FAQ : certificats wildcard et durée de validité
Les options visibles et les formules dépendent de votre abonnement. Faites vérifier le contexte depuis l’Espace client, sans transmettre de mot de passe.
Demander une vérification