What happens when Google occasionally indexes HTTP instead of HTTPS even after an SSL migration?

Quick SEO Quiz

Test your SEO knowledge in 3 questions

Less than 30 seconds. Find out how much you really know about Google search.

🕒 ~30s 🎯 3 questions 📚 SEO Google

Official statement

If HTTP and HTTPS coexist without redirection or canonical, Google may index the HTTP version instead of HTTPS. To correct this, implement a 301 redirect from HTTP to HTTPS and/or add a rel=canonical pointing to HTTPS to clearly signal which version is canonical.

37:24

🎥 Source video

Extracted from a Google Search Central video

⏱ 1h14 💬 EN 📅 04/06/2020 ✂ 44 statements

Watch on YouTube (37:24) →

✂ Other statements from this video 43 ▾

📅

Official statement from June 4, 2020 (5 years ago)

⚠ A more recent statement exists on this topic Why could your HTTPS site display an incorrect name and favicon in Google due to... John Mueller · February 17, 2026 View statement →

TL;DR

Google may index the HTTP version of a site even after a HTTPS migration if there is no clear 301 redirect or canonical tag indicating which version to prioritize. This ambiguity creates invisible technical duplication that weakens ranking and dilutes ranking signals. The solution lies in systematically redirecting HTTP to HTTPS paired with a canonical pointing to HTTPS, to eliminate any ambiguity.

What you need to understand

Why is Google hesitant between HTTP and HTTPS?

When HTTP and HTTPS coexist without clear directive, Googlebot faces two distinct URLs displaying the same content. The crawler explores both versions, collects conflicting signals, and may rule against HTTPS — even months after an SSL migration.

The canonical URL selection algorithm relies on dozens of criteria: redirects, canonical tags, internal links, external backlinks, HSTS, XML sitemaps. If no strong signal emerges, Google sometimes favors the HTTP version simply because it was indexed first or receives more historical backlinks.

What is a canonical URL and why does it matter so much?

Canonicalization refers to the process by which Google decides which URL to display in the SERPs among several similar versions. Each duplication — HTTP/HTTPS, www/non-www, trailing slash — creates a variant that the engine must arbitrate.

The problem becomes critical when ranking signals fragment: backlinks point to HTTP, social shares to HTTPS, internal links mix the two. PageRank and authority disperse instead of concentrating on a single URL.

How can you tell which version Google has actually indexed?

The Search Console displays the canonical URL selected by Google in the URL Inspection tool, under "Canonical URL selected by Google." If this value differs from your declared canonical, it signals a signaling conflict.

A site:example.com search in Google sometimes reveals a mix of HTTP and HTTPS in the results, proof that indexing remains ambiguous. Server logs confirm if Googlebot continues to actively crawl the HTTP version when it should be redirected.

301 Redirect HTTP → HTTPS: server-side signal indicating that HTTP is outdated and HTTPS is the definitive version
rel=canonical tag: HTML directive confirming which URL should be considered as the reference
HSTS (HTTP Strict Transport Security): security header instructing browsers and crawlers to use only HTTPS
Consistent internal links: internal linking pointing exclusively to HTTPS to reinforce the signal
XML Sitemap in HTTPS: submits only HTTPS URLs for indexing, eliminating any confusion

SEO Expert opinion

Is this directive consistent with field observations?

Absolutely. We regularly observe sites migrated to HTTPS for several years that retain indexed HTTP URLs, especially on less crawled sections or old pages. Google has no reason to automatically detect that a migration has occurred if both versions remain accessible as 200.

The classic case: a site with a partial 301 redirect — the homepage and a few main pages redirect, but hundreds of deep pages remain accessible via HTTP. External backlinks continue to point to HTTP, reinforcing this version in the algorithm's view.

What nuances should be added to this recommendation?

Google talks about “301 redirect and/or canonical,” but let's be clear: the 301 redirect is the strongest signal and should always be implemented first. The canonical alone is not sufficient — it's a directive that Google may choose to ignore if it deems other signals more reliable.

In practice, it is necessary to combine both mechanisms: 301 redirect to permanently close access to HTTP, and canonical HTTPS in the <head> of the HTTPS pages to confirm the intent. Adding HSTS further strengthens this signal and prevents any rollback. [To verify]: no public data from Google quantifies the relative weight of each signal in the canonicalization algorithm — these priorities are inferred from empirical observations.

In what cases does this rule not fully apply?

Some sites intentionally maintain a HTTP version for technical reasons — public APIs, webhooks, legacy systems that do not support SSL. In this case, it is essential to isolate these URLs in a dedicated subdomain and block their indexing via robots.txt or noindex.

Full-client JavaScript sites sometimes pose a specific problem: if canonical tags are injected on the client side after the first render, Googlebot may index before the tag is detected. The solution lies in a server-side 301 redirect, which is non-negotiable, or SSR rendering exposing the canonical in the initial HTML.

Warning: A poorly managed HTTPS migration can lead to a 20% to 40% traffic drop for several weeks if Google continues to serve HTTP URLs in the SERPs. Checking HTTPS indexing in the Search Console must be part of the mandatory post-migration checklist.

Practical impact and recommendations

What concrete steps should be taken to enforce HTTPS as the canonical version?

