Enter a URL
Use the WWW Redirect Checker to test whether a domain sends visitors to a consistent hostname. Enter one domain and run the check to see whether its www version redirects as expected. This is useful when you want your website to use either www.example.com or example.com as its preferred public address.
The tool performs a check and reports the detected result. It does not change your hosting configuration, install a redirect, monitor traffic, scan for malware or repair the website automatically. If the result is incorrect, the redirect must be configured through your web server, hosting panel, content management system or application.
The www and non-www versions of a domain are technically different hostnames. For example, www.example.com and example.com can be configured to serve the same website, different websites or no website at all. A hostname redirect sends requests from the secondary version to the preferred version.
You may choose either format. There is no general SEO advantage simply because a domain contains www or does not contain it. What matters is consistency: choose one primary hostname, redirect the other version to it, use the primary version in internal links and list only preferred URLs in the sitemap.
Run the test again after changing DNS, SSL, hosting or redirect settings. Some infrastructure changes may take time to become visible everywhere because of caching and DNS propagation.
A reliable redirect helps visitors reach the same preferred hostname regardless of which version they type. It also prevents your marketing material, internal navigation and backlinks from routinely pointing to mixed hostname versions.
When equivalent pages are accessible through several hostname or protocol combinations, search engines must decide which version should represent the content. Permanent redirects, consistent internal links, self-referencing canonical tags and accurate sitemap URLs reinforce the preferred version.
A consistent origin makes analytics, caching, security policies and troubleshooting easier to manage. It also reduces the chance that visitors will encounter an expired certificate, a missing page or a different site configuration on an alternate hostname.
A 301 response indicates that a resource has permanently moved to the URL supplied in the HTTP Location header. It is commonly used when permanently consolidating www and non-www hostnames or replacing an old public URL.
A 308 is also a permanent redirect. Unlike historical behavior associated with some 301 implementations, it preserves the original request method and body. Your server and application requirements determine which permanent status is appropriate.
A 302 normally indicates a temporary move. It can be appropriate when the change is not intended to be permanent. It should not be used for a permanent hostname preference merely because it appears to work in a browser.
A 307 is a temporary redirect that preserves the request method and body. It is useful when a temporary destination must receive the request using the same method.
HTTP status codes describe the response behavior. A successful-looking destination page does not by itself prove that the redirect type is correct, so examine the actual response when performing a technical audit.
Google treats permanent and temporary redirects differently. A permanent server-side redirect is a signal that the target should become the preferred URL in search results. A temporary redirect generally signals that the source should remain the preferred indexed URL.
Redirects do not guarantee indexing or rankings. Google still evaluates whether pages are accessible, useful and suitable for its index. After changing important URLs, Google must recrawl and process the redirects, so search results may not change immediately.
For a website using https://www.example.com as its preferred origin, these alternatives should normally reach that origin consistently:
http://example.comhttp://www.example.comhttps://example.comhttps://www.example.comThe ideal implementation normally reaches the preferred HTTPS version with one direct redirect rather than passing through several intermediate addresses. The same principle applies if you prefer the non-www hostname.
A redirect chain occurs when one URL redirects to another, which then redirects again before reaching the final page. For example, an HTTP non-www address might first go to HTTP www and only then move to HTTPS www. Configure a direct route to the final preferred destination when possible.
A redirect loop occurs when destinations repeatedly send the request back to an earlier address. The browser eventually stops loading the page. Loops often result from conflicting rules in a hosting panel, CDN, application, WordPress plugin or .htaccess file.
Both hostnames involved in an HTTPS redirect should be covered by a valid certificate when visitors may request either one securely. If the alternate hostname presents an invalid certificate, the connection can fail before the browser receives the redirect response.
Do not rely only on an HTTP test. Check HTTPS behavior, certificate validity and the final hostname. Confirm that pages, images, CSS, scripts and forms also use secure preferred URLs.
Always back up the existing configuration before editing server rules. A syntax error can cause a 500 response or make the entire site unavailable. Ask your host or a qualified developer for help if you are unsure which layer currently controls redirects.
A redirect and a canonical tag serve related but different purposes. A redirect sends the user and crawler to another URL. A canonical tag is placed in an HTML page to identify the preferred version among duplicate or very similar pages.
For alternate hostnames that should no longer be used, a permanent redirect is usually clearer than leaving duplicates accessible. On every preferred indexable page, use one self-referencing canonical pointing to the final HTTPS URL. Do not declare a canonical that conflicts with the redirect destination.
An old page should redirect to the most relevant replacement. Sending unrelated URLs to the homepage creates a poor visitor experience and may not be treated as a useful replacement.
If the hostname choice or page move is permanent, configure an appropriate permanent redirect. Reserve temporary redirects for genuinely temporary situations.
Testing only the homepage is not enough. A correct hostname rule should normally preserve paths, so example.com/category/page reaches the corresponding page on the preferred hostname rather than only the homepage.
A CDN may enforce HTTPS while the origin server enforces another hostname, or a plugin may duplicate rules already active in the hosting panel. Understand the full request path and keep one clear redirect policy.
No universal preference applies. Either can work. Choose one, configure it consistently and redirect the alternate hostname.
No. It only checks the submitted domain and reports the detected www redirect behavior.
No. This page is designed to check one submitted domain at a time.
No. A redirect result is not a security verdict. Do not use it as a replacement for a dedicated security or reputation service.
A correct redirect supports consistent access and URL consolidation, but it does not guarantee traffic, indexing or rankings.
Permanent redirects can be cached. CDN, server, DNS and browser caches may also delay visible changes. Verify the live HTTP response and clear only the relevant caches before testing again.
The WWW Redirect Checker provides a quick way to verify an important part of domain consistency. Use its result together with HTTPS testing, canonical inspection, internal-link checks and sitemap review. A direct permanent redirect to one preferred hostname creates a simpler experience for visitors and clearer technical signals for search engines.