Redirect Checker: How to Audit URL Redirects for SEO
Most redirect problems are invisible until you read the raw response headers. A redirect that "works" in the browser can secretly be a 302 where you wanted a 301, a four-hop chain, or a jump from HTTPS to an HTTP URL that trips a mixed-content warning. None of that shows up by clicking the link; it shows up in the hop chain. This guide is about reading that hop chain: how to run an audit with our Redirect Checker, what each status code means in context, and how to tell a redirect that's fine from one that needs fixing.
If you want the decision logic for which code to choose, see 301 vs 302: which to use. For repairing tangled redirects, see how to fix redirect chains and loops. This post is the audit layer that sits in front of both.
What the tool actually shows you
Paste a URL into the Redirect Checker and you get the full hop chain: every intermediate URL between what you typed and where you finally land, with the HTTP status code and Location header at each step. A clean result is one hop and a 200:
1. https://example.com/old → 301 → https://example.com/new
2. https://example.com/new → 200 OK
A result worth investigating looks like this:
1. http://example.com/page → 301 → https://example.com/page
2. https://example.com/page → 302 → https://www.example.com/page
3. https://www.example.com/page → 301 → https://www.example.com/page/
4. https://www.example.com/page/ → 200 OK
Three hops, a stray 302 mixed in with 301s, and the first hop starts on http://. Every one of those is a finding. You read the chain top to bottom and ask three questions at each row: right code? necessary hop? final URL the one I intended?
Reading the status codes in context
The number isn't good or bad on its own; it's good or bad relative to what you meant.
| Code | Meaning | When it's correct | When it's a red flag |
|------|---------|-------------------|----------------------|
| 301 | Moved Permanently | Permanent moves: old slug→new, http→https, www canonicalization | Appears on a temporary redirect (maintenance, A/B test); equity moves to a page you'll revert |
| 302 | Found (Temporary) | A/B tests, maintenance pages, short-lived geo routing | Appears on a permanent move; old URL stays indexed, new one stalls |
| 307 | Temporary Redirect | Temporary move where the HTTP method must be preserved (form POSTs, APIs) | Used as a generic "modern 302" without a method reason; usually fine, but check it's intentional |
| 308 | Permanent Redirect | Permanent move, method-preserving; what Next.js emits for permanent: true | Rarely a flag; Google treats it like 301. Just confirm you expected it |
Two things the tool helps you catch that people miss:
- A 308 where you "expected 301." If you built redirects in Next.js, Vercel, or a similar framework,
permanent: truereturns 308, not 301. Seeing 308 in the chain is correct, not a bug. Don't go "fix" it. - A 302 hiding inside a chain of 301s. When one hop in an otherwise-permanent chain is a 302, it can stall consolidation for the whole path. The checker makes the odd one out obvious because the codes sit in a column.
Two things the hop chain reveals that a browser won't
Mixed content (HTTPS → HTTP). If any hop redirects from an https:// URL to an http:// URL, the chain is downgrading the connection. Browsers may block it or strip the padlock, and it's a straightforward security and trust problem. In the chain, scan the scheme of each Location; every hop should be https://. A redirect that lands on http:// and then bounces back to https:// is both a chain and a mixed-content smell; collapse it to a single HTTPS hop.
Meta-refresh and JavaScript redirects. Not every redirect is an HTTP redirect. Some pages return 200 OK and then redirect via <meta http-equiv="refresh" content="0;url=..."> or window.location in script. These are invisible to a pure header check because the status is 200; the redirect happens in the rendered HTML. They're worse than a 301 for SEO: slower, less reliably followed by crawlers, and equity transfer is murky. When the checker shows a 200 but you know the page redirects in a browser, that's the tell: you've got a meta-refresh or JS redirect that should be replaced with a real server-side 301.
A practical audit workflow
- Run your money URLs first: homepage, top landing pages, anything with backlinks. Paste each into the Redirect Checker.
- Count the hops. More than one hop to reach 200? Flag it for flattening; see how to fix redirect chains and loops.
- Check the code at each hop matches intent. Permanent move → 301/308. Temporary → 302/307. A mismatch is the highest-value fix because it's silently misdirecting Google.
- Verify the scheme stays HTTPS the whole way down.
- Confirm the final URL is canonical: the version you've set as
rel=canonicaland submitted in your sitemap. A redirect that lands on a non-canonical variant just sets up another redirect later. - Cross-check on the wire. For anything surprising, confirm with
curl -I -L <url>so you're reading the live response, not a cached or config-file assumption.
When to fix versus when to leave it
Not every imperfect redirect is worth a deploy. Use this triage:
- Fix now: wrong code on a permanent move (302 where 301 belongs), any loop, any chain on a high-traffic or linked URL, any HTTPS→HTTP downgrade, any meta-refresh/JS redirect on an important page.
- Fix soon: two-hop chains on lower-traffic pages, redirects landing on a non-canonical variant.
- Leave it: a single clean 301/308 hop to the canonical URL on HTTPS. That's the target state; don't manufacture work optimizing a redirect that's already correct.
The goal of an audit isn't zero redirects; redirects are how you preserve equity through change. The goal is that every redirect is one hop, the right code, staying on HTTPS, landing on the canonical URL. The hop chain tells you, row by row, whether you're there.
Frequently Asked Questions
What's the difference between checking a redirect in the browser versus a redirect checker?
A browser only shows you the final page; it hides how many hops it took, what status code each used, and whether the scheme changed. A redirect checker exposes the full hop chain with each code and Location header, so you can spot chains, wrong codes, and HTTPS downgrades that the browser silently resolves.
My redirect checker shows 308 but I configured a 301. Is that wrong?
No. Frameworks like Next.js emit 308 Permanent Redirect when you set permanent: true. It's method-preserving and Google treats it the same as a 301. Seeing 308 in the chain is expected behaviour, not an error to fix.
How do I tell if a redirect is a meta-refresh or JavaScript redirect?
The status code will be 200 OK even though the page clearly redirects in a browser. HTTP redirects show a 3xx status; meta-refresh and JS redirects happen in the page body after a 200. If the checker reports 200 but the page moves you elsewhere, replace it with a server-side 301.
What does a mixed-content redirect look like in the hop chain?
Any hop whose Location header points to an http:// URL while the previous hop was https://. The connection is being downgraded to insecure. Audit the scheme of every hop; all of them should stay https:// from start to finish.
How often should I audit my redirects?
Spot-check key URLs after any migration, CMS change, CDN rule edit, or framework upgrade, since those are when new chains and wrong codes appear. For ongoing sites, a quarterly pass over top pages plus a check before every launch catches most problems before Google recrawls them.
Which status codes should appear in a healthy redirect?
For permanent moves, 301 or 308. For temporary ones, 302 or 307. A healthy audit shows a single such hop landing on a 200 OK at the canonical HTTPS URL. Multiple hops, a temporary code on a permanent move, or a 200 that still redirects are the patterns to fix.