---
title: Why does my SEO audit flag a redirect chain? How to check with the Redirect Checker
description: An SEO crawler reports a redirect chain or a 302 on your homepage, and the browser just shows the final page. To check redirects, request the URL people actually type and follow every hop yourself: status code, Location header and timing for each. Here's how to do it with the free Redirect Checker, how to tell a harmless chain from a costly one, and the curl command that confirms it.
canonical: https://watchfor.io/blog/how-to-check-redirects
---

# Why does my SEO audit flag a redirect chain? How to check with the Redirect Checker

2026-10-04 · WatchFor Team · Guides · guides, http, seo

An SEO crawler reports a redirect chain or a 302 on your homepage, and the browser just shows the final page. To check redirects, request the URL people actually type and follow every hop yourself: status code, Location header and timing for each. Here's how to do it with the free Redirect Checker, how to tell a harmless chain from a costly one, and the curl command that confirms it.

To check redirects, request the URL people actually type (usually the
`http://` or non-`www` form) without letting anything follow the redirect for
you, note the status code and `Location` header, then request that location
and repeat until a page answers. Each hop is a full round-trip, and its
status code tells browsers and search engines whether the move is permanent
(301, 308) or temporary (302, 307).

The free [Redirect Checker](/redirect-checker) does exactly that from a
WatchFor probe, one request per hop, and flags loops, long chains, HTTPS
downgrades and temporary redirects. No signup.

## What this tool answers

*Where does this URL really end up, through how many hops, and are they the
right kind?* Reach for it when a crawler like Screaming Frog, Ahrefs or
Search Console reports a redirect chain, when a browser stops with
`ERR_TOO_MANY_REDIRECTS`, after moving a site to HTTPS or to a new domain,
or when you change the canonical host between `www` and the apex. The
browser's address bar only shows where you landed; the hops in between are
invisible unless you follow them one at a time.

## A real example

### Checking redirects when an audit reports a chain on the homepage

A frequent audit finding is "redirect chain" or "302 redirect" on the
homepage, even though the homepage obviously works. We checked how a large
public site handles the address most people type.

In the [Redirect Checker](/redirect-checker) we entered `http://mozilla.org`
(plain HTTP, no `www`) and pressed **Follow redirects**. The run came from the
Vilnius probe:

