Faut-il vraiment créer une sitemap distincte pour chaque sous-domaine ?

Pourquoi Google impose-t-il une sitemap par sous-domaine ?

La raison est simple : Google considère chaque sous-domaine comme un site distinct lors du crawl. blog.exemple.com n'est pas identifié de la même manière qu'exemple.com ou shop.exemple.com. Chaque entité dispose donc de son propre crawl budget, de son propre historique d'indexation, et de ses propres métriques de confiance.

Concrètement, si vous déposez une sitemap globale sur exemple.com qui référence des URLs de blog.exemple.com, Google l'ignorera purement et simplement. La sitemap doit être hébergée sur le même sous-domaine que les URLs qu'elle liste. C'est un principe technique non négociable.

Quel est le rôle du fichier robots.txt dans cette configuration ?

Le fichier robots.txt permet de déclarer l'emplacement de la sitemap à l'aide de la directive Sitemap:. Chaque sous-domaine devrait donc avoir son propre robots.txt contenant la ligne adéquate. Par exemple, blog.exemple.com/robots.txt indiquera Sitemap: https://blog.exemple.com/sitemap.xml.

Cette approche présente deux avantages. D'abord, elle facilite la découverte automatique par Googlebot sans passer par Search Console. Ensuite, elle centralise la configuration technique : un humain ou un bot consulte robots.txt et sait immédiatement où trouver la sitemap. C'est une bonne pratique d'hygiène technique.

Est-ce que tous les sites ont besoin d'une architecture multi-sous-domaines ?

Non, et c'est là que le bât blesse. Beaucoup de structures en sous-domaines sont historiques ou mal pensées. Elles datent d'époques où les équipes techniques séparaient blog, e-commerce et corporate pour des raisons d'infrastructure, sans réfléchir aux implications SEO.

Or, une architecture en sous-répertoires (exemple.com/blog/, exemple.com/shop/) simplifie tout : un seul crawl budget, une autorité centralisée, une sitemap unique. Si vous n'avez pas de raison technique impérieuse de séparer vos contenus sur des sous-domaines, évitez-le. La recommandation de Mueller est valide, mais elle ne doit pas servir de prétexte à multiplier les sous-domaines sans réfléchir.

• Un sous-domaine = un site distinct aux yeux de Google, avec son propre crawl budget et ses propres métriques.
• Chaque sous-domaine nécessite sa propre sitemap XML, hébergée sur ce même sous-domaine.
• Le fichier robots.txt de chaque sous-domaine doit référencer sa sitemap via la directive Sitemap:.
• L'architecture en sous-répertoires est généralement préférable sauf contraintes techniques ou organisationnelles fortes.
• Évitez de fragmenter votre autorité en créant des sous-domaines sans nécessité stratégique claire.

Cette recommandation s'applique-t-elle à tous les contextes ?

Oui, mais elle révèle surtout un mauvais choix initial. La plupart des sites qui utilisent des sous-domaines le font par habitude ou contrainte technique, pas par stratégie SEO. Si vous êtes une marketplace avec des centaines de vendeurs indépendants (chacun sur vendeur.exemple.com), ou une plateforme SaaS multi-tenant, les sous-domaines ont du sens. Dans ces cas, vous acceptez sciemment la fragmentation du crawl budget.

Mais si vous avez simplement mis le blog sur blog.exemple.com parce que "c'était plus simple pour l'équipe dev", vous vous êtes tiré une balle dans le pied. Vous cassez votre maillage interne, vous dispersez l'autorité, vous compliquez la gestion des sitemaps. Il faut alors assumer la charge de maintenance : une sitemap par sous-domaine, une Search Console property par sous-domaine, une surveillance séparée des erreurs d'indexation.

Quelles sont les erreurs fréquentes observées sur le terrain ?

Première erreur classique : soumettre une sitemap cross-domain via Search Console. Vous êtes sur la property exemple.com et vous ajoutez une sitemap qui liste des URLs de blog.exemple.com. Google l'accepte sans broncher dans l'interface, mais ne crawle rien. Aucune erreur remontée, juste un silence radio.

Deuxième erreur : oublier le robots.txt sur certains sous-domaines. Vous configurez tout proprement sur le domaine principal, mais les sous-domaines servent un 404 sur /robots.txt. Résultat : Google doit deviner où se trouve la sitemap, ou vous devez la soumettre manuellement dans Search Console. Perte de temps, risque d'oubli lors d'un nouveau lancement.

