About the Redirect Checker
The redirect checker follows a public URL through its HTTP redirect chain and displays each hop. It helps find unnecessary redirects, loops, incorrect destinations, and HTTP-to-HTTPS or hostname canonicalization problems.
How to use this tool
Enter the exact starting URL, including its protocol and path, then run the check. Review every hop from the original address to the final response. Test common variants such as http, https, apex, www, trailing slash, and legacy paths when auditing a migration. A clean permanent migration usually sends each old URL directly to its intended canonical replacement instead of passing through several generic redirects.
How to read the result
301 and 308 normally communicate permanent moves, while 302, 303, and 307 represent temporary or request-handling redirects with different method rules. The Location header provides the next destination. The final status should be appropriate for the requested page, and the displayed final URL should agree with the page's canonical URL. Multiple hops add request latency and create more points where query strings, paths, or tracking parameters can be lost.
Limits and privacy
The chain is observed by a server-side request without your browser's cookies, authentication, cache, or JavaScript execution. Client-side redirects produced only by JavaScript or some meta refresh behavior may not appear. Geolocation and bot rules can also produce a different chain. Redirect depth, request time, and response size are limited, and private network destinations are blocked. The public URL is submitted to buffer.lol for the check.
Common questions
- How many redirects should a URL use?
- Directly reaching the final canonical URL is best. One intentional redirect is common, but avoid chains when the first hop can point straight to the destination.
- Can this detect JavaScript redirects?
- Not reliably. It follows HTTP redirects from response status and Location headers rather than executing a full browser page.