www Redirect Checker Free Tool

Enter a URL

About www Redirect Checker

What This Tool Actually Does

The www Redirect Checker on limitlessreferrals.info answers one narrow question about your domain. It asks whether either of two plain HTTP addresses returns a permanent redirect. Those two addresses are http://www.yourdomain.com and http://yourdomain.com. The tool sends a HEAD request to each one from its own server. It does not follow any redirects. It does not open a browser. It does not run JavaScript. It reads the first HTTP response status from each address and compares it against a single status code.

That code is the permanent redirect status known as Moved Permanently. If either request comes back with that status, the tool prints the word "Good" next to your domain. If neither request returns it, the tool prints "Bad - Not Redirecting!". That is the entire decision procedure. Two requests, one comparison, one word out. The code path is short enough to quote in full. The input is trimmed, lowercased, stripped of any scheme, given http:// again, and validated as a URL. Then the tool removes www. from whatever you typed, leaving the bare host. It builds two URLs from that host. One carries the www. prefix, the other does not.

The HEAD requests use a fixed Chrome 87 user agent string. They allow thirty seconds for a response. SSL certificate verification is switched off, and the requests go to plain HTTP anyway. Redirect following is disabled at the curl level. That detail is the heart of the tool. Many redirect checkers chase the chain from start to finish and report every hop. This one stops at the first response. It wants to know only whether that first response carries the permanent redirect status.

You can see the consequence immediately. A site that answers http://example.com with a permanent redirect to https://example.com will show "Good". A site that answers with a temporary redirect to the same place will show "Bad". A site that answers with a 200 and serves content directly will show "Bad". A site that answers with the newer permanent redirect code, which is also permanent, will show "Bad". The tool has no opinion about temporary redirects, the newer permanent code, other redirect variants, error codes, or timeouts. It has an opinion about the one status it accepts and about everything else, and that everything else is lumped into one bucket.

The live test run for this rewrite checked four domains from the server. The results show how the single-word verdict behaves in the wild and why you should read it with care.

The example.com row shows both variants serving content directly over plain HTTP with a 200 status. There is no redirect anywhere, so the tool says Bad. That is correct. The github.com and wikipedia.org rows show both variants redirecting, which earns Good. The limitlessreferrals.info row shows the http to https permanent redirect at the CDN edge, which also earns Good even though the https variants may behave differently.

The table cannot show the direction of any redirect, the target URL, or the status of the HTTPS versions. Those details are outside the tool's reach. The verdict is a coarse filter.

How to Use This Tool

1. Open the tool page. Find the input box above this article on the www Redirect Checker page.
2. Type your domain. Enter the bare domain without a scheme, for example example.com or github.com. You can include www. if you like, the tool strips it before building the test URLs.
3. Submit the form. Press the button to POST your domain to the output handler. The check runs from the server, not from your browser.
4. Read the verdict. The result table shows your domain with the first letter capitalised and one of two labels, "Good" or "Bad - Not Redirecting!".
5. Interpret with caution. Good means at least one plain HTTP variant returned the permanent redirect status. Bad means neither did. Neither word tells you about HTTPS, redirect targets, or chain length.
6. Run a fuller check when in doubt. Use the Redirect Chain Checker on this site or a local curl command to see the actual status codes and destinations.

The form accepts one domain at a time. There is no batch mode and no API endpoint for scripted use. If you need to check many domains, you will write a loop yourself or use a different service. The tool page sits under the Development Tools category, next to the other small SEO utilities this site hosts.

Correcting the Old Description of This Tool

The previous version of this page described behaviour that the real tool does not have. That older copy ran to roughly 2,468 words and included a section titled "Reading the Results: Status Codes That Matter". That section presented a table implying the tool reports several distinct redirect outcomes and error outcomes for each variant. The real tool reports one word. It never shows a status code to you. It never distinguishes a temporary redirect from an error code or a timeout. All of those collapse into "Bad - Not Redirecting!".

