Pourquoi HTTP et HTTPS créent-ils deux index distincts dans la Search Console ?

Google indexe-t-il vraiment HTTP et HTTPS séparément ?

Oui, et c'est un point que beaucoup de praticiens sous-estiment. Google traite HTTP et HTTPS comme deux sites distincts, chacun avec son propre budget crawl, son propre index, et ses propres signaux de ranking. La Search Console reflète cette séparation en créant deux propriétés distinctes.

Concrètement, si ton site migre de http://exemple.com vers https://exemple.com, Google ne bascule pas instantanément tout l'index. Il crawle la nouvelle version HTTPS, découvre les redirections 301, et réindexe progressivement. Pendant cette transition, les deux versions coexistent dans l'index avec des métriques potentiellement différentes : pages indexées, couverture, Core Web Vitals, backlinks comptabilisés.

Pourquoi cette distinction pose-t-elle problème lors d'une migration ?

Parce que les erreurs de configuration explosent quand tu ne surveilles qu'une seule propriété. Une redirection cassée, un canonical mal configuré, ou un sitemap XML pointant encore vers HTTP peuvent créer des signaux contradictoires. Google se retrouve avec deux versions concurrentes, et tu perds de la visibilité sans même t'en apercevoir.

Pire encore : certains backlinks continuent de pointer vers l'ancienne version HTTP. Si les redirections ne sont pas étanches (codes 302 au lieu de 301, chaînes de redirections, timeouts), l'autorité se fragmente entre les deux protocoles. Tu peux observer des URLs HTTP encore indexées des semaines après la migration, cannibalisant le ranking de leurs homologues HTTPS.

Quelles métriques divergent concrètement entre HTTP et HTTPS ?

Premier constat terrain : le nombre de pages indexées. La propriété HTTP peut afficher 1 200 URLs tandis que HTTPS en montre 980. Cette divergence indique souvent des problèmes de canonicalisation ou des pages orphelines non redirigées. Les erreurs 404 se multiplient également sur l'ancienne propriété, signalant des liens internes mal migrés.

Les données de performance (clics, impressions, CTR) se répartissent aussi entre les deux propriétés pendant la transition. Si tu ne surveilles que HTTPS, tu rates une partie du trafic qui transite encore par les anciennes URLs. Les Core Web Vitals peuvent également diverger, surtout si la migration HTTPS s'accompagne de changements d'infrastructure (CDN, certificats, HTTP/2).

• Créer deux propriétés Search Console distinctes (HTTP et HTTPS) pour tout site en migration ou ayant migré récemment
• Surveiller l'écart du nombre de pages indexées entre les deux versions comme indicateur de problèmes de redirection
• Vérifier que les sitemaps XML ne référencent que la version HTTPS après migration
• Auditer les chaînes de redirections : chaque URL HTTP doit rediriger en 301 direct vers son équivalent HTTPS, sans étapes intermédiaires
• Contrôler que les balises canonical pointent systématiquement vers la version HTTPS, y compris dans les templates dynamiques

Cette déclaration est-elle cohérente avec les observations terrain ?

Totalement. Les migrations HTTPS ratées que j'ai auditées ces dernières années confirment ce pattern : la Search Console devient schizophrène quand les redirections sont bancales. Un site e-commerce avec 15 000 références avait encore 40% de ses URLs HTTP indexées six mois après migration, simplement parce que les filtres à facettes généraient des paramètres non redirigés.

Ce qui manque dans cette déclaration, c'est la durée de coexistence entre les deux protocoles. Google ne donne aucun timing indicatif. Selon mes observations, une migration propre prend entre 2 et 8 semaines pour réindexer 90% des pages sur un site de taille moyenne (5 000-20 000 URLs). Mais les sites avec un budget crawl limité ou des erreurs de configuration peuvent traîner des résidus HTTP pendant des mois. [A vérifier] sur des sites de très grande taille (500 000+ URLs).

Quels sont les pièges que Google ne mentionne pas ?

Premier piège : les sous-domaines. Si tu as www.exemple.com et exemple.com, la combinaison HTTP/HTTPS te donne quatre propriétés Search Console à surveiller. J'ai vu des migrations où le trafic se diluait entre ces quatre versions, avec des canonical contradictoires selon les sections du site. Le bordel complet.

