Comment gérer efficacement des milliers de sous-domaines dans Search Console ?

Pourquoi cette limite de 1000 propriétés posait-elle problème ?

Pour les sites utilisant une architecture multi sous-domaines, cette contrainte devenait rapidement ingérable. Les plateformes e-commerce internationales avec un sous-domaine par pays, les médias avec des éditions régionales, ou les solutions SaaS avec un sous-domaine par client pouvaient facilement dépasser ce plafond.

Concrètement ? Cela obligeait à créer plusieurs comptes Search Console distincts, fragmentant les données et compliquant les opérations courantes. Une suppression d'URL urgente sur plusieurs sous-domaines nécessitait de se connecter à différents comptes, multipliant les risques d'erreur et le temps d'intervention. La vision d'ensemble du crawl et des performances organiques devenait également fragmentée.

En quoi la vérification au niveau du domaine racine change-t-elle la donne ?

La domain property introduite par Google résout ce problème d'un coup. Au lieu de vérifier chaque sous-domaine individuellement (blog.site.com, shop.site.com, support.site.com), vous vérifiez une seule fois le domaine racine via un enregistrement DNS TXT.

Cette vérification couvre automatiquement tous les sous-domaines existants et futurs, sans limite de nombre. Plus besoin de créer une nouvelle propriété à chaque lancement de sous-domaine. Les versions HTTP et HTTPS sont également incluses, simplifiant encore la configuration initiale.

Quelles données sont agrégées dans une domain property ?

La domain property offre une vue consolidée de tous vos sous-domaines : performances de recherche globales, couverture d'indexation, problèmes d'ergonomie mobile, Core Web Vitals. Vous pouvez ensuite filtrer par sous-domaine spécifique pour analyser les performances granulaires.

C'est particulièrement puissant pour identifier des tendances transversales : une mise à jour d'algorithme affectant plusieurs géographies, un problème technique se propageant sur l'infrastructure, ou des opportunités de mots-clés communes à exploiter. La comparaison entre sous-domaines devient également plus directe, sans export-import fastidieux entre propriétés distinctes.

• Une domain property couvre automatiquement tous les sous-domaines actuels et futurs du domaine racine
• La limite de 1000 propriétés par compte reste applicable si vous vérifiez chaque sous-domaine individuellement
• La vérification se fait via un enregistrement DNS TXT au niveau du registrar ou hébergeur
• Les données sont agrégées avec possibilité de filtrage par sous-domaine dans les rapports
• Les demandes de suppression d'URL urgentes peuvent être gérées depuis une interface unique pour tous les sous-domaines

Cette solution répond-elle vraiment aux besoins des architectures complexes ?

Pour la plupart des cas, oui. La domain property simplifie drastiquement la gestion quotidienne et évite le casse-tête des comptes multiples. Mais soyons honnêtes : elle n'est pas exempte de compromis.

Le principal inconvénient concerne la granularité des permissions. Avec des propriétés individuelles, vous pouviez donner accès à l'équipe marketing France uniquement à fr.site.com, et à l'équipe Allemagne uniquement à de.site.com. Avec une domain property, c'est tout ou rien — tout le monde voit tous les sous-domaines. Pour les grandes organisations avec des équipes cloisonnées, cela peut poser des problèmes de gouvernance des données.

Faut-il abandonner les propriétés individuelles pour autant ?

Pas nécessairement. Une approche hybride reste parfaitement viable : utiliser une domain property pour la vue d'ensemble et conserver des propriétés individuelles pour les sous-domaines critiques nécessitant un monitoring serré ou des permissions spécifiques.

Par exemple, si votre sous-domaine e-commerce génère 80% du trafic, avoir une propriété dédiée permet un monitoring plus réactif et des alertes ciblées. [À vérifier] : Google n'a jamais clairement documenté si l'agrégation des données dans une domain property introduit un décalage temporel par rapport aux propriétés individuelles, mais des retours terrain suggèrent une latence légèrement supérieure sur certains rapports.

Cette limitation de 1000 propriétés révèle-t-elle d'autres contraintes structurelles ?

Absolument. Elle met en lumière le fait que Search Console reste pensé pour des sites traditionnels plutôt que pour des infrastructures distribuées modernes. Les plateformes SaaS avec des milliers de sous-domaines générés dynamiquement ne sont clairement pas le cas d'usage prioritaire de Google.

Et c'est là que ça coince : même avec une domain property, certaines fonctionnalités restent limitées. Les paramètres d'URL, par exemple, doivent être configurés séparément pour chaque sous-domaine si vous utilisez des propriétés individuelles en complément. L'API Search Console elle-même impose des quotas qui peuvent devenir contraignants pour des extractions massives de données multi sous-domaines.

Comment mettre en place une vérification domain property concrètement ?

La procédure est relativement simple mais nécessite un accès à la zone DNS de votre domaine. Dans Search Console, sélectionnez "Ajouter une propriété" puis choisissez "Domaine" (et non "Préfixe d'URL"). Google vous fournit alors un enregistrement TXT à ajouter dans votre configuration DNS.

Une fois l'enregistrement publié, la propagation DNS prend généralement quelques minutes, parfois jusqu'à 48 heures selon votre hébergeur. Google vérifie ensuite automatiquement l'enregistrement. Point crucial : cet enregistrement doit rester en place indéfiniment — sa suppression révoque la vérification et l'accès aux données.

Quelles erreurs faut-il absolument éviter lors de la migration ?

La première erreur consiste à supprimer les propriétés individuelles existantes dès que la domain property est active. Vous perdrez alors l'historique de ces propriétés, qui n'est pas rétroactivement fusionné dans la domain property. Conservez les anciennes propriétés en parallèle pendant au moins 3-6 mois pour comparer les données et valider la cohérence.

Deuxième piège : négliger la configuration des utilisateurs et permissions. Comme mentionné, une domain property donne accès à tous les sous-domaines. Auditez vos accès actuels avant de migrer et documentez clairement qui doit avoir accès à quoi. Dans certains cas, maintenir des propriétés individuelles avec permissions restreintes reste préférable.

Comment vérifier que la configuration fonctionne correctement après migration ?

Testez les demandes de suppression d'URL sur différents sous-domaines pour confirmer que la domain property les couvre bien. Vérifiez également que les données de performance apparaissent correctement pour chaque sous-domaine dans les filtres de rapports.

Comparez les métriques clés (impressions, clics, pages indexées) entre vos anciennes propriétés individuelles et la nouvelle domain property filtrée sur le même sous-domaine. Des écarts mineurs sont normaux, mais des différences importantes signalent un problème de configuration ou de périmètre.

• Obtenir un accès administrateur à la zone DNS du domaine racine avant de démarrer
• Ajouter l'enregistrement TXT fourni par Search Console dans la configuration DNS
• Attendre la propagation DNS complète (vérifiable via des outils comme whatsmydns.net)
• Conserver les propriétés individuelles existantes en parallèle pendant 3-6 mois minimum
• Auditer et reconfigurer les permissions utilisateurs en tenant compte de la visibilité élargie
• Tester les fonctionnalités critiques (suppressions d'URL, inspection d'URL) sur plusieurs sous-domaines