Published: May 13, 2021 Updated: Jul 19, 2026

www Redirect Checker Free Tool

Enter a URL

About www Redirect Checker

What the www Redirect Checker Actually Tests

A www Redirect Checker looks at how a domain handles the two most common ways people type it: with the "www" prefix and without it. Enter a domain and the tool sends requests to both versions — example.com and www.example.com — over both HTTP and HTTPS where applicable, then reports what happens: does the server redirect one to the other, does it serve identical content on both, does it return a redirect chain, or does it just fail silently on one variant while working fine on the other. The output typically includes the HTTP status code returned at each hop (200, 301, 302, 307, 308, 404, or a connection error), the final destination URL after all redirects resolve, and the number of hops in the chain.

This sounds like a minor detail, but it's one of those things that quietly breaks SEO and user trust when nobody checks it. A domain can look perfectly fine when you visit it in a browser — because browsers, autocomplete, and cached DNS quietly paper over the problem — while search engine crawlers, old backlinks, and freshly typed-in traffic hit a version of the URL that behaves completely differently.

Why www vs Non-www Even Matters

Technically, www.example.com and example.com are two different hostnames. To a web server and to a search engine, they are not automatically "the same site" just because they look similar to a human. Unless the server is explicitly configured to treat them as one canonical destination, you can end up with:

Two separate, fully indexable copies of every page on your site — a duplicate content problem search engines have to resolve on their own, often not the way you'd choose.
Split link equity — external sites linking to www.example.com and others linking to example.com means your backlink authority is divided between two hostnames instead of consolidated on one.
Broken user experience when one variant works and the other returns a connection timeout, an SSL certificate mismatch, or a generic hosting "coming soon" page.
Analytics fragmentation — traffic and sessions recorded separately depending on which hostname a visitor landed on, muddying your real numbers.

The standard fix is a server-side 301 (permanent) redirect from the non-preferred version to the preferred one. Pick one canonical hostname — most sites today go with the non-www, bare domain, though plenty of established sites still run on www for legacy reasons — and make sure every request to the other variant gets forwarded there with a 301, not silently served as duplicate content.

The Protocol Layer Adds a Second Dimension

www vs non-www isn't the only redirect axis in play. There's also HTTP vs HTTPS. A properly configured domain should funnel all four possible entry points into one final destination:

http://example.com
http://www.example.com
https://example.com
https://www.example.com

All four should ultimately resolve, via redirect, to a single canonical URL — usually the HTTPS version of whichever hostname you've chosen as primary. A www Redirect Checker that also reports on the HTTP/HTTPS behavior gives you the full picture in one pass instead of testing each combination by hand.

How to Use the www Redirect Checker

