URL input
Use a public HTTP or HTTPS domain. Local targets and direct IPs are blocked for safety.
JSON output
The normalized request, summary, and hop-by-hop details appear here.
| Hop | Method | Status | Request URL | Location | Result |
|---|---|---|---|---|---|
Run a check to inspect the redirect chain. | |||||
About this tool
Why redirect checking matters for SEO, migrations, and debugging
Redirect issues are easy to miss when a browser silently lands on the final page. A dedicated redirect checker shows each hop, the HTTP status code at that step, and the final destination URL so you can confirm whether the chain is clean or bloated.
This matters during domain migrations, canonicalization changes, HTTPS rollouts, login handoffs, callback debugging, and technical SEO reviews. If the final destination looks suspicious, continue with URL Parser & Query Params Viewer or URL Encoder & Decoder. If you need to inspect headers and request examples around the same flow, pair this page with cURL to Fetch Converter and User-Agent Parser.
Common redirect workflows
Teams use redirect checks when moving from apex to www, switching from HTTP to HTTPS, changing application paths, tightening auth callbacks, or reviewing CDN and proxy behavior. A quick hop-by-hop report catches chained redirects, stale legacy paths, and final destinations that do not match expectation.
What makes a clean redirect path
In most cases, the healthiest redirect path is short and predictable. One redirect for HTTP to HTTPS or apex to www is normal. Longer chains cost time, complicate debugging, and can cause crawler or cache confusion when intermediate hops do not stay stable.
Example: verify apex to www
Confirm that a naked domain reaches the canonical www hostname in one clean step without bouncing through extra legacy hosts or mixed protocols.
Example: review callback links
Check whether auth, payment, or email callback URLs land on the expected path and preserve the encoded parameters you actually need.
Example: audit legacy URLs
Trace an older endpoint during a migration to confirm it lands on the correct new page and does not loop or stop on an outdated intermediate target.
Can this tool detect redirect loops?
Yes. The checker tracks visited URLs and reports when a redirect points back to an earlier hop instead of settling on a final destination.
Does it support both GET and HEAD?
Yes. You can choose GET or HEAD. If a server rejects HEAD, the checker retries that hop with GET and notes the fallback.
Why are local or direct IP URLs blocked?
The checker is limited to public domains for safety. Local, internal, and direct IP targets are blocked to avoid turning the endpoint into a generic network probe.