Broken Link Checker v2.0

Scan any web page and find its broken links in seconds. We check every link on the page, follow redirects, and tell you honestly which are truly dead versus just blocking our checker.

Try: a Wikipedia page, example.com

About Broken Link Checker

A broken link checker is a tool that requests every link on a web page and reports which ones fail to load. The hard part is not finding failures. It is telling the difference between a link that is genuinely dead and one that simply refuses to answer an automated request, which is why so many scan reports flag working LinkedIn profiles and Cloudflare-protected sites as 404s. The ToolsPivot Broken Link Checker sorts every result into four buckets instead of two, so you fix what is actually broken and leave the rest alone.

What This Broken Link Checker Actually Does

ToolsPivot fetches one page you specify, extracts every link in its HTML, and tests each destination individually. It reads both anchors and sources, resolves relative paths against any tag, drops non-web protocols like mailto: and tel:, and de-duplicates the rest while keeping a count of how many times each URL appears.

Each surviving link then gets probed on its own. The result comes back with a status code, a plain-language reason, the anchor text that pointed at it, and, for anything that redirects, the final destination plus the number of hops it took to get there. Everything runs on the server side, because a browser cannot read the status code of a cross-origin request. That is a hard constraint of the web, not a design choice, and any tool claiming to check external links purely in your browser is describing something browsers do not permit.

Writers and site owners typically reach for this after publishing a long reference post, inheriting a site from someone else, or finishing a migration. Editors running an archive check it against old posts where outbound sources have quietly disappeared. Developers use it as a fast pre-deploy sanity pass on a template or landing page before it ships.

How ToolsPivot Broken Link Checker Works

Paste a page URL. Enter the full address of the single page you want scanned, including the protocol. Private and reserved IP ranges are refused for security reasons.
Pick a scope. Choose All links, Internal only, or External only from the dropdown before you run the scan.
Run the check. The page HTML is fetched with a real browser User-Agent, links are extracted, and each one is probed at bounded concurrency with a per-host throttle so you do not hammer any single server.
Read the verdict. A banner tells you the broken count or confirms the page is healthy, and five stat tiles show Total, Broken, Blocked, Redirects, and Working.
Filter and investigate. Click any tile to filter the results table, then read the anchor text and redirect target for each row to find the exact element in your content.
Recheck or export. Retest any single row on demand, or download the full table as CSV to hand to a developer or work through offline.

The Four Result Buckets, Explained

Most link checkers classify results as broken or not broken, which forces every ambiguous response into one of those two boxes. This tool uses four buckets, and the third one is the reason the report is worth trusting.

Bucket	Statuses	What it means
Working	2xx	The link resolved normally. No action needed.
Redirect	3xx	It resolves, but only after one or more hops. The final URL and hop count are shown.
Blocked (may be fine)	401, 403, 429, 999	The server refused an automated request. It very often works in a real browser.
Broken	404, 410, 5xx, DNS, timeout, SSL	Genuinely failing. This is your fix list.

The Blocked bucket exists because a 403 or a 429 does not mean a page is gone. It means a bot filter, a rate limiter, or a login wall got in the way. LinkedIn returns a nonstandard 999 for exactly this purpose, and Cloudflare commonly answers automated traffic with a 403. Pew Research Center hit the same wall in its 2024 link rot study and handled it the same way, counting a page as inaccessible only when it returned one of nine error codes that definitively indicate the page or its host no longer exists. Conservative classification is what serious research does, and it is what this tool does by default.

Key Benefits

You stop deleting good links. Blocked responses are separated from broken ones, so a working LinkedIn profile never lands on your delete list.
Fewer false positives at the source. Each probe starts as a HEAD request and retries as GET when a server rejects HEAD, which removes a common cause of phantom failures.
Every result is actionable. Anchor text tells you where the link sits in your copy, so you are not scrolling a page hunting for a bare URL.
Redirect chains become visible. Seeing the final destination and hop count lets you point links directly at the endpoint and skip the intermediate hops.
Images are checked too. A missing image is a broken link that most people never audit, and it damages a page visibly.
Soft 404s get caught. Pages that answer 200 while displaying an error message are flagged rather than counted as healthy.
No account, no paywall. CSV export and per-link recheck are available without signing up, and the interface runs in 18 languages.

Core Features

HEAD to GET fallback. Servers that reject HEAD requests get a GET retry automatically, so a quirk of server configuration is not mistaken for a dead page.
Realistic request headers. Probes send a genuine browser User-Agent, which avoids the crudest bot blocks without pretending to defeat serious protection.
Anchor text capture. The clickable text for each link appears in the results table alongside the URL.
Redirect chain resolution. Final destination and hop count are recorded for every 3xx response.
Image source checking. Every on the page is probed alongside the anchors.
Soft 404 detection. For working page links, a slice of the response body is fetched and its title and headings are scanned for not-found phrasing.
Occurrence counting. Duplicate links are collapsed into one row with a count, so a template link repeated 30 times does not flood the table.
Internal and external split. Results are tagged by host and can be filtered to just one side before you scan.
Clickable stat tiles. The five summary counters double as filters for the results table.
Per-link recheck. Any single row can be retested without rerunning the whole scan, which is useful for transient 5xx and 429 responses.
CSV export. Download the complete table for triage in a spreadsheet or handoff to a developer.
SSRF protection. Requests to private and reserved IP ranges are refused, and connections are pinned to a validated public address.

When to Use It

Reach for a link check whenever the pages a link points to might have changed without you noticing. Link rot is steady rather than dramatic. Pew Research Center found that a quarter of all webpages existing at some point between 2013 and 2023 were gone by October 2023, and that 23% of news pages and 21% of government pages carried at least one broken link.

After publishing a reference post. Long resource pages carry dozens of outbound links, and a single typo in one href is easy to miss in review.

Before a page goes live. Scanning a staging URL catches placeholder hrefs and half-finished links before visitors see them.

Right after a migration. URL restructures break internal links in bulk, and pairing this with a www redirect check confirms your canonical host resolves the way you intended.
When auditing an old archive. Posts more than a few years old accumulate dead outbound sources faster than most people expect.
During a competitor teardown. Finding 404s on someone else's resource page is the starting point for broken link outreach, and a backlink check shows whether those dead pages still attract links worth reclaiming.
When redirect chains creep in. Chains cost real load time, which a page speed check will show you in milliseconds.
Before submitting a page for indexing. Confirm the page is clean, then verify it is actually indexed with an index checker.

Real-World Use Cases

Cleaning up an inherited blog

An agency takes over a client site with 400 published posts and no maintenance history. Scanning the highest-traffic posts one at a time surfaces which outbound sources have vanished and which merely block bots. The anchor text column makes each fix a find-and-replace rather than a hunt, and the CSV export becomes the ticket list handed to the content team.

Post-migration verification

A site moves from a dated CMS to a new platform and the URL structure changes. A scan of the homepage and each main category page catches internal links still pointing at the old paths. Once those are fixed, regenerating an XML sitemap and reviewing the robots.txt rules makes sure crawlers are pointed at the new addresses rather than the retired ones.

Debugging a stubborn result

A link keeps landing in the Broken bucket with an SSL error while it loads fine in a browser. Checking the certificate with an SSL checker usually reveals an incomplete chain that browsers paper over and automated clients do not. If the failure is a 5xx instead, a server status check confirms whether the host is down for everyone or just refusing this one request.

Verifying the Blocked list by hand

A scan returns 14 blocked links. Rather than trust or dismiss them wholesale, you export the CSV, paste the URLs into a bulk URL opener, and confirm in tabs which genuinely load. Most will. The handful that do not move to your fix list with evidence behind them.