Type or paste the domain you want to test into the input field. You can enter it with or without a protocol prefix (example.com or https://example.com) — the tool will normalize it and test both www and non-www variants regardless of which form you entered.
Run the check. The tool sends real HTTP requests to each variant of the domain and follows any redirects it encounters, the same way a browser or a crawler would.
Review the status code for each variant. A clean setup shows one variant returning a 301 redirect straight to the other, which then returns a 200 OK.
Check the redirect chain length. Ideally there's a single hop — non-www to www (or vice versa) in one clean 301. If you see two, three, or more hops before landing on the final page, that's worth fixing; each extra hop adds latency and dilutes crawl efficiency.
Confirm the final destination URL matches what you intended as your canonical domain. Sometimes a redirect technically "works" but lands on the wrong protocol, a trailing slash mismatch, or an unexpected subdomain.
If either variant returns an error (timeout, DNS failure, SSL warning, 404, 500), note it — that's a broken entry point that needs a fix at the DNS or server config level, not just a redirect rule.

Reading the Results: Status Codes That Matter

Redirect behavior lives or dies by which status code the server returns. Here's what each of the common codes actually means in the context of a www redirect check, and what it implies for SEO:

Status Code	Meaning	Is It the Right Choice Here?
200 OK (both variants)	Both www and non-www serve content directly, with no redirect at all.	No — this is the classic duplicate content setup. One variant should redirect to the other.
301 Moved Permanently	Tells browsers and crawlers this redirect is permanent; link equity and ranking signals should transfer to the target.	Yes — this is the correct code for a canonical www/non-www redirect.
302 Found (temporary)	Signals a temporary redirect; search engines are more cautious about consolidating ranking signals through a 302.	No — commonly misused for permanent redirects, but not the right choice for canonicalization.
307 / 308 Temporary/Permanent Redirect	Newer HTTP/1.1 codes that preserve the original request method (important for POST requests); 308 is the modern equivalent of 301.	308 is acceptable and behaves like 301 for SEO purposes; 307 behaves like 302.
404 Not Found	The requested hostname/path returns no content at all.	No — means one entry point to your site is completely broken.
Connection error / timeout	DNS isn't resolving for that hostname, or no server is listening on it.	No — usually a missing DNS record (often a missing CNAME or A record for the www subdomain) rather than a redirect problem.

Common Use Cases

People reach for a www Redirect Checker in a handful of recurring situations, and the reason usually shapes what they're actually looking for in the results:

Post-migration verification. After moving hosts, changing CMS platforms, or switching from HTTP to HTTPS, redirect rules frequently get lost or misconfigured in the process. This is one of the first things to re-check after any infrastructure change.
SEO audits. Consultants and in-house SEOs check this as a routine part of a technical audit, because duplicate-content-via-hostname is a common and easy-to-miss issue on sites that were never properly configured in the first place.
Choosing a canonical hostname for a new site. When launching a new domain, deciding once and for all whether the site will be www or non-www, and verifying the redirect is actually enforced server-side rather than assumed.
Debugging inconsistent traffic reports. If analytics show unexpected drops or an odd split between two "different" hostnames that are supposed to be the same site, checking the redirect setup is a fast first diagnostic step.
Verifying SSL certificate coverage. Some sites secure HTTPS for one hostname variant but forget to include the other in the certificate's Subject Alternative Names, causing browser security warnings on the uncovered variant.
Checking third-party or newly acquired domains. Before pointing marketing spend or backlinks at a domain, confirming it resolves cleanly on both common entry points avoids wasted clicks and broken campaigns.

The Technical Background: DNS, Web Server Config, and Canonical Tags

A correct www/non-www setup actually involves two separate layers working together, and it helps to understand both when something isn't behaving as expected.

DNS Layer

For www.example.com to resolve at all, there needs to be a DNS record for it — typically a CNAME pointing to the bare domain, or an A/AAAA record pointing to the same IP address as the root domain. If that record is missing entirely, requests to the www subdomain will fail with a DNS resolution error before they even reach a web server — this is a DNS problem, not a redirect problem, and no amount of server-side redirect configuration will fix it until the DNS record exists.

Web Server / Application Layer

Once both hostnames resolve to a server, that server (or the application/CMS running on it) needs an explicit rule to redirect one to the other. This is usually done through the web server config (an Nginx server block, an Apache .htaccess rewrite rule), a CDN/edge rule (Cloudflare, for example, has a built-in "always use HTTPS" and canonical redirect option), or occasionally through the CMS itself. Without this rule, both hostnames will happily serve identical content side by side, which is the duplicate-content scenario search engines have to resolve for you — and they don't always resolve it the way you'd want.

Canonical Tags as a Secondary Signal

Even with redirects properly configured, it's good practice to also set a <link rel="canonical"> tag on every page pointing to the preferred hostname version. This is a secondary signal, not a replacement for the redirect — a canonical tag tells a crawler which version you prefer if it somehow accesses a page directly, but it doesn't stop users from landing on and getting stuck on the non-canonical version the way a proper server-side redirect does.

Best Practices for www/Non-www Configuration

Pick one canonical version — www or non-www — and stick with it site-wide, including in internal links, sitemap URLs, canonical tags, and any URLs submitted to search consoles.
Use a 301 (or 308) redirect, never a 302/307, for the canonical consolidation. Search engines treat permanent and temporary redirects differently when it comes to passing ranking signals.
Redirect in a single hop. Chains like non-www HTTP to non-www HTTPS to www HTTPS waste a request and add latency; configure the server to jump straight from the non-preferred variant to the final canonical URL.
Make sure your SSL/TLS certificate covers both hostnames, even though only one will be the final destination — the DNS lookup and initial connection for the non-preferred variant still need to succeed before the redirect can even fire.
Test after every hosting migration, CDN change, DNS provider switch, or CMS platform move — these are the events most likely to silently break a previously-working redirect rule.
Check redirects on both the root domain and a handful of internal pages, not just the homepage — some misconfigurations only affect the root and leave inner pages working fine, or vice versa.

Limitations of an Automated Redirect Check

A www Redirect Checker gives you an accurate real-time snapshot of server behavior, but it has boundaries worth knowing about:

It reports what the server does right now, at the moment of the check. DNS propagation delays after a recent change mean a check run minutes after updating a record might not reflect the final state yet.
It typically tests the domain root and doesn't crawl your entire site, so it won't catch a redirect rule that's correct at the root but missing or inconsistent on specific subdirectories or subdomains.
It can't tell you whether search engines have already indexed both hostname variants from before the redirect was put in place — fixing the redirect going forward doesn't instantly clean up historical indexation; that's a separate cleanup process involving your search console tools.
Results can vary slightly by geographic location or DNS resolver in edge cases involving geo-routing or CDN-based configurations, though for a standard redirect rule this is uncommon.
It checks HTTP-level redirect behavior, not JavaScript-based client-side redirects some sites use instead of server-side ones — those behave very differently for crawlers than for browsers and are generally not a recommended approach for canonicalization in the first place.

Frequently Asked Questions

Should I use www or non-www as my canonical domain?

There's no universal SEO advantage to either choice — search engines handle both equally well as long as the redirect is configured correctly and consistently. The decision usually comes down to existing brand recognition, what your backlinks already point to, cookie-scoping considerations for subdomains, or simple preference. What actually matters is picking one and enforcing it everywhere, not which one you pick.

Why does my browser show the correct site on both www and non-www, but this tool reports an error on one of them?

Browsers often mask underlying problems through cached DNS lookups, browser autocomplete correcting the URL for you, or cached redirects from a previous visit. A fresh server-side check bypasses all of that and reveals what a new visitor, a crawler with no cache, or a freshly typed URL would actually experience — which is exactly why it's worth checking with a tool instead of just trusting what you see in your own browser.

I see a redirect but it's a 302 instead of a 301 — does that actually matter?

Yes, for two reasons. First, 302 signals to search engines that the redirect is temporary, which makes them more cautious about consolidating ranking signals and indexing decisions onto the target URL — sometimes they'll keep both versions indexed longer than they should. Second, many CMS platforms and hosting panels default to 302 for convenience settings even when you intend a permanent move, so it's a common misconfiguration worth actively correcting to a 301 or 308.

What does it mean if one of the variants times out completely instead of redirecting?

A timeout or connection error (rather than a redirect or an HTTP error page) almost always points to a missing DNS record for that hostname — most often, no A or CNAME record exists for the www subdomain, so the request never even reaches a web server to be redirected. This needs to be fixed at the DNS provider level, not in the web server's redirect rules, since there's no server for the redirect rule to run on until the DNS record resolves.

Can I check redirects for a specific page, not just the homepage?

Yes — enter the full URL of the page rather than just the bare domain, and the tool will test the www and non-www redirect behavior for that exact path. This is worth doing periodically on a sample of inner pages, since some sites have redirect rules that work correctly at the root but are inconsistently applied deeper in the site structure.

Does fixing the redirect immediately remove duplicate pages from search engine results?

No, not immediately. Correcting the redirect stops new duplicate content from being created going forward and starts consolidating future signals onto the canonical version, but any pages already indexed under the old, non-canonical hostname will only drop out of the index gradually as search engines recrawl and process the redirect. Submitting the canonical URLs through your search console tools and being patient through the normal recrawl cycle is the expected path here — there's no instant fix for historical indexation.