Overview
The Mass Alive Checker is a bulk URL status checker: a standalone desktop bot that takes a list of URLs, visits each one in a real browser, and records whether it is alive or dead along with its HTTP status code, final URL after redirects, redirect count, content type, server header and protocol. Results are exported as CSV across three datasets - Alive_Checker (the full report), Alive_URLs and Dead_URLs.
What does the Mass Alive Checker do?
You paste a list of URLs, one per line, and the bot works through the whole list in a single run. It is built for speed and honesty rather than depth: three browser workers run in parallel, and every sub-resource - images, scripts, stylesheets, fonts, media, XHR, fetch, websockets and manifests - is blocked, because a status check only needs the navigation response itself. Each URL is visited inside error handling, so a timeout or a domain that no longer resolves never kills the run; the failure is recorded and the next URL proceeds. The scope is deliberately narrow: it validates a list you supply. It does not crawl sites, discover links, or re-check anything on a schedule.
Who uses a bulk URL status checker?
The SEO consultant cleaning a backlink list asks “which of these three hundred domains still resolve, and which redirect somewhere else entirely?” The webmaster mid-migration asks “do all the old URLs return a 3xx, and do they land where I intended?” The content maintainer asks “which links on our resource pages have quietly died this year?” The developer asks “which endpoints in this list now serve JSON or a PDF instead of HTML?” All four need the same artifact: a dated CSV with one row per URL, a status code, and a final destination - produced on their own machine, with no per-check URL cap and nothing uploaded to anyone else’s servers.
How does a run work, step by step?
Inputs come from project settings rather than a mid-run dialog: urls_to_check (a required list, one URL per line), check_status_min (default 100) and check_status_max (default 399). The engine starts at a blank page - initial navigation is skipped - and works through your list. For each URL, a try_catch block wraps a goto navigation; if the navigation throws, the catch branch logs the failure with a comment step carrying ${last_error} and the run continues. After the attempt, the engine’s last-navigation metadata (target, status, final URL, redirect count, content type, server, protocol, success flag, error) is read by three extract_data steps: the full Alive_Checker report; Alive_URLs, filtered to statuses where Number(item.Status) >= Number('${check_status_min}') && Number(item.Status) <= Number('${check_status_max}'); and Dead_URLs, filtered to everything else. Each dataset is exported as CSV beside the launcher.
What does the HTTP status code checker output look like?
The sample row is the listing’s own published sample output, so table and prose agree by construction:
| Target_URL | Status | Final_URL | Redirect_Count | Content_Type | Server | Protocol | Navigation_OK | Error |
|---|---|---|---|---|---|---|---|---|
| https://shop.example.com/old-page | 301 | https://shop.example.com/new-page | 1 | text/html; charset=UTF-8 | nginx | HTTP/2 | true |
Target_URL is the URL you supplied, exactly as pasted - the join key back to your original list.
Status is the HTTP status code observed at the end of navigation: 200 for a clean hit, 301/302 for a redirect, 404/410 for gone, 5xx for server errors.
Final_URL is where the browser actually landed after all server-level redirects. Diff it against your intended destination to catch mis-mapped redirects.
Redirect_Count is the number of hops taken. Anything above one is a chain worth collapsing for crawl efficiency.
Content_Type is the served MIME type - the column that reveals a URL now answering with a PDF, JSON or a generic error page type instead of HTML.
Server is the server response header when the host publishes one. Empty is normal: many servers omit or mask it, and absence is never treated as a failure.
Protocol is the negotiated protocol version, useful for spotting URLs still stuck on plain HTTP.
Navigation_OK is the success flag for the attempt itself. When it reads false, the URL never completed a navigation and the row belongs in Dead_URLs regardless of status.
Error carries the failure text - timeout, DNS resolution failure, connection refused - and is empty on successful navigations.
How does it work as a dead link checker for long lists?
The split happens inside the run, not in your spreadsheet afterwards: Dead_URLs collects every row whose status falls outside your alive window or whose navigation failed, with the reason attached. Because sub-resources are blocked and three workers run in parallel, long lists finish in minutes rather than hours, and there is no per-run cap on how many URLs you paste - the practical limits are your connection and the patience of the target servers. Hosted tools in this space commonly meter checks per batch; here the marginal cost of a bigger list is your own bandwidth.
Can it serve as a URL list validator before a migration?
Yes, in both directions. Before the switch, run the old URL list and confirm nothing is already dead. After the switch, run it again and validate three things per row: the Status is a 3xx, the Final_URL matches the intended new location, and Redirect_Count is one. Rows that fail any of the three become your fix list, and re-running after fixes produces a clean dated CSV you can attach to the migration report as evidence. It is a snapshot validator, though - nothing re-runs itself, so schedule the launcher through your operating system’s scheduler if you want periodic checks.
How does the bulk redirect checker data help after a redesign?
Redesigns break URLs in patterns: old paths 404ing, new paths redirecting to the homepage instead of the right page, chains forming where two redirect rules overlap, and protocol stragglers still answering on HTTP. The Redirect_Count, Final_URL and Protocol columns turn each pattern into a one-line spreadsheet filter. A pivot on Status and Content_Type after a platform rebuild quickly answers “how many old article URLs now serve something other than an HTML page?”
How does it compare to hosted crawlers and monitoring services?
Desktop crawlers discover links themselves and audit whole sites; this bot does the opposite - it validates a list you already have, and never wanders beyond it. Hosted checkers and monitoring services run continuously, keep your URL lists and results in their cloud, and commonly meter how many URLs one check may contain; this bot runs once per launch, entirely on your machine, with the CSVs landing on your disk and no account, upload or per-check quota. The trade is real: no dashboards, no alerting, no history, no crawl discovery. You own the artifact and the workflow outright, and a thousand-URL list costs exactly as much as a ten-URL one.
How do you set it up on Windows, macOS and Linux?
Download the launcher for your operating system from this page. On Windows, run the executable; SmartScreen may ask for confirmation on first launch, and “More info” then “Run anyway” proceeds if you trust the published checksum. On macOS, Gatekeeper may quarantine the download; right-click and “Open”, or clear the flag with xattr -d com.apple.quarantine /path/to/MassAliveChecker, then launch. On Linux, the launcher is a shell script: chmod +x ./mass-alive-checker then ./mass-alive-checker. On first run, paste your URL list into urls_to_check (one per line) and adjust the status thresholds if you want anything other than the default 100-399 alive window; the shipped defaults include one deliberately non-existent domain so you can see what a failure row looks like. A visible browser window opens during the run - flip the headless setting to true for unattended use, and pair it with your OS scheduler for recurring checks.
What do I check when a run returns zero rows?
In order: was the list pasted into urls_to_check one URL per line, with full https:// schemes? Did every navigation fail at once - check the visible browser window and your own connection, since a dead local network produces an all-error batch. Are the thresholds sane - check_status_min greater than check_status_max would classify everything as dead, and an unusual window can hide rows from the dataset you expected them in. If Alive_Checker itself is empty, the runs never recorded navigation metadata; re-run a handful of URLs and watch the browser. The contract is that failure is loud: dead URLs appear in Dead_URLs with their error text, and a row is never fabricated, silently dropped, or marked alive without an observed response.
What are the limits of the bot?
It checks the list you give it - no crawling, no link discovery, no sitemap parsing. It runs once per launch: no scheduling, alerting, history or diffing is built in. There is no retry logic; a flaky host produces one failure row, and re-running is your retry. Because scripts are blocked for speed, JavaScript-driven redirects fired after load may not execute, and pages behind logins, consent walls or bot challenges will report their gate response rather than real content. Server and Protocol columns depend on what hosts choose to publish - empty values are normal. And it sees one moment in time: a 200 now says nothing about next Tuesday.
What is responsible URL list checking?
Check URLs you own or have explicit permission to test. Three parallel workers with blocked sub-resources is already a light footprint, but keep lists batched and re-runs purposeful - do not hammer a small host, and never point the bot at third-party infrastructure as a probe or stress test. Server headers in the output are operational metadata about systems you are entitled to audit; using them to fingerprint and target sites you do not own is out of scope and out of bounds. The acceptable-use policy applies in full before your first run.
