HTTP vs HTTPS canonicalization
https://example.com and http://example.com are different URLs, so serving content on both creates duplication and mixed signals. The standard fix is to force HTTPS: 301-redirect HTTP to HTTPS, reference only HTTPS in links, sitemaps, and canonicals, and use HSTS so clients default to the secure scheme.
Why HTTP vs HTTPS matters
The scheme is part of the URL, so http://example.com/page and https://example.com/page are distinct addresses. If both serve content, the page exists twice from a crawler's view, splitting signals and risking the wrong version being indexed.
HTTPS is the expected default for modern sites, and consolidating on it removes the duplication while also providing transport security.
How to force HTTPS
Redirect every HTTP URL to its HTTPS equivalent with a 301 — same path, just the secure scheme. Make internal links, sitemap entries, and canonical tags reference HTTPS only. Then add HSTS (Strict-Transport-Security), which tells browsers to use HTTPS automatically on future visits, avoiding an initial insecure request.
Watch for mixed signals: an HTTPS page whose canonical tag still points to HTTP, or internal links that use http://, undercut the consolidation. Also avoid chains where HTTP first hops to one host and then to another before reaching the final HTTPS URL.
- 301-redirect HTTP to the matching HTTPS URL
- Use HTTPS in links, sitemap, and canonical tags
- Add HSTS so clients default to HTTPS
Operator checklist
Confirm HTTP 301-redirects to HTTPS for every path. Check canonical tags and internal links use HTTPS, not HTTP. Enable HSTS once HTTPS is fully working. Combine with host and trailing-slash rules so each page has a single canonical URL reached in one hop.
How it appears in analytics and logs
When the same content is reachable over both HTTP and HTTPS, crawlers see two URLs per page and signals can split. Forcing HTTPS with redirects, consistent canonicals, and HSTS tells crawlers the secure scheme is authoritative.
Diagnostic use case
Consolidate on HTTPS by redirecting HTTP, aligning canonical signals, and using HSTS to prevent scheme-level duplication.
What WebmasterID can help detect
WebmasterID can show whether crawlers reach HTTP or HTTPS URLs and whether HTTP redirects to HTTPS, helping you confirm scheme canonicalization is consistent.
Common mistakes
- Serving the same content over both HTTP and HTTPS with no redirect.
- An HTTPS page whose canonical tag still points to the HTTP URL.
- Enabling HSTS before HTTPS works correctly across the whole site.
Privacy and accuracy notes
Scheme canonicalization concerns URLs, redirects, and transport security, not personal data. WebmasterID reports these patterns for crawler traffic without exposing individual visitors.
Related pages
- www vs non-www canonicalization
To a crawler, https://www.example.com and https://example.com are distinct URLs that can serve the same content, creating duplication. The fix is to choose one canonical host, redirect the other to it with a 301, and keep internal links, sitemaps, and canonical tags consistent with the chosen version.
- Canonical mismatch diagnosis
A canonical mismatch happens when your rel=canonical tag points one way while redirects, sitemaps, internal links, or hreflang point another. Conflicting signals confuse which URL should represent a piece of content, so crawlers may pick a canonical you did not intend. Aligning the signals fixes it.
- Website observability
See whether crawlers reach HTTP or HTTPS URLs on your site.
Sources and verification notes
- Google Search Central — Canonicalization and duplicate URLsDocuments consolidating duplicate URLs including scheme variants.
- MDN — Strict-Transport-Security (HSTS)
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.