How to Check an HTTP to HTTPS Redirect: A Step by Step Test

At Talha Aslan and team, this is the first thing we test in every site migration and technical SEO audit. The reason is simple. The problem usually hides in plain sight: the site loads, the padlock shows, yet behind it runs a two or three hop chain, a temporary 302, or a blanket rule that sends everything to the homepage. For a quick first look, keep our free redirect checker open in another tab.

This guide first shows what a correct result looks like. Then it walks through a step by step test, and after that it covers HSTS, mixed content and redirect chains. We base every claim on primary sources such as Google Search Central, IETF standards and web.dev. All example addresses use example.com.

Why does the HTTP to HTTPS redirect matter so much?

When a site moves to HTTPS, the old http addresses still live on, because nobody deletes them from the web. Old backlinks, bookmarks, email signatures, printed flyers and links on other sites still point to the http version. As a result, each of those visits passes through your redirect rule.

According to Google's documentation on redirects, a permanent redirect signals that the target should be the canonical, or preferred, version. If the rule is missing or wrong, both versions stay reachable. Google then has to pick one on its own, and your signals can end up split between two addresses.

Users also feel the difference. For example, if a form page still loads over http, the data a visitor types may travel unencrypted. That is why the redirect has to work on every URL of the site, not only on the homepage. If you want the basics of certificates first, our guide on SSL certificates and HTTPS security covers them.

What does a correct redirect look like?

In practice, a correct setup produces a simple picture. You request http://example.com/services/ and the server answers with a 301 status and a Location header that says https://example.com/services/. Next, the client requests that new address and gets a 200. In total there are two steps and one redirect.

So look at three details here. First, the status code must be permanent. Second, the path must survive: /services/ should land on /services/, not on the homepage. Finally, the target must be the one version you prefer, so decide in advance whether your site uses www or not.

As an example scenario, compare two chains. In the healthy one, http://example.com/blog/ goes straight to https://example.com/blog/. In the faulty one, it first goes to https://example.com/blog and then, after a trailing slash rule fires, to https://example.com/blog/. The second chain still works in the end. However, it adds an extra round trip to every single visit.

Which status code should you see: 301, 308 or 302?

An HTTP to HTTPS redirect is a permanent change, so you should see 301 or 308. Google's page on HTTP status codes treats 308 as equivalent to 301 and calls both a strong signal that the target should be processed. By contrast, Google treats 302, 303 and 307 as a weak signal.

The IETF HTTP standard, RFC 9110, adds a useful note on 301. For historical reasons, a client may change a POST request into a GET on the next step. If you need to keep the method, 308 is the alternative. We explain the differences in detail in 301 vs 302 vs 307 vs 308.

How do you test an HTTP to HTTPS redirect step by step?

In practice, the most reliable manual method is a tool that sends a fresh request at every hop and lists each status code. You can follow this order on your own site.

1. Open the redirect checker and type your address with http at the front, for example http://example.com/, into the Address (URL) field.
2. Pick Single URL mode and press Check. Each row of the chain shows the status code, the address and the response time.
3. Look at the redirect count. The ideal value is 1; anything from 2 upward means a chain.
4. Read the type. If you only see 301 or 308, the rule is permanent; a 302 or 307 means a temporary rule is running.
5. Make sure the final status is 200 and the final address starts with https.
6. Repeat the test for an inner page, a blog post and a URL with a query string.
7. Finally, run 4 versions mode to confirm that all four variants of your domain end at the same target.

Our tool follows a chain for up to 10 hops. That limit matches the number of hops Google's crawlers generally follow. However, it does not show meta refresh or JavaScript redirects, because it only reads the status codes the server returns.

Why should you test all four versions of your domain?

For example, a domain has at least four front doors: http://example.com, http://www.example.com, https://example.com and https://www.example.com. However, server rules often catch some of them and forget the rest. So testing just one version gives you false confidence.

