Bulk Redirect Checker

A bulk redirect checker follows the redirects of many URLs at once and tells you where each one really ends up. Paste up to 100 addresses, one per line, or upload a CSV, and our free Bulk Redirect Checker requests every URL from our server, follows each HTTP redirect hop by hop and reports the final URL, the final status code, the number of hops and the code used at every step. Add an expected target next to each old URL and the checker becomes a migration test: it marks every row as a match or a mismatch, so you can see in minutes which redirects from a relaunch, a domain move or an HTTPS switch were set up correctly. Long chains, temporary 302s, loops, HTTP to HTTPS upgrades and www changes are flagged, and the full results export to CSV.

How to use the Bulk redirects

1. 1 Paste or upload your URLsEnter up to 100 URLs, one per line, or upload a CSV or text file. Bare domains such as example.com get https:// added. Duplicate lines are removed, and anything that is not a public web address is listed with the reason it was rejected.
2. 2 Add expected targets for a migration checkTo test a redirect map, put the new URL after the old one on the same line, separated by a comma or a tab: old URL, expected URL. The target can be a full address or a path such as /new-page, which is read on the old URL's site.
3. 3 Run the checkPress Check redirects. URLs are sent to our server five at a time and the progress bar fills as each batch returns. You can stop the run at any point and keep the results gathered so far.
4. 4 Filter and sort the resultsUse the summary tiles or the filter menu to show only chains, temporary hops, 4xx and 5xx errors, failed checks or mismatches. Click a column heading to sort, and click a row to see every hop in its chain.
5. 5 Export and fixDownload the table as CSV or copy it into a spreadsheet, hand it to whoever manages the server or CMS, then run the list again after the fixes to confirm every row is green.

What a bulk redirect checker does

A redirect tells a browser or a search engine crawler that the content it asked for lives at a different address. The server answers with a status code in the 300 range and a Location header naming the new URL, and the client requests that address instead. Sometimes the new address redirects again, and the series of requests from the first URL to the page that finally loads is called a redirect chain.

Checking one URL in a browser hides most of this. The address bar jumps straight to the final page and you never see the codes or the steps in between. A redirect checker makes each step visible by asking for the URL without following redirects automatically, reading the status code and Location header, then requesting the next address itself, one hop at a time.

A bulk checker does the same for a whole list. That matters whenever redirects come in batches: after a site redesign that changed the URL structure, when products or categories were renamed in an online store, when a blog moved to a subfolder, or when a company consolidated several domains into one. In those cases you rarely care about one URL. You need to know that dozens or hundreds of old addresses all land in the right place, with the right type of redirect, in as few steps as possible.

Reading the results: status codes and redirect types

Each row shows the final status code, the number of hops and the final URL, and the expandable chain lists the code used at every step. The codes tell you different things, and the difference is worth knowing before you change anything on the server.

• 301 Moved Permanently: the standard redirect for a page that has moved for good. Search engines treat the new URL as the replacement and, over time, show it in results instead of the old one.
• 308 Permanent Redirect: also permanent, but it requires the client to repeat the same request method, so a form POST stays a POST. For ordinary pages it behaves like a 301.
• 302 Found and 307 Temporary Redirect: temporary moves. They are right for short-lived situations such as a maintenance page or a seasonal campaign, but on a permanent move they send a mixed signal, and search engines may keep the old URL indexed for longer.
• 303 See Other: mostly used after a form submission to send the browser to a confirmation page. It is unusual for normal content URLs.
• A final 2xx status means the chain ended on a page that loaded. A final 4xx, such as 404 Not Found or 410 Gone, means the redirect leads to a dead end, and a final 5xx means the destination server failed.
• Failed rows mean the chain could not be completed: the domain did not resolve, the server did not answer in time, a redirect pointed at a private or internal address, or the chain looped.

Redirect chains, loops and why hops matter

Every hop is a separate request, so each one adds a round trip before the visitor sees anything. On a fast connection that may be barely noticeable, but on a mobile network a chain of three or four redirects can add a visible delay to the first page view. Chains also tend to grow by accident. A site moves from HTTP to HTTPS, later drops the www, and later still renames a section, and an old link ends up passing through all three rules before it arrives.

