Broken Redirect Checker

Identify dead ends, infinite loops, and 404 errors hidden at the end of URL redirection chains.

The Dangers of Broken Redirects

A redirect chain occurs when one URL forwards to a second, which forwards to a third, and so on. A broken redirect happens when the final destination in that chain does not return a successful 200 OK status.

404 Dead Ends: The chain eventually leads to a page that no longer exists, frustrating users and wasting crawl budget.
Infinite Loops: URL A redirects to URL B, which redirects back to URL A. The browser eventually gives up and displays an ERR_TOO_MANY_REDIRECTS error.
Malicious Hijacking: Attackers often look for broken external redirects on your site to register the expired target domain and hijack your outbound traffic for phishing.

Our Broken Redirect Checker follows the complete redirect chain from any URL and identifies the failures — loops that never terminate, chains that end in a 404, excessive hops, and open redirects that forward users to arbitrary external destinations.

What is a Broken Redirect?

A broken redirect is one that fails to deliver the visitor to a working page. There are several distinct failure modes, and they have different causes.

A redirect loop occurs when two rules point at each other, so the browser cycles until it gives up. A chain ending in 404 sends the visitor through several hops only to arrive at a page that no longer exists. An excessive chain works but wastes round trips and dilutes ranking signals at each step.

The most serious variant is the open redirect: an endpoint that takes a destination from a URL parameter and forwards to it without validation. It works exactly as designed, which is precisely the problem — attackers use it to make phishing links that begin with your trusted domain.

Loops cycle until the browser gives up with an error
Chains ending in 404 send visitors to a dead page
Long chains waste crawl budget and add latency
Open redirects forward to attacker-supplied destinations
Redirect rules accumulate over years and are rarely audited

Why Broken Redirects Matter

Redirect rules accumulate. Every site migration, every URL restructure and every campaign landing page leaves another rule behind, and over a few years the ruleset becomes something nobody fully understands. Conflicts appear, chains lengthen, and the failures are invisible until a user reports them.

Open redirects deserve particular attention. A phishing link reading yoursite.com/go?url=attacker.example passes casual inspection, survives many email filters because the visible domain is legitimate, and lends your reputation to the attack. They are also routinely used to bypass OAuth redirect validation and similar allowlists.

Accumulated rules eventually conflict and produce loops
Redirects to 404 lose visitors and inbound link value
Open redirects lend your domain reputation to phishing campaigns
Attackers chain open redirects to bypass OAuth allowlists
Each hop in a chain dilutes ranking signals slightly

How This Broken Redirect Checker Works

The tool follows the redirect chain step by step and analyses where and how it fails.

Validates the URL input against format and SSRF safety checks
Issues a request and follows each redirect in turn
Records the status code and target of every hop
Detects loops by identifying URLs that repeat within the chain
Reports the final destination and flags chains that fail or run long

How to Use the Broken Redirect Checker

Enter the URL you want to trace
Run the check to follow the full redirect chain
Review each hop and its status code
Confirm the chain ends at a working page with a 200 status
Investigate any chain longer than two hops

Understanding Your Redirect Chain Results

The chain is reported hop by hop. Here is what each outcome means:

Field / Value	Meaning
`Single hop to 200`	The ideal result. One redirect straight to a working page, with no wasted round trips and no dilution of ranking signals.
`Multiple hops`	The chain works but each hop costs a round trip. Two is tolerable; three or more indicates rules that should be flattened.
`Redirect loop`	A URL repeats in the chain, so it never terminates. Browsers abort with an error and the page is completely inaccessible.
`Chain ends in 404`	The redirect works but the destination no longer exists. Inbound links and any ranking signals are lost entirely.
`Cross-domain redirect`	The chain leaves your domain. Legitimate for deliberate outbound links, but a warning sign on an endpoint that takes its target from a parameter.
`Mixed status codes`	A chain combining 301 and 302 responses. Ranking signals pass inconsistently, and the intent of the rules is usually unclear even to their authors.

Common Problems & How to Fix Them

Two rules send requests back and forth until the browser aborts.

The usual cause is a www normalisation rule and an HTTPS rule disagreeing, or an application-level redirect duplicating one already applied at the proxy. Trace the chain to find the two URLs that alternate, then remove or reorder one of the rules. Handle protocol and hostname normalisation in a single rule rather than two.

Visitors follow the redirect and land on a missing page, losing both the visit and the value of the inbound link.

Update the redirect to point at the current equivalent page. Where no equivalent exists, redirect to the most relevant category page rather than the homepage, which is usually treated as a soft 404.

Rules accumulated across several migrations now form a sequence of hops, each costing a round trip.

Flatten them: point the original URL directly at the current destination and remove the intermediate rules. Audit the full redirect map periodically rather than only adding to it.

An endpoint such as /redirect?url=... forwards to any destination supplied, which attackers use to build phishing links that begin with your domain.

Validate the target against an allowlist of permitted destinations. If external redirects are genuinely required, show an interstitial warning page, or sign the target parameter so only URLs your application generated are accepted.

Ranking signals pass through 301 but not fully through 302, so a chain mixing both loses value unpredictably.

Decide whether each redirect is permanent or temporary and set the code accordingly. In practice almost all migration redirects should be 301.

Best Practices

Redirect in a single hop to the final destination wherever possible
Use 301 for permanent moves and 302 only for genuinely temporary ones
Audit and flatten accumulated redirect rules periodically
Point redirects at the equivalent page, not the homepage
Combine protocol and hostname normalisation into one rule
Test redirects after every deployment and migration
Keep a documented map of redirect rules and why each exists

Security Recommendations

Treat any redirect target taken from user input as an open redirect until proven otherwise
Validate redirect destinations against an allowlist rather than attempting to block bad patterns
Be aware that open redirects are used to bypass OAuth redirect_uri validation and similar allowlists
Show an interstitial warning for deliberate external redirects so users see where they are going
Sign or tokenise redirect parameters so only application-generated targets are accepted
Monitor for unusual volumes of traffic through redirect endpoints, which can indicate abuse in a phishing campaign

Frequently Asked Questions

Two rules pointing at each other. The most common cause is a www normalisation rule conflicting with an HTTPS rule, or an application-level redirect duplicating one already applied at the reverse proxy. The browser cycles until it aborts.

One is ideal. Two is tolerable. Three or more wastes round trips, dilutes ranking signals and risks crawlers abandoning the chain before reaching the destination.

An endpoint that takes a destination from a URL parameter and forwards to it without validation. Attackers use it to build phishing links that begin with your trusted domain, and to bypass allowlists in OAuth and similar flows.

Because the link carries your domain reputation. It passes casual inspection, survives many email filters, and users trust it because the visible hostname is yours. It also defeats redirect allowlists in authentication flows.

Update them to point at the current equivalent page if one exists. If the content is genuinely gone, remove the rule and let the URL return 404 or 410 rather than redirecting to an unrelated page.

A single 301 passes ranking signals with minimal loss. Long chains, loops and redirects to irrelevant pages all cause real harm. Redirecting everything to the homepage is treated as a soft 404 and loses the value entirely.

Validate the target against an allowlist of permitted destinations, or sign the parameter so only URLs your application generated are honoured. Where the destination is genuinely arbitrary, show an interstitial page telling the user where they are about to go.