Troisième cas observé : les sous-domaines wildcard mal gérés. Certains CMS ou plateformes génèrent dynamiquement des sous-domaines utilisateurs (user123.exemple.com). Si vous ne maîtrisez pas la génération automatique de sitemaps et de robots.txt pour chacun, vous vous retrouvez avec des milliers de sous-domaines non indexés ou crawlés de façon chaotique. [À vérifier] : Google ne documente pas clairement comment il priorise le crawl dans ces configurations wildcard massives.

Dans quels cas faut-il vraiment conserver des sous-domaines ?

Si vous avez des contenus géographiques ou linguistiques indépendants (fr.exemple.com, de.exemple.com), l'usage de sous-domaines reste défendable, même si les sous-répertoires avec hreflang sont souvent préférables. Si vous gérez une infrastructure technique hétérogène (blog sur WordPress, shop sur Shopify, corporate sur un CMS custom), et que migrer tout sur une seule stack est irréaliste à court terme, assumez les sous-domaines.

Mais soyez honnête avec vous-même : est-ce une vraie contrainte ou juste un choix de facilité ? Parce que vous allez payer cette facilité initiale pendant des années en complexité SEO. Chaque sous-domaine est un silo, et vous devrez compenser par du netlinking interne agressif pour reconstituer artificiellement l'autorité que vous auriez eue naturellement avec des sous-répertoires.

Que faire si vous utilisez déjà des sous-domaines ?

D'abord, auditez l'existant. Listez tous vos sous-domaines actifs, vérifiez que chacun dispose bien d'une sitemap XML à jour et d'un robots.txt qui la référence. Utilisez un crawler comme Screaming Frog en mode liste pour vérifier que les URLs de chaque sitemap sont effectivement crawlables et non bloquées par robots.txt ou noindex.

Ensuite, posez-vous la question de la migration. Si vos sous-domaines ne servent aucune logique métier forte, envisagez sérieusement de tout ramener en sous-répertoires. Oui, c'est un chantier. Oui, il faut des redirections 301 propres, une gestion rigoureuse, un suivi dans Search Console. Mais sur 12-18 mois, vous récupérez de l'autorité centralisée et simplifiez drastiquement votre stack technique.

Comment configurer proprement une architecture multi-sous-domaines ?

Chaque sous-domaine doit avoir son fichier robots.txt dédié à la racine, contenant au minimum la directive Sitemap: pointant vers sa sitemap XML. Pas de sitemap générique, pas de copier-coller du robots.txt du domaine principal. Chaque entité est autonome.

Créez une property Search Console distincte pour chaque sous-domaine. Google vous permet de créer une property de type "Domain" qui agrège tout, mais elle ne remplace pas les properties individuelles pour le suivi fin. Vous devez pouvoir isoler les erreurs d'indexation, les performances de crawl, les Core Web Vitals par sous-domaine.

Mettez en place un monitoring automatisé qui vérifie régulièrement que chaque sitemap est accessible, à jour, et ne contient pas d'URLs en erreur 4xx ou 5xx. Un sous-domaine oublié pendant six mois, c'est du contenu qui disparaît progressivement de l'index sans que vous vous en rendiez compte.

Quelles erreurs éviter absolument ?

Ne déployez jamais une sitemap qui liste des URLs cross-domain. Google l'ignorera silencieusement, et vous croirez être en règle alors que rien n'est crawlé. Vérifiez aussi que vous n'avez pas de canonicals cross-domain involontaires : un canonical sur blog.exemple.com qui pointe vers exemple.com casse la logique de sous-domaine distinct.

Évitez de multiplier les sous-domaines pour des raisons cosmétiques. Chaque nouveau sous-domaine est un coût de maintenance SEO permanent. Si vous n'avez pas de raison forte, restez en sous-répertoire. Et si vous avez un doute, testez d'abord avec un sous-répertoire : migrer de /blog vers blog.exemple.com est faisable, l'inverse est plus délicat.

• Vérifier que chaque sous-domaine dispose de sa propre sitemap XML hébergée sur ce sous-domaine.
• Créer un fichier robots.txt distinct par sous-domaine, référençant la sitemap via Sitemap:.
• Configurer une Search Console property séparée pour chaque sous-domaine.
• Auditer régulièrement les sitemaps pour détecter URLs en erreur, doublons ou cross-domain.
• Évaluer sérieusement l'opportunité d'une migration vers des sous-répertoires si aucune contrainte technique forte ne justifie les sous-domaines.
• Mettre en place un monitoring automatisé de l'accessibilité et de la fraîcheur des sitemaps.