Overview
The Outbound Link Checker is an outbound link checker: a standalone desktop bot that reads every anchor on each URL you supply, classifies links by scheme and destination, counts internal vs external targets, records navigation health per page, and routes pages by link density - exporting four CSV datasets after the run.
What does the Outbound Link Checker do?
You give it a list of URLs - one per line - and a link-density threshold. For every URL it opens a real browser page, waits for the document, and extracts four datasets: Outbound_Links (scheme-level anchor counts plus navigation diagnostics), Link_Census (a script-computed internal vs external aggregate with the top external domains), High_Link_Pages (pages above your threshold) and Good_Link_Partners (pages at or below it). Each dataset is de-duplicated by page URL, so re-running with overlapping lists never doubles rows.
Two design choices shape everything it reports. First, it blocks heavyweight resources - images, media, fonts, stylesheets, websockets, manifests, texttracks, eventsources and other assets - but deliberately does not block scripts. Pages load fast, yet client-rendered JavaScript still executes, so anchors injected by front-end frameworks are counted too. Second, it runs with a visible browser (headless is off in the configuration), which keeps the run observable and avoids the detection profile of headless traffic. Because everything runs on your desktop, your audit list - which properties, which competitors, which client sites - never passes through anyone else’s servers.
One honesty note up front: this is a page-structure auditor, not a crawler and not a broken-link checker. It never follows the links it counts, so it cannot tell you whether an outbound destination is alive. What it tells you is how each page is wired: how many links leave the site, how many stay inside it, which schemes are in play, which external domains receive the most anchors, and how the page itself behaved during navigation.
Who uses a website link checker?
The technical SEO asks “which templates leak the most link equity off-site, and to whom?” and needs the external counts and top-domain lists per URL. The site owner mid-migration asks “did the new theme silently double my footer links?” and needs before-and-after Total_Links numbers on the same URL set. The outreach marketer asks “which pages on my site are sensible, uncluttered places to request a link back?” and needs the Good_Link_Partners dataset - pages whose link count stays under a sane ceiling. The agency auditor asks “can I hand the client a dated artifact instead of a screenshot of a dashboard?” and needs four CSVs with the run date attached by the filesystem. All four want numbers they produced themselves and can re-derive on demand, not a credit-metered report inside someone else’s cloud.
How does outbound link analysis work on a batch of URLs?
The run has no interactive prompts and no in-flow navigation commands. Before launch you fill two project-settings inputs derived from the configuration’s variables: urls_to_check, a required multi-line list (the shipped default holds three example URLs - replace them), and max_outbound_links, an optional threshold defaulting to 100. The launcher turns the list into the run queue; the engine navigates each URL itself, with up to five concurrent workers, and records the navigation outcome (status, final URL, redirect count, response time, content type, server, protocol, success flag, error text) as runtime variables.
Then, for every URL, four extract_data steps run in order. The first extracts Outbound_Links: the page title plus count-type properties over CSS selectors - css=a[href] for the total, css=a[href^='/'] for root-relative, css=a[href^='//'] for protocol-relative, css=a[href^='http'] for absolute HTTP(S), css=a[href^='#'] for fragments, and matching selectors for mailto, tel, javascript and href-less anchors (css=a:not([href])) - joined with the navigation variables via variable= selectors such as variable=last_http_status. The second extracts Link_Census: a nested list property over every css=a[href] whose raw rows (origin and href) pass through a script transformation that resolves, classifies and aggregates them into one object per page. The third and fourth extract_data steps re-extract the page-level totals under filter conditions - Number(item.Total_Links) > Number('${max_outbound_links}') for High_Link_Pages and Number(item.Total_Links) <= Number('${max_outbound_links}') for Good_Link_Partners - so every audited page lands in exactly one of the two routing datasets. When the queue is exhausted, each dataset is written to its own local CSV file named after the dataset.
What does the output look like?
The sample row below is the listing’s own published sample output, taken from the first dataset, so table and preview agree by construction:
| Page_URL | Page_Title | Total_Links | Root_Relative_Links | Protocol_Relative | Absolute_HTTP_Links | Fragment_Links | Mailto_Links | Tel_Links | Javascript_Links | No_Href_Anchors | HTTP_Status | Final_URL | Redirect_Count | Response_Time_ms | Navigation_OK |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| https://rtila.com/ | RTILA X - Local-First AI Web Automation | 148 | 96 | 0 | 34 | 12 | 2 | 0 | 3 | 1 | 200 | https://rtila.com/ | 0 | 412 | true |
Page_URL is the URL you queued, and the de-duplication key plus required field for the dataset - a row always carries it.
Page_Title is the document title exactly as rendered, useful for spotting the moment a URL resolves to a sign-in or error page whose title gives it away.
Total_Links counts every anchor with an href, of any scheme. This is the number the threshold routing acts on.
Root_Relative_Links counts hrefs beginning with a single slash - links resolved against the current origin. A healthy internal-navigation page shows most of its density here or in absolute same-host links.
Protocol_Relative counts hrefs beginning with a double slash. This legacy pattern should normally be zero; a nonzero value is a small modernisation finding in itself.
Absolute_HTTP_Links counts fully qualified http and https hrefs. Note this includes absolute links pointing back at the same site - the internal vs external split lives in Link_Census, not here.
Fragment_Links counts in-page anchors beginning with a hash - table-of-contents and accordion markup typically.
Mailto_Links and Tel_Links count contact-scheme anchors. They are tallies only: no email address or phone number is copied into any output.
Javascript_Links counts hrefs invoking a javascript scheme. These are anchors that go nowhere without scripting, and a high count is an accessibility and crawlability finding worth recording.
No_Href_Anchors counts anchor elements with no href at all - decorative or JS-bound elements that are not links in any crawlable sense.
HTTP_Status, Final_URL, Redirect_Count, Response_Time_ms describe the navigation of the queued URL itself: what the server answered, where the browser settled, how many hops it took, and how long the response took in milliseconds.
Navigation_OK is the success flag for the page load; when it is false, Error (present in the dataset, empty on healthy rows) carries the engine’s failure text, and the link counts for that row should be treated as describing whatever partial document rendered, if any.
The configuration also captures Content_Type, Server and Protocol per row - the response’s MIME type, the server header and the negotiated protocol - so a page served as a PDF or from an unexpected host is visible in the data rather than silently counted.
What does the Link_Census aggregate add?
One row per page, keyed by Page_URL, the census object reports: total anchors examined; internal and external counts after hostname resolution; unique_internal and unique_external (distinct targets, so a footer link repeated on every template is counted once); unique_external_domains (how many distinct off-site hosts receive links); top_external_domains (the ten most-linked hosts with their counts, e.g. a ranked “who does this page point at” list); fragment_links, mailto_links, tel_links, javascript_links and empty_href tallies; and href, which holds up to eight sample external destinations joined by a pipe so you can eyeball where the outbound weight goes without re-opening the page. The script also separates data and blob scheme targets and counts unparseable hrefs, so exotic markup is quarantined rather than misclassified as external.
What do the two routing datasets contain?
High_Link_Pages and Good_Link_Partners share a compact shape - URL (required, de-dup key), Total_Links, Absolute_HTTP, Root_Relative and HTTP_Status - and partition the audited set by the threshold. They are triage views: the first is your cleanup backlog, the second your safe-to-reference shortlist.
How are internal vs external links counted?
The census script resolves every href against the page’s own origin, then compares hostnames. A target counts as internal when its hostname equals the page hostname, including the www variant on either side - so www and bare-domain links to the same site are not falsely split. Everything else that resolves over http or https counts as external, and its hostname feeds the domain tally behind top_external_domains. Relative paths, root-relative paths and protocol-relative URLs resolve before comparison, so they classify correctly instead of falling through as “other”. Fragments, mailto, tel, javascript, data and blob targets never count as external; they are reported in their own columns. This is the same-site logic a careful human auditor would apply - implemented once, applied identically to every URL, and readable in the configuration’s transformation script rather than hidden in a vendor’s backend.
Can it serve as a link audit tool before an outreach campaign?
Yes, with the routing datasets doing the work. A link audit tool ultimately answers “which pages are link-dense, where does the outbound weight go, and which pages are clean enough to be worth referencing?” - and the four exports answer exactly that, dated by the run. Before requesting links to your own properties, check Good_Link_Partners for pages under your threshold; before fixing a template that bleeds equity, sort High_Link_Pages by Total_Links and read its top_external_domains. What it will not do is score domain authority, track rankings, or schedule itself: re-run the launcher on your own cadence and diff the CSVs to build the trend.
How does it compare to hosted crawlers and manual spreadsheets?
Copying hrefs into a spreadsheet by hand works for one page and collapses at twenty, and it produces no unique-domain or redirect data at all. This bot produces the full four-dataset audit on your own machine for nothing per run, and the workflow is yours to keep and re-run. Against subscription crawling services, the difference is structural: those meter pages or credits, hold your crawl data in their cloud, and define retention for you. Here the data lands on your disk immediately, the threshold is a plain number you control, and the marginal cost of a longer URL list is your own bandwidth. The trade is real - no crawl discovery, no historical dashboards, no destination status checks - but you own the artifact and the method outright, which is exactly what an auditor needs when a client asks “where did these numbers come from?”
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/OutboundLinkChecker, then launch. On Linux, the launcher is a shell script: chmod +x ./outbound-link-checker then ./outbound-link-checker. On first run, replace the three example URLs in the urls_to_check list with your own - one per line - and adjust max_outbound_links if 100 is not your threshold. A visible browser window opens during the run (headless is off by design); five workers run in parallel, so keep the list proportionate. To re-audit on a cadence, point your operating system’s scheduler at the launcher - the bot itself does not self-schedule.
What do I check when a run returns zero rows?
In order: did you leave the example URLs in place, or supply an empty urls_to_check list - the queue is only what you enter? For a specific URL missing from the output, check its row’s Navigation_OK and Error fields first: a failed navigation still records diagnostics rather than vanishing silently. If rows exist but High_Link_Pages is empty, that is a legitimate result - no page crossed the threshold; lower max_outbound_links and re-run to confirm. If Total_Links is zero on a page you know has links, the likeliest cause is a consent wall or interstitial that rendered instead of the document - compare Page_Title and Final_URL against what a human browser shows. The bot’s contract is that failure is loud: a page either navigates and reports its real structure, or reports its navigation error - counts are never fabricated to fill a row.
What are the bot’s limits?
It audits only the URLs you queue - there is no crawl, no sitemap discovery, no link following. It counts anchors present in the DOM after scripts run, including hidden ones such as off-canvas navigation, so counts reflect markup, not what a visitor visually sees. It does not report anchor text, rel attributes (nofollow, sponsored, ugc), link position, or destination status - an outbound link that 404s still counts as one outbound link. It cannot see logged-in or consent-walled content. Five workers is the configured ceiling for parallelism, and very large URL lists simply take proportionally longer. And it is a snapshotter, not a monitor: nothing re-runs or alerts by itself.
What is responsible link auditing?
Point this bot at pages you own or have permission to test - your sites, your clients’ sites under engagement, public pages whose terms tolerate automated reading. Review robots.txt and each site’s terms before queueing third-party URLs, and keep request rates at what a patient human could sustain; five concurrent workers with assets blocked is already efficient, and a thousand-URL list pointed at one host is not an audit, it is a load test. The recorded Server, Protocol and response-time fields are for documenting the pages you are allowed to document, never for probing infrastructure you do not control. The output contains no page copy and no contact details - mailto and tel anchors are counted, not harvested - and it should stay that way in anything you publish from it. The acceptable-use policy applies in full before your first run.
