You moved to HTTPS, but Google still shows the HTTP version in search results. Or worse — both versions appear, competing for the same keywords. This is not a rare edge case. It happens when the signals that tell Google which version is canonical are missing, conflicting or broken.
The problem is not that Google prefers HTTP. Google prefers HTTPS. But preference does not override missing or contradictory signals. If both versions are accessible, both can be crawled, and if the canonical and redirect signals are unclear, both can be indexed.
This guide explains why Google indexes both HTTP and HTTPS versions, how to confirm the problem, and what to fix first. The result: one indexed version, the HTTPS one.
How to confirm both versions are indexed
Before fixing, confirm the problem. Three checks.
Check 1: Search with site: and protocol. Run site:yourdomain.com in Google. If you see results with http:// and results with https:// for the same page, both are indexed. This is not definitive — Google may show the HTTP URL as a display choice — but it is a strong signal.
Check 2: Google Search Console URL Inspection. Inspect the HTTPS URL. Check the status. Then inspect the HTTP URL. If both return URL is on Google, both are indexed. If the HTTP URL returns URL is not on Google, the problem is smaller — but the HTTP URL may still be crawled and treated as a duplicate.
Check 3: Google cache checker. Use the Google cache checker on both URLs. If both have cached versions, Google has processed both. The cached version of the HTTP URL may be older, but its presence confirms indexing.
If both versions are indexed, the cause is one of four signal failures below.
Reason 1: no redirect from HTTP to HTTPS
The most direct cause. If the HTTP version of a page returns 200 OK instead of a 301 redirect to the HTTPS version, Google can crawl and index both.
This happens when the server is configured to serve content on both protocols, or when the redirect is misconfigured. A common scenario: the redirect exists for the homepage but not for inner pages. Or the redirect was added but then removed during a server migration.
How to check: use the URL redirect checker on the HTTP version. The tool shows the full chain of hops. If the final status is 200 and the final URL is still HTTP, there is no redirect. If the chain goes HTTP → HTTPS but the HTTPS URL returns 200, the redirect exists.
The fix: add a 301 redirect from every HTTP URL to its HTTPS equivalent. The redirect should be direct — one hop, not a chain. If the HTTP version of a page redirects to the HTTPS homepage instead of the HTTPS version of the same page, Google may treat the HTTP page as a soft 404 or a separate entity.
Reason 2: canonical points to the HTTP version
If the HTTPS page has a canonical tag pointing to the HTTP version, Google receives a direct instruction: the HTTP version is canonical. The HTTPS version is a duplicate. This is counterintuitive but happens more often than expected, especially after migrations where the canonical tag was hardcoded or generated by a CMS that still uses the old protocol.
How to check: use the canonical tag checker on the HTTPS URL. The tool shows the canonical value. If it starts with http://, that is the problem. If the canonical is missing entirely, Google chooses on its own — and may choose the HTTP version if it has more signals (older links, more internal links).
The fix: ensure the canonical tag on the HTTPS page points to the HTTPS URL. The canonical should be self-referencing for the preferred version. If the CMS generates canonicals dynamically, check the protocol setting. If canonicals are hardcoded, update the template.
For a broader check of canonical issues across the site, the article on why canonical tags are ignored covers the common reasons Google may override the tag.
Reason 3: internal links use HTTP URLs
Internal links are a signal. If most internal links on the site point to the HTTP version of a page, Google sees the HTTP version as more important. Even if the canonical tag says HTTPS, the link signal pulls in the opposite direction.
This happens when the site has mixed content or when navigation menus, footers or widgets were not updated after the HTTPS migration. A single link in the main menu to an HTTP URL can send a strong signal, especially if it appears on every page.
How to check: use the internal links checker on a few key pages. Look for internal links that start with http:// instead of https://. Also check the rendered HTML — some CMS or plugins may generate HTTP links dynamically.
The fix: update all internal links to use HTTPS. Start with navigation menus, footers and sidebars — these appear site-wide. Then check content links. If the CMS has a setting for the site URL, ensure it uses HTTPS. If links are hardcoded in templates, update the templates.
Reason 4: sitemap includes HTTP URLs
The sitemap tells Google which URLs are important. If the sitemap includes HTTP URLs, Google may crawl and index those URLs, even if the canonical and redirect signals point to HTTPS.
This is common after a migration where the sitemap generator was not updated. Or when the sitemap includes both protocols because the CMS generates URLs from a database that still has old entries.
How to check: open the sitemap and search for http://. If any URLs use HTTP, that is a signal conflict. Use the sitemap checker to validate the sitemap and see the URLs it includes.
The fix: update the sitemap to include only HTTPS URLs. If the sitemap is generated dynamically, check the protocol setting in the CMS or sitemap plugin. If it is static, regenerate it after updating the site URL configuration.
How to fix duplicate indexing: priority order
Not all fixes are equal. Some signals are stronger than others. This order gives the fastest results.
Step 1: Add the 301 redirect. This is the strongest signal. A 301 from HTTP to HTTPS tells Google the move is permanent. Do this first. If the redirect is already in place but broken (chain, loop, wrong target), fix it before anything else.
Step 2: Fix the canonical tag. After the redirect, the canonical should point to HTTPS. If the canonical points to HTTP, Google may still hesitate. The canonical reinforces the redirect signal.
Step 3: Update internal links. This takes longer but is necessary for long-term stability. Start with site-wide elements (menu, footer). Then update content links page by page.
Step 4: Update the sitemap. This is a supporting signal, not a primary one. But a sitemap with HTTP URLs can slow down consolidation. Fix it after the redirect and canonical are correct.
After all four fixes, request re-indexing of the HTTPS URL in Google Search Console. Use URL Inspection → Request Indexing. This puts the HTTPS version in a priority queue.
How to verify the fix
Verification takes time. Google needs to re-crawl the HTTP URL, see the redirect, and process the HTTPS version as the canonical. This can take days or weeks, depending on crawl frequency.
Check 1: search for site:yourdomain.com and look for HTTP URLs. If they disappear, the fix is working. If they remain, check the redirect again — it may be cached or misconfigured.
Check 2: use the Google cache checker on the HTTP URL. If the cache shows the HTTPS version, Google has processed the redirect. If the cache still shows HTTP content, the redirect is not being followed.
Check 3: Google Search Console → Pages report. Look for the HTTP URL in the Page indexing section. If it moves to Page with redirect, the redirect is recognized. If it stays as Duplicate, Google chose different canonical, the canonical signal may need reinforcement.
If the HTTP URL remains indexed after four to six weeks despite correct redirects and canonicals, check for external links pointing to the HTTP version. Google may keep the HTTP URL indexed if it has significant external link equity. In that case, the HTTP URL may need to stay as a redirect indefinitely — Google will eventually consolidate.
FAQ
Does Google prefer HTTPS over HTTP?
Yes. Google uses HTTPS as a lightweight ranking signal. But preference does not mean Google will automatically ignore the HTTP version. If both are accessible and the signals are unclear, Google can index both. The preference is a tiebreaker, not a replacement for correct redirects and canonicals.
Can I use a 302 redirect instead of 301?
No. A 302 tells Google the move is temporary. Google may keep the HTTP URL indexed and wait for it to return. Use 301 for permanent HTTPS migration. If you used 302, change it to 301 as soon as possible.
What if the HTTP version has better rankings than HTTPS?
This is a signal that the migration was incomplete. The HTTP version may have accumulated more links and authority over time. The fix is not to keep HTTP — it is to consolidate signals to HTTPS. Ensure the 301 passes authority, update internal links, and wait for Google to consolidate. Rankings should transfer to HTTPS after consolidation.
How long does consolidation take?
For small sites, a few days to two weeks. For larger sites or sites with many external links to HTTP URLs, four to eight weeks. The timeline depends on crawl frequency and the strength of the conflicting signals.
Should I block HTTP in robots.txt?
No. Blocking HTTP in robots.txt prevents Google from crawling the HTTP URL, which means Google cannot see the redirect. If Google cannot crawl the HTTP URL, it may keep it indexed based on old signals. Use a 301 redirect, not a robots.txt block.
