The fastest way to confirm a redirect works is to check three things: the server returns the correct 3xx status code, the Location header points to the intended final URL, and the request actually lands there without looping or chaining through more than one or two hops. You can verify all three with an online redirect checker, a single curl command, or the browser Network tab.
TL;DR:
- Most redirect issues stem from long chains, conflicts, or improper status codes; fixing these involves pointing internal links directly to the final URL and replacing temporary redirects with permanent ones after confirmation.
- Manual and automated tools like curl, online checkers, and browser DevTools help verify correct server responses, but each has limitations, especially with client-side redirects or caching.
- For large sites, regular automated crawls and monitoring flags can identify chains, loops, or broken redirects quickly, saving time over manual spot checks.
- Batch tools and monitoring services facilitate quick diagnosis, rule generation, and automatic alerts for redirect failures on critical pages, reducing reliance on manual tests.
- Prioritize testing high-traffic URLs and perform checks from incognito or fresh requests to avoid cached responses, ensuring redirect configurations are properly validated before deployment.
Table of Contents
- How do online redirect checkers verify a URL?
- Command-line testing with curl: exact commands and how to read each hop
- Checking redirects in the browser with DevTools
- Common redirect problems and how to fix them
- Automated audits and monitoring: when to crawl versus spot check
- Pingfloat's toolkit for redirect testing
- An editorial take on how much redirect testing is enough
- Put your redirect checks on autopilot with Pingfloat
- Sources
- FAQ
How do online redirect checkers verify a URL?
An online redirect checker is the quickest way to confirm a redirect before you touch a terminal. Paste the URL, run the trace, and the tool returns each hop in sequence: the status code, the Location header value, the final destination URL, and often the response time for each step.
Reading the output correctly matters more than running the tool. A clean result shows one hop with a 301 or 308 status and a Location header matching your intended destination. Anything beyond that deserves a second look.
- Chain length over three hops signals a redirect that has been patched repeatedly instead of fixed at the source, a pattern Ahrefs flags as a red flag worth collapsing.
- Unexpected 4xx or 5xx codes mid-chain mean a broken intermediate rule, not a working redirect.
- A final URL that doesn't match your target often points to a stale rule or a conflicting rewrite further down the stack.
Online checkers have blind spots. Many don't execute JavaScript, so they miss client-side redirects entirely, and most send a generic user-agent, which means a redirect that only fires for mobile devices or for Googlebot can look like it's missing when it isn't.
Command-line testing with curl: exact commands and how to read each hop
Curl gives you the clearest, least interfered-with view of a redirect because there's no browser cache, no JavaScript execution, and no rendering layer between you and the server response. According to the cURL manual, the three commands below cover nearly every situation you'll run into.
curl -I -L [URL]returns headers only (-I) while following every hop (-L), giving you a status line and Location header for each redirect in the chain.curl -v [URL]runs in verbose mode, showing the full request and response cycle, including TLS negotiation, which helps when a redirect fails silently.curl -I --max-redirs 2 [URL]caps how many hops curl will follow, useful for catching loops before they run indefinitely.
To test a redirect that only fires for a specific client, add a custom header: curl -I -L -H "User-Agent: Googlebot" [URL]. Pingfloat's browser and crawler user agent reference has a current list of strings worth keeping on hand.
When you read the output, scan for each HTTP/1.1 3xx status line, note the Location: header directly beneath it, and confirm the last response in the sequence is a 200 OK on the page you expect.
Pro Tip: Run curl -I -L before and after any server config change and diff the output; it's the fastest way to catch a redirect that silently broke.
Checking redirects in the browser with DevTools
Curl tells you what the server sends, but the Network tab shows you what actually happens in a real browser, which matters when a redirect depends on cookies, referrers, or JavaScript.
- Open DevTools, go to the Network tab, and check Disable cache before loading the URL, since a cached response will hide a redirect you just changed.
- Load the page and look for the request in the waterfall: each redirect shows up as its own entry with a 3xx status, and clicking it reveals the Location header in the response panel.
- Use the device toolbar or Network conditions panel to emulate a mobile device or a custom user-agent, which surfaces conditional redirects that only trigger for certain clients.
- Test in an incognito window as a second check, since a private session skips most cached entries a regular tab might still be holding.
Per MDN's documentation on redirects, client-side redirects such as meta refresh or JavaScript-based navigation don't carry an HTTP status code at all, so they won't show up the same way a server-side 3xx does. If your Network tab shows a 200 followed by a second page load with no visible redirect entry, you're likely looking at one of these, and it's worth flagging as less reliable for SEO than a server-side response.
Common redirect problems and how to fix them
Most redirect issues fall into a handful of repeatable patterns, and each has a specific fix rather than a general one.
- Long chains happen when a URL gets redirected, then redirected again months later without anyone updating the original rule. Fix it by pointing the internal links and rewrite rules directly at the final destination so the request resolves in a single hop.
- Loops usually come from conflicting rules across layers, server config, CDN, and application routing all trying to redirect the same URL in different directions. Trace the conflict by checking each layer's rules in order, and watch for provider-specific headers that hint at which layer fired first.
- Wrong status code shows up when a temporary 302 sticks around after a migration is permanent, or when a permanent 301 gets used for content that's still being tested. Switch to 301 once the move is final, since Google Search Central treats 301 and 308 as the signal for permanent moves and 302, 303, and 307 for temporary ones.
- Homepage catch-alls for deleted, unrelated pages create a poor experience and can be treated as a soft 404 by crawlers. A 410 Gone status is the more honest signal when there's no real replacement page.
Pro Tip: If you're mid-migration, start new redirects as 302 while you confirm the destination is correct, then flip them to 301 once you're certain the move is permanent.
Automated audits and monitoring: when to crawl versus spot check
Manual checks work fine for a handful of pages, but once you're dealing with dozens or hundreds of URLs, you need a repeatable process instead of ad hoc curl commands.
- Use a site crawler like Screaming Frog or a built-in site audit tool when you need to sweep an entire domain for chains, loops, and unexpected status codes, since these tools flag "redirect chain too long" and "redirect loop" errors automatically, a workflow Backlinko recommends for larger sites.
- Reserve spot testing with curl or an online checker for isolated changes, like a single page migration or a one-off rule fix.
- Set an audit cadence: run a full crawl immediately after any migration or domain change, then fall back to a routine check on a monthly or quarterly basis depending on how often your redirect rules change.
- Export results to a spreadsheet or crawler report so you can track chain length, status code changes, and response times over time instead of relying on memory.
- Watch for spikes in new 3xx or 4xx responses and for any sudden jump in redirect response time, both of which usually mean a recent deployment introduced a problem.
Pingfloat's toolkit for redirect testing
Free tools cover most of the workflow above without needing a terminal open. The Response Headers Inspector shows status codes and Location values directly, the Redirect Rule Generator produces Nginx and Apache config snippets when you need to fix a rule rather than just diagnose it, and the HTTP Status Codes Reference is useful when you need a quick definition of a less common 3xx or 4xx code mid-audit.
A practical sequence: inspect headers to confirm the current behavior, generate a corrected redirect rule, re-check with the same inspector to confirm the fix, then add the URL to a monitor so you catch regressions automatically instead of finding them months later.
An editorial take on how much redirect testing is enough
Most teams either over-test every URL on the site or under-test the handful that actually carry traffic, and neither approach holds up. Start narrow: smoke test your top landing pages and canonical URLs with curl or the Network tab, confirm those are clean, and only then run a full-site crawl to catch what's left.
Prioritize by traffic, not by how recently a URL was touched. A high-traffic page with a two-hop chain matters more than a low-traffic page with three. And when you think a fix has landed, confirm it in an incognito window and with a fresh curl request rather than trusting the first browser tab you had open, since that tab is exactly the one still holding the cached response.
— Andreas
Put your redirect checks on autopilot with Pingfloat
Running a curl command every time you want to confirm a fix gets old fast, especially once you're maintaining redirects across a growing site. Pingfloat's Response Headers Inspector gives you the same header and Location detail without opening a terminal, and the Redirect Rule Generator turns a diagnosis straight into a config snippet you can drop into Nginx or Apache.
For URLs where a broken redirect would actually cost you traffic, checking manually on a schedule isn't realistic. Set up the Website Uptime Monitor on those pages instead, and it will flag a failure the moment a redirect breaks rather than the next time someone happens to notice.
- Inspect any URL's headers instantly with the Response Headers Inspector, no account required.
- Generate a corrected redirect rule for Nginx or Apache in seconds.
- Add critical pages to a free uptime monitor so redirect failures surface automatically.
Start with the Response Headers Inspector on your most important redirect, and add it to monitoring once you've confirmed it's clean.
Sources
- Redirects and Google Search | Google Search Central
- 11 Types Of Redirects & Their SEO Impact — Ahrefs
- curl(1) — cURL manual
- Redirections in HTTP — MDN Web Docs
- Redirects 101: A Beginner’s Guide to Setup & Best Practices — Backlinko
FAQ
How to check if a redirect is working?
Run curl -I -L against the URL and confirm you see a 3xx status code followed by a Location header pointing to your intended destination, ending in a 200 response on the final page. You can also paste the URL into an online redirect checker or watch the request in your browser's Network tab with caching disabled.
How can I check if a link is redirected?
Load the link with caching disabled in your browser's Network tab, or run a quick curl command with the -I flag to see the response headers without loading the full page. A redirected link returns a 3xx status code and a Location header instead of a 200.
Why is my URL redirect not working?
The most common causes are a cached 301 response still being served from an earlier browser visit, a conflicting rule at another layer such as the CDN or application routing, or a client-side redirect (JavaScript or meta refresh) that doesn't behave the same way a server-side 3xx does, as MDN notes. Clear your cache or test in an incognito window before assuming the rule itself is broken.
How to check a 301 redirection?
Run curl -I -L on the URL and look for an HTTP/1.1 3xx status line followed by a Location: header showing the destination. If you see a 200 instead, the browser or intermediate cache may be serving a stored version rather than hitting the server directly.