Enter a URL
A www redirect checker helps you examine how a website handles its www and non-www hostnames. For example, it can help determine whether visitors requesting www.example.com are redirected to example.com, whether the opposite happens, or whether both versions remain independently accessible.
Choosing either version is technically valid. The important issue is consistency. A predictable redirect can reduce duplicate URL variants, simplify analytics and reporting, and support clearer canonical signals. The check may also reveal extra redirect steps, an unexpected destination, a temporary response where a permanent redirect was intended, or a failed request.
Suppose a business has selected https://example.com/ as its preferred form. A request for http://www.example.com/services might redirect directly to https://example.com/services. That is generally simpler than first changing HTTP to HTTPS and then removing www in a second redirect.
In another situation, www.example.com and example.com may both return successful pages without redirecting. The pages might look identical, but they remain separate URLs from the perspective of browsers, crawlers, caches and reporting systems. This is not automatically proof of a problem, but it warrants checking canonical tags, internal links and server policy.
A third possibility is that a redirect sends every old URL to the homepage. For example, a request for an old product path could lose its path and end at the main page. Even if the redirect technically works, the destination may not satisfy the visitor’s original intent.
| Observed response | What it can indicate | What to review next |
|---|---|---|
| 301 or 308 | A permanent redirect is being communicated. | Confirm that the destination is intentional and that paths and parameters are preserved appropriately. |
| 302 or 307 | A temporary redirect is being communicated. | Determine whether the behavior is genuinely temporary or produced by application, location or session logic. |
| 200 | The requested URL returned content without an HTTP redirect. | If both hostname versions return 200, review canonicalization and internal linking. |
| 4xx | The request was rejected, forbidden or not found. | Check DNS, access controls, routing rules, firewall policy and the exact URL. |
| 5xx | The server or an intermediary could not complete the request. | Review server, proxy, CDN and application logs; repeat the test after ruling out a temporary incident. |
| Repeated destinations | A redirect loop may exist. | Inspect conflicting rules across the server, application, CDN and HTTPS configuration. |
Status codes should be interpreted alongside the full chain and final page. A permanent status does not prove that the destination is relevant, and a successful final response does not make every intermediate step desirable.
Open both hostname variants in a private browser window and confirm the final address. Inspect the browser’s network panel to see the request sequence. Test representative deep URLs, query strings and trailing-slash variations. Review internal links, canonical elements, XML sitemaps and structured data for hostname consistency. Technical teams should also inspect web server, application, load balancer and CDN rules to identify overlapping redirects.
After a configuration change, clear relevant caches carefully and repeat checks from more than one network or location where possible. Monitor logs for loops, spikes in errors and requests that unexpectedly lose their paths.
Only submit URLs that are appropriate to disclose to a third-party service. Do not enter private administration addresses, credentials, signed download URLs, password-reset links, session tokens or confidential query data. A URL may be recorded in operational logs by the checking service, hosting provider or other network intermediaries.
Results represent a request made at a particular time and from a particular environment. DNS propagation, CDN caching, geolocation, cookies, user-agent rules, rate limits, bot protection, IPv4 or IPv6 routing, TLS certificate issues and temporary server conditions can change the response. Some tools may use a different HTTP method or request headers from a normal browser.
HTTP checks may not detect redirects performed only by JavaScript, application interactions or HTML refresh instructions. Authentication, consent screens and personalized routing can also produce different outcomes for real users. Treat the report as diagnostic evidence rather than a complete account of every visitor experience.
Either can work. Select one primary hostname and apply it consistently across redirects, internal links, canonical references and sitemaps.
No. A 301 communicates a permanent move, while a 302 communicates a temporary one. The appropriate status depends on the intended duration and purpose of the redirect.
Fewer steps are usually easier to maintain and faster to resolve. A direct redirect is generally preferable when it can safely replace a chain.
Your browser may use cached redirects, cookies, HSTS rules, a different location or different request headers. Security systems may also treat automated requests differently.
No. Redirect rules can vary by directory, content type or application route. Test several important internal URLs.
They serve different purposes. A canonical tag provides a preference signal within a page, while an HTTP redirect sends visitors and clients to another URL.
Confirm whether that behavior is intentional. Then review canonical references, internal links, sitemaps, analytics configuration and server rules before deciding whether to implement a redirect.