Faut-il rediriger ou désactiver un sous-domaine SEO non utilisé ?

Pourquoi Google fait-il cette distinction entre trafic utilisateur et crawl ?

La logique est simple : l'expérience utilisateur prime. Si quelqu'un tape l'URL de votre ancien sous-domaine ou clique sur un lien externe pointant vers lui, il doit atterrir quelque part de pertinent — pas sur une erreur 404 ou DNS. C'est pour ça que Google recommande la redirection dans ce cas.

Mais si le sous-domaine ne reçoit que des visites de crawlers — parce qu'il n'existe plus aucun lien externe actif, plus aucun bookmark utilisateur — alors le maintenir en ligne ne sert qu'à consommer du crawl budget. Autant couper court.

Qu'entend Google par « retirer l'entrée DNS » ?

Concrètement, supprimer l'enregistrement DNS (A, AAAA ou CNAME) du sous-domaine fait que le serveur ne voit même plus arriver les requêtes. Le domaine devient techniquement inexistant aux yeux du web.

C'est plus radical qu'un simple code HTTP 410 ou qu'une désindexation via robots.txt. Le crawler tente de résoudre le nom de domaine, échoue, et abandonne rapidement. Google finit par retirer les URLs de son index.

Quels sont les points essentiels à retenir ?

• Trafic utilisateur existant : redirection 301 obligatoire vers les nouvelles pages pertinentes
• Seulement du crawl bot : désactivation DNS acceptable pour économiser le budget de crawl
• Suppression DNS : empêche le serveur de recevoir les requêtes, solution la plus propre si aucun humain n'accède au sous-domaine
• Vérifier avant d'agir : analyser les logs serveur pour s'assurer qu'il n'y a réellement aucun trafic organique

Cette recommandation est-elle cohérente avec les pratiques terrain ?

Oui, et c'est même du bon sens technique. J'ai vu des dizaines de sites maintenir en ligne des sous-domaines zombies (blog.exemple.com abandonné, support.exemple.com obsolète) simplement parce que « ça a toujours été là ». Résultat : Googlebot continue de crawler ces URLs mortes, épuise du budget qui pourrait être alloué aux pages stratégiques du domaine principal.

La nuance importante que Google ne précise pas : avant de couper l'entrée DNS, il faut s'assurer qu'il n'existe aucun backlink de valeur encore actif vers ce sous-domaine. Si vous avez des liens entrants depuis des sites d'autorité, une redirection 301 est plus intelligente qu'une suppression pure — même si le trafic utilisateur est nul.

Quelles sont les zones grises de cette déclaration ?

Google ne dit rien sur le délai de désindexation après suppression DNS. D'expérience, ça peut prendre plusieurs semaines, voire mois, si le sous-domaine avait beaucoup de pages indexées. Pendant ce temps, les URLs restent dans l'index et génèrent des erreurs DNS.

Autre point : [À vérifier] Google ne précise pas si désactiver un sous-domaine peut avoir un impact (même minime) sur le domaine principal si les deux étaient liés par du maillage interne ou des données structurées. Sur un site e-commerce avec sous-domaine blog désactivé brutalement, j'ai déjà constaté une légère baisse de crawl global — difficile de dire si c'était corrélé ou coïncidence.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si votre sous-domaine héberge encore du contenu historique précieux (ex : archives d'un forum, anciennes documentations techniques) accessible via recherche Google, le désactiver brutalement frustrera les utilisateurs qui trouvent ces pages en SERP. Dans ce cas, maintenir une redirection ou même laisser le contenu accessible en lecture seule peut être plus judicieux.

Que faut-il faire concrètement avant de désactiver un sous-domaine ?

Première étape : analyser les logs serveur sur au moins 90 jours. Distinguez le trafic bot du trafic humain. Si vous voyez uniquement Googlebot, Bingbot et quelques scrapers, vous êtes probablement safe pour désactiver.

Deuxième étape : vérifier les backlinks externes avec Ahrefs, Majestic ou Search Console. Si des liens de qualité pointent encore vers le sous-domaine, privilégiez la redirection 301 — même si le trafic direct est nul, vous préservez le jus SEO.

Quelles erreurs éviter lors de la migration ou désactivation ?

Ne désactivez jamais un sous-domaine sans avoir d'abord mis en place un monitoring des erreurs 4xx/5xx sur votre domaine principal. Pourquoi ? Parce que si vous aviez du maillage interne (liens depuis le domaine principal vers le sous-domaine), ces liens vont devenir morts et générer des 404.

Autre piège classique : retirer l'entrée DNS avant d'avoir configuré les redirections. Si vous décidez finalement qu'une redirection est nécessaire après coup, c'est trop tard — le sous-domaine n'existe plus et vous ne pouvez plus rediriger au niveau serveur.

Comment vérifier que la désactivation se passe bien ?

• Surveillez la Search Console : les erreurs DNS doivent apparaître dans « Couverture » sous quelques jours
• Vérifiez que le nombre de pages indexées du sous-domaine diminue progressivement (commande site:ancien-sous-domaine.exemple.com)
• Contrôlez les logs : les tentatives de crawl doivent cesser après 2-3 semaines
• Assurez-vous qu'aucune baisse de trafic n'est constatée sur le domaine principal (signe d'un maillage interne cassé)
• Documentez la date de désactivation et les raisons dans votre wiki technique interne