Here is an example scenario. http://example.com correctly goes to https://example.com. Meanwhile, http://www.example.com first goes to https://www.example.com and only then to https://example.com. The main version looks fine, yet every old www link passes through a two hop chain.

Google's redirect documentation suggests that if your homepage is reachable at several URLs, you pick one as the preferred address and redirect the others to it. Your goal, then, is clear: all four versions should reach the same https address in one hop. The preferred version itself should return a 200 with no redirect at all.

• http without www: one 301 to the preferred address.
• http with www: one hop, no chain, same target.
• https on the non-preferred host: one 301 to the preferred address.
• https on the preferred host: a direct 200.

Why can your browser show a misleading result?

Typing http into the address bar and watching the page open as https is not a real test. There are two technical reasons for that, and both appear in official standards.

The first is caching. RFC 9110 says a 301 response is heuristically cacheable. In other words, your browser can remember a permanent redirect it saw before and jump to https without asking the server. Even if someone deleted the rule on the server, everything still looks fine in your browser.

The second is HSTS. According to RFC 6797, once a browser knows a domain as an HSTS host, it turns http links to that domain into https before it sends any request. In that case the http request never reaches your server. So you have not actually tested the server side redirect at all.

In short, if you want to know what a first time visitor or a search engine crawler sees, you need a client with no cache and no HSTS record. That is why a checker that runs on a server gives a more accurate answer.

Can you test the redirect from the command line?

Technical teams also check redirects from the command line. The logic matches our tool. You send a request that asks only for the response headers, then you read the status code and the Location header. That way neither the browser cache nor an HSTS record can affect the result.

That said, keep two points in mind. First, many command line clients do not follow redirects by default and only show the first response. To see the full chain, you either turn on the option that follows redirects or request each hop by hand. Second, the DNS cache on your machine or a proxy on your office network can produce a different result than a visitor elsewhere would get.

That is why we always compare a command line result with a checker that runs from outside. If both match, you can relax. If they differ, the cause usually sits in a cache layer, a CDN, or a local network setting. For instance, a stale rule on a CDN shows up in an external check, while your local test might skip it. Looking from two places instead of one can turn an hours long hunt into a few minutes of work.

What is a redirect chain, and how many hops are acceptable?

A redirect chain happens when an address passes through more than one redirect before it reaches the final page. In HTTPS moves, chains usually come from three rules: the protocol rule, the www rule and the trailing slash rule. Each rule is fine on its own, though. The trouble starts when they fire one after another.

Google's guide to site moves with URL changes recommends redirecting straight to the final destination. If that is not possible, it advises keeping the chain short, ideally no more than 3 redirects and fewer than 5. Google's crawlers also generally follow up to 10 hops, and a chain beyond that may never reach its target.

In practice, we set one target for HTTPS moves: no version should need more than one redirect. That way users skip the extra wait on every visit, and crawlers stop spending requests on needless hops. We show how to find and merge chains in what a redirect chain is and how to fix it.

How can you tell that you have a redirect loop?

Put simply, a loop means the redirects keep bouncing between addresses and never reach a 200. In a browser, this usually ends in an error page saying there were too many redirects. With a checker, by contrast, you see the same address appear twice in the chain, and the result never becomes 200.

In HTTPS moves, the classic cause is two layers that apply opposite rules. Consider an example scenario: a CDN talks to visitors over https but connects to your origin server over http. The server sees an http request and redirects to https, and the CDN asks over http again. The result is an endless loop.

You will see a similar loop when the site address setting in your CMS conflicts with the server rule. To break the loop, list which layer applies which rule, one by one. For a full walkthrough, read our guide on fixing ERR_TOO_MANY_REDIRECTS.

What is HSTS, and does it replace the redirect?

Put simply, HSTS is a security policy that lets a site tell the browser to use only HTTPS from now on. RFC 6797 defines it. The server sends the policy in the Strict-Transport-Security response header, and the required max-age value states how many seconds the policy lasts.