The old copy also claimed the "protocol layer adds a second dimension" to the check, implying that HTTPS variants are tested alongside HTTP. The real tool never makes an HTTPS request. The code builds http://www.<domain> and http://<domain> and nothing else. SSL verification is disabled in the curl options, which only confirms that the requests are plain HTTP. There is no second dimension. There is one protocol, HTTP, and two host variants.

Another old passage asked "what if one variant times out", suggesting the tool reports per-variant outcomes. It does not. A timeout on the www request and a 200 on the bare request produce the same Bad verdict as two 200s. A timeout on both produces Bad as well. The tool cannot tell you which request failed or why. It gives you a single label for the pair.

The old copy also invited readers to check redirects for a specific page, such as a product URL or a blog post. The real tool operates at the host level. It strips www. from your input and builds two host URLs. Any path you type is kept in the string, but the HEAD request goes to the host root as effectively constructed. The check is not per-page. It cannot tell you whether /old-page redirects to /new-page. It can only tell you whether the host root answers with the accepted status on either variant.

These corrections matter because the old description set expectations the tool cannot meet. A reader who believed the tool reported the newer permanent redirect code as a distinct outcome would be confused by a Bad verdict on a site that uses that code correctly. A reader who believed HTTPS was tested would draw false comfort from a Good verdict. The tool is smaller and simpler than the old page claimed. This rewrite describes what the code actually does, which is two HEAD requests over plain HTTP and a single word as output.

What a Good Verdict Does and Does Not Prove

A Good verdict from this tool proves one thing only. At the moment of the test, at least one of the two plain HTTP addresses returned the permanent redirect status in response to a HEAD request. That is the entire logical content of the word. It does not prove that your canonical redirect is configured correctly. It does not prove that HTTPS works. It does not prove that search engines will see the redirect you intend. It does not even prove which variant redirected.

Consider the most common modern setup. A site sits behind Cloudflare with "Always Use HTTPS" enabled. Every plain HTTP request, whether to the www host or the bare host, receives a permanent redirect to the HTTPS version of the same URL. This tool will say Good. The redirect is real and permanent. But the HTTPS versions of the two hosts might both serve content directly with 200 status and no canonical redirect between them. In that case, the site has an http to https redirect and no www vs non-www canonical redirect at all. The tool cannot see the difference. Its Good verdict covers both situations.

Consider the opposite setup. A site uses the newer permanent redirect code for its canonical redirect because the site owner wants to preserve the request method and body on redirects. The tool will say Bad. The redirect is permanent, standards compliant, and understood by modern browsers and search engines. The tool does not care. It checks for the literal status code it accepts and nothing else.

Consider a third setup. A site uses a meta refresh tag or a JavaScript redirect to move visitors from the www host to the bare host. The tool will say Bad. A HEAD request fetches no body and executes no script, so the tool never sees the meta tag or the JavaScript. The redirect works in a browser but is invisible to this check. Search engines treat meta refresh and JavaScript redirects differently from server-side redirects anyway, so the Bad verdict may be fair for SEO purposes even though the site appears to work for humans.

The Good verdict also says nothing about the redirect target. A permanent redirect from http://www.example.com to http://example.com earns Good. A permanent redirect from http://www.example.com to http://www.evil-domain.com also earns Good. The tool does not read the Location header. It reads the status code and discards everything else. If you care where the redirect goes, you need a different tool.

The Good verdict says nothing about redirect chains. A permanent redirect from the www host to the bare host, followed by another permanent redirect from the bare host to a third host, earns Good. The tool sees the first response and stops. It never learns about the second hop. Search engines may follow chains but they prefer short ones, and a chain that ends somewhere unexpected is a problem this tool will not surface.

What the Good verdict does prove is modest but real. It proves that someone configured a server or a CDN edge to answer plain HTTP with the accepted status on at least one host variant. The metric changes by at least 10 percent. It means the site is not serving duplicate content over plain HTTP on both variants. It means the site owner has thought about redirects at all. Many sites have not.

What a Bad Verdict Does and Does Not Prove

