Skip to main content
Technical SEO

Why Your www Redirect Goes Through HTTP Before HTTPS (and How to Fix It)

admin9 min read
Illustration of a www redirect goes through HTTP before HTTPS detour compared with a direct secure route

You type the www address, land on the secure page and everything looks fine. Yet the request may have taken a detour you never saw. When a www redirect goes through HTTP before HTTPS, a visitor or crawler is sent to an insecure URL for one hop before reaching the final secure address. The fix is to choose one HTTPS host as the destination and make every other variation redirect straight to it in a single step. This guide starts with a domain-level comparison in the www Redirect Checker, which tests the www and non-www versions of a domain. Then I test four explicit protocol-and-host URLs for one page path with the Server Status Checker and a GET-based curl command. One of those four is your final destination, so the other three are the ones that should redirect. That way you can read each response and repair overlapping rules without guessing.

Two routes to one secure destination, one with an unnecessary detour

Two different detours, not one

Two chains look similar but carry different weight, so name them separately before you test anything. In both examples below, example.com is a synthetic domain.

Detour A: http://www.example.com/page -> http://example.com/page -> https://example.com/page
Detour B: https://www.example.com/page -> http://example.com/page -> https://example.com/page

In Detour A the request already starts on HTTP, and the host change and the protocol change happen in two hops. It is an unnecessary extra step, but the visitor was on HTTP anyway. In Detour B the visitor starts on a secure HTTPS URL and is sent down to HTTP before being sent back up. That is a different situation, and it deserves a closer look.

Google Search Central’s site move documentation advises redirecting directly to the final destination, because redirect chains add latency and can impede crawling. The ideal state is simple: each of the other three starting URLs for a page redirects once to the single HTTPS address you prefer, with the same path preserved, while the final URL itself answers directly.

Four starting routes converging on a single final destination

Test four starting URLs for the same path

A domain-level check is a good first pass, but the HTTP detour only shows up when you test each protocol and host combination separately. Use one real page path, not just the homepage, so path handling is tested too.

  1. Choose your final URL, for example https://example.com/page. Decide this before testing, so you know what correct looks like.
  2. Enter your domain in the www Redirect Checker to compare how the www and non-www versions behave. Its page describes status code, redirect chain and response header analysis, but treat it as a starting point and confirm hop details in the next steps.
  3. Submit each explicit starting URL to the Server Status Checker: http://example.com/page, http://www.example.com/page, https://example.com/page and https://www.example.com/page. Note the status code and any reported destination.
  4. If a result shows only a first or final status, trace the hops with the Redirect Chain Checker, which is described as tracing HTTP redirects and finding loops.
  5. To see the raw Location values, use Get HTTP Headers on each URL, or run a GET-based command from a terminal.
for u in http://example.com/page http://www.example.com/page https://example.com/page https://www.example.com/page; do
  echo "== $u"
  curl -sS -L -D - -o /dev/null "$u" | grep -iE '^(HTTP/|location:)'
done

This sends GET requests, follows redirects with -L and prints only the status lines and Location headers of every hop. I avoid curl -I for this job, because it sends HEAD, which some servers handle differently or reject, so it may not match what a browser sees.

Magnifying glass inspecting each step in a redirect chain

Read status codes, Location and the final URL

For each starting URL, write down four things: the requested URL, the response code, the Location value and the final URL. Then compare the four rows.

  • 301 or 308 means a permanent redirect. These are the right choice for a lasting host and protocol preference.
  • 302 or 307 means a temporary redirect. It is fine for temporary moves, but not a good signal for a permanent www or HTTPS decision.
  • 200 on a starting URL that you expected to redirect means that version is still served as a separate page.

The most common reading mistake is to look only at the end of the chain. A final HTTPS URL does not rule out an HTTP intermediate hop. The Location header may also be relative, such as /page, so resolve it against the URL that returned it before deciding whether the next hop is HTTP or HTTPS.

If you want to check many pages at once, the Bulk HTTP Status Code Checker is described as checking up to 100 URLs and returning redirect chains and final URLs. Paste the four variations of several important paths and compare the output against what you saw with raw headers. As with any single check, results are a snapshot from the tool’s server and may differ from your own browser.

Why a www redirect that goes through HTTP before HTTPS needs attention

Google Search Central’s canonicalization documentation says that an HTTPS page redirecting users to or through HTTP can conflict with Google’s usual preference for HTTPS canonicals. That is the reason Detour B matters more than Detour A. It does not mean the chain automatically costs you rankings or forces Google to choose the HTTP version. Canonical selection stays Google’s decision, and permanent redirects are one signal among several. It does mean you are sending mixed signals that are easy to avoid.

