Pourquoi vos données de clics disparaissent-elles entre Search Console et Analytics après une migration HTTPS ?

Que se passe-t-il vraiment quand Google bascule votre URL vers HTTPS ?

Google ne se contente pas d'indexer passivement vos pages. Il normalise activement les URLs selon sa propre logique : protocole (HTTP vs HTTPS), sous-domaine (www ou non), trailing slash, paramètres. Quand vous migrez vers HTTPS, Google choisit la version qu'il considère comme canonique et c'est elle qui hérite de toutes les données d'impressions et de clics dans Search Console.

Concrètement ? Si votre ancienne propriété Search Console suivait uniquement HTTP, vous constaterez une chute brutale des impressions. Pas parce que votre site performe moins, mais parce que les données sont désormais attribuées à la version HTTPS que vous n'avez peut-être pas déclarée comme propriété distincte.

Pourquoi Google ne fusionne-t-il pas automatiquement les données ?

Search Console traite chaque combinaison protocole/sous-domaine comme une propriété séparée. C'est une question d'architecture technique : http://example.com et https://example.com sont deux entités distinctes du point de vue du crawler. Google ne présume pas que vous contrôlez les deux versions, même si c'est évident pour vous.

Cette séparation crée un décalage entre ce que vous observez dans Search Console et la réalité du comportement utilisateur dans Analytics. Analytics peut consolider automatiquement les versions si votre tracking est bien configuré, mais Search Console ne le fera jamais. Vous devez déclarer explicitement chaque version comme propriété pour voir l'image complète.

Comment cette logique affecte-t-elle votre suivi quotidien ?

La plupart des SEO découvrent le problème après coup, quand ils constatent une discontinuité dans leurs courbes de performance. Les impressions semblent s'effondrer, les clics disparaissent, alors que le trafic réel reste stable dans Analytics. C'est le signe classique d'un tracking éclaté entre plusieurs propriétés Search Console.

Pire encore : si vous n'avez jamais créé de propriété pour votre version HTTPS, vous ne verrez aucune donnée apparaître. Google enregistre bien les performances, mais vous n'y avez simplement pas accès tant que la propriété n'existe pas dans votre compte. Les données historiques ne sont pas rétroactives : vous ne récupérerez jamais les 3 mois où vous n'aviez pas déclaré HTTPS.

• Search Console ne fusionne jamais les données entre protocoles (HTTP/HTTPS) ou sous-domaines (www/non-www)
• Les impressions et clics sont attribués à la version canonique choisie par Google, pas celle que vous préférez
• Créer une propriété après coup ne récupère pas l'historique perdu pendant la période non surveillée
• Analytics peut consolider les versions si le tracking est unifié, mais Search Console reste cloisonné
• La version canonique de Google ne correspond pas toujours à votre balise canonical ou vos redirections

Cette recommandation de Mueller est-elle vraiment nouvelle ?

Non, et c'est justement ce qui surprend. Cette logique de séparation stricte des propriétés existe depuis la création de Search Console (ex-Webmaster Tools). Mueller ne fait que rappeler un fondamental que beaucoup de praticiens oublient ou découvrent tardivement. La vraie question : pourquoi Google ne propose-t-il toujours pas de vue unifiée pour les variantes d'un même site ?

D'autres outils (Bing Webmaster Tools, certaines suites SEO tierces) permettent de regrouper les variantes sous une même interface. Google maintient cette séparation stricte, officiellement pour éviter les confusions de propriété, officieusement peut-être pour limiter les volumes de données à traiter côté serveur. [A vérifier] : aucune déclaration officielle n'explique pourquoi cette fusion n'est pas proposée en option.

Que faire quand Google choisit une version canonique différente de la vôtre ?

C'est le cas typique où vous avez mis en place des redirections 301 parfaites, une balise canonical propre, et pourtant Google indexe une autre version. Cela arrive plus souvent qu'on ne le pense, notamment sur des sites avec plusieurs sous-domaines ou variantes régionales. Search Console vous montre alors la version que Google a décidé d'indexer, pas celle que vous imposez.

