/en/tool/redirect-chain-checker/ works Follows the chain automatically
Enter a URL—our server follows the chain from there: one request per step, without automatically following Location, checking each new URL again, up to twenty steps. For each step, you can see the code and what it means, protocol version, response time, size, and all response headers in full—including those that caused the step in the first place. Redirects hidden in the page body are included in the chain too. You can check up to one hundred URLs at once as a list, and export the results to CSV.
Each response in full: its status code and meaning, protocol version, time, destination, and the headers returned with it. Click a step to expand all response headers. Nothing is filtered or combined: repeated Set-Cookie headers appear on separate lines, one cookie per line.
Conditional redirects can only be detected by comparison. We’ll request the same URL with five user agents — Chrome, iPhone, two Google bots, and YandexBot — and show where they differ. If the site itself returns a Vary header that mentions User-Agent, that is the first sign that responses may differ.
| User agent | Redirects | Final URL | Status | Time |
|---|
Rows appear in the order you pasted them. The “Download CSV” button below the panel exports this table as a file, with full URLs rather than shortened ones.
| URL | Redirects | Status codes by step | Note | Final URL | Time |
|---|
You can omit the protocol: example.com/old-page. The server requests the first URL, checks Location, requests the next one, and continues until it reaches a page that does not respond with a redirect.
A move to a mobile version, a separate chain for bots, and a regional redirect are all tied to User-Agent. The “Compare signatures” button checks the URL with all five and shows where they differ.
Inside, you will find the code with its explanation, the protocol version, the time, where Location points, and what changes in the URL. Below that are all response headers in full: X-Robots-Tag, canonical from the Link header, Vary, HSTS, the server, and every Set-Cookie cookie on a separate line, with its own path, domain, and expiration.
The tool separately reports a loop, dead end, a temporary code during a permanent migration, lost query parameters, and a redirect hidden in the page body.
If there is more than one step, an analysis block appears below with a rule for nginx and .htaccess: one redirect straight to the final URL instead of the entire ladder.
The “URL list” mode accepts up to one hundred lines at a time and puts the results in a table. All one hundred are processed in a single run, so you will not have to stop halfway through. “Download CSV” saves the table as a file that opens in Excel and Sheets.
The input data is the same as the default field values: you can calculate it mentally and confirm that the tool is telling the truth.
3 steps, 2 redirects: the first two responses have Location; the third does not.
The first step changes only the protocol: http becomes https. The second changes only the path: /old-page becomes /new-page/.
Both redirects are permanent, 301. There are no temporary redirects, no loop, and the final code is 200.
The final response has X-Robots-Tag: noindex—the chain led to a page that has itself disallowed indexing.
The two rules can be reduced to one: return 301 directly to https://example.com/new-page/. The tool prints ready-made lines for nginx and .htaccess and also warns about noindex at the end of the path. Without this warning, the analysis would look fine.
The URL you check and the selected user-agent signature are sent. Our server makes requests to the third-party site from its own address, not yours. The response is returned to you and stored nowhere: not in a database, file, or log. All site tools share a limit of three hundred requests per hour from one address, and a list of one hundred URLs fits within it completely. The “Ready headers” mode runs in your browser, so nothing leaves it.
301 and 308 are permanent: the URL has changed forever, search engines transfer the old URL’s signals to the new one, and the browser remembers the rule for a long time. 302, 303, and 307 are temporary: the old URL remains primary. The difference between 301 and 308 is the request method: 301 changes POST to GET, while 308 preserves the method. The same distinction applies to 302 and 307.
Because the redirect is configured by User-Agent. This is used for mobile versions on the m. subdomain, bot protection, and regional redirects. The tool uses the signature you select, while the “Compare signatures” button checks the URL with all five and shows where they differ. This is the only way to see a conditional rule from the outside.
It means the redirect is in the page body: a meta refresh tag or a line such as location.href in a script. We read the final page and add this redirect to the chain as a separate step, marked as not coming from a header. There is almost no difference for visitors, but there is one for search engines: they understand a header redirect unambiguously, while a redirect in the page body comes with caveats and is not always recognized.
The same URL appeared twice in the chain: the redirect rules point to each other in a loop. The browser will stop the request with an error, and the page will not open at all. Usually, this happens when two rules are unaware of each other—for example, one adds a slash and the other removes it.
Up to one hundred lines at a time, and all one hundred are processed in a single run: the server limit is three hundred requests per hour from one address, so the list fits with room to spare. The limit prevents people from using the site as an external crawler: crawling even a small site takes thousands of requests, not hundreds. If a check still stops—a network failure or the third-party site stops responding—it will tell you which URL caused it. Completed checks remain in the table and can be exported to CSV. Run the list again: completed URLs are taken from the page memory and will not be requested again.
We request each step with HEAD: it returns the headers without the body, and this is the only reliable way to follow a long chain without downloading every page in full. The size comes from the Content-Length header, which not every site sends. If a site does not accept HEAD at all, it returns code 405, and the tool marks this separately.
There is no reason to continue: twenty redirects in a row are no longer a chain but a broken configuration. The browser stops at about the same point and shows an error instead of the page. We used to stop at ten, but that was not enough: after a domain migration, a twelve-step chain is common, and the analysis ended exactly where things got interesting. If the check reaches the limit, the last URL is shown on a separate line with a note that we did not request it.
Because we show every header that arrived, in the order it arrived. Selecting seven was not enough: the reason for a step was often in a header that had not been selected. We do not combine repeated headers—Set-Cookie appears one line per cookie, so five cookies remain five lines, each with its own path, domain, and expiration. The header that caused the step to exist is also moved to the top, into a short summary below the response code.
The protocol version used by the server for its response at that step. It is useful when steps respond differently: the old domain often remains on HTTP/1.1, while the new one already responds over HTTP/2 or HTTP/3. The protocol version does not eliminate the cost of an extra step—a trip to the server and back is required either way—but it explains the difference in time between neighboring steps.
Writes the title and description and instantly shows how they appear in search results.
Open