A Bad verdict proves one thing only. Neither of the two plain HTTP addresses returned the accepted status in response to a HEAD request at the time of the test. That is all. It does not prove your site is broken. It does not prove you have a duplicate content problem. It does not prove search engines will penalise you. It does not even prove that no redirect exists, because the redirect might use a different status code or a different mechanism.

The most common cause of a Bad verdict on a well configured site is the http to https redirect. Many sites answer every plain HTTP request with a permanent redirect to HTTPS. This tool counts that as Good, as the limitlessreferrals.info test shows. But some sites answer plain HTTP with a temporary redirect to HTTPS, or with a method-preserving redirect, or with the newer permanent code. Any of those earns Bad. The site redirects fine, just not with the single status code this tool accepts.

Another common cause is a site that serves plain HTTP directly with a 200 and handles the canonical redirect only over HTTPS. The tool never tests HTTPS, so it sees two 200s and says Bad. The site may have a perfect permanent redirect from https://www.example.com to https://example.com. The tool cannot see it. The verdict is accurate for plain HTTP and misleading for the site as a whole.

A third cause is a site with no www DNS record. The www request fails at the DNS level or times out, returning status code 0 from curl. The bare request returns a 200 or a redirect. If the bare request returns 200, the verdict is Bad. If the bare request answers with a permanent redirect, the verdict is Good; if it answers with a normal page, the verdict is Bad. The failed www request never surfaces as its own result. It is folded into the pair and forgotten.

A Bad verdict does not tell you which variant failed. It does not tell you the status codes you actually received. It does not tell you whether the problem is DNS, a missing server block, a misconfigured redirect, or a deliberate choice to serve both variants. To learn any of that, you need to run the check yourself with a tool that shows responses.

The reading of Bad is that your plain HTTP setup does not match the pattern this tool looks for. Whether that matters depends on your goals. If you want search engines to see the accepted redirect from one host variant to the other over plain HTTP, Bad means you have work to do. If you serve everything over HTTPS and use the newer permanent code, Bad may be irrelevant.

The Two Request Design

The tool makes two HEAD requests from its own server. The first goes to http://www.<domain>. The second goes to http://<domain>. Both use the same fixed Chrome 87 user agent and the same thirty second timeout. Neither follows redirects. The order of the requests matters only for timing, not for the verdict. The tool checks the status of each and applies the OR logic.

Why HEAD requests? A HEAD request asks the server for the same headers a GET would return, and it omits the response body. It is faster, lighter, and sufficient for reading a status code. Servers that implement redirects at the HTTP level return the same status for HEAD and GET. The curl option is CURLOPT_NOBODY, which tells libcurl to send a HEAD request. This design keeps the tool quick and avoids downloading entire pages just to read a redirect status.

The fixed older Chrome build user agent is a deliberate choice. Some servers behave differently based on the user agent, serving redirects to browsers and different responses to bots. A fixed, recognisable browser user agent increases the chance that the server treats the request like a real visitor. The older Chrome build dates from late 2020, which makes it an old browser by 2026 standards, but servers rarely reject it. The user agent is consistent across all requests, which makes results comparable.

SSL verification is off in the curl options. This sounds alarming until you remember that the requests go to plain HTTP. There is no TLS handshake to verify. The option is probably inherited from a shared helper used by other tools on this site that do make HTTPS requests. For this tool, it has no practical effect.

The thirty second timeout is generous for a HEAD request. Most servers respond in well under a second. A timeout means the server is unreachable, the DNS lookup fails, the connection hangs, or the server deliberately delays. The tool does not distinguish these cases. A timeout produces no status code, which means no accepted status, which means Bad.

The two request design has a blind spot worth naming. If the www host has no DNS record, the www request fails immediately with a DNS error. The bare request proceeds alone. The tool still produces a single verdict. It never tells you that one of the two requests never reached a server. A domain that exists only as the bare host, with no www record at all, can earn Good if the bare host redirects to HTTPS. Visitors who type www.example.com will get a DNS error, not a redirect. The tool cannot warn you about that.