Dans ces situations, vérifier "toutes les versions" comme le conseille Mueller devient critique. Mais attention : créer 8 propriétés différentes (HTTP/HTTPS × www/non-www × différentes TLD) transforme Search Console en usine à gaz. La solution praticien : utiliser une propriété de type Domaine (validation DNS) qui agrège toutes les variantes. Sauf que cette option pose ses propres limites, notamment l'impossibilité de filtrer finement par sous-domaine.

Quelles sont les limites pratiques de ce conseil ?

Mueller suggère de "vérifier toutes les versions", mais sur un site complexe, cela peut représenter des dizaines de combinaisons. Vous avez vraiment besoin de surveiller http://www, http://non-www, https://www, https://non-www pour chaque sous-domaine significatif ? Techniquement oui, pratiquement c'est ingérable.

La vraie recommandation devrait être : forcez une version canonique via redirections strictes, vérifiez que Google la respecte dans le rapport de couverture d'index, puis surveillez uniquement cette version dans Search Console. Si Google persiste à indexer une autre variante malgré vos signaux, alors oui, créez une propriété pour cette version "rebelle" et creusez pourquoi vos directives ne sont pas respectées. [A vérifier] : dans quelle proportion Google ignore-t-il les signaux canonical explicites ? Aucune stat officielle là-dessus.

Que faut-il configurer immédiatement dans Search Console ?

Première étape : créez une propriété de type Domaine (validation DNS) si vous ne l'avez pas encore fait. Elle agrège automatiquement toutes les variantes protocole/sous-domaine. C'est la solution la plus propre pour avoir une vue d'ensemble sans jongler entre 6 propriétés différentes. Gardez vos anciennes propriétés URL actives pour l'historique, mais basculez votre monitoring quotidien sur la propriété Domaine.

Ensuite, vérifiez dans le rapport de Couverture d'index quelle version Google indexe réellement. Si vous voyez massivement indexer des URLs HTTP alors que vous avez migré HTTPS depuis 6 mois, vous avez un problème de redirections ou de signaux canonical contradictoires. C'est ce décalage qui crée l'éclatement des données entre propriétés.

Comment éviter de perdre des données lors d'une migration ?

Avant toute migration (HTTP→HTTPS, changement de domaine, refonte d'URLs), créez la nouvelle propriété Search Console en avance. N'attendez pas que la migration soit terminée. Google commence à accumuler des données dès que la propriété existe et que des URLs y sont découvertes. Si vous créez la propriété 3 semaines après la bascule DNS, vous perdez définitivement 3 semaines de données.

Parallèlement, gardez l'ancienne propriété active au moins 6 mois post-migration. Vous verrez les impressions/clics décliner progressivement sur l'ancien, croître sur le nouveau. Cette période de transition vous permet de détecter les problèmes : si l'ancien continue à recevoir 40% des impressions 2 mois après migration, c'est que Google n'a pas complètement basculé, signe de redirections incomplètes ou de liens internes cassés.

Quelle stratégie adopter pour les sites multi-variantes complexes ?

Sur un site avec plusieurs sous-domaines métier (blog.example.com, shop.example.com, support.example.com), la propriété Domaine ne suffit pas. Vous perdez la granularité par sous-domaine. Solution praticien : créez une propriété Domaine pour la vue consolidée, puis une propriété URL distincte pour chaque sous-domaine stratégique que vous voulez surveiller finement.

Oui, cela fait 4-5 propriétés à gérer. Mais c'est le seul moyen de réconcilier vue d'ensemble (propriété Domaine) et analyse détaillée (propriétés URL). Automatisez la surveillance via l'API Search Console si vous avez les ressources techniques, sinon concentrez votre monitoring quotidien sur les 2-3 propriétés qui génèrent 80% du trafic.

• Créer une propriété de type Domaine (validation DNS) pour agréger toutes les variantes protocole/sous-domaine
• Vérifier dans le rapport de Couverture quelle version canonique Google indexe réellement
• Avant toute migration, créer la nouvelle propriété Search Console au moins 2 semaines en avance
• Conserver les anciennes propriétés actives 6 mois post-migration pour suivre la transition
• Sur sites multi-sous-domaines : combiner 1 propriété Domaine (vue globale) + propriétés URL par sous-domaine stratégique
• Exporter régulièrement les données via API ou manuellement pour constituer un historique unifié hors Search Console