Domain Redirect Checker

Server assisted New DNS & Domains

The Mutqan server builds the four start URLs from the domain, follows each one hop by hop (up to five responses per variant, six seconds per hop, twenty seconds in all, no page bodies read) and compares where they end. You see every status code and Location header, the canonical host when the four agree, and findings for plain-HTTP endings, downgrades to HTTP, temporary redirects, long chains, loops and variants that do not resolve. Every hop passes the same public-address check as the first request.

Privacy: The Mutqan server sends the small, fixed test requests described on this page to the host you name, and nothing is stored. Use it only against systems you are authorised to test.

How should a domain's www, non-www, HTTP and HTTPS addresses redirect?

A site should answer on one canonical address and send the other three combinations of http/https and www/non-www there with permanent redirects (301 or 308), so browsers, links and search engines see a single site. Plain HTTP should redirect to HTTPS, on the same host first when the domain is to be HSTS-preloaded, and chains should stay short: every extra hop costs a round trip before the page loads.

How to use Domain Redirect Checker

  1. Type the domain (with or without www.; a pasted URL is reduced to its host).
  2. Press Check redirects.
  3. Read the summary: one canonical host, all four variants consistent and four of four ending on HTTPS is the goal.
  4. Use the findings and the table of every response to fix the redirects that are temporary, too long or end in the wrong place.

Domain Redirect Checker features

  • All four variants in one run: http://, https://, http://www. and https://www. of the domain
  • Every response of every chain with its status code and Location header, downloadable as CSV
  • The canonical host when the four agree, and whether they end on one scheme and host
  • Findings for plain-HTTP endings, HTTPS downgraded to HTTP, temporary redirects, chains of more than two redirects, error pages and loops
  • A check that plain HTTP first redirects to HTTPS on the same host, which matters when the domain is to be HSTS-preloaded
  • Clear per-variant errors: does not resolve, timed out, unreachable, blocked address, invalid Location header

Inputs and outputs

Inputs

  • Domain name: the apex or the www. name (the four variants are always built from the apex), or a URL, which is reduced to its host.
  • Internationalised names are accepted; IP addresses are not, because the www. variants need a name.

Outputs

  • Summary: the domain, the canonical host (when all variants end on one host), whether the four are consistent, how many end on HTTPS and how many failed.
  • The four variants: start URL, number of redirects, status chain, final URL and result.
  • Every response: each hop with its URL, status code and Location header.
  • Findings: what to fix, or confirmation that all four variants end at the same address.

Domain Redirect Checker example

A domain whose four variants all reach https://www.

Input:

wikipedia.org

Output:

Summary: Domain wikipedia.org · Canonical host www.wikipedia.org · Consistent Yes · Ending on HTTPS 4 / 4 · Variants with errors 0
The four variants:
http://wikipedia.org/ | 2 | 301 → 301 → 200 | https://www.wikipedia.org/ | OK (2xx)
https://wikipedia.org/ | 1 | 301 → 200 | https://www.wikipedia.org/ | OK (2xx)
http://www.wikipedia.org/ | 1 | 301 → 200 | https://www.wikipedia.org/ | OK (2xx)
https://www.wikipedia.org/ | 0 | 200 | https://www.wikipedia.org/ | OK (2xx)
Findings: All four variants end at the same address: https://www.wikipedia.org

How to read the Domain Redirect Checker results

Consistent with a canonical host and four of four on HTTPS is the healthy result: every variant reaches the same HTTPS address.

A variant that "stays on plain HTTP" or "redirects down to plain HTTP" exposes visitors to an unencrypted page; redirect it to the HTTPS address with a 301 or 308.

A temporary redirect (302, 303, 307) on a canonical-domain move tells search engines the old address is still the real one; use 301 or 308 unless the move really is temporary.

Different final hosts mean the variants serve two sites; pick one host and redirect the others to it.

