Audit every redirect in your URL list from your own desktop

Overview

The Redirect Checker is a redirect checker: a standalone desktop bot that walks a list of URLs, follows every HTTP hop like a real browser, and reports status codes, final destinations, chain shapes and response times into three datasets - Redirect_Report, Errors and Destination_URLs. It ships in the SEO & Web Audits family, runs entirely on your machine, and pre-loads a six-URL public test list so your first run doubles as a self-test.

What does the Redirect Checker do?

You give it URLs; it gives you a defensible audit row per URL. For each address in your list, the bot performs a genuine browser navigation - not a synthetic header probe - and captures what happened along the way: where the URL finally landed, which status codes each hop returned, how long the chain was, how many milliseconds it took, and what the destination server said in its Content-Type, Server, X-Robots-Tag and Cache-Control headers.

Two settings shape the run. The browser starts on a blank page rather than a fixed home URL, because the only navigations that matter are the ones from your list. And almost every resource type - images, media, fonts, stylesheets, scripts, background requests - is blocked, so each check downloads only the navigation documents themselves. That makes the bot fast and polite, and it also defines an honest limit described below: redirects that fire only from client-side script are not observed.

The configuration does not pin a fixed output filename. Results land in the run’s three datasets and export from the launcher’s results view to CSV, JSON or XLSX. Redirect_Report de-duplicates on Source_URL, Destination_URLs de-duplicates on the destination so you can see many-to-one consolidations at a glance, and Errors collects only the rows where navigation failed or no status was recorded.

Who uses a redirect checker?

The SEO consultant finishing a domain migration asks “did every old URL actually land where the redirect map promised?” and needs the Chain_Details column as evidence. The web developer deleting legacy routes asks “does this five-year-old campaign URL still 301 somewhere sensible, or does it 404 in front of real users?” The site owner asks “is my non-www host redirecting to www with a permanent code, or a temporary one that leaks signal?” All three want a dated artifact they produced themselves - a spreadsheet with source, destination, status and timing per URL - rather than a screenshot inside someone else’s dashboard.

How does a bulk redirect checker run work, step by step?

Every command in the run is linked to its reference page. A single for_each loop iterates over the urls_to_check settings variable - a list you edit before the run, one URL per line - binding each entry as target_url. Inside the loop, a try_catch wraps the goto navigation so a failed URL is recorded rather than aborting the batch; the catch branch logs a comment carrying the engine’s last_error text.

Then three extract_data steps run per URL. The first writes the full Redirect_Report row. The second writes to Errors only when the navigation failed or no status code came back. The third writes to Destination_URLs when a final destination exists, building the de-duplicated destination list.

The extraction mechanism is unusual and worth understanding: the Redirect_Report properties use variable= selectors such as variable=last_final_url and variable=last_redirect_chain. The engine exposes navigation facts as runtime variables surfaced through injected HTML meta elements, and the dataset reads those variables instead of parsing the visible page. Script transformations then do the shaping work - joining hop statuses with arrows, numbering hops in Chain_Details, drawing the Chain_Visual map, setting the Has_301 through Has_308 flags, classifying Redirect_Type, and grading Chain_Length_Verdict.

What does the http status code checker output look like?

The sample row below mirrors the published sample output, so table and prose agree by construction:

Source_URL is the address you submitted, normalized by the engine. It is the required field and the de-duplication key, so submitting the same URL twice in one list yields one row.

Final_URL is where the browser actually landed after all hops. Diffing it against your intended destination is the core migration check.

Status_Code and Status_Text are the code and phrase of the last hop - 301 Moved Permanently, 200 OK, 404 Not Found and so on.

Redirect_Count is the number of hops between source and destination. Zero means the URL answered directly.

Navigation_OK is true when the browser completed the navigation. False rows also appear in the Errors dataset with the reason.

Error carries the engine’s failure text - DNS resolution failures, timeouts, connection resets. Empty on healthy rows, and never invented: a failed URL shows a real error string or lands in Errors, never a fabricated success.

Content_Type, Server and Protocol describe the final response: what came back, from what software, over which HTTP version. Useful for spotting a redirect that lands on an unexpected PDF, or a destination still served by the old host.

Response_Time_ms is the full navigation time in milliseconds, chain included. Redirects are a latency tax; this column quantifies it.

X_Robots_Tag and Cache_Control are the corresponding response headers from the last hop. An X-Robots-Tag of noindex on a destination page, or a long cache on a temporary redirect, are exactly the kind of quiet problems an audit exists to catch. Empty is normal when the header is absent.

Chain_Status_Codes is the hop-by-hop status sequence, arrow-joined. Chain_Details numbers each hop with its target. Chain_Visual draws the full source-to-hop-to-destination map, one hop per line.

