Most people check redirects by clicking a link and seeing where they land. If the page loads, they call it fixed. That’s the trap: redirects fail silently. A 302 where you needed a 301, a five-hop chain that bleeds link equity, a loop that quietly burns crawl budget — none of it shows up in a browser, because the browser’s only job is to get you to a page, not to tell you how many detours it took or what status code it collected along the way. To actually check redirects, you have to read the HTTP layer the browser hides from you.
Why a broken redirect costs you rankings
A redirect is a promise to a crawler: “this URL moved, send the signals to the new one.” When the promise is malformed, the signals don’t transfer cleanly. Search engines treat a permanent 301 as an instruction to consolidate ranking authority onto the destination and swap it into the index. A temporary 302 says the opposite — keep the old URL indexed, this is only a detour — so PageRank, links, and history stall on a URL you meant to retire. The page still “works” for a human, which is exactly why the bug survives for months. You only find it when traffic to a migrated section quietly flatlines and nobody can point to a single dead page.
The four failure modes to check for
Every redirect problem worth finding falls into one of four buckets. Structure your checks around these instead of eyeballing landing pages:
- Wrong status code — a 302 (or 307) used for a move that is permanent, so authority never consolidates.
- Redirect chains — A → B → C → D. Every hop dilutes signal and adds latency; long chains can get truncated by crawlers before they reach the real destination.
- Redirect loops — A → B → A. The browser gives up with an error, the crawler abandons the URL, and the page falls out of the index entirely.
- Bad destinations — the redirect fires cleanly but lands on a 404, a soft-404, or a generic homepage instead of the relevant replacement. Mass-redirecting retired pages to the homepage is treated as a soft 404 and passes almost nothing.
If your check answers “which of these four is happening, and on which URLs,” you’re doing real technical SEO. If it only answers “did the page load,” you’re not.
Status codes: 301 vs 302 vs 307 vs 308
This is the part most guides skip, and it’s where the money is. The two you’ll use deliberately are 301 (Moved Permanently) and 302 (Found / temporary). Use 301 for anything that has genuinely moved for good — consolidated URLs, HTTP-to-HTTPS, www canonicalization, a retired product mapped to its successor. Use 302 only when you truly mean “this is temporary and I want the original to stay indexed,” such as a short-term promo or geolocation test.
The 307 and 308 codes are the HTTP/1.1 strict equivalents: 308 is a permanent redirect that preserves the request method (a POST stays a POST), and 307 is the temporary version that does the same. For ordinary content moves a clean 301 is what search engines expect and what most CMS and server configs emit. The practical rule: when you audit a permanent move, it must return 301 or 308, and seeing a 302 on a permanent move is a bug to fix, not a cosmetic detail.
How to check redirects on a single URL with curl
The fastest, most honest way to check one URL is the command line, because it shows you the raw response headers with no browser interpretation. Run:
curl -sIL -A "Mozilla/5.0" https://example.com/old-page
The flags matter: -I fetches headers only, -L follows every redirect to the end, -s silences the progress meter, and -A sends a real user-agent so servers that vary behavior by client don’t hand you a different answer. You’ll get one header block per hop. Read the HTTP/ status line and the location: header of each. A healthy single move looks like one 301 block pointing straight at the final URL, followed by a 200. A worked example of a chain looks like this:
HTTP/2 301→location: http://example.com/page(HTTPS to HTTP — already wrong)HTTP/2 301→location: https://www.example.com/page(now back to HTTPS + www)HTTP/2 302→location: https://www.example.com/page/(temporary, trailing-slash fix)HTTP/2 200
Three hops and a stray 302 to reach a page that should have been one clean 301. Collapse that into a single rule at the server or CDN so the origin URL points directly at the final destination. When you check redirects this way, always paste the true starting URL — the http:// version, the non-www version, the version with and without the trailing slash — because those variants are exactly where accidental chains hide.
Check context-dependent redirects in the browser
Some redirects only fire under specific conditions — a logged-in cookie, a geo header, a mobile user-agent, an A/B test. curl won’t reproduce those unless you replicate the context, so open Chrome DevTools, go to the Network tab, tick Preserve log and Disable cache, then load the URL. Each hop appears as its own row with a 3xx status; click any row to inspect the request and response headers. Preserve log is the setting people forget — without it, the redirect rows vanish the instant the final page loads, and you’re back to guessing. This is the method for reproducing “it redirects wrong but only for real users” bugs.
How to check redirects across a whole site
Single-URL checks are for diagnosis. To find every broken redirect you don’t already know about, you need a crawler that follows internal links and logs the status code and full hop path of each one. A site-wide crawl surfaces the patterns a URL-by-URL check never will: an entire retired category chaining through three hops, a batch of old blog posts all 302-ing instead of 301-ing, internal links still pointing at the pre-redirect URL so you pay the hop tax on every crawl.
This is where a real-crawler audit earns its keep. SEO Rocket’s site audit runs an actual crawler over your site and flags redirect chains, loops, temporary redirects that should be permanent, and internal links pointing at redirected URLs — the four failure modes, mapped to exact URLs, without you scripting anything. The point isn’t to replace curl for spot checks; it’s to catch the redirect debt accumulating across thousands of pages that no human is going to click through by hand.
How to check redirects before a site migration
Migrations are where redirects do the most damage, because you’re moving hundreds or thousands of URLs at once and any gap leaks authority permanently. Build a redirect map — every old URL to its single best new URL — before launch, then validate it against staging. Run your full list of old URLs through a batch check and confirm each returns exactly one 301 landing on the intended new page with a 200. Watch specifically for old URLs that map to the homepage (soft 404 territory), old URLs that 404 because they were forgotten, and chains created when the new site’s own canonicalization rules stack on top of your migration rules. Do this before you flip DNS, not after traffic craters.
How to read redirect data in Search Console
Google Search Console is your ground truth for how Google actually sees your redirects. The Page Indexing report has a “Page with redirect” bucket — a normal, healthy category for URLs you’ve intentionally moved, but a red flag if pages you want indexed are landing there. Use the URL Inspection tool to check any single URL: it tells you the crawled status, whether Google followed the redirect, and what it chose as the canonical. If Search Console reports a redirect on a URL you didn’t intend to redirect, or shows Google ignoring your 301 and keeping the old URL, that’s a discrepancy worth chasing — usually a conflicting canonical tag or a chain Google gave up following.
How to fix redirects already broken in production
Finding the break is half the job; here’s the repair order that limits the bleeding. First, kill loops immediately — a looped URL is fully deindexed until it resolves, so it’s your top priority. Second, collapse chains to a single hop by rewriting the origin rule to point straight at the final destination, and update internal links so they stop referencing the intermediate URLs. Third, convert any permanent-but-302 redirects to 301 so authority finally consolidates; expect Google to take days to weeks to reprocess and swap the canonical. Fourth, re-map any redirect landing on a 404 or the homepage to the genuinely relevant page. After each fix, re-run the URL through curl and request re-indexing in Search Console so Google recrawls sooner rather than on its own schedule.
How to monitor redirects so they stay fixed
Redirects rot. A CMS update, a plugin, a new canonicalization rule, or a well-meaning colleague’s “.htaccess edit can silently re-break a redirect you fixed last quarter. The durable move is to check redirects on a schedule rather than only when something looks wrong: keep your redirect map in version control, re-crawl the site periodically, and watch rank tracking for the early warning sign — a cluster of migrated URLs slipping in position with no content change usually means the redirects behind them broke. Pairing a recurring real-crawler audit with rank tracking, the way SEO Rocket does, turns redirect health from a fire drill into a background metric you glance at, which is the whole point of building on a playbook proven across 1,000,000+ ranking pages: the boring checks are the ones that compound.
Frequently asked questions
What’s the fastest way to check a redirect?
For a single URL, curl -sIL -A "Mozilla/5.0" <url> in a terminal is fastest — it prints every hop’s status code and destination in one shot with no browser noise. For redirects that depend on cookies or device, use Chrome DevTools’ Network tab with Preserve log enabled. For a whole site, a crawler-based audit is the only realistic option.
Is a 301 or 302 better for SEO?
Use a 301 for anything permanent — it tells search engines to consolidate ranking authority onto the destination and swap it into the index. Use a 302 only for genuinely temporary moves where you want the original URL to stay indexed. A 302 on a permanent move is one of the most common redirect bugs and quietly strands your rankings on the old URL.
How many redirect hops are too many?
Aim for zero intermediate hops — one 301 straight to the final destination. Two hops is tolerable but wasteful; beyond three, crawlers may stop following before they reach the end, and you’re paying latency and diluting signal on every crawl. Any time you find a chain, collapse it at the origin.
Why does a page redirect in my browser but not in curl?
Because the redirect is context-dependent — it fires only for a specific cookie, user-agent, or geolocation that curl isn’t sending. Reproduce the context in DevTools, or add the relevant headers to your curl command, and the hidden hop appears.