Google has said its crawler follows a limited number of redirect hops in a row, and its documentation describes long chains as something to avoid. The practical advice is simple: point every old URL straight at its final destination in a single permanent redirect. This tool counts the hops for every row and highlights anything with two or more, so you know which rules to collapse.

A loop is the worst case. URL A redirects to B and B redirects back to A, or a longer circle forms, and the page never loads. Browsers give up with an error such as too many redirects. Loops usually come from two rules fighting each other, for example a server rule that adds a trailing slash and a CMS setting that removes it, or an HTTPS redirect at the CDN and another at the origin server that disagree. The checker stops as soon as a chain returns to an address it has already visited and marks the row as a loop. It also stops after 10 hops and reports the chain as too long.

Testing a site migration with expected targets

The most useful way to run a bulk redirect check is against a redirect map. Before a migration, most teams build a spreadsheet with two columns: the old URL and the new URL it should go to. After launch, that map is the specification, and the question is whether the live server actually follows it.

Export those two columns as a CSV, upload it, and the checker compares where each old URL really ends with the target in the second column. A row is marked as a match when the final URL is the expected one and that page loads. The comparison ignores letter case in the domain and a trailing slash at the end of the path, but it does treat http and https as different, and it keeps query strings, because those are different addresses to a search engine.

Even matching rows can need attention. The note under each match tells you whether the target was reached in one permanent redirect, through a chain of several hops, or with a temporary code. A mismatch note tells you whether the URL ended somewhere else, whether it reached the right address but that page returns an error, or whether the chain failed before it finished. Sorting by the Expected column puts every mismatch together, which makes a convenient fix list for a developer.

A header row such as "old url, new url" is skipped automatically, and blank lines and lines starting with # are ignored, so you can usually upload a file exported from a spreadsheet without editing it first.

HTTPS, www and trailing slash normalization

Many redirects exist only to normalize the address: to send http:// to https://, to add or remove www, or to settle on one form of trailing slash. Each row carries small labels when these happen, such as HTTP to HTTPS, Adds www, Removes www or Different domain. A label reading HTTPS to HTTP is a warning sign. It means a secure URL is being sent to an insecure one, which browsers may flag and which undoes the point of having a certificate.

Normalization rules are a common source of chains. If an old link uses http and the non-preferred host, the request may hit the HTTPS rule first, then the www rule, then the page redirect itself. Checking a sample of old URLs in their original form, not just the tidy https version, shows whether those rules are stacking up. Where possible, combine them on the server so any variant goes to the final URL in one step.

For a single domain, the separate Redirect Checker on this site tests the four basic variants, http, https, www and non-www, and tells you whether they all end on one address. Use it for the homepage and this bulk tool for everything deeper in the site.

What this tool does not check

It is important to know the limits of any automated check. This tool follows HTTP redirects only, meaning responses with a 3xx status and a Location header. It does not read page content, so a meta refresh tag or a JavaScript redirect inside an HTML page is not followed, and a URL that redirects that way will show as a normal 200 response. If you rely on those methods, test those pages in a browser as well, and consider replacing them with server-side redirects.

Requests come from our server, not your browser. A site that redirects visitors by country, language, device or cookie may send our checker somewhere different from where it sends you. Some sites and firewalls answer automated requests with 403 Forbidden or 429 Too Many Requests even when the page works normally in a browser. The checker asks for each URL with a lightweight HEAD request and falls back to GET only when a server rejects HEAD, so the rare server that answers HEAD differently from GET can also produce a different result.

For safety, every hop is checked before it is requested, and addresses that resolve to private, loopback or internal networks are refused. Only the standard web ports 80 and 443 are allowed. Finished chains are cached for 10 minutes to keep the service fast and polite to the sites being tested, so a redirect you changed a moment ago may take a short while to show its new result. A run is limited to 100 URLs; for larger lists, split them into several runs.

Examples you can copy

old url,new url
https://example.com/services/web-design,https://example.com/web-design/
https://example.com/blog/2021/summer-sale,/offers/
http://shop.example.com/product?id=42,https://example.com/products/blue-mug/

# Before: http://www.example.com/old -> https://www.example.com/old
#         -> https://example.com/old -> https://example.com/new
RewriteEngine On

# Page rules first, each pointing straight at the final URL
RewriteRule ^old/?$ https://example.com/new [L,R=301]

# Then one combined HTTPS + non-www rule for everything else
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

Common mistakes to avoid

Frequently asked questions