www Redirect Checker


Enter a URL



About www Redirect Checker

Check how a public URL behaves across its HTTP, HTTPS, www, and non-www versions. This is especially useful after a hosting change, HTTPS rollout, domain configuration update, or site migration. The result can reveal the final destination and any intermediate redirects, helping you confirm that old URL variants lead to the hostname and protocol you intend to use.

Check all four URL variants

A migration review should not stop after testing one homepage address. For a site that prefers https://www.example.com/, compare these variants:

URL to test Typical intended behavior
http://example.com/ Redirects to the preferred HTTPS and www address
http://www.example.com/ Redirects to the preferred HTTPS address
https://example.com/ Redirects to the preferred www hostname
https://www.example.com/ Loads as the preferred version without another hostname redirect

The same checks should be repeated for representative internal paths. Homepage rules can work while product pages, articles, files, or legacy URLs lose their paths or lead somewhere unexpected.

A practical migration verification sequence

  1. Define the preferred format. Write down the intended protocol and hostname, such as https://www.example.com.
  2. Test the four homepage variants. Record each starting URL, redirect step, status code, and final destination.
  3. Repeat the test on deeper pages. Include an article, category, product, and any other URL pattern the site uses.
  4. Check mapped legacy URLs. Old pages should lead to their relevant replacements rather than automatically sending every request to the homepage.
  5. Confirm path handling. A request for /products/widget should not become / unless that was the migration plan.
  6. Review query strings when they matter. Test only non-sensitive parameters and check that required values are retained. Never submit tokens, session identifiers, password-reset links, or private preview URLs.
  7. Compare unexpected errors separately. The Server Status Checker can help distinguish a redirect issue from a broader response or availability problem.
  8. Retest after corrections. Check both the original failing URL and other representative paths so that a narrow fix does not conceal a wider rule conflict.

Worked example: non-www migration to www

Suppose a store has chosen https://www.example.com as its preferred address. You test an old product URL and observe this chain:

http://example.com/products/widget
301 → https://example.com/products/widget
301 → https://www.example.com/products/widget
200 → final page response

This result preserves the product path and reaches the intended hostname. However, it also uses two redirects: the first changes HTTP to HTTPS, and the second adds www. If the site configuration permits it, a direct redirect from the starting address to https://www.example.com/products/widget may be simpler to maintain.

Do not judge the result by the final 200 response alone. Open the destination and confirm that it is the correct product page. A successful response from an unrelated category page would still indicate a faulty migration mapping.

How to read the reported behavior

Observed result What to investigate
No redirect The tested variant may be serving content directly, or the relevant rule may not apply under the conditions used by the checker.
One redirect to the preferred URL Confirm that the protocol, hostname, path, and necessary parameters are all correct.
Several redirect steps Separate rules may be changing the protocol, hostname, language, or legacy path. Review each step rather than assuming the chain is necessary.
Redirect loop Competing server, proxy, application, or content delivery rules may be sending the request back to an earlier URL.
Unexpected final address Compare the outcome with the migration map before changing configuration. The technically reachable page may not be the editorially correct destination.

Status codes provide context but are not a complete diagnosis. Codes such as 301 and 308 generally describe permanent redirects, while 302 and 307 generally describe temporary ones. A code does not confirm that the configuration matches the site owner’s actual intent.

A common migration mistake

Testing only http://example.com/ can create false confidence. That address may reach the correct homepage while https://example.com/article-name loads without redirecting, drops the article path, or enters a chain. Test every protocol and hostname combination on multiple URL patterns. Internal links should also point directly to the preferred URLs rather than relying on redirects for routine navigation.

Limits of a redirect check

The output is an observation made under a particular set of request conditions. Responses can vary by location, headers, cookies, authentication state, cache, firewall rules, device handling, or content delivery configuration. A browser may also have a cached redirect that differs from the current server response.

Client-side navigation performed by JavaScript may not appear as a standard HTTP redirect. The checker also cannot determine how a search engine will index a URL or establish that a migration is complete. Review the tool methodology and limitations when a result differs from a browser, crawler, or server log.