Has_301, Has_302, Has_303, Has_307 and Has_308 are per-row booleans: did any hop in the chain use that code? Filter a whole report on Has_302 to find every temporary redirect in seconds.

Redirect_Type classifies the row - 301 Permanent, 308 Permanent, 302 Temporary, 303 See Other, 307 Temporary, or No HTTP Redirect when the URL answered directly. When several codes appear in one chain, permanence wins the label, and the Has_ columns carry the full truth.

Chain_Length_Verdict grades the hop count: No Redirect at zero, OK at one or two, Long Chain up to five, Redirect Loop Risk beyond that.

The Errors dataset is a three-column triage view - Source_URL, Status_Code, Error - and Destination_URLs is the de-duplicated set of landing pages, which answers “how many of my old URLs collapse onto the same new page?”

How does it work as a redirect chain analyzer?

A redirect chain analyzer has to answer three questions per URL: what path did the request take, was every hop the right kind of redirect, and is the path getting worse over time? The chain columns answer the first two directly - Chain_Visual is the path, Has_302 and Redirect_Type are the kind - and the third is a workflow: save each run’s export with a date in the filename, then diff Chain_Length_Verdict counts week over week. A migration that starts accreting intermediate hops (old page to newer page to newest page) shows up as OK rows drifting to Long Chain, long before users feel it.

Can it serve as a 301 redirect audit tool after a migration?

Yes, and that is its most common job. Export the old URL list from the previous CMS, the legacy sitemap, or server access logs; paste it into the list field; run. Then work three filters in order: rows where Redirect_Type is anything other than 301 Permanent or 308 Permanent - those are moves being served as temporary; rows where Final_URL is not the intended new address - those are broken or stale rules; and rows in Errors - those are old URLs now failing outright, which may be acceptable (deleted content should 404 or 410) or a regression. What this bot will not do is crawl your site to discover URLs, grade on-page SEO, or alert you when something changes; it checks the list you give it, when you give it.

How does it compare to spot checks and subscription audits?

Checking redirects through browser developer tools works for one URL at a time and produces no artifact - there is nothing to hand a client or re-run next month. Subscription crawling platforms will audit redirects as part of a full-site crawl, but they meter the crawl, keep the data in their cloud, and you audit the URLs they discover rather than the exact list you care about. This bot inverts that: you supply the precise list, the checks run from your own machine at no per-run cost, and the dated export is yours. The trade is real - no dashboards, no history, no scheduling - but for a targeted migration or legacy-URL audit, a precise list beats a sampled crawl.

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/RedirectChecker, then launch. On Linux, the launcher is a shell script: chmod +x ./redirect-checker then ./redirect-checker.

On first run the launcher fetches its configuration, opens a visible browser window starting on a blank page, and presents the urls_to_check list for editing - one URL per line, with the six public test addresses pre-loaded so you can verify the whole pipeline before pointing it at anything real. The test list deliberately includes a domain that does not exist, so a healthy self-test produces report rows and at least one Errors row. No proxies, solver keys or AI providers are required. To run audits on a schedule, trigger the launcher from your operating system’s scheduler; the bot itself does not self-schedule.

What do I check when a run returns zero rows?

In order: is the URL list actually populated - an empty list means the loop never executes and every dataset stays empty? If rows appear only in Errors, read the Error column: DNS text means the host does not resolve, timeout text means the server never answered within the navigation limit. If Redirect_Report rows exist but Navigation_OK is false, the browser gave up mid-chain - the classic signature of a genuine redirect loop. The contract is that failure is loud: this bot never fabricates a status code or a destination, so a missing row is always a visible failure, never a silent success.

What are the limits of the bot?

It checks only the URLs you supply - it does not crawl, discover, or follow links found on destination pages. It navigates with scripts and sub-resources blocked, so a redirect implemented purely in client-side script or a single-page-app router is not observed; server-side HTTP redirects and meta-refresh behavior at the document level are its domain. It performs one browser navigation per URL - no HEAD variants, no alternate methods, no cookie or auth states. It de-duplicates on Source_URL, so the same URL listed twice yields one row. It has no scheduler, no alerting and no history; those are your spreadsheet’s job. And it follows redirects like a browser, which means very long chains can end in a hard navigation failure rather than a tidy verdict row - by design, and recorded in Errors when it happens.

What is responsible redirect checking?

Every URL in your list receives a real request from a real browser session on your machine. That is harmless at audit scale against servers you own, and it is the reason for the one firm rule: only check URLs you own or have explicit permission to test. Never point the list at third-party infrastructure to probe its behavior, keep run frequency proportionate to what the target server would expect from a handful of visitors, and remember that exported reports may contain internal or pre-launch URLs - store them with the same care you give any internal document. The acceptable-use policy applies in full before your first run.