How do I check if a list of URLs is still live?
Paste the list, one URL per line, into the urls_to_check variable on the launcher input screen and start the run. The bot visits each URL in a real browser, records its HTTP status, and splits the results into an Alive_URLs dataset and a Dead_URLs dataset, both exported as CSV you can open in Excel or Sheets.
How do I find dead links in bulk?
The Dead_URLs dataset isolates every URL whose final status falls outside your alive window (100-399 by default) or whose navigation failed outright, with an Error column explaining timeouts, DNS failures and connection resets. You get the full dead list in one file instead of hunting through the complete report.
What HTTP status codes count as alive?
By default, any status from 100 to 399 counts as alive, which means 3xx redirects land in Alive_URLs because the resource still exists somewhere. If you want only clean 200-level responses treated as alive, set check_status_min to 200 and check_status_max to 299 and redirects will move to the dead list instead.
How do I check redirects for a list of URLs?
Every row of the full Alive_Checker report carries a Redirect_Count and a Final_URL column. Redirect_Count tells you how many hops the URL took, and Final_URL tells you where it ended up, so you can spot both single 301s and long redirect chains without opening a browser for each URL.
Can I customize which status codes are treated as alive?
Yes. The check_status_min and check_status_max variables define the alive window, and both filtered datasets are driven by that same window, so Alive_URLs and Dead_URLs always stay consistent with each other no matter what thresholds you set.
How fast is a bulk URL status check?
The configuration runs three browser workers in parallel and blocks all sub-resources - images, scripts, stylesheets, fonts, media, XHR and websockets - because a status check only needs the navigation itself. That makes per-URL cost close to raw response time; hundreds of URLs typically finish in minutes, with slow hosts and timeouts dominating the total.
Does it capture the final URL after redirects?
Yes, Final_URL records the address the browser landed on after all server-level redirects. One honest caveat: because scripts are blocked for speed, purely client-side redirects fired by JavaScript after page load may not execute, so a JS-driven redirect can show as its initial response rather than its destination.
How do I audit a domain migration for broken links?
Export your old URL list from a sitemap or analytics package, run it through the bot, then check three things in the CSV: old URLs now returning 404 or 410, Final_URL values that do not match the intended new destination, and Redirect_Count values greater than one that reveal chains worth collapsing. Re-run after fixes to confirm.
Does the checker work without a browser window?
The shipped configuration runs with headless set to false, so a visible browser window opens and you can watch each URL being checked - useful for diagnosing slow or blocked runs. For scheduled or background use, flip the headless setting to true and the run proceeds without any window.
What happens when a URL times out or fails to resolve?
Each navigation is wrapped in error handling, so one bad URL never stops the run. The failure is recorded with Navigation_OK set to false and the error text captured in the Error column, and the row lands in Dead_URLs. Failures are always visible in the output; a row is never silently dropped or marked alive.
Does the bot need an internet connection to run?
Yes on first run: the launcher fetches its configuration by id from the backend at launch, so an internet connection is required at least the first time it starts.
Can I rename the downloaded file?
No. The downloaded file must keep its exact name - the filename carries the per-bot configuration id, and renaming it breaks the configuration fetch at launch.
