Passer au contenu 
Je montre étape par étape comment créer une Sous-domaine IONOS je crée les DNS correctement et je teste proprement l'adresse. Ainsi, je mets en place des destinations, SSL et des redirections, je garde la structure claire et je résous les erreurs typiques sans détour.
Points centraux
Avant de commencer, je garde à l'esprit les facteurs de réussite suivants et je les travaille l'un après l'autre pour que les sous-domaine fonctionne rapidement et de manière stable.
- Configuration: Se connecter, choisir le domaine, nommer le sous-domaine
- DNS: définir correctement l'enregistrement A, AAAA ou CNAME
- SSL: activer le certificat par sous-domaine
- SEO: plans du site, structure claire, pas de duplicate content
- TestsAttendre la propagation, vérifier la cible
Pour chaque projet, je conserve des noms clairs, des enregistrements DNS propres et un nom de domaine valide. SSL en point de mire. Je délimite ainsi clairement les services, les tests et les prestations en direct. Je documente chaque modification afin de pouvoir m'adapter plus rapidement par la suite. Je planifie la structure des sous-domaines de manière à faciliter les extensions ultérieures. Je vérifie l'accessibilité de plusieurs sites avant de promouvoir activement des contenus.
Qu'est-ce qu'un sous-domaine ? Explication rapide
Un sous-domaine étend le domaine principal en le faisant précéder d'un nom d'hôte tel que blog. Ainsi, je sépare les contenus, les services ou les équipes sur le plan technique et organisationnel, sans acheter un nouveau domaine. Des exemples sont blog.mondomaine.fr, shop.mondomaine.fr ou dev.mondomaine.fr pour les tests. L'idée : j'encapsule des fonctions et je peux contrôler indépendamment les objectifs, SSL et l'évaluation. Ceux qui souhaitent lire les termes et les options de manière condensée trouveront dans ce définition succincte du sous-domaine des connaissances de base supplémentaires.
Créer un sous-domaine IONOS : étape par étape
Je me connecte à mon compte client et j'ouvre Domaines & SSL, puis je sélectionne l'adresse appropriée. Domaine sur le site. Dans la zone de sous-domaine, je clique sur Créer un sous-domaine et j'attribue un nom court comme blog, boutique ou client. Comme destination, je détermine soit le répertoire web du site principal, soit un dossier propre pour une application autonome. Pour les services externes, je définis dans les paramètres DNS un CNAME ou un A-Record sur l'adresse cible au lieu d'une cible de dossier. Après l'enregistrement, j'attends la diffusion DNS, je teste le sous-domaine dans le navigateur et je vérifie le statut et le SSL dans l'aperçu.
Chez IONOS, j'utilise ces types de destination en fonction de l'objectif : 1) répertoire de l'espace web pour les contenus propres, 2) redirection (HTTP/HTTPS) vers une autre URL, 3) lien d'application ou de site si un module/boutique est connecté, 4) purement basé sur DNS si un service externe est sollicité. Je maintiens la cohérence de la structure des chemins et des autorisations dans l'espace web afin que les déploiements restent reproductibles. Pour les instances de staging, j'active de manière ciblée la protection d'accès afin que les moteurs de recherche et les utilisateurs ne s'y retrouvent pas par inadvertance.
Définir correctement les cibles DNS et les enregistrements
Pour les contenus web, je renvoie généralement le sous-domaine via A-Record sur une adresse IPv4 ou via un enregistrement AAAA sur une adresse IPv6. Si le service cible fonctionne en externe, je place souvent un CNAME qui pointe vers l'hôte du fournisseur. Il est important d'avoir une valeur TTL raisonnable pour que les modifications prennent effet rapidement et que les changements ultérieurs n'attendent pas indéfiniment. Je contrôle dans les paramètres DNS si le nom d'hôte, le type d'enregistrement et la destination correspondent exactement. Si vous souhaitez lire les étapes de manière compacte, utilisez le guide de Paramètres DNS sur IONOS comme aide-mémoire.
Je planifie la stratégie TTL : dans les phases où il y a beaucoup de changements, je définis un TTL plus bas (par exemple 300-900 secondes), après la stabilisation, je l'augmente à nouveau pour utiliser la mise en cache. A et AAAA doivent pointer en parallèle sur le même système, sinon le comportement varie selon le client. J'évite les CNAME lorsque j'ai besoin d'un contrôle granulaire sur A/AAAA ou que je veux minimiser la latence. Si un CDN ou un reverse proxy est utilisé, j'attribue le sous-domaine au fournisseur par CNAME et je documente les IP d'origine en interne.
Pour les configurations complexes, je délègue des sous-zones : Je place les enregistrements NS pour, par exemple, dev.mondomaine.fr sur d'autres serveurs de noms lorsqu'une équipe gère l'environnement de développement de manière autonome. Ce faisant, je vérifie qu'il n'y a pas de double autorité (pas d'enregistrements concurrents dans la zone parente). Je fais également attention aux enregistrements CAA dans la zone principale si l'émission de certificats est limitée ; le sous-domaine hérite de ces règles.
Mettre en place correctement les redirections
Je fais une distinction claire entre 301 (permanent), 302/307 (temporaire) et 308 (permanent, méthode conservée). Pour les sous-domaines qui doivent uniquement être redirigés, j'utilise une redirection côté serveur et je laisse si possible les chemins et les chaînes de requête passer sans modification. J'évite les redirections masquées, car elles compliquent le SSL, le SEO et la sécurité. Lors de déménagements, je planifie des matrices de redirection : sources de sous-domaines, URL de destination, codes d'état, durée d'exécution. Je maintiens la chaîne à plat (un saut maximum) pour ne pas grever les performances et le budget de crawl.
Sous-domaines wildcard et accès FTP
Si je route de nombreux sous-domaines de manière dynamique, je place une Wildcard comme *.mondomaine.fr et les pointer vers une destination standard. Ainsi, même les hôtes qui n'ont pas encore été créés atterrissent sur une page utile ou un projet catch-all. Pour les accès FTP, j'aime utiliser ftp.mondomaine.fr et déposer un CNAME sur l'adresse technique du serveur afin que les outils puissent facilement reconnaître l'hôte. Cette convention facilite le travail d'équipe et documente les intentions dès le nom d'hôte. Je garde en outre les noms tels que dev, staging ou test cohérents afin de séparer clairement les états de test.
Pour les wildcards, je fais attention au SSL : selon le tarif et la méthode de validation, un certificat wildcard est nécessaire, sinon la connexion HTTPS échoue. Je vérifie si certains hôtes doivent être exclus, par exemple lorsque shop.mondomaine.fr pointe vers un fournisseur externe. Les wildcards sont puissantes, mais je les utilise de manière ciblée pour éviter les recoupements involontaires entre les hôtes hardcoded et catch-all.
Utiliser judicieusement le courrier électronique sur les sous-domaines
Si j'ai besoin de boîtes aux lettres pour un sous-domaine (par ex. support.mondomaine.fr), je place des enregistrements MX dédiés. Si les services envoient depuis un sous-domaine (par exemple newsletter.mondomaine.fr), j'ajoute des enregistrements SPF et je configure DKIM/DMARC de la même manière que pour le domaine principal. Ainsi, la délivrabilité reste stable et je sépare correctement les identités des expéditeurs. J'évite d'utiliser simultanément des sous-domaines web productifs pour le courrier électronique afin d'encapsuler proprement les services et d'exclure les conflits d'enregistrements DNS.
Sécurité et protection des accès
J'enclenche SSL pour chaque sous-domaine et redirige automatiquement HTTP vers HTTPS. Pour les environnements internes, j'active en outre Basic-Auth, les restrictions IP ou l'accès VPN afin d'empêcher les moteurs de recherche et les personnes non autorisées d'y accéder. Je vérifie les contenus mixtes, HSTS et les suites de chiffrement modernes afin d'éviter les avertissements du navigateur. Pour les API, j'établis des règles CORS par sous-domaine afin que les frontaux puissent y accéder de manière contrôlée. Lorsque cela est pertinent, j'isole les sessions et les cookies par hôte afin de réduire les risques liés à des domaines de cookies largement définis.
Performance, mise en cache et CDN
Je décide pour chaque sous-domaine si un CDN ou un reverse proxy offre une valeur ajoutée : contenus statiques, portée internationale, protection contre les DDoS. Pour les caches actifs, je prévois des stratégies de purge et de versionnement (noms de fichiers avec hash) afin que les déploiements puissent être mis en service proprement, sans rafraîchissements difficiles du navigateur. Côté serveur, j'utilise des balises/modifications de charge et des en-têtes de contrôle de cache pertinents. Je sépare les applications gourmandes en ressources informatiques (par ex. API) des sous-domaines de contenu, afin que les caches fonctionnent efficacement et que les charges ne se perturbent pas mutuellement.
Mettre en œuvre efficacement des cas d'utilisation typiques
Pour les contenus avec une tonalité propre, je crée blog.mondomaine.fr et j'y gère un blog allégé. CMS. J'encapsule une boutique sur shop.mondomaine.fr, afin que la caisse et la logique des produits fonctionnent séparément. Je place un portail client sur kunden.meinedomain.de et limite l'accès par des rôles et des règles IP. Les campagnes reçoivent aktion.mondomaine.fr, afin que le suivi, le SEO et le contenu restent mesurables de manière autonome. Je place les niveaux de développement sur dev ou staging afin de pouvoir tester les nouvelles fonctions en toute sécurité avant de les mettre en ligne.
Pour les API, je place api.mondomaine.fr, je tiens compte de CORS, des limites de taux et d'une version claire du chemin (par ex. /v1/). Pour les outils internes, je choisis des sous-domaines admin ou intranet et je les sécurise fortement. Pour les médias, j'utilise media ou cdn, afin que les navigateurs se chargent en parallèle et que les stratégies de cache soient ciblées. Pour les expériences et les tests de fonctionnalités, j'utilise des sous-domaines éphémères que je supprime une fois le test terminé afin de conserver une structure légère.
SEO pour les sous-domaines : meilleures pratiques
Je choisis des textes courts et parlants Noms comme blog, shop ou faq et garde la structure cohérente. Chaque sous-domaine reçoit son propre certificat SSL, son propre plan de site et une propriété séparée dans la Search Console. Je garde les liens internes thématiques propres afin que les robots d'indexation et les utilisateurs comprennent l'objectif de chaque adresse. J'évite le duplicate content en utilisant des canons clairs, des redirections propres et des contenus univoques. Pour les contenus internationaux, je crée un sous-domaine par langue avec hreflang ou j'utilise des sous-dossiers si la structure doit être gérée de manière centralisée.
Je veille à ce que les sous-domaines comme staging ou dev soient sur noindex et protégés par Auth. En cas de déménagement entre un sous-domaine et un répertoire, je planifie des redirections, j'actualise les sitemaps et je contrôle les fichiers journaux pour les erreurs de crawl. Je sépare les propriétés de suivi par sous-domaine, mais je conserve un tableau de bord global pour identifier les tendances entre les différents départements. Je laisse volontairement les pages de recherche et de filtrage internes hors des sitemaps afin que l'index reste propre.
Installer WordPress sur un sous-domaine
Pour un projet autonome, je crée un Répertoire et j'y attribue le sous-domaine, puis j'y installe WordPress. Si j'utilise plutôt un multisite, j'active les sous-domaines dans la configuration du réseau et je vérifie au préalable le Wildcard-DNS. Je gère la mise en cache, l'optimisation des images et les mises à jour séparément pour chaque sous-domaine afin de réduire les sources d'erreur. Pour ceux qui ont besoin d'une antisèche pour la configuration de base du domaine, consultez ce guide. Configurer le domaine IONOS et complète les étapes pour les sous-domaines. Ainsi, la maintenance reste planifiable et la performance pour chaque sous-domaine reste concluante à tout moment.
Pour les installations individuelles, je veille à avoir mes propres bases de données ou des préfixes clairs, des répertoires de téléchargement séparés et des jobs cron indépendants. Je place correctement l'URL du site et l'URL d'accueil sur le sous-domaine et je vérifie qu'il ne reste pas d'anciens liens absolus du domaine principal. Dans les configurations multisite, je teste d'abord les nouveaux sous-domaines sur le réseau avant de les activer en externe. Pour les instances de staging, je désactive l'indexation, renouvelle les saltos, bloque les moteurs de recherche et garde les données d'accès séparées.
Gouvernance, désignation et coopération
Je définis un schéma de nommage et je le respecte systématiquement : fonctionnel (api, media, shop), organisationnel (team, hr) ou géographique (eu, us), mais pas de mélange. Je documente les modifications de manière durable : qui a créé quel enregistrement DNS, quand, pourquoi et avec quel TTL. Pour les grandes équipes, je délègue des sous-zones à des serveurs de noms dédiés et je sécurise les droits d'écriture afin que n'importe qui ne puisse pas effectuer des modifications n'importe où. J'établis des processus de révision pour les DNS, SSL et les redirections afin d'éviter les pannes et les dommages SEO.
Tests, propagation et diagnostic
Je vérifie la résolution à partir de différents réseaux et appareils. Avant la conversion globale, je teste localement via le mappage de fichiers Hosts afin de vérifier les configurations de serveur. Je distingue si une erreur provient du DNS (NXDOMAIN, mauvaise IP), du réseau (timeout) ou de l'application (404/500). Pour SSL, je compare la chaîne de certificats, la couverture de l'hôte et la validité. J'observe le temps nécessaire à la propagation complète et ne planifie pas les changements visibles lors des pics de charge ou juste avant le lancement de la campagne.
Troubleshooting : résoudre rapidement les erreurs fréquentes
Si la nouvelle adresse n'apparaît pas, je vérifie d'abord DNS sur les fautes de frappe, les types d'enregistrement erronés ou les destinations manquantes. J'attends de manière réaliste quelques heures, voire 48 heures, car la diffusion mondiale prend du temps. Je vide le cache du navigateur et les caches DNS locaux pour éliminer les anciens enregistrements. Pour un audit externe, je teste la résolution sur plusieurs sites et vérifie si A ou CNAME répondent correctement. Si le SSL fait des siennes, je relance l'émission de certificats pour le sous-domaine et je vérifie si l'hôte est accessible au public.
En cas d'erreur 404, je vérifie si le répertoire est correctement lié et si les règles .htaccess sont efficaces. Si le serveur renvoie 403, les droits ou l'index du répertoire sont souvent concernés. S'il renvoie 421/421-Misdirected-Request, l'hôte virtuel ne correspond pas à la requête SNI. Si le CNAME et l'enregistrement A existent simultanément sur le même sous-domaine, je supprime les conflits. En cas d'erreurs DNSSEC, je vérifie les signatures et la chaîne ; pour les enregistrements CAA, j'adapte les émetteurs afin que les certificats soient à nouveau émis.
Exploitation, suivi et maintenance
Je mets en place des contrôles de temps de réponse pour chaque sous-domaine critique, je surveille les données d'exécution SSL et je garde un œil sur la latence et les taux d'erreur. Les déploiements sont contrôlés par des scripts et reproductibles afin que les retours en arrière soient possibles rapidement. Je planifie des fenêtres de maintenance, j'affiche proprement les pages de maintenance et je garde des redirections à disposition en cas d'urgence. Pour les contenus, je gère un plan de sauvegarde séparé par sous-domaine afin que les restaurations soient effectuées de manière ciblée et que les accords de niveau de service puissent être respectés.
Gérer et supprimer sans interruption
Dans le menu de sous-domaine, je modifie le ObjectifJe peux aussi faire des recherches si un service est déplacé ou si un nouveau répertoire est utilisé. Avant de les supprimer, je vérifie les dépendances telles que le routage des e-mails, les redirections, le suivi et les plans de site. Je désactive les redirections de manière ordonnée, je sécurise les contenus et, si nécessaire, je mets en place des redirections 301 temporaires. Ainsi, le guidage des utilisateurs reste intact pendant que je nettoie ou fusionne des sous-domaines. Une brève documentation permet d'éviter que d'anciens hôtes soient réactivés par erreur par la suite.
Après les désactivations, je maintiens les redirections 301 suffisamment longtemps, j'actualise les liens et je veille à ce que les anciennes URL disparaissent des sitemaps. Je nettoie les groupes de sécurité, les accès et les tâches cron afin qu'il ne reste pas de processus orphelins. Dans la Search Console, je ne supprime les propriétés devenues obsolètes que si aucun signal n'est plus nécessaire à long terme.
Comparaison : IONOS et alternatives
Pour les projets quotidiens, la Administration d'IONOS pour les sous-domaines, SSL et DNS standard. Les configurations exigeantes avec de nombreux enregistrements, des redirections spéciales et des services externes profitent de fournisseurs offrant des fonctionnalités DNS très étendues. Il est important d'avoir des interfaces claires, des journaux pour les modifications et une assistance rapide lorsque les enregistrements sont critiques. J'évalue le confort par rapport à la flexibilité et je décide en fonction de la taille du projet et de la structure de l'équipe. Le tableau suivant compare les points clés de manière compacte afin de faciliter le classement.
| Fournisseur | Gestion des sous-domaines | Flexibilité du DNS | Soutien |
|---|---|---|---|
| webhoster.de | Très complet | Excellent | 24/7 Premium |
| IONOS | Simple à moyen | Bon | Bon standard |
| Concurrent X | Moyens | Moyens | Standard |
En bref
Je crée des sous-domaines chez IONOS de manière ciblée, je mets en place des Records et contrôle soigneusement l'accessibilité. Une dénomination claire, un propre SSL et des sitemaps propres rendent l'administration et le référencement prévisibles. Pour WordPress, je sépare systématiquement les projets et maintiens la mise en cache et les mises à jour séparées par sous-domaine. En cas de perturbations, je vérifie le DNS, le cache et le certificat avant de modifier les objectifs ou de mettre en place des redirections. Ainsi, la structure reste fiable, les contenus se chargent rapidement et chaque sous-domaine remplit sa fonction sans perte de friction.