When to use Domain Redirect Checker

  • Checking a launch or a migration to HTTPS: every variant should land on the new canonical address.
  • Preparing an HSTS preload submission, which needs the same-host HTTPS redirect.
  • Finding why "example.com" works but "www.example.com" does not, or the other way round.
  • Auditing SEO duplicates caused by a site that answers on both www and non-www.

Troubleshooting

  • "Does not resolve" for the www. variants: the www name has no A or AAAA record. Add one (or a CNAME) at your DNS provider.
  • "Unreachable" or "Timed out" for https://: no web server answers on port 443, or the TLS handshake fails; the SSL Certificate Checker shows why.
  • "Refused (blocked address)": the name or a hop resolves to a private or reserved address that the Mutqan server never connects to.
  • "Redirect loop": two rules send the request back and forth, often an HTTPS redirect at the server fighting one at the CDN. Disable one of them.

Frequently asked questions about Domain Redirect Checker

Should my site use www or the bare domain?

Either works. What matters is choosing one and sending the other three variants to it with a permanent redirect, so links, cookies and search engines see one address. The tool shows the host the variants end on and flags any that end elsewhere.

Does it matter whether the redirect is 301 or 302?

Yes. 301 and 308 say the move is permanent, so browsers may cache it and search engines move the old address's signals to the new one; 302, 303 and 307 say it is temporary and the original address stays the indexed one. A canonical-domain redirect is normally permanent, and 308 and 307 also keep the request method, which matters for forms and APIs.

Why is a long redirect chain a problem?

Every hop is one more round trip before the page starts to load, and long chains break more easily. http://example.com → https://example.com → https://www.example.com is common and fine; anything longer should be shortened. The tool flags a variant that needs more than two redirects.

What does "does not first redirect to HTTPS on the same host" mean?

It matters only if the domain is to go on the HSTS preload list. hstspreload.org requires the plain-HTTP address to redirect first to HTTPS on the same host (http://example.com → https://example.com), so the browser receives the HSTS header for that name before any move to www. A first hop straight from http://example.com to https://www.example.com, or one that stays on plain HTTP, skips that step; for a site that is not being preloaded, such a redirect is fine.

Is the check made from my computer?

No. The requests go from the Mutqan server at the Cloudflare edge, without cookies and without reading page bodies. A site that redirects by country, by network or by client type may send your own browser somewhere else.

Technical notes

Redirect semantics come from RFC 9110 §15.4: 301 and 308 are permanent, 302, 303 and 307 temporary, and 307 and 308 keep the request method. The Location value may be relative and is resolved against the URL that returned it. Each hop is a GET without a body read; its host is resolved through public DNS and every address must be public before the request is sent, so a redirect into private address space is refused rather than followed.

HSTS (RFC 6797 §7.2) asks a host to answer plain HTTP with a permanent redirect to HTTPS, and hstspreload.org additionally requires that redirect to stay on the same host. A variant is followed for at most five responses; a chain still redirecting at the fifth is reported as too many redirects, and a URL seen twice as a loop.

Limitations and methodology

The requests leave from the Mutqan server at the Cloudflare edge. Sites that redirect by country, network or client type, or that block automated clients, may behave differently in your browser.

Only the redirect chain is read: page bodies, meta refresh tags and JavaScript redirects are not followed, and paths other than / are not tested.

Each variant stops after five responses, six seconds per hop and twenty seconds for the whole check.

When no variant reaches a final address (all four fail), there is no canonical host to show; the per-variant errors say why.

Security and privacy

The Mutqan server sends plain GET requests, with no cookies and no body, to the four addresses of the domain you enter and to each address they redirect to. Nothing is stored; use it only on sites you are allowed to test.

References

  • RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
  • Redirections in HTTP — MDNMDN Web Docs (Mozilla)HTTP redirects: 3xx status codes with a Location header, permanent (301, 308) versus temporary (302, 303, 307), and how redirect loops arise.
  • Redirects and Google SearchGoogle Search CentralHow Google treats permanent (301, 308) and temporary (302, 303, 307) server-side redirects when it picks the canonical URL of a moved page or site.