HSTS does not replace the redirect; it works alongside it. The standard spells out why. A browser only honors this header when it arrives over a secure connection and must ignore it over plain http. So a visitor has to reach an https page once, and the 301 redirect is what gets them there.

The standard also admits that the first visit stays exposed for this reason. If the browser has not learned the policy yet, the first request still goes out over an insecure channel. As one possible fix, the standard mentions lists that ship preloaded with browsers. That said, joining such a list is hard to undo. Therefore, make sure your redirect and certificate work flawlessly first.

What should you check before you turn on HSTS?

HSTS is a strong tool, and a bad configuration has an equally strong effect. The HTTPS guide on web.dev advises you not to enable HSTS until you are sure your site runs reliably. Browsers that have stored the policy can lock users out entirely if a certificate problem appears.

So we follow this order:

1. Confirm that the HTTPS version works on every page, before you add any redirect.
2. Next, turn on the 301 redirect and test all four versions.
3. Check the certificate and its chain with our SSL checker.
4. Start HSTS with a low max-age and raise it step by step while nothing breaks.
5. Add includeSubDomains only if you are sure every subdomain supports HTTPS.

Per the standard, includeSubDomains extends the policy to all subdomains. For instance, if an old admin panel or a staging subdomain still runs on http only, this option can cut off access to it. The standard also notes that a max-age of zero removes the policy. Still, remember that browsers only learn about that change on their next secure visit.

Why should you check mixed content separately?

However, even with a perfect redirect, the images, scripts and stylesheets inside a page may still use http addresses. Web.dev calls this mixed content. In other words, the page address is HTTPS, yet some of its resources arrive over an unencrypted connection.

Web.dev also separates two types. Passive mixed content covers images, video and audio; the browser may flag the page as not secure, and Chrome sometimes tries to upgrade these files to https on its own. Active mixed content covers scripts, stylesheets and iframes, and most browsers block it by default. As a result, menus stop working, forms fail, or the layout breaks.

A redirect checker only shows the journey of the page URL; it does not scan the resources inside the page. That is why you check mixed content in the Issues panel and console of your browser's developer tools. The lasting fix is to write resource URLs with https, or as protocol independent relative paths. Our guide to the mixed content error goes deeper.

Do inner pages and URLs with parameters redirect correctly?

Still, the most common mistake we see is testing only the homepage and calling it done. You only find out whether a rule keeps the path and the query string when you test inner pages. Some rules send every http request to the https homepage, and in that case the homepage test passes anyway.

Example scenario: when you test http://example.com/products/blue-chair?color=navy, the target should be https://example.com/products/blue-chair?color=navy. If the target is https://example.com/, the rule drops the path. If the ?color=navy part disappears, the query string gets lost, and campaign tags vanish with it.

So add these to your test list:

• The homepage and your three most visited pages.
• One category or service page and one blog post.
• A URL with a query string, such as a campaign link with UTM tags.
• A direct file URL, such as an image or a PDF.
• An address that does not exist; after the move to https it should return a 404, not the homepage.

Have your internal links, canonicals and sitemap moved to HTTPS?

Specifically, a redirect is a safety net that catches old addresses. Your own site should not rely on it day to day. Google's site move guide explicitly says to change internal links on the new site from the old URLs to the new ones. Otherwise every internal click goes through a needless redirect.

The same guide asks for a self referencing canonical tag on each new URL. It also tells you to confirm, once redirects are live, that canonical annotations point to the new URLs. In addition, it recommends building a sitemap with the new URLs and submitting it in Search Console. We collected typical canonical errors in how to detect and fix canonical issues.

Here is a practical check. Search the page source for http:// and look at every match that points to your own domain. Each one is either an internal link or a resource URL, and you need to fix it. Web.dev likewise recommends keeping intrasite URLs independent of the protocol. As for links to other sites, only switch them to https if that site supports it.

How do you monitor the HTTPS move in Search Console?

Google's site move guide suggests verifying both the HTTP and the HTTPS variants of your site in Search Console. This lets you watch the old version leave the index and the new one take its place, side by side. According to the same guide, you do not need the Change of Address tool for an HTTP to HTTPS move.