![The Redirect Checker result for http://mozilla.org: 2 redirects before the content, final 200, 476 ms total. Hop 1 http://mozilla.org/ answers 302 with Location https://mozilla.org:443/ in 16 ms, hop 2 https://mozilla.org/ answers 301 with Location https://www.mozilla.org/ in 214 ms, hop 3 https://www.mozilla.org/ answers 200 in 86 ms, and an amber warning says one hop uses a temporary redirect](/blog/how-to-check-redirects-chain.webp)

Three requests, **two redirects**, and a final **200** after 476 ms:

1. `http://mozilla.org/` answered **302 Found** with
   `Location: https://mozilla.org:443/`, in 16 ms.
2. `https://mozilla.org/` answered **301** to `https://www.mozilla.org/`, in
   214 ms. The jump here is the new TLS connection the switch to HTTPS needs.
3. `https://www.mozilla.org/` answered **200** in 86 ms.

The checker raised one warning: a temporary redirect on hop 1.

Is the chain itself a problem? Not this one. HTTP to HTTPS on the same host,
then apex to `www`, is the order the
[HSTS preload list](https://hstspreload.org/) asks for: it wants the HTTP
redirect to stay on the same host so the browser receives the apex's HSTS
header. Collapsing it into one hop (`http://mozilla.org` straight to
`https://www.mozilla.org/`) saves a round-trip but skips that header. Two
hops is the usual minimum for a site that redirects apex to `www`.

The 302 is the real finding. Google treats a temporary redirect as "the old
URL stays canonical" and a permanent one as a signal that the target should
be canonical, and browsers can cache a 301 but not, by default, a 302. For a
move that will never be undone, HTTP to HTTPS, it should be permanent.

**The answer:** keep the two hops, change the first one to **301** (or 308).
In nginx that's the port-80 server block:

```nginx
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}
```

In Apache, `Redirect permanent / https://example.com/`; on Cloudflare, the
**Always Use HTTPS** setting sends a 301.

## How to read the results

| What you see | What it means |
| --- | --- |
| **N redirects before the content** | Redirect hops only; the request that finally lands isn't counted. 0 means the URL answers directly. |
| **final 200** | The status of the last hop. Green for 2xx, red for 4xx/5xx or no answer. A chain ending on 404 sends every visitor to an error. |
| **Total ms** | Time for the whole walk, every hop included. |
| **Row number and status** | One row per request. Amber for 3xx, green for 2xx, red for errors. |
| **URL and Location** | What was requested and the raw `Location` header it got back. |
| **ms on the right** | Time to first byte for that hop. A hop that changes host or scheme pays for a new connection. |
| **Amber warnings** | A temporary redirect (302/307), three or more redirects, or a page that redirects again with a meta refresh or JavaScript. |
| **Red verdicts** | A loop, a hop from HTTPS back to HTTP, a chain still redirecting after 10 hops, a hop to a private address, or a final error. |
| **Green line** | "Clean chain": permanent redirects only, ends on success, never leaves HTTPS. |

## More ways to use it

- **After a domain move.** Run a handful of old deep URLs, not just the
  homepage. Each should land on its own new page with one 301, not on the
  new homepage.
- **Fixing ERR_TOO_MANY_REDIRECTS.** The checker stops on the first repeated
  URL and shows which two rules are bouncing. The usual pair is a CDN set to
  "Flexible" SSL with an origin that forces HTTPS; the
  [redirect loop guide](/blog/too-many-redirects) lists the others.
- **Language and login redirects.** A 302 from `/` to `/en-US/` or to a login
  page is correct: it depends on the visitor and shouldn't be cached.
- **Marketing links.** Check a short link or tracking URL before it goes into
  a newsletter, so it doesn't pass through four hosts on the way.

## Tips and gotchas

- **Start from what people type.** `https://www.example.com/` often answers
  directly; `http://example.com` is where the chain lives.
- **One location, one view.** Redirects that depend on country, language or
  cookies can differ elsewhere. The checker sends no cookies, so a
  cookie-based redirect looks like the first visit.
- **Meta refresh and JavaScript redirects are flagged, not followed.** The
  checker reads the start of a 200 page and warns if it redirects again;
  crawlers may not follow it either. Replace it with a server-side 301.
- **A 301 sticks in browsers.** Browsers can cache a permanent redirect for a
  long time, so test a new rule with 302 first and switch to 301 once it's
  right. The differences are in
  [301 vs 302 redirects](/blog/301-vs-302-redirects).
- **HTTPS to HTTP is always a bug.** Browsers warn, and HSTS-preloaded
  domains refuse to load the HTTP hop at all.

## Check it from the command line too

`curl -I` sends HEAD requests; `-L` follows each `Location`:

```bash
curl -sIL http://mozilla.org | grep -iE '^(HTTP/|location:)'
```

```text
HTTP/1.1 302 Found
Location: https://mozilla.org:443/
HTTP/2 301
location: https://www.mozilla.org/
HTTP/2 200
```

The same chain from our machine. `-w` sums it up:

```bash
curl -s -o /dev/null -L -w 'redirects=%{num_redirects} final=%{url_effective} code=%{http_code} total=%{time_total}s\n' http://mozilla.org
```

```text
redirects=2 final=https://www.mozilla.org/ code=200 total=0.471412s
```

Some servers answer HEAD differently from GET. If the chain looks wrong,
drop `-I` and use `curl -sL -D - -o /dev/null` to print the headers of real
GET requests.

## Keep watching it

Redirects break quietly: a config change turns a 301 into a 302, a new CDN
rule adds a loop, an old URL starts returning 404. An
[HTTP monitor](/http-monitoring) with **Follow Redirects** switched off
checks the redirect itself on a schedule; set **HTTP Status Evaluation** to
accept only `301`, and an incident opens the day it changes. With
redirects followed, the same monitor records how many there were and
whether the final URL is HTTPS.

## FAQ

**How many redirects are too many?**
One or two is normal (HTTP to HTTPS, then apex to `www`). From three on, each
hop adds a round-trip and the checker warns. Browsers give up at 20 and
show `ERR_TOO_MANY_REDIRECTS`.

**Is a 302 redirect bad for SEO?**
Not when the move is temporary. For a permanent move, use 301 or 308: Google
uses a permanent redirect as a signal that the target should be canonical,
and a temporary one as a signal that the old URL stays canonical.

**How do I find a redirect loop?**
Follow the chain hop by hop until a URL repeats. The Redirect Checker stops
there and marks it as a loop; the two URLs that alternate tell you which two
rules disagree, often `www` versus apex or HTTP versus HTTPS. The status
codes themselves are explained in
[HTTP status codes explained](/blog/http-status-codes-explained).

---

Canonical page: https://watchfor.io/blog/how-to-check-redirects · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt