Redirect Checker — trace every hop, status code and header

What a redirect checker shows you

When you type a URL, the server often answers "not here — go there" before any page loads: from http:// to https://, from example.com to www.example.com, from an old page to its replacement. Browsers follow those redirects so quickly you never see them, which is exactly why broken, slow or wrong redirects go unnoticed. This checker follows the chain one hop at a time and shows every step: the status code, where it points (the Location header), how long it took — split into connection, TLS and server time — and all the response headers.

Reading the status codes

• 301 Moved Permanently and 308 Permanent Redirect — the page has moved for good. Search engines transfer its rankings to the new URL. A 308 also obliges the browser to repeat the same method (POST stays POST).
• 302 Found, 303 See Other and 307 Temporary Redirect — temporary. The old URL may stay in search results and keep its credit. Right for login, language and campaign redirects; wrong for a page that has moved permanently.
• 200 OK — the chain ended on a real page. This is what every chain should end with.
• 404 Not Found and 410 Gone — a dead end. Links and rankings that pointed at the first URL are lost.
• 403, 429 and 503 — the server, or a firewall in front of it, refused the request. The checker names the culprit when it can recognise it (Cloudflare, Akamai, Imperva, Sucuri, DataDome, AWS WAF).
• 5xx — the destination is failing. Search engines slow down crawling and eventually drop pages that keep erroring.

What the checker flags

Loops and chains

A loop — rule A sends visitors to B and rule B sends them back — breaks the page entirely with "too many redirects". It's usually two layers disagreeing: a CDN that talks to your server over http while the server forces https, or one rule adding a trailing slash while another removes it. Chains of three or more hops don't break anything, but each hop is another round trip on a mobile connection, and Googlebot stops following after ten. Point the first URL straight at the final one.

Temporary where it should be permanent

The most common SEO mistake in redirects: a page moved for good with a 302. Search engines may keep indexing the old URL and won't fully credit the new one. If the move is permanent, make it a 301 or 308.

Downgrades, hosts and the final page

The checker warns when a redirect drops from https to http, confirms when http:// is upgraded to https://, and shows which host is canonical (with or without www). On the page the chain ends at, it reads the <meta http-equiv="refresh"> tag (a browser-side redirect), the meta robots tag and X-Robots-Tag header (a noindex there hides the page from search), and the canonical link, which may point search engines somewhere else entirely.

Check as Googlebot, GPTBot or an iPhone

Servers don't always treat every visitor the same. A mobile redirect may only fire for a phone, a firewall may block AI crawlers by user agent, and a misconfigured rule may send bots somewhere humans never go — which search engines treat as cloaking. Switch the user agent to Googlebot, Bingbot, GPTBot, ClaudeBot, PerplexityBot or an iPhone and compare the chains. One honest caveat: the real crawlers request pages from their own networks, and some firewalls verify bots by IP address, so a block that only appears for a crawler user agent can also mean "impersonators are blocked".

Bulk mode: up to 20 URLs

Paste a list — your key landing pages, every variant of the home page, the URLs from a sitemap — and get a table with each chain's status codes, final URL, time and verdict. Expand any row to see every hop, or export the whole table as CSV.

Migration map mode: verify a redirect plan

Site migrations live or die by their redirects. Paste your redirect map as "old URL, new URL" pairs — exported from the spreadsheet, CSV or tab-separated, or with arrows — and each row is judged on its own:

• Pass — the old URL answers with a permanent redirect and lands, with a 200, on the expected page.
• Wrong target — it redirects, but somewhere else (often the home page, which search engines treat as a soft 404).
• Temporary — right destination, but via a 302 or 307.
• Chain or slash differs — right destination, reached through extra hops.
• No redirect or broken target — the old URL still serves its old page, or the new one returns an error.

Problems come first, and the result exports as CSV for the client or the developers. Relative paths like /blog/old-post are resolved against the site address you give (or the first full URL in the list).

Related tools

If a hop fails with a certificate error, the SSL Certificate Checker explains why. The Robots.txt Tester tells you whether crawlers may fetch the final URL at all, and the SEO & AI Visibility Audit reviews the page the chain ends on.

Redirects break later. Monity catches it.

Redirects that work on launch day break later: a CMS update rewrites the rules, a plugin is removed, a CDN setting changes. Monity re-checks your important URLs on a schedule and alerts you in email, Slack or Teams when a status code changes — a 301 that becomes a 404 — when the canonical URL changes, or when a page turns noindex. Set it up for the weeks after a migration and you'll hear about a broken redirect before your rankings do. The free plan watches three URLs, forever.