That said, watch one detail. Google's page on HTTP status codes says its inspection tools do not follow redirects. So when you inspect the http address, you only see the redirect itself. To learn the status of the target page, inspect the https address separately.

In the weeks after the move, you should see fewer http URLs and more https URLs among indexed pages. Google may keep the redirected URL as an alternate name for a while, which is normal. We explain how to read the report in the Search Console HTTPS report.

How long should an HTTP to HTTPS redirect stay in place?

The short answer: as long as you can. Google's site move guide advises keeping redirects for as long as possible, generally at least one year. For HTTPS moves, we suggest going further, because there is no good reason to ever remove this rule.

Think about it for a moment. Old http links on other websites stay in place for years. If the rule goes away, those links either open an unencrypted page or stop working. Moreover, the HTTP to HTTPS redirect is usually a single server rule with almost no upkeep. So removing it adds risk, while keeping it costs next to nothing.

Whenever you change servers or hosting, check that this rule made it to the new environment. It is one of the things people forget most often during a move. For the general question of duration, see how long 301 redirects should stay.

Which redirect method should you choose?

Google's redirect documentation ranks server side redirects as the method most likely to be interpreted correctly. With this method, server configuration files or server side code set up the redirect, and the status code comes straight back with the response.

If a server side redirect is not possible, meta refresh is an option. Google treats an instant, zero second meta refresh as permanent and a delayed one as temporary. It recommends JavaScript redirects only as a last resort, because Google might never see the redirect if rendering fails.

For an HTTPS move in particular, meta refresh and JavaScript are not practical. Both need the http page to load first, so the visitor meets an unencrypted page, even if only for a moment. That is why we recommend a rule at the server or CDN level for the HTTP to HTTPS redirect. Our checker also reads server responses only, so it tests exactly this method.

What are the most common mistakes?

Across the sites we audit, the same mistakes also keep coming back. The list below sums up the points we suggest you check closely.

• Temporary codes: a 302 left in place for a permanent move sends Google a weak signal.
• Chains: protocol, www and trailing slash rules firing one after another.
• Dropped paths: every http URL sent to the https homepage.
• Lost query strings: campaign parameters missing at the target.
• HTTPS to HTTP downgrades: an old rule working in exactly the wrong direction.
• Forgotten subdomains: no rule on the blog, shop or panel subdomain.
• Stale internal links: the site's own menu still pointing to http URLs.
• Rushed HSTS: a high max-age that locks users out when a certificate fails.

One round of testing exposes most of these. Some, however, such as missing subdomains, only show up once you list every variant of the domain.

What should you check after the move, and when?

An HTTPS move looks like a one time setting, but any change to the site can break the rule. For instance, theme updates, plugin changes, server moves and new CDN settings top the list. So tying the check to a schedule makes life easier.

If the site is moving to a new domain or a new structure altogether, the HTTPS check is just one part of a bigger list. In that case, we suggest you also follow the steps in our website migration SEO checklist.

Bottom line: what result should put your mind at ease?

To sum up, a healthy HTTP to HTTPS redirect looks like this. Each of the four versions reaches the same https address with a single 301 or 308. The preferred version returns a direct 200, and inner pages keep their path and parameters. Internal links, canonical tags and the sitemap already point to https URLs.

If you then add HSTS in a careful order, you protect your users and send search engines a consistent signal. Once you clean up mixed content as well, browser warnings disappear too.

Running this check once is not enough, so repeat the same list after every major change. At Talha Aslan and team, we start this list from scratch in every technical audit, because even the simplest rule can break quietly after an unexpected update.

Sources: Google Search Central: Redirects and Google Search, Google Search Central: Site moves with URL changes, Google Search Central: HTTP status codes, IETF RFC 6797: HSTS, web.dev: What is mixed content?

Core guide: What Is Digital Marketing? Its types, examples and how it is done, on one page with an interactive film that travels through the brain.