Redirect Checker

Trace redirect chains and HTTP status codes for any URL. Identify 301, 302 redirects and diagnose issues that may impact your SEO performance.

Enter a URL above to check its redirect chain

Every redirect costs you something. The question is how much, and whether you noticed.

Redirects are the duct tape of the web. Most sites have hundreds of them, accumulated over years of migrations, rebrands, CMS swaps, and tracking experiments nobody documented. A single hop is fine. Three or four hops in a row is a smell. By the time you're at five, you're losing crawl budget, leaking link equity, and adding measurable latency to every user who lands on the chain. This tool follows the chain end to end and shows you every step (status code, destination, and time spent) so you can see exactly what's happening between the URL someone clicked and the page that finally renders.

The status codes matter more than the SEO folklore around them suggests, but in the opposite direction from what most articles claim. The "301 vs 302" debate has been mostly settled by Google itself: both pass signals, and over time Google treats a long-lived 302 the same as a 301. What actually matters is whether the redirect is permanent in your intent. Use 301 or 308 for permanent moves so other crawlers, CDNs, and browser caches handle it correctly. Use 302 or 307 only when the original URL will come back. The HTTP method preservation differences (307 and 308 preserve POST, 301 and 302 historically did not) matter for APIs but rarely for content sites.

Meta-refresh redirects are a 30-year-old hack from the Netscape era. Google can follow them, treats instant ones (delay=0) similarly to a 301, and treats delayed ones as a soft redirect that may or may not pass signals. There's no reason to use them today on a server you control. If you see them in the wild, it's usually because someone couldn't configure server-side redirects and reached for a meta tag instead. Replace them whenever you have access.

JavaScript redirects sit in their own category. Google renders pages and follows JS-based location changes, but with a rendering delay measured in days or weeks compared to immediate HTTP redirects. For URLs that need to move now, never use JS. For URLs where the redirect is part of an app flow (post-login, post-purchase), JS is fine because those URLs aren't supposed to be in the index anyway. Knowing which category you're in is the whole game.

The reason to check redirect chains regularly: they grow on their own. Someone changes a category slug, the old redirect still points at the now-redirected URL, and you've silently added a hop. Multiply that by ten migrations and you have URLs taking four redirects to reach a page. Each hop adds latency, each hop is a chance for the chain to break, and each hop dilutes whatever link equity is flowing through. Auditing them is unglamorous and one of the highest-ROI hours you'll spend on technical SEO.

When the Redirect Checker is the right tool

After any site migration or replatforming

Migrations are the single biggest source of broken or chained redirects. Run every high-traffic URL through the checker the week after launch, and again a month later when the long tail of edge cases starts surfacing in your logs.

When organic traffic drops after a URL change

If you renamed a category or restructured paths and traffic dipped, the first thing to check is whether the redirects are clean 301s landing on the right destination, not chains, not loops, not 404s. The tool will tell you in seconds.

When auditing backlinks pointed at old URLs

Backlinks often point to URLs that have moved twice or three times. Each extra hop weakens the signal. Identify the chains, then update the redirect map to make every old URL hit the current canonical in a single 301.

Before launching a campaign that uses tracking URLs

Marketing tools love to insert their own redirect layer for tracking. Run the campaign URL through the checker before you spend money on traffic, so you know the final destination is right and the chain is short enough not to add visible delay.

When users report a page feels slow before content appears

A surprising amount of perceived slowness is redirect latency, especially on mobile. If a URL takes three hops to land, that's three TLS handshakes worth of delay before the browser even starts requesting the real page.

How to use the Redirect Checker

Trace every hop in a redirect chain with status codes and timing.

Enter the URL to test

Paste any URL — works for 301, 302, 307, 308, meta refresh, and JS redirects.

Inspect every hop

See each intermediate URL, its status code, and the time to the final destination.

Fix unnecessary hops

Replace redirect chains with direct 301s to save crawl budget and load time.

Mistakes we see all the time

Using 302 for a permanent move

When you delete or merge a page for good, 301 or 308 is the right call. Long-lived 302s eventually behave like 301s for Google, but other crawlers and CDNs honor the temporary signal exactly as stated and don't cache the redirect. Use the code that matches your intent.

Letting chains accumulate instead of updating the source

When a URL changes, every redirect that used to point at it should be updated to point at the new final URL directly. Don't chain old-to-new1-to-new2. Rewrite the map so every legacy URL reaches the current canonical in one hop.

Redirecting everything to the homepage

A retired URL with no good equivalent should 404 or 410, not 301 to /. Mass-redirecting to the homepage tells Google the old URLs were soft 404s and devalues the link equity instead of preserving it. Match URLs to relevant destinations, or let them go.

Using meta-refresh or JS redirects for permanent moves

Meta-refresh and JS redirects exist for cases where you have no server access. If you have access, use HTTP 301. JS-based redirects in particular can take days or weeks for Google to follow, leaving the wrong URL in the index while you wait.

Redirect Checker — Frequently Asked Questions

What types of redirects does it detect?

301, 302, 307, 308, meta-refresh, and JavaScript redirects — including the full chain to the final URL.

Why does redirect chain length matter for SEO?

Each hop slows page load and dilutes link equity. Google recommends a single redirect — anything past 2 hops is a fix-it signal.

Does it follow cross-domain redirects?

Yes. The checker traces the full hop sequence even across domains.

How many redirects in a chain is too many?

One is normal. Two is acceptable. Three is the point where you should be investigating. Google has said it will follow up to about ten hops, but it doesn't mean it likes to. Past three, you're measurably losing crawl efficiency and adding user-visible latency.

Do redirects pass link equity in full?

Google has said 301, 302, 307, and 308 all pass PageRank, and that there's no longer a "loss" the way older guidance suggested. In practice, very long chains and oddly-configured redirects (cross-protocol, cross-domain with mismatched canonicals) still seem to leak signal. Keep chains short.

What's the difference between 307 and 308?

307 is the strict temporary redirect, where the HTTP method (POST, PUT) is preserved across the redirect. 308 is the strict permanent version with the same method-preservation guarantee. For content URLs you mostly want 301 or 308; for API endpoints, 307 and 308 are the safer picks.

How do I detect a redirect loop?

The checker will flag a chain that returns to a URL already visited. Common causes are www vs non-www misconfiguration, http to https rules that don't exempt the canonical hostname, or trailing-slash rules that fight each other. Fix the loop at the rule level, not by adding more redirects.

Are HTTPS upgrades counted as a redirect?

Yes. An http -> https redirect is a real HTTP hop with its own latency. It's usually unavoidable and worth it for security, but it counts toward your chain length. Make sure no other redirects are stacked on top of it for high-value URLs.

Does Google follow JavaScript redirects?

Yes, but with the rendering delay that comes with any JS-dependent content, sometimes days, sometimes longer. For URLs you need moved fast for indexing, server-side HTTP redirects beat JS every time. JS redirects are fine for in-app navigation, not for canonical changes.

How often should I audit my redirects?

Once a quarter for a stable site, monthly if you publish or restructure frequently. Pull your top 200 traffic URLs and any URLs receiving meaningful backlinks, run them through the checker, and clean up any chain of three or more hops. It's rarely glamorous, always worth the time.

Redirects are quietly one of the largest sources of technical SEO debt on most sites. They don't throw errors, they don't show up in dashboards, and they pile up until a site feels slow and crawls feel inefficient. Spend an hour a quarter walking your top URLs through the chain. The fixes are usually trivial. The cost of ignoring them compounds.