The 301 Only Rule

The tool accepts exactly one status code as evidence of a working redirect. That code is the permanent redirect status known as Moved Permanently. Every other status, including other redirect codes, counts as failure. This rule is the single most important thing to understand about the tool, and it is also the easiest to forget when you read a Bad verdict.

The permanent redirect status was defined in HTTP and has been the standard for permanent redirects since the earliest days of the web. Search engines treat it as a signal that the old URL should be replaced by the new one in their indexes. Link equity passes through it in most cases. The permanent redirect is the workhorse of canonical redirects, and this tool is built entirely around it.

The 302 Found status is a temporary redirect. Search engines historically treated 302s as temporary, keeping the old URL in the index. Using a temporary redirect for a permanent canonical redirect is a mistake. This tool's refusal to accept that status is defensible for that reason.

The 307 Temporary Redirect and 308 Permanent Redirect statuses are newer. The 307 preserves the HTTP method and body across the redirect, which makes it useful for form submissions. The 308 does the same for permanent redirects. Both are valid HTTP standards. The newer permanent code is semantically equivalent to the 301 for GET requests. Search engines treat the newer permanent code as permanent. This tool rejects both.

The table shows the full range of outcomes the tool can produce, which is to say one Good outcome and five Bad outcomes. The tool does not report which status it received. It collapses all five Bad outcomes into the same label. If you need to know whether your site returns a temporary redirect or the newer permanent code, this tool will not tell you.

The single-status rule also means the tool cannot validate modern redirect practices. A site that switched from the older permanent code to the newer one to preserve method semantics on form posts will show Bad. A site that uses a temporary redirect for maintenance redirects will show Bad. A site that uses JavaScript redirects will show Bad. The tool is conservative to the point of rigidity. It checks for the one status code that has dominated canonical redirect practice for decades, and it ignores everything else.

What the Tool Does Not Check

The tool does not check HTTPS. This is the largest gap and the one most likely to mislead. Modern web traffic is mostly HTTPS. Search engines prefer HTTPS. Browsers mark plain HTTP as insecure. A site can have a perfect HTTPS setup with canonical redirects on both the www and bare hosts, and this tool will still say Bad if the plain HTTP variants do not return the accepted status. Conversely, a site can have no canonical redirect at all over HTTPS, and this tool will say Good because plain HTTP redirects to HTTPS.

The tool does not check the redirect target. It reads the status code and ignores the Location header. A permanent redirect to the correct canonical host and a permanent redirect to a parked domain or a malicious site both earn Good. The tool cannot distinguish a healthy redirect from a harmful one.

The tool does not check the redirect direction. A site that redirects www to the bare host earns Good. A site that redirects the bare host to www also earns Good. The tool has no opinion about which convention you follow. Both are valid for SEO, as long as you are consistent. The tool simply does not tell you which one you have.

The tool does not check the redirect chain. It stops at the first response. If that response carries the accepted status, the verdict is Good, regardless of what the next hop returns. A chain of five redirects earns the same Good as a single clean redirect. Search engines tolerate short chains but prefer none. This tool cannot help you find chain problems.

The tool does not check page level redirects. It operates on the host root. If you need to verify that /old-page redirects to /new-page, you need a different tool. The Redirect Chain Checker on this site can do that, because it follows redirects and reports each hop.

The tool does not check for meta refresh or JavaScript redirects. HEAD requests fetch no body and execute no script. A page that redirects via <meta http-equiv="refresh"> or via window.location is invisible to this tool. Those redirect mechanisms are weaker for SEO than server side redirects, so the Bad verdict may be appropriate, but the tool cannot tell you why it is Bad.

The tool does not check DNS configuration. It never tells you whether the www host has a DNS record. A missing www record produces a failed request that folds into the Bad verdict without explanation.

The Four Live Test Results

The live test run for this rewrite took place on September 4, 2026, from the server that hosts this tool. Four domains were checked. The results are recorded in the table in the first section of this article. They are worth examining again because they show the tool's logic in action.