The first step is to set up a permanent 301 redirect on the server side (Apache, Nginx, IIS) to redirect all HTTP traffic to HTTPS. This redirect must be global, affecting all URLs without exception, and return the HTTP 301 code — not 302 or 307, which signal a temporary move.

Next, add a link <link rel="canonical"> in the <head> of all HTTPS pages, pointing to their own HTTPS URL. Even if it seems redundant, this signal confirms to Googlebot that HTTPS is indeed the reference version, even in the presence of variants (URL parameters, trailing slash, etc.).

Implement the HSTS (Strict-Transport-Security) header with a long duration (min. 1 year) to force browsers and crawlers to never attempt to access the site over HTTP again. This header is configured on the server side and is added to HTTPS responses.

What mistakes should be avoided during the HTTPS migration?

The most common mistake is chain redirecting: HTTP → HTTPS non-www → HTTPS www, for example. Each additional hop slows the crawl, dilutes PageRank, and may cause Googlebot to abandon before reaching the final URL. Always redirect in a single leap to the definitive canonical URL.

Another classic trap: leaving internal links in HTTP in the source code, XML sitemaps, or hreflang tags. Google interprets these links as a signal that HTTP remains a legitimate version. Moving all assets (CSS, JS, images) to HTTPS or using relative protocol // eliminates mixed content that weakens the HTTPS signal.

Don't forget to submit a new HTTPS sitemap in the Search Console and monitor index coverage reports for at least 4 to 6 weeks. Google may take weeks to recrawl an average-sized site fully and switch all indexed URLs.

How can you check that the HTTPS migration is genuinely effective?

Use the URL Inspection tool in the Search Console on a representative sample of pages. Check that "Canonical URL selected by Google" shows the HTTPS version. If Google still returns an HTTP URL, it means the signals remain ambiguous.

Conduct a Screaming Frog or Oncrawl crawl in Googlebot user-agent mode to detect pages still accessible via HTTP 200, chain redirects, contradictory canonicals, and mixed internal links. Filter indexed HTTP URLs via site:example.com inurl:http:// in Google to find pages still present in the index under their non-secure version.

Set up a global permanent 301 redirect HTTP → HTTPS on the server side
Add <link rel="canonical" href="https://..."> on all HTTPS pages
Enable the HSTS header with max-age of at least 31536000 seconds (1 year)
Update all internal links, XML sitemaps, hreflang, and canonicals to point to HTTPS
Check in the Search Console that the selected canonical URL is indeed in HTTPS for a representative sample
Crawl the site with Screaming Frog to detect the last accessible HTTP URLs or chain redirects

The HTTPS migration is not just about installing an SSL certificate — it requires precise technical orchestration to enforce HTTPS as the only legitimate version in Google’s eyes. 301 redirects, HTTPS canonical, HSTS, and coherence in internal linking must converge to eliminate any ambiguity. These optimizations can be complex to manage alone, especially on large sites or with heterogeneous technical architectures. Engaging a specialized SEO agency can ensure each step is secured, anticipate common pitfalls, and guarantee that the migration does not result in temporary or permanent visibility loss.

❓ Frequently Asked Questions

Google peut-il indexer HTTP même si j'ai un certificat SSL actif ?

Oui, l'existence d'un certificat SSL ne suffit pas. Si les deux versions HTTP et HTTPS restent accessibles en 200 sans redirection, Google peut choisir d'indexer HTTP s'il juge que les signaux (backlinks, canonical, liens internes) favorisent cette version.

Faut-il privilégier la redirection 301 ou la balise canonical pour forcer HTTPS ?

La redirection 301 est le signal le plus fort et doit toujours être implémentée en priorité. Le canonical HTTPS vient en complément pour confirmer l'intention, mais ne remplace jamais une redirection serveur.

Combien de temps Google met-il à basculer toutes les URLs de HTTP vers HTTPS après migration ?

Cela dépend de la taille du site et de sa fréquence de crawl, mais compter entre 2 et 6 semaines pour un site moyen. Les sites à faible crawl budget peuvent prendre plusieurs mois si aucune action proactive (sitemap, crawl forcé) n'est menée.

Le header HSTS est-il obligatoire ou simplement recommandé ?

Il n'est pas strictement obligatoire pour l'indexation, mais fortement recommandé. HSTS force navigateurs et crawlers à ne plus jamais tenter HTTP, éliminant définitivement le risque de duplication et renforçant le signal HTTPS.

Que faire si Google continue à indexer HTTP malgré redirections et canonical ?

Vérifier que la redirection 301 fonctionne bien pour toutes les URLs (pas seulement la homepage), que les liens internes et sitemaps pointent vers HTTPS, et forcer un recrawl via la Search Console. Si le problème persiste, analyser les logs serveur pour identifier d'éventuels backlinks ou signaux contradictoires.

🏷 Related Topics

HTTPS redirection 301 canonical indexation duplication migration SSL HSTS crawl

Crawl & Indexing HTTPS & Security AI & SEO Redirects

🎥 From the same video 43

Other SEO insights extracted from this same Google Search Central video · duration 1h14 · published on 04/06/2020

🎥 Watch the full video on YouTube →

Related statements

« Previous

Category/List Pages: Don't Default to Noindex...

FAQ markup: acceptable even if added for the rich ...

« Back to results