Domain Redirect Checker

What a healthy chain looks like

Two hops. That is the shape of a well-configured domain: the scheme upgrade, then the canonical host. Measured against ten major domains on 2026-08-21, starting from plain http://:

Nine of the ten use 301 for both hops. Microsoft is the only one that treats the scheme upgrade as temporary. If a hop in your own chain is missing entirely, check the record first with the DNS propagation checker or the CNAME lookup before assuming the redirect rule is wrong.

Four or five hops usually means you are stacking rules: a platform-level redirect on top of an application-level one, a trailing-slash normalizer, and a locale prefix, each added by someone who could not see the others. The second hop is usually the apex-versus-www decision. Every extra hop is a full round trip: DNS resolution if the host changed, a TCP connection, a TLS handshake, then the response.

Why the chain here may differ from the one in your browser

Two reasons, and both are the browser's doing rather than the tool's.

HSTS. Once a host has sent Strict-Transport-Security, the browser refuses plain HTTP to that host for the lifetime of the max-age and rewrites the scheme itself. DevTools labels this "307 Internal Redirect", a status code no server sent and that never crossed the network. See HSTS for the mechanics.

The preload list. Chromium ships a file of hosts that are force-HTTPS before any header is seen. It carries 94,628 entries as of 2026-08-21, and 57 of them are entire top-level domains: .app, .bank, .dev, .foo, .mov, .new, .page, .rsvp, .zip and others. On a .dev or .app domain no browser will ever issue a plain-HTTP request, so an http-to-https redirect there is unreachable in a browser and perfectly visible to this tool.

Neither tool is wrong. This one reports what your server does; the browser reports what it decided not to ask.

There is a third case that no HTTP-level checker can see at all: meta refresh tags and JavaScript location assignments. Those run after a 200 response, inside the page, so there is no status code and no Location header to report.

We probe with GET, and that matters

Most redirect checkers use HEAD because it is cheaper. It also lies on any origin that handles methods differently.

$ curl -sI https://netflix.com    → 405 Method Not Allowed
$ curl -s  https://netflix.com    → 301 Moved Permanently

A HEAD-based checker reports "no redirect, 405" for Netflix. This tool issues a GET with redirect: manual on each hop, so it sees the 301. It follows up to 12 hops, detects loops by exact-URL repetition, and stops on the first non-3xx response.

Bot filtering is the other distortion worth knowing about. Some origins, Amazon among them, answer an unfamiliar user agent with a 503 partway down the chain. That is a response to us, not the redirect your users get. The website status checker is the quicker way to tell a blocked probe from a genuinely broken destination.

Reading the status codes

The column that surprises people is the third one. Per RFC 9110, 301 and 308 are heuristically cacheable and 302 and 307 are not. That, not the words "permanent" and "temporary", is the behavioural difference. A bare 301 gets stored by the browser and reused without asking your server again, which is what makes it feel irreversible.

The fix is not to downgrade to a 302. It is to send Cache-Control on the redirect itself: bit.ly ships 301s with private, max-age=90, and TinyURL ships them with no-store. Both keep the permanent semantics and keep the ability to retarget a link. The full breakdown is on the 301 vs 302 glossary page, and the TTL on the DNS record is a separate clock that governs none of this.

The fourth column is the one that breaks APIs. Both 301 and 302 permit a client to rewrite a POST into a GET. The RFC says so explicitly, and curl does it, so a redirected API endpoint silently loses its request body. Use 307 or 308 there.

Loops, and where they come from

ERR_TOO_MANY_REDIRECTS almost never means a chain that is merely long. Chromium's limit is 20 hops and curl's is 50; real chains are two.

The classic loop is a TLS termination mismatch: your origin redirects http to https, while a proxy or load balancer in front of it terminates TLS and forwards the request to the origin as plain http. The origin sees http, redirects to https, the proxy terminates again, forever. If you are behind a proxy, trust X-Forwarded-Proto instead of the scheme on the socket. See TLS termination for the shape of that setup.

The other common one is an apex/www pair where both sides redirect to the other, usually because one rule lives at the registrar and the other in the app.

Redirects are not a DNS feature

There is no DNS record that produces a redirect. DNS returns A and CNAME records and finishes before any HTTP request is made; a 301 is an HTTP response from a web server.

Registrar "URL forwarding" is a real redirect, but the registrar is running the web server that sends it, which is why forwarding stops working the moment you move your nameservers elsewhere, while the records themselves keep resolving. The domain forwarding explainer covers what each provider actually implements, and domain masking covers the neighbouring case where the URL is supposed to stay put, which is what the domain masking API implements without an iframe. Domain aliasing is the third neighbour: same content, second hostname, no status code at all.

If you run redirects for other people's domains

Redirecting a customer's domain has an ordering requirement that a personal site does not: the destination needs a valid certificate before the redirect is worth issuing, or the browser shows a warning instead of a page. Resolve DNS, provision the cert, confirm the destination answers 200 with the SSL certificate checker, then redirect. How SSL works for custom domains covers the issuance side, and connecting custom domains covers the record set your customers need for multi-tenant custom domains.

Domainee is a custom domains API for SaaS with a native MCP server — 50 domains and 100 GB free. The domain forwarding API handles the redirect case, custom domains handle the serve case, and the debugging runbook covers what to check when a customer's domain misbehaves.

From the command line

Keyless, no signup:

curl -s "https://api.domainee.dev/v1/tools/redirect-checker?url=https://example.com" | jq

Rate limits are per IP and there is no uptime commitment, so it fits scripts and audits rather than a production dependency.