Example.com returned 200 for both the www and bare variants over plain HTTP. The verdict was Bad. That result is unsurprising. Example.com is a reserved domain used for documentation, and it serves a simple page without redirects. The tool correctly identified that no redirect exists.

Github.com returned the accepted status for both variants. The verdict was Good. Both variants of GitHub answered with a permanent redirect. Both requests hit the accepted status, so the OR logic produces Good.

Wikipedia.org returned the accepted status for both variants. The verdict was Good. Wikipedia does the same thing, redirecting plain HTTP to HTTPS and canonicalising the host. The tool sees the accepted status and approves.

Limitlessreferrals.info returned the accepted status for both variants. The verdict was Good. The CDN edge that fronts this site answers plain HTTP with a permanent redirect to HTTPS. The tool sees the accepted status and approves, even though the HTTPS variants may not have a canonical redirect between www and bare.

These four results illustrate the tool's behaviour across the two possible verdicts. One site earned Bad because both variants serve content directly over plain HTTP, and three sites earned Good because at least one variant answered with a permanent redirect. The tool cannot tell you anything beyond that. It cannot tell you that example.com serves the same content on both variants, which is a duplicate content risk. It cannot tell you that GitHub and Wikipedia both redirect to HTTPS and then canonicalise. It cannot tell you whether limitlessreferrals.info has a www vs non-www canonical redirect over HTTPS. The single word verdict hides all of that detail.

How to Run a Fuller Check Yourself

When the single word verdict is not enough, you can run a fuller check with tools you already have. The curl command line tool is available on macOS, Linux, and Windows 10 and later. It can show you the exact status codes and redirect targets for any URL.

The most useful curl command for this purpose follows redirects and reports each hop. On a Unix-like system you can run curl -sIL http://example.com to see the headers for each step of the chain. The -s flag silences progress output, the -I flag sends a HEAD request, and the -L flag follows redirects. The output shows the HTTP status and the Location header for each response.

To check the www and bare variants separately, run the command twice. First curl -sIL http://www.example.com, then curl -sIL http://example.com. Compare the final URLs. If both end at the same host with a 200 status, your canonical redirect works. If they end at different hosts, you have a problem.

To check HTTPS, replace http:// with https:// in the commands. Run all four combinations. https://www.example.com, https://example.com, and the two plain HTTP versions. A complete canonical setup shows all four requests eventually landing on the same HTTPS URL with a 200 status.

The Redirect Chain Checker on this site does this work in a browser interface. It follows the full chain from the URL you enter and reports each redirect hop with its status code and destination. Use it when you need to see the chain, not just the first response.

For a quick check of the status code without following redirects, run curl -sI http://example.com. The first line of the output shows the HTTP version and status code. This is exactly what the www Redirect Checker does internally, except that curl shows you the code and this tool hides it.

The table summarises the options. The curl commands give you full control and full output. The Redirect Chain Checker gives you a readable report without leaving the browser. Both are better than the www Redirect Checker when you need details, and both are worse when you want a single word answer.

Interpreting Results for SEO

The www vs non-www question is one of the oldest in search engine optimisation. Search engines treat www.example.com and example.com as different hosts. If both serve the same content, you have duplicate content. The standard fix is to choose one as canonical and redirect the other to it with the accepted status. This tool checks whether you have done that, at least over plain HTTP.

Google has said for years that it treats www and non-www as equivalent for crawling and indexing purposes, in the sense that it will pick one and consolidate signals. But you should not rely on that. A clean canonical redirect removes ambiguity. It tells search engines and visitors which host you prefer. It also prevents the scenario where someone links to the wrong variant and the link equity splits.

The direction of the canonical redirect is a matter of taste. Some sites prefer www because it looks traditional and works better with cookies on subdomains. Others prefer the bare domain because it is shorter and cleaner. Both are acceptable. What matters is consistency. Every internal link, every canonical tag, and every redirect should point to the same host.