Deuxième piège : les versions mobiles séparées (m.exemple.com). Si ton site mobile utilise encore un sous-domaine distinct, tu multiplies par deux le nombre de propriétés à monitorer. Et si la migration HTTPS n'a pas été synchronisée entre desktop et mobile, tu te retrouves avec des annotations alternate/canonical asymétriques entre HTTP et HTTPS.

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

Pour les sites natifs HTTPS lancés après 2018-2019, la question ne se pose même pas. Pas de version HTTP, pas de problème. Mais pour les anciens sites qui ont migré, la propriété HTTP reste pertinente comme outil de détection d'erreurs résiduelles, même des années après.

Un cas particulier : les sites avec redirections serveur avant que Google ne crawle. Si ton serveur redirige HTTP vers HTTPS au niveau infrastructure (HSTS preload, redirection Nginx/Apache en amont), Google ne verra jamais la version HTTP. Techniquement, elle existe, mais ne sera jamais crawlée ni indexée. Dans ce scénario, la propriété HTTP Search Console restera vide, ce qui est bon signe.

Que faut-il faire concrètement après une migration HTTPS ?

Premier réflexe : créer ou conserver les deux propriétés Search Console (HTTP et HTTPS) et les comparer quotidiennement pendant les 8 premières semaines. Configure des alertes sur l'écart du nombre de pages indexées. Un delta qui persiste ou s'aggrave au-delà de 15 jours signale un problème structurel.

Ensuite, exporte la liste des URLs encore indexées en HTTP depuis la Search Console. Passe-les une par une dans un crawler (Screaming Frog, Oncrawl) pour vérifier le code de redirection. Toute réponse autre qu'un 301 propre vers l'équivalent HTTPS exact est un bug à corriger immédiatement. Les 302, les chaînes de redirections, et les 404 fragmentent ton autorité.

Quelles erreurs éviter absolument ?

Ne supprime jamais la propriété HTTP de la Search Console après une migration, même si elle semble vide. Elle reste ton canari dans la mine : si des URLs HTTP réapparaissent dans l'index des mois plus tard, c'est le signe d'un problème (lien interne oublié, sitemap corrompu, canonical dérivé). Garde cette propriété active pendant au moins un an.

Deuxième erreur classique : ne surveiller que les métriques de trafic. Les clics et impressions peuvent rester stables même si l'index se fragmente, parce que les deux versions rankent partiellement. Ce n'est qu'en croisant avec le nombre de pages indexées que tu détectes la cannibalisation. Un site qui perd 30% de pages indexées en HTTPS mais garde 90% de son trafic a simplement concentré ses positions sur moins d'URLs, ce qui le rend vulnérable aux mises à jour d'algorithme.

Comment vérifier que mon site est conforme ?

Utilise l'outil d'inspection d'URL de la Search Console sur un échantillon représentatif de pages. Vérifie que la version canonique détectée par Google est bien HTTPS, que le sitemap référencé est HTTPS, et que les liens internes découverts pointent vers HTTPS. Si Google trouve encore des liens HTTP dans ton maillage interne, c'est que ton CMS ou tes templates génèrent des URLs relatives mal configurées.

Contrôle également les backlinks via la Search Console. Filtre par protocole (HTTP vs HTTPS). Si des backlinks de qualité pointent massivement vers HTTP, évalue la possibilité de contacter les sites référents pour mise à jour. Sinon, assure-toi que tes 301 sont bulletproof et que le PageRank transite correctement.

• Créer les deux propriétés Search Console (HTTP et HTTPS) avant toute migration et les monitorer en parallèle
• Vérifier que 100% des redirections HTTP → HTTPS sont des 301 permanentes, sans chaînes ni détours
• Auditer les balises canonical sur un échantillon de pages : elles doivent toutes pointer vers HTTPS
• Soumettre un sitemap XML HTTPS uniquement, et supprimer tout référencement des URLs HTTP dans les sitemaps
• Configurer HSTS (HTTP Strict Transport Security) avec preload pour forcer le navigateur et les bots vers HTTPS
• Exporter mensuellement la liste des URLs HTTP encore indexées et investiguer chaque cas