How to Check a URL Redirect Chain (Step-by-Step)

A redirect chain is the full route between the URL someone requests and the page that finally loads. A simple migration might produce one clean hop:

http://example.com/old → 301 → https://example.com/new → 200

Real sites are often messier. Protocol rules, host normalization, legacy CMS mappings, localization and campaign services can stack several redirects together. Browsers hide most of that work, so the final page may look healthy even when the underlying route is slow or fragile.

This guide explains how to inspect that route and decide what actually needs fixing.

How to check a redirect chain

1. Open the free URL Redirect Checker.
2. Paste the exact starting URL, including the protocol, path and query string.
3. Run the check and wait for all user-agent results.
4. Read each hop from the original URL to the final response.
5. Compare Chrome, mobile Safari, Googlebot, Twitter Bot and curl for differences.

Test the version users or crawlers are likely to encounter. If old backlinks use http://www.example.com/page, checking only the preferred HTTPS URL will miss the migration path you need to audit.

What to record for every hop

Do not reduce a chain to “it redirects.” Capture the evidence that determines whether it is correct:

Field	Why it matters
Requested URL	Reveals host, protocol, path and query changes
Status code	Distinguishes permanent and temporary server redirects
Redirect type	Separates HTTP redirects from meta refresh or JavaScript
Location or target	Shows the next destination and whether it is relevant
Response time	Helps identify a slow service or origin in the chain
Final status	Confirms that the route ends in a usable response

A chain that ends in 200 OK is not automatically good. It can still pass through unnecessary hops, remove important parameters, switch to an unexpected domain or give Googlebot a different destination.

How to interpret redirect status codes

The four redirect codes most teams encounter are 301, 302, 307 and 308.

• 301 Moved Permanently communicates that the resource has a new durable URL.
• 302 Found is commonly used for temporary routing.
• 307 Temporary Redirect preserves the original HTTP method and body.
• 308 Permanent Redirect is the permanent method-preserving equivalent.

For ordinary GET page requests, users may not notice the method distinction. It matters much more for forms, APIs and uploads. The permanent-versus-temporary intent also matters to caches and search engines. Use the code that reflects the actual lifecycle of the move instead of relying on historical browser behavior.

See 301 vs 302 redirects for a deeper comparison.

Server-side vs client-side redirects

An HTTP redirect is returned before the destination page is rendered. Its status and Location header are explicit, easy for clients to process and usually the best option for URL migrations.

A meta refresh is an instruction embedded in HTML. A JavaScript redirect runs after enough page code has loaded. Both add more dependencies and are harder to diagnose. They may be appropriate in narrow application flows, but they should not be the default mechanism for a permanent content move.

When a checker reports a client-side redirect, ask why the server could not send a direct 3xx response.

Signs of a problematic chain

Too many hops

Every avoidable hop adds another network round trip and another rule that can fail. Replace:

/old → /archive → /category/new → /new

with a direct mapping from /old to /new, while preserving the final rule for any external references that still use intermediate URLs.

A redirect loop

A loop occurs when a URL eventually points back to an earlier member of the chain. Common causes include conflicting HTTP-to-HTTPS rules, mismatched trailing-slash policies and a CDN that disagrees with the origin about the preferred host.

An irrelevant final destination

Sending every retired product or article to the homepage is easy to configure but unhelpful. Redirect to the closest equivalent page when one exists. If no useful replacement exists, a genuine 404 Not Found or 410 Gone can be more honest.

User-agent differences

Different destinations for mobile devices, bots or social preview crawlers may be intentional. They can also indicate obsolete device detection, WAF rules or accidental cloaking. Compare the content purpose—not only the status code—and investigate unexplained differences.

Redirect audit checklist

• The final URL is relevant and uses the preferred HTTPS host.
• The chain is as direct as practical.
• The final page returns the intended successful response.
• Internal links, canonical tags and sitemaps use the final URL directly.
• Query parameters required for page behavior are preserved.
• Googlebot and ordinary browsers reach equivalent primary content.
• No hop returns an intermittent 4xx or 5xx response.
• Old high-value URLs remain covered after a migration.

After changing rules, clear relevant CDN caches and run the same starting URLs again. Redirect work is complete only when the public route—not merely the configuration file—shows the intended behavior.

Frequently asked questions

How many redirects are acceptable?

One direct redirect is ideal for a moved URL. A small number may be unavoidable when an external shortener or authentication system is involved, but each hop should have a clear purpose.

Can I check many chains at once?

Use the Bulk URL Checker to identify redirected URLs across a list, then investigate the most important or unusual results with the redirect checker.

Does a redirect checker prove that a page is indexable?

No. It verifies routing and live responses. Indexability also depends on robots controls, canonicalization, content, rendering and search-engine decisions.