This tool cannot tell you which direction your redirect goes. It can only tell you that the accepted status exists on at least one variant. For a full SEO audit, you need to know the direction, the target, and the behaviour over HTTPS. The curl commands in the previous section give you that information.

A common mistake this tool can help you catch is the missing canonical redirect over plain HTTP. If your site serves both http://www.example.com and http://example.com with 200 status, you have duplicate content over plain HTTP. Search engines may crawl those URLs and see two copies of your site. The tool will say Bad, which is the correct warning.

Another common mistake is the redirect that goes to the wrong place. A permanent redirect from http://www.example.com to http://example.com is fine if you want the bare domain. A permanent redirect to http://www.other-site.com is a hijack. The tool says Good for both. Only a chain checker or a curl command reveals the target.

The http to https redirect is a separate concern from the www canonical redirect. Many sites handle both in one rule. A typical Apache configuration redirects all plain HTTP to HTTPS and then handles the www canonicalisation at the HTTPS level. This tool sees the first redirect, the http to https permanent redirect, and says Good. It never sees the second redirect, the www canonicalisation over HTTPS. A site with no www canonicalisation at all can still earn Good if it redirects plain HTTP to HTTPS.

The table shows five common setups and the verdict each earns. The second row is the trap. A site with no www canonicalisation earns Good because the http to https redirect satisfies the tool. The fourth row shows a standards compliant newer permanent code earning Bad. The fifth row shows a JavaScript or meta refresh setup earning Bad even though it works in browsers.

Limitations

The limitations of this tool come directly from its code. There is no speculation needed. The tool tests only plain HTTP. It never makes an HTTPS request. It checks for exactly one status code. It does not follow redirects. It does not read the Location header. It does not report per-variant results. It collapses two requests into one word.

The HTTPS gap is the most serious limitation. Modern websites serve most of their traffic over HTTPS. Search engines use HTTPS as a ranking signal. Browsers warn users about plain HTTP. A tool that ignores HTTPS entirely can give a misleading picture of your site's redirect configuration. A Good verdict may hide a missing canonical redirect over HTTPS. A Bad verdict may ignore a perfect canonical redirect over HTTPS.

The single-status rule is a close second. The newer permanent redirect code is semantically equivalent to the accepted status for GET requests and is supported by all modern browsers and search engines. This tool rejects it. The temporary redirect codes are temporary, and rejecting them is more defensible, but the tool does not explain why it rejects them. It just says Bad.

The lack of per-variant reporting means you never know which request produced the accepted status. A site that redirects www to the bare host and a site that redirects the bare host to www both earn Good. A site that redirects only the www variant and serves the bare variant directly also earns Good, because the OR logic needs only one accepted response. That third case is not a complete canonical setup, but the tool cannot distinguish it from the first two.

The host level check means page level redirects are invisible. The tool strips www. from your input and tests the host root. It cannot verify that a specific URL redirects correctly. For content migrations or URL structure changes, you need a tool that tests full paths.

The rate limit applies to every page on this site. There is no CAPTCHA on this tool and no tool specific request cap. A shared site wide throttle does apply. If you send more than roughly fifteen requests within a single second from one visitor address, that address receives a 503 error for the rest of the day. For a tool that makes two server side requests per check, you would need to submit many domains very quickly to hit that limit. Normal use is safe.

The tool makes its requests from the server, not from your browser. That means the results reflect the network path between the server and your domain. If the server cannot reach your domain due to a firewall or geographic block, you will see Bad even if the redirect works for your visitors. The fixed older Chrome build user agent may also trigger different behaviour from servers that vary responses by user agent.

Related Tools

When you need to see the full redirect chain with every hop and status code, use the Redirect Chain Checker. It follows redirects from the URL you enter and shows you each step, which fills the main gap in the www Redirect Checker.

When you need to write the actual redirect rules for Apache, use the Htaccess Redirect Generator. It produces the mod_rewrite rules you can paste into your configuration file to implement the canonical redirect this tool checks for.

When you need to confirm that your server is responding at all, use the Server Status Checker. It tells you whether your host is up and returning normal status codes, which helps you distinguish a redirect problem from an availability problem.

