Why do HTTP and HTTPS create two distinct indexes in Search Console?

Does Google really index HTTP and HTTPS separately?

Yes, and this is something that many practitioners underestimate. Google treats HTTP and HTTPS as two distinct sites, each with its own crawl budget, its own index, and its own ranking signals. Search Console reflects this separation by creating two distinct properties.

In practice, if your site migrates from http://example.com to https://example.com, Google does not instantly switch the entire index. It crawls the new HTTPS version, discovers the 301 redirections, and gradually re-indexes. During this transition, both versions coexist in the index with potentially different metrics: indexed pages, coverage, Core Web Vitals, counted backlinks.

Why does this distinction cause issues during a migration?

Because configuration errors explode when you only monitor a single property. A broken redirection, a misconfigured canonical, or an XML sitemap still pointing to HTTP can create conflicting signals. Google ends up with two competing versions, and you lose visibility without even realizing it.

Worse yet: some backlinks continue to point to the old HTTP version. If the redirections are not airtight (302 codes instead of 301, redirect chains, timeouts), authority gets fragmented between the two protocols. You may observe HTTP URLs still indexed weeks after the migration, cannibalizing the ranking of their HTTPS counterparts.

What metrics actually diverge between HTTP and HTTPS?

First field observation: the number of indexed pages. The HTTP property may show 1,200 URLs while HTTPS shows 980. This divergence often indicates canonicalization issues or orphaned pages that are not redirected. 404 errors also multiply on the old property, signaling poorly migrated internal links.

Performance data (clicks, impressions, CTR) also gets split between the two properties during the transition. If you only monitor HTTPS, you miss part of the traffic that still passes through the old URLs. Core Web Vitals can also diverge, especially if the HTTPS migration is accompanied by infrastructure changes (CDN, certificates, HTTP/2).

• Create two distinct Search Console properties (HTTP and HTTPS) for any site undergoing or recently completed migration
• Monitor the gap in the number of indexed pages between the two versions as an indicator of redirection problems
• Ensure that the XML sitemaps only reference the HTTPS version after migration
• Audit the redirect chains: every HTTP URL must redirect 301 directly to its HTTPS equivalent, without intermediate steps
• Check that canonical tags consistently point to the HTTPS version, including in dynamic templates

Is this statement consistent with field observations?

Absolutely. The failed HTTPS migrations I have audited in recent years confirm this pattern: Search Console becomes schizophrenic when redirections are shaky. An e-commerce site with 15,000 references still had 40% of its HTTP URLs indexed six months after migration, simply because the faceted filters generated unredirected parameters.

What’s missing from this statement is the duration of coexistence between the two protocols. Google does not provide any indicative timing. Based on my observations, a clean migration takes between 2 and 8 weeks to reindex 90% of pages on a medium-sized site (5,000-20,000 URLs). However, sites with a limited crawl budget or configuration errors can hold on to HTTP remnants for months. [To be verified] on very large sites (500,000+ URLs).

What traps does Google not mention?

The first trap: subdomains. If you have www.example.com and example.com, the HTTP/HTTPS combination gives you four Search Console properties to watch over. I have seen migrations where traffic diluted among these four versions, with conflicting canonicals depending on the sections of the site. Total chaos.

The second trap: separate mobile versions (m.example.com). If your mobile site still uses a separate subdomain, you double the number of properties to monitor. And if the HTTPS migration was not synchronized between desktop and mobile, you end up with asymmetric alternate/canonical annotations between HTTP and HTTPS.

When does this rule not apply?

For native HTTPS sites launched after 2018-2019, the question is moot. No HTTP version, no problem. But for older sites that have migrated, the HTTP property remains relevant as a tool for detecting residual errors, even years later.

One particular case: sites with server-side redirections before Google crawls. If your server redirects HTTP to HTTPS at the infrastructure level (HSTS preload, upstream Nginx/Apache redirection), Google will never see the HTTP version. Technically, it exists, but it will never be crawled or indexed. In this scenario, the HTTP Search Console property will remain empty, which is a good sign.

What should you do after an HTTPS migration?

First reflex: create or maintain both Search Console properties (HTTP and HTTPS) and compare them daily for the first 8 weeks. Set alerts for the gap in the number of indexed pages. A persistent or worsening delta beyond 15 days indicates a structural issue.

Next, export the list of URLs still indexed in HTTP from Search Console. Go through them one by one in a crawler (Screaming Frog, Oncrawl) to check the redirect code. Any response other than a clean 301 to the exact HTTPS equivalent is a bug to fix immediately. 302s, redirect chains, and 404s fragment your authority.

What mistakes should I absolutely avoid?

Never delete the HTTP property from Search Console after migration, even if it seems empty. It remains your canary in the mine: if HTTP URLs reappear in the index months later, it signals a problem (forgotten internal link, corrupted sitemap, derived canonical). Keep this property active for at least a year.

The second classic mistake: only monitoring traffic metrics. Clicks and impressions can remain stable even if the index fragments, because both versions rank partially. It is only by cross-referencing with the number of indexed pages that you detect cannibalization. A site that loses 30% of indexed pages in HTTPS but keeps 90% of its traffic has simply concentrated its positions on fewer URLs, making it vulnerable to algorithm updates.

How can I check that my site is compliant?

Use the URL Inspection tool in Search Console on a representative sample of pages. Check that the canonical version detected by Google is HTTPS, that the referenced sitemap is HTTPS, and that the discovered internal links point to HTTPS. If Google still finds HTTP links in your internal linking, it means your CMS or templates are generating poorly configured relative URLs.

Also check backlinks via Search Console. Filter by protocol (HTTP vs HTTPS). If quality backlinks are heavily pointing to HTTP, assess the possibility of contacting referring sites for updates. Otherwise, ensure your 301s are bulletproof and that PageRank passes correctly.

• Create both Search Console properties (HTTP and HTTPS) before any migration and monitor them in parallel
• Verify that 100% of HTTP → HTTPS redirections are permanent 301s, with no chains or detours
• Audit the canonical tags on a sample of pages: they should all point to HTTPS
• Submit a sitemap XML for HTTPS only, and remove any references to HTTP URLs in the sitemaps
• Configure HSTS (HTTP Strict Transport Security) with preload to force the browser and bots to HTTPS
• Monthly export the list of still indexed HTTP URLs and investigate each case