Screpy’s Bulk HTTP Status Checker checks a supplied list of up to 50 URLs and shows the first response, final response and observed redirect steps. Use it to review old links after a move, investigate unavailable pages or prepare a focused repair list. The result describes a public GET request at the time shown, not continuous uptime, browser page-load speed or proof that a URL is indexed.
Choose a URL list with a clear purpose
Paste one complete public HTTP or HTTPS address per line. Start with a question: do the old campaign URLs reach their replacements, or do links in your navigation still return errors? Include the original addresses when checking redirects. Pasting only their final destinations cannot show what happens to an old link.
The limit is 50 nonblank submitted lines. Blank lines are ignored, and repeated normalized URLs are checked once; remove duplicates before submission if they push the list over the limit. Invalid lines must be corrected. The checker does not discover your website’s pages or automatically import a sitemap.
A useful migration sample includes an unchanged page, a moved page and deliberately removed content. Write down the intended result for each before running the check. A removed page may correctly return 404, while that same response on a live checkout page requires investigation. Use real public paths from your site, not private dashboards or addresses containing login credentials.
Read the first response and the final destination
The first code belongs to the submitted address. The final code belongs to the destination reached after the followed redirects. Final URLs appear in the table; observed redirect chains are grouped in the report details. A successful destination does not make the original address a direct 200 response.
These fictional examples illustrate how to interpret completed checks; they are not results from a particular website.
| First → final response | Meaning | What to review |
|---|---|---|
| 200 → 200 | Direct successful response | Is this the intended page, with useful content? |
| 301 → 200 | Permanent redirect reaching a successful response | Does the final URL match the intended replacement? |
| 302 → 200 | Temporary redirect reaching a successful response | Is the move genuinely temporary? |
| 301 → 404 | Redirect reaching a not-found response | Repair the destination or mapping if the page should exist |
| 403 → 403 | The request was refused | Investigate access rules; do not assume every visitor is blocked |
MDN’s HTTP status reference explains the code meanings. A 404 means not found; 410 indicates that the resource is gone. Either can be intentional. A 429 signals too many requests, while 5xx codes indicate server errors. The code identifies a response category, not its complete cause.
Summary counts overlap: a redirected URL can also finish successfully or with an HTTP error. Do not add those categories and expect the number of unique URLs.
Keep unavailable checks separate from HTTP errors
An HTTP error is a response, such as 404 or 503. An unavailable result means the checker could not finish the observation. DNS resolution, a secure-connection failure or a timeout can prevent a final HTTP response. Read the reason instead of interpreting a blank final-code cell as 404.
Each URL has an eight-second limit and the whole batch has 30 seconds. The checker follows up to five HTTP redirects. A loop, missing destination or longer chain can leave a result unfinished. These are the checker’s operational limits, not a statement of Google’s crawling limits. Earlier observed steps remain visible: a 301 followed by a failed secure connection can show its first response while still having no final code.
An HTTPS-to-HTTP change is flagged for review. Also note that the checker follows HTTP response redirects; it does not render JavaScript or follow page-level meta-refresh instructions. A browser can therefore behave differently.
Request duration describes this check, including its request path. It does not measure image loading, JavaScript execution or when a visitor can interact with the page. Use it to investigate this observation, not as a page-speed score.
Export a repair list and verify the same URLs
Prioritize errors on pages that should remain available, incorrect redirect destinations and broken addresses still linked from important pages. Do not redirect every removed URL to the homepage merely to turn the result green. Where content has moved, choose a relevant replacement; where it has genuinely gone, assess the intended response and remove obsolete references.
Filter HTTP errors, redirects or unavailable checks and search by URL to isolate the relevant rows. CSV export includes only the currently filtered rows, with first/final codes, destination, duration, reason, check time and observed chain. Keep that snapshot with the expected outcome, make the repair, and rerun the same original addresses.
Inspect questionable content separately. Google’s HTTP guidance confirms that 2xx does not guarantee indexing; even an error page can return 200. This checker does not inspect the body to identify soft 404s. Use the Noindex Checker for indexing directives or the Redirect Checker for focused redirect investigation. A corrected status is one verified condition, not a complete SEO audit.
For a list of declared preferred URLs, use Bulk Canonical Checker. It checks HTML and HTTP header declarations and one immediate target per page; it does not report Google’s selected canonical.