How to Fix Each Result Type

The right response depends on the bucket, and treating all four the same is how sites end up worse after an audit than before it.

Broken internal links are yours to fix directly. If the destination moved, add a 301 to the new address. If it was deleted and a close equivalent exists, redirect there. If nothing replaces it, remove the link and edit the surrounding sentence so it still reads properly.

Broken external links usually need a replacement rather than a redirect. Search the same domain for the moved page first, since publishers often relocate content without redirects. If the site is gone entirely, swap in a different source or unlink the text and keep the wording.

Redirects are not errors, and a single hop is fine. Update the href to the final URL when a chain runs two or more hops deep, and check the raw response with an HTTP header tool if you need to confirm whether each hop is a 301 or a 302.

Blocked links need a human. Open them in a browser and confirm. If a page loads normally, the link is fine and nothing needs changing.

Honest Limitations

Knowing what the ToolsPivot scan does not do matters as much as knowing what it does.

It checks one page, not a whole site. There is no site-wide crawl. To cover a site, run the pages that matter most individually, or use a full site SEO audit for broader coverage.
It reads raw HTML only. Links injected by JavaScript after page load are invisible to it. A spider simulator shows you the same raw source a crawler sees, which is a good way to confirm whether your links are in the HTML at all.
Checks run from one IP address. A server that blocks that address will return a Blocked result even though the link works for your visitors.
Blocked is genuinely ambiguous. The bucket is honest about uncertainty rather than resolving it. Confirming those links is manual work.
Soft 404 detection is heuristic. It matches not-found phrasing in titles and headings, so an unusually worded error page can slip through.
Results cache briefly per URL. Immediately after you fix something, use the per-link recheck rather than expecting a fresh full scan.
It does not read link quality. Whether a working link points somewhere worth linking to is a separate question, and a link analyzer is the better tool for that.

Frequently Asked Questions

What is a broken link?

A broken link is a hyperlink whose destination cannot be loaded. The most common cause is a deleted or moved page returning a 404, but DNS failures, server errors, and expired SSL certificates break links the same way.

Is the ToolsPivot Broken Link Checker free?

Yes, with no account and no paywalled features. CSV export, per-link recheck, image checking, and soft 404 detection are all included.

Why do some working links show as blocked?

Because the destination server refused an automated request rather than confirming the page is gone. LinkedIn returns a 999 status specifically to stop scanners, and Cloudflare-protected sites frequently answer bots with a 403.

Does this tool crawl my entire website?

No. It checks the links on one page at a time. Scan your most important pages individually rather than expecting site-wide coverage.

How do broken links affect SEO?

Dead internal links waste crawl requests and stop link equity from reaching the destination page. Dead outbound links mostly signal a page nobody maintains, which matters more for reader trust than for rankings directly.

What is the difference between a 404 and a 410?

A 404 means the page was not found and might return. A 410 means it was deliberately removed and will not, which search engines act on faster.

Does it check images as well as links?

Yes. Every image source on the page is probed alongside the anchor links, so missing images appear in the same results table.

What is a soft 404?

A soft 404 is a page that returns a 200 success status while showing an error message to visitors. The tool checks the title and headings of working page links for not-found phrasing to catch these.

Why does a link work in my browser but fail here?

Your browser carries cookies, a session, and a full browser fingerprint that an automated request does not. This is exactly what the Blocked bucket is for, and it is why those results are not counted as broken.

How often should I check for broken links?

Quarterly is enough for most pages, and monthly suits sites that publish often or link heavily to external sources. Always check immediately after a migration or URL restructure.

Can it check links inside PDFs or JavaScript?

No. It parses raw HTML, so links inside PDF files or injected by JavaScript after page load are not seen. A link to a PDF is checked, but the contents of that PDF are not.

What should I do about redirect chains?

Update the href to point at the final destination when a chain runs two or more hops. Single redirects are normal and rarely worth changing.