Common Misunderstandings

The most common misunderstanding about this tool is that Good means your canonical redirect is correct. It does not. Good means the accepted status exists on at least one plain HTTP variant. The redirect could point to the wrong host, the wrong protocol, or a chain of further redirects. The tool cannot see any of that.

The second most common misunderstanding is that Bad means your site has duplicate content. It does not. Bad means no accepted status was found on either plain HTTP variant. Your site might use the newer permanent redirect code, which is permanent and valid. It might handle canonicalisation only over HTTPS. It might use a CDN that answers plain HTTP with a 200 and handles redirects at the edge over HTTPS. All of those earn Bad without creating duplicate content.

The third misunderstanding is that the tool checks HTTPS. It does not. The old page on this site implied that it did, and that implication was wrong. The code makes two requests, both over plain HTTP. If you want to know about HTTPS, run curl yourself or use a service that tests HTTPS.

The fourth misunderstanding is that the tool reports status codes. It does not. It reports one word. The old page's table of status codes that matter was aspirational fiction. The real tool gives you Good or Bad and nothing else.

The fifth misunderstanding is that the tool can check a specific page. It cannot. The check is host level. Typing example.com/some-page does not test that page. The tool strips the scheme, strips www., and tests the host root.

When to Trust a Good Verdict

A Good verdict is trustworthy as a positive signal in one specific scenario. You have confirmed separately that your HTTPS setup is correct, that your canonical redirect points to the right host, and that your redirect chain is short. In that context, Good confirms that plain HTTP also redirects, which closes the last gap.

A Good verdict is also trustworthy as a sign that someone configured a server side redirect for plain HTTP. The tool completes the crawl in under two minutes. Many sites serve plain HTTP with 200 status on both variants, creating duplicate content. If your site earns Good, you are not in that group.

A Good verdict is not trustworthy as a complete audit. It is one data point from a two request check. Use it as a quick filter. When it says Good, run a fuller check to confirm the details. When it says Bad, run a fuller check to learn why. The single word is a starting point.

The tool's design makes sense for its purpose. It is a fast, free, no signup check that answers a binary question. Does a permanent redirect exist on plain HTTP for at least one host variant? That question is useful for a first pass over a domain list. It is not useful for a deep audit. Knowing the tool's limits lets you use it appropriately.

Frequently Asked Questions

Does this tool check HTTPS redirects?

No. The tool sends two HEAD requests over plain HTTP only, one to http://www.<domain> and one to http://<domain>. HTTPS variants are never requested. A site that redirects plain HTTP to HTTPS earns Good even if the HTTPS versions have no canonical redirect between www and bare.

Why does my site show Bad when I use a 308 redirect?

The tool accepts only the permanent redirect status as evidence of a working redirect. The newer permanent redirect code is a valid permanent redirect, but this tool rejects it. The same applies to the temporary redirect codes. Only an exact match for the accepted status earns the Good verdict.

Can I check a specific page URL with this tool?

No. The tool operates at the host level. It strips the scheme and the www. prefix from your input and builds two host root URLs. Any path you type is not meaningfully tested. For page level redirect checks, use the Redirect Chain Checker or a curl command.

What does Good actually mean?

Good means at least one of the two plain HTTP addresses returned the accepted status in response to a HEAD request. It does not tell you which variant redirected, where the redirect points, or what happens over HTTPS. It is a coarse positive signal, not a full audit.

Why does my site show Bad when both variants work in a browser?

The tool sends HEAD requests and does not follow redirects or execute JavaScript. If your site uses meta refresh tags, JavaScript redirects, or serves content directly over plain HTTP with a 200 status, the tool sees no accepted status and says Bad. The site may work fine for human visitors.

Is there a rate limit on this tool?

There is no CAPTCHA and no tool specific request cap. A shared site wide throttle applies to every page on this site. More than roughly fifteen requests within a single second from one visitor address blocks that address for the rest of the day. Normal use of this tool will not approach that limit.