URL Works on HTTP and HTTPS: How to Close the Protocol Split

Every page on your site has a protocol. The right setup is one live version — https — with http permanently redirecting to it. When both protocols answer with a 200, you have doubled your URL space overnight: http://example.com/page/ and https://example.com/page/ are, to a crawler, two different URLs serving the same content. The stakes: split link equity, duplicate-content ambiguity, wasted crawl budget, and a security signal you are throwing away by leaving an unencrypted version reachable.

A real example: curl both protocols

One command tells you everything. A healthy site 301s http to https; a broken one returns 200 on both:

# BROKEN — both protocols serve the page (this check fires)
$ curl -sI http://example.com/page/  | head -1
HTTP/1.1 200 OK                       ✕ insecure version is live
$ curl -sI https://example.com/page/ | head -1
HTTP/2 200                            ✓ secure version is live too
                                      → two indexable duplicates

# HEALTHY — http permanently redirects to https
$ curl -sI http://example.com/page/  | grep -iE 'HTTP|location'
HTTP/1.1 301 Moved Permanently
location: https://example.com/page/   ✓ one canonical version

In the broken case, both return 200 with no redirect. That is the whole diagnosis. Do it for the homepage and a couple of deep URLs — if http never 301s, the split is site-wide, not a one-off.

The fix in one move: add a server-level rule that 301-redirects all http traffic to the https equivalent, preserving the path. Once every http URL returns a 301, the duplicate set collapses to one canonical https version and the ambiguity is gone.

What the protocol split actually costs

This is closely related to — but not the same as — the case where http simply fails to redirect at all. If your http version 404s or errors instead of serving a 200, see HTTP does not redirect to HTTPS.

How to detect it

1. curl both protocols. Run curl -sI http://yourdomain/ and the https equivalent on the homepage and a few deep pages. Any http URL returning 200 instead of 301 is a hit.
2. Crawl the http tree explicitly. In Screaming Frog, crawl http://yourdomain/ as the start URL. If the spider finds a full tree of 200-status http pages (rather than everything 301ing to https), the split is confirmed. Compare the http and https crawls — matching 200s across both is the signature.
3. Check Search Console. If you have both an http:// and https:// property (or a domain property showing both), look for the same pages indexed under both protocols, or "Duplicate, Google chose different canonical than user" in the Page indexing report.
4. Test HSTS. curl -sI https://yourdomain/ | grep -i strict-transport-security. No header means browsers will still attempt http first, so even with a redirect you want HSTS in place.

How to fix it

1. Force http → https at the server. Add a permanent redirect for all http requests. On Apache, a rewrite rule sending http:// to https://%{HTTP_HOST}%{REQUEST_URI} with a 301; on Nginx, a dedicated port-80 server block that returns 301 to the https URL. Preserve the full path so deep links land correctly.
2. Verify the redirect is a 301, not 302. Temporary redirects tell Google to keep the http URL indexed. Re-run curl and confirm you see 301 Moved Permanently.
3. Add HSTS. Once https is stable, send a Strict-Transport-Security header so browsers skip http entirely on future visits. Only add preload when you are certain every subdomain is https-ready.
4. Update internal links and canonicals to https. Point every internal link, canonical tag, sitemap entry, and hreflang reference at the https version so nothing keeps feeding the old protocol.
5. Fix mixed content. After forcing https, hunt for sub-resources (images, scripts, CSS) still loaded over http. See mixed content for finding and clearing them.
6. Re-crawl and confirm. Every http URL should now return 301, and only https URLs should return 200. Consolidate to the https property in Search Console.

FAQ

Isn't a canonical tag enough to point Google at the https version?

A canonical is a hint; a 301 is a directive. Canonicals help, but they still leave the http URL crawlable and served to any user who requests it over http. The clean fix is the redirect — it removes the duplicate at the source and secures the connection. Use the canonical as reinforcement, not the whole solution.

Will forcing https hurt my rankings during the switch?

Done right, no — and Google has used https as a lightweight ranking signal for years, so consolidating helps. The risks are botched redirects (chains, wrong paths, 302s) and mixed content. Test with curl before and after, keep the redirect a clean single-hop 301, and you consolidate signals rather than lose them. Our HTTPS migration checklist covers the full sequence.

Do I need HSTS if I already have the 301?

The 301 handles crawlers and search; HSTS handles the user's browser. Without HSTS, a returning visitor's first request each time still goes to http before the redirect fires — a small window an attacker could exploit. HSTS tells the browser to go straight to https, so it is worth adding once your https is solid.

Both versions are indexed already. How do I clean it up?

Deploy the 301, update internal links and the sitemap to https, then let Google recrawl. The http URLs will drop out as the redirect is processed. In Search Console, treat the https property as canonical; you do not need to manually remove the http URLs — the permanent redirect handles it over the next crawl cycles.

What if only some pages serve on both protocols?

That points to a partial or per-directory redirect rule rather than a global one. Audit which paths 301 and which return 200 on http, then replace the piecemeal rules with a single site-wide http-to-https redirect so there are no gaps left serving the insecure version.

Related reading: HTTP does not redirect to HTTPS · Mixed content · HTTPS and site security as ranking signals · HTTPS migration checklist