Sous-domaine créé automatiquement lors de la configuration d'un nouveau domaine

Comprendre le problème

Quand vous ajoutez un domaine, certaines configurations de cPanel créent aussi un sous-domaine technique associé. Vérifiez les noms et les racines dans Domaines avant de le modifier : supprimer un élément associé peut affecter le domaine que vous voulez conserver.

Si les deux noms affichent le même contenu, une page peut avoir plusieurs URL publiques. Ne pas avoir créé de lien vers le sous-domaine ne garantit pas que personne ne le connaît ni qu'un moteur de recherche ne le découvrira pas. Vérifiez la réponse réelle et les données de Search Console avant de décider quoi faire.

L'emplacement de la racine du document dépend de la façon dont le compte a été créé. Un dossier dans public_html pourrait aussi être accessible par le domaine principal ; ne supposez pas que toutes les anciennes installations ont été créées hors de cette racine.

Les domaines d'un même compte peuvent avoir leur propre contenu, mais ils partagent les ressources et les permissions de ce compte : ils ne sont pas totalement isolés comme des comptes séparés.

Choisir le comportement

• Si le sous-domaine affiche le même contenu et reçoit des visites ou des liens, utilisez une redirection permanente vers le domaine et le chemin équivalents.
• Si une URL ne doit pas exister et n'a pas de remplaçant pertinent, elle peut répondre 404 ou 410.
• S'il s'agit d'un environnement de test avec des données privées, protégez-le par une authentification ; le cacher aux moteurs de recherche n'en restreint pas l'accès.

Ne redirigez pas un sous-domaine au contenu utile vers une page d'accueil sans rapport uniquement pour faire disparaître un avertissement. Vérifiez d'abord le trafic, les liens et les chemins importants.

Résoudre le problème

Gardez une copie du .htaccess de la racine concernée. Ajoutez une seule des alternatives avant les règles de l'application et remplacez les domaines d'exemple. La condition limite l'action à l'hôte technique exact.

Pour répondre 404 :

RewriteEngine On
RewriteCond %{HTTP_HOST} ^subdominio\.votredomaine\.com(?::[0-9]+)?$ [NC]
RewriteRule ^ - [R=404,L]

Pour rediriger vers le domaine public en conservant le chemin quand le même contenu y existe :

RewriteEngine On
RewriteCond %{HTTP_HOST} ^subdominio\.votredomaine\.com(?::[0-9]+)?$ [NC]
RewriteCond %{THE_REQUEST} \s/+([^?\s]*)
RewriteRule ^ https://dominio-publico.example/%1 [R=301,L,NE]

La deuxième condition reprend le chemin original de la requête pour conserver ses caractères encodés ; la chaîne de requête est conservée puisque la destination n'en définit pas d'autre. La destination est un nom fixe que vous devez remplacer ; ne la construisez pas à partir de l'hôte envoyé par le visiteur. Le signe ! devant la condition inverserait sa portée et pourrait affecter le mauvais domaine.

Ces règles s'appliquent à la racine du document de ce site. Si vous traitez un accès alternatif par sous-dossier, il faut une règle spécifique à ce chemin ; ne copiez pas la condition d'hôte en espérant le résoudre.

Vérifier sans affecter le domaine public

Testez la page d'accueil et une page intérieure du sous-domaine, et confirmez que le domaine public se charge toujours directement. Vérifiez les codes, la destination, les paramètres et l'absence de boucles. Une redirection permanente peut rester en cache dans le navigateur : utilisez une nouvelle session pour vos vérifications.

Gardez le certificat de l'ancien nom valide tant qu'il reçoit des requêtes HTTPS ; la négociation TLS a lieu avant la redirection. Mettez à jour les liens internes et la canonical pour qu'ils pointent vers l'URL publique et conservez les redirections des adresses qui ont des signaux utiles.

Si une erreur 500 apparaît, restaurez le fichier sauvegardé et consultez le journal avant d'essayer de nouvelles règles.