Comment isoler le trafic SEO d'un sous-domaine ou d'une version mobile dans Search Console ?

Pourquoi cette segmentation des propriétés est-elle indispensable ?

Google ne propose pas de filtres natifs dans Search Console pour isoler le trafic d'un sous-domaine ou d'une version mobile au sein d'une seule propriété. La seule méthode officiellement supportée consiste à créer des propriétés distinctes dès la configuration initiale.

Concrètement, si vous gérez blog.example.com et shop.example.com, vous devez enregistrer trois propriétés : une pour le domaine principal, une pour chaque sous-domaine. Même logique pour les versions m.example.com sur mobile. C'est la seule façon d'obtenir des rapports de performance, d'indexation et de Core Web Vitals isolés.

Quelle différence entre propriété de domaine et propriété d'URL ?

Search Console propose deux types de propriétés. La propriété de domaine (domain property) agrège toutes les déclinaisons : HTTP, HTTPS, www, non-www, tous les sous-domaines. Pratique pour une vue d'ensemble, mais elle écrase justement la granularité que vous cherchez.

La propriété d'URL (URL prefix property) cible une adresse précise : https://blog.example.com uniquement. C'est celle qu'il faut multiplier pour segmenter. Le revers : plus vous avez de sous-domaines actifs, plus vous multipliez les interfaces à surveiller.

Quels sont les risques si on zappe cette configuration ?

Sans segmentation, vous pilotez à l'aveugle. Si votre sous-domaine blog perd 40 % de trafic mais que le shop compense, la vue agrégée masque le problème. Vous découvrez le souci des semaines trop tard, quand les revenus chutent ou qu'un client remonte une alerte.

Pire, les signaux d'erreurs d'indexation ou de Core Web Vitals dégradés se noient dans un rapport global. Vous ne savez pas quelle partie du site corrige en priorité. C'est du temps perdu et des décisions basées sur du bruit statistique.

• Créez une propriété URL distincte pour chaque sous-domaine ou version mobile que vous souhaitez mesurer indépendamment.
• Conservez également une propriété de domaine pour la vue consolidée, utile pour les audits globaux.
• Documentez la structure de vos propriétés dans un wiki interne : qui a accès, quel périmètre couvre chaque propriété.
• Vérifiez régulièrement que les nouvelles déclinaisons (m.example.com lancé en urgence, nouveau sous-domaine marketing) sont bien trackées.
• Anticipez la charge de travail : 10 sous-domaines actifs = 10 dashboards à consulter quotidiennement.

Cette déclaration est-elle cohérente avec les pratiques terrain observées ?

Oui, mais elle passe sous silence un irritant majeur : l'interface de Search Console n'est pas conçue pour gérer facilement plusieurs dizaines de propriétés. Les agences qui pilotent des clients avec 15 sous-domaines passent un temps fou à jongler entre les comptes, sans vue consolidée intelligente.

Google pousse la propriété de domaine comme solution miracle, mais dès que tu veux isoler une version mobile spécifique ou un sous-domaine de test, tu retombes sur le système de propriétés URL. Résultat : tu multiplies les accès, les permissions, les exports. L'API Search Console existe, mais tous les praticiens n'ont pas les compétences pour automatiser.

Quelles nuances faut-il apporter à cette recommandation ?

Mueller ne précise pas à partir de quand il devient contre-productif de multiplier les propriétés. Si ton site a 50 sous-domaines géographiques (fr.example.com, de.example.com…), créer 50 propriétés devient ingérable sans outillage custom. Dans ce cas, une stratégie hybride s'impose : propriétés URL pour les 5-10 sous-domaines critiques, propriété de domaine pour le reste, et extraction de données via l'API pour reconstituer des vues métier.

Autre angle mort : les versions AMP. Si tu sers du contenu AMP depuis un sous-domaine dédié (amp.example.com), tu dois là aussi créer une propriété distincte. Mais Google ne documente nulle part comment croiser proprement les données AMP et non-AMP pour éviter les doubles comptes dans tes dashboards analytics. [À vérifier] en croisant avec les logs serveur.

Dans quels cas cette approche devient-elle un frein opérationnel ?

Quand tu gères un écosystème de marques avec des dizaines de sites et sous-domaines, la multiplication des propriétés Search Console crée un goulot d'étranglement humain. Les équipes passent plus de temps à exporter et concaténer des CSVs qu'à analyser les tendances.

De plus, les alertes automatiques de Search Console (erreurs d'indexation, problèmes de sécurité) sont envoyées propriété par propriété. Si tu n'as pas configuré un système de centralisation (webhook, IFTTT, Zapier, ou script maison), tu rates des alertes critiques noyées dans 40 boîtes mail différentes. C'est du vécu.

Que faut-il faire concrètement pour segmenter correctement son trafic ?

Commence par cartographier l'architecture de ton site : liste tous les sous-domaines actifs (blog, shop, m., amp., api., etc.). Identifie ceux qui servent du contenu indexable, et ignore ceux purement techniques (cdn., admin.). Pour chaque sous-domaine indexable, crée une propriété URL dans Search Console.

Assure-toi que les fichiers de vérification (HTML, DNS TXT) sont bien en place pour chaque propriété. Si tu utilises Google Tag Manager, vérifie que la balise de vérification est déployée sur tous les environnements, y compris les versions mobiles. Un sous-domaine non vérifié = zéro donnée exploitable.

Quelles erreurs éviter lors de la configuration multi-propriétés ?

Ne crée pas de propriété pour des variantes canonicalisées. Si m.example.com redirige systématiquement vers www.example.com, inutile de multiplier : Google ne verra qu'une seule version. Inversement, si les deux versions coexistent (erreur de config), tu vas observer des données fragmentées et des signaux de contenu dupliqué.

Évite aussi de mélanger propriétés URL et propriétés de domaine sans documentation claire. Les équipes perdent le fil, accordent les mauvais accès, et finissent par travailler sur des datasets incomplets. Un fichier partagé (Google Sheets, Notion) listant chaque propriété, son URL exacte, et les personnes ayant accès est un minimum syndical.

Comment vérifier que la segmentation fonctionne correctement ?

Compare les totaux de clics dans chaque propriété URL avec la somme affichée dans la propriété de domaine. Si les chiffres ne collent pas (écart > 5 %), c'est qu'un sous-domaine n'est pas tracké, ou qu'une redirection fausse les compteurs. Croise aussi avec Google Analytics (propriété GA4 segmentée par hostname) pour valider la cohérence.

Teste les rapports de couverture : déclenche volontairement une erreur 404 sur un sous-domaine, attends 48h, vérifie qu'elle remonte bien dans la propriété correspondante et pas ailleurs. Si l'alerte apparaît dans la mauvaise propriété, c'est que ta configuration DNS ou tes redirections créent des fuites.

• Cartographier tous les sous-domaines indexables du site
• Créer une propriété URL distincte pour chaque sous-domaine critique
• Vérifier chaque propriété via DNS TXT ou fichier HTML
• Documenter la structure dans un fichier partagé avec accès et périmètres
• Croiser les données Search Console / GA4 pour valider la cohérence
• Tester les alertes d'erreurs pour s'assurer qu'elles remontent dans la bonne propriété