Redirects fail silently. The page still loads, nobody files a bug, and six months later a chunk of your traffic has quietly leaked into a chain of three hops ending on a 404. If you only check redirects when something looks broken, you will never find the ones that matter. The problems worth catching are invisible from the browser.
This is a mechanical job with a clear finish line. You need to know what every 3xx on your site does, whether it lands in one hop, and whether the destination is the page you meant.
The four things you are actually looking for
Before picking a tool, know what counts as a finding. A redirect checker that returns “301 → 200, OK” tells you nothing on its own.
- Wrong status code. A permanent move served as a 302, or a temporary one served as a 301. The code decides which URL Google keeps in the index.
- Chains. Old URL → newer URL → current URL. Every hop adds latency and dilutes the signal. Google follows a handful of hops but stops eventually.
- Loops. A points to B, B points back to A. Browsers give up and show ERR_TOO_MANY_REDIRECTS. Crawlers give up too, and the page is simply unreachable.
- Bad destinations. Redirects landing on 404s, on the homepage in bulk, or on pages with no topical relationship to the original.
Everything below is a way of surfacing one or more of these at different scales.
Single URL: curl is faster than any web tool
For one URL, the command line beats every browser-based redirect checker because it shows you the raw response with no interpretation layer:
curl -sIL https://example.com/old-pageThe -I flag requests headers only, -L follows redirects, and -s suppresses the progress meter. You get one header block per hop, each with its status line and Location header, ending with the final 200. Count the blocks — that is your chain length. If you want a compact view, add a format string:
curl -sIL -o /dev/null -w "%{http_code} %{num_redirects} %{url_effective}\n" https://example.com/old-pageTwo things trip people up here. First, some servers respond differently to HEAD than to GET; if the output looks wrong, rerun with -X GET. Second, curl sends its own user agent, and sites with bot rules or geo-routing may serve you a different redirect than they serve Googlebot. Spoof the user agent with -A when you suspect that.
Browser DevTools for redirects you cannot reproduce
When a redirect only fires for logged-in users, on mobile, or after a cookie is set, you need a real browser session. Open DevTools, go to the Network tab, tick Preserve log and Disable cache, then load the URL. Every hop appears as its own row with its status code in the Status column.
Click a row and read the Response Headers. Look at the Location header for the destination, and check whether the redirect came from your server or from a CDN — Cloudflare, Fastly, and similar services add identifying headers that tell you which layer fired. This matters because a redirect you cannot find in your server config is usually living in a CDN rule, a hosting-panel setting, or a plugin.
One row you can safely ignore: an internal 307 with no response headers and no timing. That is the browser enforcing HSTS locally before the request leaves the machine. It is not a server redirect and there is nothing to change.
Checking a site’s redirects at scale
Individual checks are for verifying a fix. Finding problems requires crawling every URL you have and inspecting the responses in bulk. That means a crawler that records the status code, the destination, and the full hop path for each URL.
Run the crawl with redirect following on, then export and sort. Three views do most of the work:
- All 3xx responses grouped by status code. This is your inventory. Scan the 302s and ask whether each source URL is genuinely coming back.
- Redirects with a hop count above one. These are chains. Update each source to point straight at the final URL.
- Redirects whose final status is not 200. These end on errors and are pure waste.
Add a fourth pass on internal links. Any link inside your own templates or content that points at a redirecting URL should be rewritten to the destination. Redirects exist to catch external links and old bookmarks; you control your own links, so there is no excuse for making a crawler take an extra hop to reach your own content.
Checking redirects during a migration
Migrations are where redirect testing earns its keep, and the mistake is always testing after launch instead of before. Build the mapping file first — one row per old URL with its new destination — and validate it in staging.
A minimal pre-launch routine:
- Export every indexed URL from Search Console and every URL from a pre-migration crawl of the live site. Deduplicate. That is your source list.
- Confirm every source URL has exactly one destination, and that no destination appears as a source elsewhere in the file — that is how chains get born.
- Batch-test the mapping against staging with a script, checking status code and final URL for each row.
- Verify the highest-traffic and highest-link-equity URLs manually. If the top 50 pages land correctly, most of the risk is gone.
- Re-run the full crawl within 48 hours of launch, because CDN and server rules behave differently in production.
Expect ranking movement either way. Even a clean migration usually shows a dip while Google re-crawls and re-consolidates, and daily position swings of two or three places are normal noise on top of that. Judge the outcome on a trend line across several weeks, not on the Monday after launch.
Reading what Search Console tells you
Google’s own data closes the loop that third-party tools cannot. The Page Indexing report has a “Page with redirect” bucket listing URLs Google crawled and found redirecting — useful for confirming that old URLs are being processed, and a warning sign when pages you expected to be indexed show up there instead.
The URL Inspection tool goes one level deeper for a single URL, showing the crawled response and the canonical Google selected. When a redirect and a canonical tag disagree, this is where you see which signal won. Search Console reporting lags by a few days, so use it to confirm outcomes rather than to test changes you made this morning.
Building this into a routine
Redirect problems accumulate through ordinary work — a plugin update, a CDN rule, a content cleanup, a developer fixing one path and shadowing another. The fix is not a better one-off tool. It is checking on a schedule so the list stays short.
Monthly is enough for most sites, plus a check after every deployment that touches URLs, server config, or CDN rules. Keep a record of the redirects you deliberately created with the reason and a review date, so the next person can tell an intentional rule from an accident.
SEO Rocket’s technical audits cover this end of the work: an instant quick scan of around 25 pages for a fast read, or a deep full-site crawl verified past 900 pages, with the actual URLs, status codes, and destinations attached to each issue rather than a generic warning. Run it once and you will have a finite list of redirects to fix instead of a suspicion that something somewhere is wrong.
