What does a bulk status checker do?
The question "which of these still work?" arrives as a list. A redirect map after a migration, the URLs in a spreadsheet, an export from a sitemap or an analytics report, a client's list of pages they think are live. Checking them one at a time in a browser is a slow way to answer it, and opening forty tabs to read forty status codes hides the pattern that matters. This tool takes the list, asks each address for its status in parallel, and returns one row per address.
It asks for as little as possible. HEAD is the first request for every address, because only the status is wanted and there is no reason to download a page to find it; where a server refuses HEAD — 405 or 501 — or fails outright, the address is requested again with GET and the body is thrown away as it arrives rather than buffered. Sixty pages costs sixty status lines, not sixty page loads.
What comes back is sorted worst-first, because the interesting rows are the ones that failed. Each row carries the status code and its reason phrase, the address the request finally settled on where there was a redirect, and the time it took. A row with no status has the reason instead: a host that does not resolve, a connection that was refused, or an address this tool declines to fetch — and that refusal is deliberate, because the same guard that protects every other tool here protects this one, and a pasted list is not a reason to make an exception for a private address.
How to check a list of URLs at once
- Paste the list into the box, one address per line. Commas work too, so a column pasted out of a spreadsheet is fine, and whitespace around each entry is ignored.
- Omit the scheme if you like: an entry without `http://` or `https://` is assumed to be https://. Fixed both here and in your list is the same result.
- Press Check statuses. Every address is requested at once, with HEAD first and a GET fallback only where HEAD is refused. Sixty addresses take a few seconds rather than sixty.
- Read the six counts across the top — reached, redirecting, client errors, server errors, no answer, refused — to see the shape of the list before looking at individual rows.
- Work down the table. It is sorted worst-first, so the rows that need attention are at the top, with the address each redirect settles on shown for the ones that moved.
- Download the CSV when the list is going into a spreadsheet, a ticket or a client report. It carries the status, the reason phrase, the final URL and the note for every row.
Bulk status check limits and rules
| Item | Limit |
|---|---|
| Addresses per run | 60. Split a longer list and run it in parts |
| Accepted formats | One per line, or comma-separated; with or without a scheme; leading and trailing whitespace is stripped |
| Request method | HEAD first for every address, then GET with the body discarded only where HEAD is refused (405, 501) or fails |
| Redirects | Followed, and the address the request finally settles on is reported as the final URL with a hop count |
| Sweep deadline | 28 seconds for the whole list; an address not reached in time is reported as such rather than as passing |
| Refused addresses | Anything on a private, loopback, link-local or non-public address, and any scheme that is not http or https, is listed with the reason instead of being fetched |
| Rate limit | 40 runs per minute per visitor |
| Not included | Page content, titles, canonical tags, whether the page is indexable — this reports status codes, and the audit and the link checker report the rest |
| Not verified | A 200 does not mean the page is correct, only that the server answered with a body. A soft 404 — a page that says "not found" while returning 200 — looks healthy here |
When to use it
- Checking a redirect map after a migration, to confirm that every old address still answers and that none of them was missed in the rewrite rules.
- Confirming that a list of URLs from an analytics report still exists, so the traffic going to them is not landing on a 404.
- Testing both the `www` and the non-`www` forms of a set of addresses, to see which ones redirect and which answer directly.
- Checking an API's endpoints or a set of asset URLs on a deploy, where knowing that every address answers is the whole question.
- Producing a spreadsheet of status codes for a client, with the redirect targets filled in, rather than a list of notes taken by hand.
Is it private?
The addresses are requested by this site's server rather than your browser, for the same reason the other checking tools do: a browser will not report the real status of a cross-origin request, and it will not let a page request sixty origins anyway. When you press the button, your browser sends your list to this site's own endpoint, which requests each address with a crawler user agent and returns the statuses. The sites you check see requests from this server and learn nothing about who asked. No cookies, credentials or browser details are forwarded, and your list is not stored — your IP is only counted against a per-minute meter.
Frequently asked questions
Because it is not a public address. Anything on a private range, a loopback address, a link-local address or a hostname that does not resolve to a public IP is listed with the reason instead of being fetched, and any scheme other than http or https is refused outright. That guard exists so a list of URLs cannot be used to make this server probe a network it should not see — including its own — and it applies per row, so one refused address does not stop the rest of the list.
Because the status code only promises that the server answered with something. A soft 404 returns 200 with a page that says the content is not found, and it is common on sites where the not-found page is a custom template. A 200 on an address that redirects somewhere unexpected, or on a placeholder page, looks the same here. This tool answers whether the address responds; whether it responds with the right thing is a page-level question the audit and the Googlebot view answer.
Usually not. A 403 is usually bot protection answering a request that does not look like a browser, and a 405 means the server does not implement HEAD for that address — which is why HEAD is retried as GET before the result is trusted. Cloudflare, WAFs and some CDNs all do this deliberately. Treat both as "needs a look in a browser" rather than as broken; a 404 or a 410 will not have that excuse.
Not in one run, and the limit is there for a reason: every address in the list is a request made from this server in real time, so a list of a thousand would be a small crawl rather than a check, and it would take long enough that the browser would give up waiting. Split the list into parts of sixty and run them one after another — the CSV of each part merges cleanly in a spreadsheet.
Because the final URL is only interesting when it differs from the address you submitted. A row that shows "same address" means the server answered directly, with no redirect — which is the healthy case and the one worth wanting. A row with a final URL means the request was redirected at least once, and the URL shown is where it ended up; the hop count is in the CSV for the rows where more than one redirect happened.
Both. That pair is usually the useful finding rather than an inconsistency: the 200 is the address the site actually uses, and the 404 is the old one that was never redirected — which is exactly the request that follows, adding a redirect from the dead address to the live one. If the 404 was unexpected, the difference between the two rows is normally a trailing slash, a case difference, or a query string the server needs and did not get.
Related tools
Written and maintained by Md. Nur Hossain Repon.