Official statement
Other statements from this video 43 ▾
- 2:22 What should you do if your site lost traffic after a Core Update without making any mistakes?
- 2:22 Are Core Web Vitals Really Going to Transform Your SEO Strategy?
- 3:50 Does a ranking drop after a Core Update really indicate an issue with your site?
- 3:50 Should You Really Wait Before Optimizing Core Web Vitals?
- 3:50 Why is Google delaying the complete transition to the Mobile-First Index?
- 7:07 Can Google really delay Mobile-First Indexing indefinitely?
- 11:00 Why doesn't Google canonicalize URLs with fragments in sitelinks and rich results?
- 11:00 Do URLs with fragments (#) in Search Console mean you need to rethink your tracking and analysis strategy?
- 14:34 Why do the numbers from Analytics, Search Console, and My Business never match?
- 14:35 Why do your Google metrics never align between Search Console, Analytics, and Business Profile?
- 16:37 How are FAQ clicks really counted in Search Console?
- 18:44 Are mobile and desktop accordions really neutral for SEO?
- 18:44 Is it true that mobile accordion hidden content is indexed as visible content?
- 29:45 Does the rel=canonical via HTTP header really still work?
- 30:09 Does the HTTP header rel=canonical really work to manage duplicate content?
- 31:00 Why does Search Console still show 'PC Googlebot' on recent sites when Mobile-First Index is supposed to be the standard?
- 31:02 Is it true that all sites indexed after July 2019 default to Mobile-First Indexing?
- 33:28 Why does Google emphasize textual context in Search Console feedback?
- 33:31 Are Search Console tools really enough to solve your indexing problems?
- 33:59 Why are your pages still not indexed after 60 days in Search Console?
- 37:53 Is it really necessary to combine both 301 redirections AND canonical tags for an HTTPS migration?
- 39:16 What really causes your sitemap to fail in Search Console and how can you effectively resolve the issue?
- 41:29 Is your brand disappearing from the SERPs for no apparent reason: can Google feedback really fix it?
- 44:07 Should you choose a subdomain or a new domain for launching a service?
- 44:34 Subdomain or New Domain: What Does Google Really Think for SEO?
- 44:34 Do Google penalties really transfer between domains and subdomains?
- 45:27 Do Google penalties really spread between domains and subdomains?
- 48:24 Should you really overlook PageRank when deciding between a domain and a subdomain?
- 48:33 Do links between root domains and subdomains really pass PageRank?
- 49:58 Should you really be worried about duplicate content from scraping?
- 50:14 Can you relaunch an old domain without being penalized for duplicate content by spammers?
- 50:14 Should you really report every scraping URL via the Spam Report to prompt action from Google?
- 57:15 Is it really necessary to report spam URL by URL to assist Google?
- 58:57 Why does Google refuse to show your FAQs in rich results despite perfect markup?
- 59:54 Why doesn't Google display your FAQ rich results even with perfect markup?
- 65:15 Is it possible to add FAQs to your pages just to secure rich results in SEO?
- 65:45 Can you really add a FAQ just to get the rich result without risking penalties?
- 67:27 Should you still optimize rel=next/prev tags for pagination?
- 67:58 Should you really submit all paginated pages in the XML sitemap?
- 70:10 Should you really index all category pages to optimize your crawl budget?
- 70:18 Should you really stop placing category pages in noindex?
- 72:04 Does the number of JavaScript files really slow down Google indexing?
- 72:24 Does Googlebot really render all JavaScript in a single pass?
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.
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
❓ Frequently Asked Questions
Google peut-il indexer HTTP même si j'ai un certificat SSL actif ?
Faut-il privilégier la redirection 301 ou la balise canonical pour forcer HTTPS ?
Combien de temps Google met-il à basculer toutes les URLs de HTTP vers HTTPS après migration ?
Le header HSTS est-il obligatoire ou simplement recommandé ?
Que faire si Google continue à indexer HTTP malgré redirections et canonical ?
🎥 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 →
💬 Comments (0)
Be the first to comment.