There is also a security angle. An HTTPS request that is downgraded to HTTP for one hop exposes that hop to anything on the network path, and the visitor briefly leaves an encrypted connection. An initial HTTP request and an HTTPS-to-HTTP downgrade are not equivalent, so do not file them under the same label.

Browser behaviour can also hide the problem. According to MDN’s documentation on the Strict-Transport-Security header, a browser that already knows an HSTS policy for your site upgrades an HTTP URL before making a network request. A first visit without that knowledge can still begin over HTTP. So your browser may show a clean path while a checker, a crawler or a new visitor sees the detour. Test with a tool or a command line client, and do not rely on what your own browser seems to do.

Consolidate the rules and retest

Detours usually come from rules written at different times: a CMS setting that forces www, a hosting panel that forces HTTPS, and a CDN rule that does something else. Each layer is reasonable alone, but together they stack hops. Do not add another rule on top. Find every layer that issues redirects, then replace them with one rule that sends any non-final URL directly to the final HTTPS address.

For Apache with mod_rewrite, a single rule in .htaccess can do it. This example assumes TLS terminates on the same server (not behind a proxy that hides the protocol), that the final host is example.com, and that your certificate covers every host you redirect from. Without a valid certificate on the www host, HTTPS visitors get a certificate warning before any redirect can happen.

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

The generator at .htaccess Redirects can help you draft Apache redirect syntax, but you still need to review the output against your own setup and back up the original file first. Use a 301 only when you are sure of the final choice, and watch for loops if another layer redirects back.

  1. Remove or merge the overlapping rules in the CMS, hosting panel, web server and CDN.
  2. Rerun the four-URL test and confirm each non-final URL makes exactly one hop with a permanent status.
  3. Test a deeper page and a URL with a query string to confirm path and parameters survive.
  4. Update internal links, canonical tags and sitemap entries to the final HTTPS address. My article on why an XML sitemap contains redirect and non-canonical URLs shows how stale sitemap entries keep old versions in circulation.

Retest after every change, because a fix in one layer can reveal a rule in another.

Frequently asked questions

Is it a problem if the first request starts on HTTP?

A visitor who types a bare domain or follows an old HTTP link starts on HTTP, and that is normal. What matters is that the first response redirects straight to the final HTTPS URL. The more concerning pattern is an HTTPS URL that redirects to HTTP and back.

Does a 301 status code prove my redirect is correct?

No. A 301 only says the redirect is permanent. You still need to check that the destination is HTTPS, that it is the host you chose, that the path and query string are preserved, and that the chain has one hop and no loop.

Will an HTTP detour hurt my rankings?

I cannot promise that it will or will not. Google Search Central warns that an HTTPS page redirecting through HTTP can conflict with its HTTPS canonical preference, and that redirect chains add latency. Both are good reasons to remove the detour, but neither is a guaranteed ranking loss.

Can HSTS hide the detour in my browser?

Yes. If your browser already knows an HSTS policy for the site, it upgrades HTTP URLs before sending a request, so you may not see the problem. A first-time visitor or a crawler without that knowledge can still start on HTTP, so test with a checker or a command line client.

Should I choose www or non-www?

Either works. Pick one, make it the HTTPS final destination and redirect the others to it. Consistency across redirects, internal links, canonical tags and sitemaps matters more than which version you choose.

Why does curl -I give a different result from my browser?

The -I option sends a HEAD request, which some servers treat differently or reject. A GET request with -L to follow redirects is closer to what a browser does, and -D – prints the headers of each hop.

What if a checker shows only the final status?

Then it has not shown you the middle hops. Use a redirect chain tool or a header checker on each starting URL, or run the GET-based curl loop, and record every Location value. Do not assume a checker displays every intermediate hop in every result.

Next steps

If your www redirect goes through HTTP before HTTPS, the final page can look perfect while the route to it is not. Test the four starting URLs for one path, record each status code and Location, and treat an HTTPS-to-HTTP hop as the most important finding. Then consolidate your rules into a single permanent redirect to one HTTPS host, align your internal links, canonicals and sitemap, and test again. A clean single hop is easier for visitors and crawlers to follow, though it is not a promise of any ranking change.

Related tools and resources on AllEasySEO:

Sources and further reading

#canonicalization #HTTPS #redirect chains #redirects #technical SEO #www vs non-www

Try these free SEO tools

Free, browser-based and no signup needed.

See all free SEO tools