Redirect Checker: See Where Any URL or Link Redirects
A redirect checker follows a URL from hop to hop and reports the HTTP status of every hop until the chain ends. Enter http://github.com and it records two hops: hop 1 answers 301 Moved Permanently and points to https://github.com/, which answers 200 OK. That is one redirect, which is healthy; each extra redirect adds another round trip. This checker follows 301, 302, 303, 307 and 308 responses as well as HTML meta refresh tags, flags loops and long chains, and can send the request as Googlebot or as a phone.
One URL per line, up to 10. Each URL is traced separately, then the whole batch can be exported.
Bulk results
| Start URL | Redirects | Final status | Final URL | Time (ms) | Note |
|---|---|---|---|---|---|
Final Destination
Redirect chain
This URL passes through more than one redirect before the final page. Each extra hop costs a round trip; point the first URL straight at the final destination.
Redirect loop detected
This URL redirects back to a page already in the chain, so it never reaches a final destination.
Redirect chain too long
The chain was still redirecting after 10 hops, so checking stopped there.
Stopped after 20 seconds
The chain was still going when the time limit for one check ran out. The last URL reached is shown below.
Redirect chain
Popular Tools
About Redirect Checker
This redirect checker traces what actually happens between the URL you type and the page that finally loads. From our server it sends one GET request per hop, without cookies, records the status code, the Location header and the time each hop took, and moves on to the next URL until it reaches a response that is not a redirect — or after 10 hops, which is already as deep as Google’s crawlers go and about half the roughly 20 hops a browser allows before it gives up with ERR_TOO_MANY_REDIRECTS. When a hop answers 200 with an HTML page, it reads at most the first 64 KB looking for a meta refresh tag, because that kind of redirect lives in the page and not in the headers. Nothing on the page is executed, which is also why JavaScript redirects are out of reach: they only exist once a browser runs the page’s scripts.
The output is deliberately literal. Hop 1 is the URL you entered, and every following row is the exact URL the previous hop sent you to, including the scheme change, the added or removed www, the trailing slash and the query string; a hop reached through a meta refresh is marked as such, with its delay. That is what makes the tool useful for migrations: a rule that looks correct in an nginx config often behaves differently once HSTS, a CDN edge rule and an application-level canonical redirect are all in play, and the only honest way to see the result is to follow it from outside. Because some sites send phones, crawlers and desktop browsers to different places, the request can go out as our own crawler, as Chrome on Windows, as Safari on an iPhone, as Googlebot (smartphone or desktop) or as Bingbot.
Bulk mode takes up to ten URLs at once, traces them one after another, and gives you a table with the number of redirects, the final status, the final URL and the total time that you can export as CSV or paste straight into a spreadsheet or a ticket. The variants button builds the four combinations of http and https, with and without www, for the address you entered and traces them in one go, which is the quickest way to confirm that every entry point collapses into one canonical URL.
Typical work it answers in seconds: does the old product URL still land on the new one in a single 301, did the HTTP-to-HTTPS rule survive the last deploy, does an affiliate link keep its query string all the way through, and where exactly does a shortened link end up. Private addresses, localhost and cloud metadata endpoints are refused, and each check stops after 20 seconds, so the checker cannot be used to probe an internal network.
Use Cases
How to check where a URL redirects
Paste the URL or link you want to test, for example http://github.com, or click one of the example chips below the box.
Optionally choose who the request comes from: our default crawler, Chrome, an iPhone, Googlebot or Bingbot. Sites that treat phones or bots differently will show a different chain.
Press Enter or click Check Redirects. Each hop is requested from our server and followed through 301, 302, 303, 307 and 308 responses and meta refresh tags, for up to 10 hops.
Read the summary: how many redirects were found, the final HTTP status, the total time and the final URL. A warning appears when the URL loops or passes through more than one redirect.
Follow the numbered chain to see each hop with its URL, its status badge such as 301 Moved Permanently, whether it was a meta refresh, and how long that hop took.
To test several addresses, switch to bulk mode (up to 10 URLs) or click the variants button to trace the http, https, www and non-www versions at once, then export the results as CSV.
Pro Tips
- Aim for one 301 straight to the final URL. Every extra hop costs a full round trip, a hop that switches to HTTPS adds a TLS handshake, and a hop that changes host adds a DNS lookup on top — together typically 100-300 ms on a mobile connection before anything renders.
- Use 308 rather than 301 when the redirected request might be a POST. 301 and 302 allow clients to rewrite the method to GET; 307 and 308 must preserve the method and the body.
- Test the http:// and www versions as well as the https:// one; the variants button does all four at once. Plenty of sites redirect correctly on HTTPS while a stale plain-HTTP rule still points at a decommissioned host.
- Read the status of the last hop, not just the number of redirects. A chain that ends in 404 or 405 is broken even though every redirect along the way was a clean 301.
- After a migration, run your top URLs from Search Console through bulk mode, download the CSV, and diff it against the same list a week later to catch rules that a deploy quietly reverted.
Troubleshooting
The check returns 403 when I choose Googlebot.
Many large sites confirm that a visitor claiming to be Googlebot really comes from Google’s network and refuse everyone else, including this checker. Compare with the default or Chrome agent; to see what Google itself received, use URL Inspection in Search Console.
The chain ends in 403, 405 or 503, but the page opens in my browser.
The site is probably filtering clients: a bot shield or CDN challenge that needs cookies and JavaScript, or a block on server IP ranges. Try the Chrome or iPhone agent; if the answer does not change, the filter works on the network or on behaviour, and a server-side check cannot get past it.
My browser shows ERR_TOO_MANY_REDIRECTS, but the checker shows a normal chain.
The loop probably depends on something this checker does not send: a cookie, a logged-in session, or the HSTS entry your browser keeps. Clear the site’s cookies or open a private window, then compare the http:// and https:// versions with the variants button to find the rule that sends visitors back.
A hop fails with an SSL certificate error instead of a status code.
The certificate on that host is expired, self-signed or issued for another name, so the connection is refused before any redirect can be read. Browsers stop at the same point. Renew or fix the certificate, or point the previous hop at a host with a valid one.
Frequently Asked Questions
It shows where a URL really sends visitors and search engines. You get every hop between the address you typed and the page that finally answers, with the status code and timing of each one. That answers three questions at once: is the redirect firing, does it point at the right destination, and how many hops are wasted along the way. It is also the safe way to see where a shortened or affiliate link leads before you click it.
A 301 says the move is permanent: browsers cache it, and Google consolidates the old URL's ranking signals into the new address and keeps the old one only as an alternate name, so it usually stops appearing in results but can still surface when a query suggests users trust it. A 302 says the move is temporary, so the original URL normally stays indexed and the response is not cached unless the headers allow it. Use 301 for migrations and HTTPS upgrades, 302 only for A/B tests and maintenance pages.
One is the target, two is tolerable, three or more should be collapsed. Browsers abort after roughly 20 hops, and Google’s crawlers follow up to 10 redirect hops before treating the URL as an error. Every extra hop costs a round trip, a hop that switches scheme adds a TLS handshake, and a hop that changes host adds a DNS lookup as well, so a three-redirect chain can add several hundred milliseconds on mobile before the first byte of real content arrives.
Enter your domain and click the variants button. It traces http://, https://, http://www. and https://www. for the same path in one batch. In a healthy setup all four end on the same final URL with a 200: the canonical version shows no redirect and each of the other three a single 301 or 308. Two redirects on the http://www. version usually mean the scheme and the host are fixed by separate rules that can be merged into one.
Yes. Choose the user agent before you run the check: Chrome on Windows, Safari on an iPhone, Googlebot smartphone or desktop, or Bingbot. Sites that send mobile visitors to an m. subdomain or treat crawlers differently will show a different chain for each. One caution: many large sites verify that a visitor claiming to be Googlebot really comes from Google’s network and answer 403 otherwise, so a 403 with the Googlebot agent often means exactly that. To see precisely what Google received, use URL Inspection in Search Console.
Meta refresh, yes. When a hop answers 200 with an HTML page, the checker reads its first 64 KB, finds a meta refresh tag that carries a URL and follows it as the next hop, marked as a meta refresh with its delay in seconds. JavaScript redirects, no: they only happen once a browser runs the page’s scripts, and this checker never executes anything. If the last hop is a 200 but your browser ends up somewhere else, a script is the likely cause; the Network tab in DevTools shows it as a navigation started by a script.
Four usual causes. Your browser has the site in its HSTS cache, so it upgrades http:// to https:// before any request leaves the machine. The site varies its answer by cookie, language header or country, and our server looks different from you. The site sends phones and desktops to different places, which you can reproduce by switching the user agent. Or a JavaScript redirect finishes the journey after the page loads, which a server-side trace never sees.
Yes. Switch to bulk mode and paste up to ten URLs, one per line. Each is traced separately and the results land in one table with the number of redirects, the final status, the final URL and the total time. Download that table as CSV or copy it as tab-separated text, which pastes cleanly into Sheets, Excel or a Jira ticket without any reformatting. The variants button fills the same table with the four http/https and www versions of one address.
Open DevTools with F12, go to the Network tab, tick Preserve log, then load the URL. Each hop appears as its own row with a 301 or 302 status; click one and read the Location header under Response Headers. The catch is that DevTools shows what your browser did, complete with your cookies, HSTS cache and extensions, so a colleague on another machine may see a different chain.
A single 301 or 308 passes ranking signals and is not a problem. Chains are, for two reasons: Google’s crawlers follow up to 10 redirect hops and report anything longer as a redirect error, and every hop delays the first byte, which feeds directly into Core Web Vitals. Loops are worse, because the page is never reachable and drops out of the index entirely. Collapse chains so the first URL points at the last.