Broken Link Checker (Cached) Free Tool

Paste your links one full URL per line. The tool checks each one and flags any broken link — a page that returns an error (status 400–599) or does not respond at all. Recently checked URLs are cached for one hour, so re-running the same list is near-instant and does not hammer the target sites.

Enter one URL per line

About Broken Link Checker (Cached)

What Counts as a Broken Link

A broken link is a link that no longer takes a visitor (or a search engine crawler) to a working page. That sounds obvious until you try to define it precisely, because "doesn't work" actually covers several distinct failure types, and knowing which one you're looking at usually tells you how to fix it.

• 4xx client errors. The most familiar case: a 404 Not Found means the server is reachable and responded, but has nothing at that specific address. A 410 Gone is a more deliberate version of the same thing: the server is explicitly saying the page used to exist and was intentionally removed. A 403 Forbidden means the server is reachable but is refusing the request outright (worth a closer look, see the "isn't the whole story" section below, because this one doesn't always mean the page is actually dead).
• 5xx server errors. A 500 Internal Server Error, 502 Bad Gateway, or 503 Service Unavailable means the destination server itself is having a problem: misconfigured, overloaded, or mid-outage. These can be temporary, which is exactly why a link checker with caching (see below) is useful for re-checking later rather than treating one failed request as final.
• DNS failures. The domain itself doesn't resolve to any server at all, often because a domain expired, was never renewed, or the target site shut down entirely and let the registration lapse. There's no HTTP status code here because the request never even reaches a server to respond.
• Timeouts and no response. The server exists and the domain resolves, but nothing comes back within a reasonable wait: the connection hangs, gets refused, or drops. Functionally identical to a dead link from a visitor's point of view, even though the underlying cause (an overloaded server, a firewall silently dropping the connection, a misconfigured host) is different from a clean 404.

What all four have in common is the practical outcome: a real visitor who clicks that link gets nothing useful, and a crawler that follows it hits a dead end instead of a page it can index. That shared outcome is why a broken-link checker groups all four under one "broken" label, even though the underlying causes are quite different from each other.

Broken Link vs. Working Redirect: Why the Distinction Matters

A redirect is not a broken link, even though the raw HTTP response in transit is technically a 3xx status code (the same numeric family that sits right next to the 4xx/5xx errors above). The difference is what happens next: a redirect points to a new destination and, when it's set up correctly, that destination loads successfully. A visitor following a 301 redirect from an old URL to its new location gets exactly what they were looking for, just from a slightly different address. Nothing is broken about that.

This is exactly why a link checker that's actually useful needs to follow redirects to their final destination before deciding whether a link is broken, rather than stopping at the first response it sees. A tool that flagged every 301 or 302 as "broken" would bury real, actionable problems under a flood of false positives: every legitimately redirected URL on a normal, well-maintained site would show up as an error, and nobody could tell the genuine dead links apart from the noise. The status that matters is the one at the end of the chain, after every hop has been followed, not the first hop a request happens to land on.

Where this gets murkier is a redirect chain that never actually resolves, one that loops back on itself, or that exceeds a reasonable number of hops before giving up. That's a distinct problem from either a clean redirect or a clean broken link, and it deserves its own dedicated check rather than being folded into either category. If you suspect a specific URL is looping or chaining through more hops than it should, the Redirect Chain Checker traces the full hop-by-hop path for a single URL and shows you exactly where it stalls, which is a more useful view for that specific problem than a broken-link scan run across a whole list.

HTTP Status Codes at a Glance

A quick reference for the status code families you'll actually see in your results, and how this tool judges each one:

This table describes the general meaning of each status family, independent of any specific tool. The "Reading Your Results" section further down explains what this particular tool's own output columns and badges mean once you've run a check, a related but different question from what a status code means in general.

Why Broken Links Hurt SEO and User Experience

None of the individual effects below sink a site on their own from a single dead link buried on a low-traffic page. The real cost shows up cumulatively, across a site that's accumulated dozens or hundreds of them over years of content changes without anyone auditing the links.

Wasted Crawl Budget on Dead Ends

Search engine crawlers allocate a limited amount of attention to any given site, generally described as crawl budget. Every time a crawler follows a link and hits a 404, 5xx error, or timeout, it's spent part of that budget on a dead end instead of discovering or re-indexing a page that actually exists and matters. This is a bigger deal on larger sites, where crawl budget is a genuine constraint, but even a modest site benefits from a clean link graph: fewer dead ends means crawlers spend more of their limited visits on pages worth indexing.

A Poor Experience for Real Visitors

A visitor who clicks a link expecting content and lands on an error page forms an immediate, negative impression, of that specific page, and often of the site's overall credibility. This matters most on internal links, where the visitor was following your own site's navigation and trust, but it also matters for outbound links: a reference or citation link that goes nowhere undermines the credibility of the content that pointed to it, even though the failure is technically on the other site.

Lost Internal Link Equity When the Dead Link Is Your Own

When a broken link points to a page on your own site that's been deleted or moved without a redirect, you lose more than a working link: you lose whatever internal link equity was flowing to that page through every link that pointed at it. If several other pages on your site all linked to that now-dead URL, all of that accumulated internal linking signal is currently going nowhere instead of reinforcing a page that could still be earning it, whether that's the original page (restored) or its closest live replacement (via a redirect).

Common Causes of Broken Links

Almost nobody breaks a link on purpose. They accumulate as a natural side effect of how content, sites, and the web at large change over time. The most common real-world sources:

• Pages deleted without a redirect. Someone removes an old page (an outdated product, a retired promotion, a duplicate post cleaned up during a content audit) and nothing is put in its place to catch visitors and crawlers who still arrive via an old link.
• Typos in manually-typed URLs. A single mistyped character in a hand-entered link (an extra letter, a wrong file extension, a missing slash) produces a URL that was never valid in the first place, distinct from a link that used to work and stopped.
• External sites going offline or restructuring. You don't control the sites you link out to. A source you cited, a tool you referenced, or a resource you pointed readers to can shut down, get redesigned with a new URL structure, or simply reorganize its own content without leaving a redirect behind, and there's no way to know until you check.
• Site migrations that miss some old paths. Moving to a new CMS, changing a URL structure, or switching domains is one of the single largest sources of broken links at scale, because a redirect map built during migration planning rarely covers every single old URL perfectly. A handful of edge cases, such as old query-string variants, deep archive pages, or rarely-linked assets, commonly get missed.
• Expired domains and DNS issues on the target site. A domain you linked to years ago can simply expire and stop resolving if its owner didn't renew it, or a target site's DNS configuration can break independently of anything about the specific page you linked to. From your side, both look identical to a link that's gone dead.

How Often to Check for Broken Links

There's no single correct frequency, but a few practical triggers cover most real situations. Right after a site migration, a URL structure change, or a bulk content deletion is the single highest-value time to run a check, since that's when the largest batch of broken links gets introduced all at once, and catching it early means fixing dozens of links in one pass instead of discovering them one at a time over the following months. Older, evergreen content is worth a periodic re-check on its own schedule, separate from anything you're actively editing, precisely because link rot on a page you haven't touched in a year or two is invisible until someone checks: the content itself hasn't changed, but the sites it links out to have kept moving, restructuring, and occasionally disappearing entirely, so a page can accumulate a handful of dead outbound links without a single edit ever being made to it.

A practical middle ground for most sites is a quarterly pass across the highest-traffic and highest-value pages, plus an immediate check any time a page is substantially edited or a site-wide change goes out. There's no need to re-check a page's links every single week; broken links accumulate slowly enough that infrequent, deliberate passes catch the overwhelming majority of them before they've had time to meaningfully hurt crawl efficiency or visitor experience, and the 1-hour cache described next means re-running the same list of pages on a recurring schedule stays fast even as your list of pages to check grows over time.

Why This Tool Caches Results

Checking a link means making a real network request to the destination server and waiting for a response. Do that for every single URL on every single run, and two things get worse than they need to be. First, it's slow: a list of a hundred or more links, each with a multi-second network round trip, adds up to real wait time on every check, even when most of those links haven't changed since the last time you looked. Second, and more importantly, repeatedly hitting the same external targets in a short window can look like abusive or bot-like traffic to some of the sites on the receiving end, especially smaller sites without much server capacity to spare, which is not the impression you want to leave on a site you're trying to check in good faith.

A short-lived cache is the practical answer to both problems. This tool caches each URL's checked status for one hour. Re-run the same list of links again within that hour (after fixing a few of them, for instance) and anything unchanged is served instantly from the cache instead of triggering a fresh network request, while a URL you've just fixed and want to confirm still gets a genuinely fresh check once its cache entry ages past the hour mark (or you can simply wait it out; there's no manual cache-bypass option, which is a deliberate simplicity tradeoff, not an oversight).

The expiry itself is handled lazily rather than through some background cleanup process: nothing proactively deletes old cache entries on a schedule. Instead, whenever a URL is looked up, the tool checks the timestamp on its cached entry, and if that entry is older than one hour, it's simply treated as if it didn't exist: a fresh check runs, and the result overwrites the stale entry. This is a small implementation detail, but it's worth knowing: it means a URL you haven't checked in weeks doesn't carry a stale week-old cache forward. The very next time you check it, it's a genuinely fresh result, because anything past the one-hour window is functionally the same as never having been cached at all.

How the Broken Link Checker (Cached) Works

Paste your list into the box above, one URL per line, up to 2,000 non-empty lines per submission. Every line is validated as a real, well-formed http:// or https:// URL before anything else happens. A line that isn't a valid URL at all (a bare domain with no scheme, a typo, a stray note copied in by accident) is skipped entirely, counted separately, and never sent out as a network request.

Once the valid lines are identified, duplicates are removed by comparing a normalized form of each URL (lowercased, trimmed of surrounding whitespace, with any trailing slash stripped) so that two lines pointing at what's functionally the same address are checked only once, keeping the first-seen original form for display in your results. Only the first 150 distinct valid URLs are actually checked in a single run; if your deduplicated list is larger than that, the results will note that the list was truncated and only the first 150 were processed. For a larger list, running it in a couple of batches gets everything checked.

Each check starts with a lightweight HEAD request, asking the server only for the response headers, not the full page content, which is faster and lighter on the target server than downloading the whole page just to read its status code. If a server rejects the HEAD request outright or simply doesn't respond to it (some servers are configured to reject HEAD requests specifically, even though they handle a normal page load fine), the tool automatically retries with a small ranged GET request instead, pulling only the first couple of kilobytes rather than the entire page. Redirects are followed automatically, up to five hops, and it's the status at the end of that chain that determines whether the link is judged broken or OK. Each request waits up to ten seconds for a response before giving up and recording it as no response at all.

How to Use This Tool

This is the literal step-by-step process for running a check, separate from the technical explanation above of what happens once you submit your list.

1. Gather the list of URLs you want to check. This could be a sitemap export, an old redirect map you're auditing, the outbound citation links in a specific article, or a spreadsheet of affiliate/partner links — anywhere you already have a set of URLs written down.
2. Format your list as one full URL per line, including the http:// or https:// scheme on each one. Bare domains or partial paths without a scheme won't validate.
3. Paste your full list into the text box at the top of this page.
4. Complete the verification step if one is shown, then submit the form.
5. Read the summary line at the top of your results: how many links were checked, how long it took, and how many came back broken versus OK.
6. Scroll down to the results table and look for anything marked Broken in the Result column — that's your action list.
7. For each link marked Broken, check its status code against the "When 'Broken' Isn't the Whole Story" section below before assuming it's truly dead, especially for a 403 or an unusually fast no-response result.
8. After fixing the genuine problems, paste the same list back in later to confirm the fixes worked — anything checked within the last hour will come back instantly from cache, and anything fixed since your last run will show a fresh, updated result.

Reading Your Results

Each part of the output answers a slightly different question about the specific run you just submitted:

This table is about what this specific tool's own output columns and badges mean, once you've actually run a check — a related but different question from the general HTTP-status-code reference earlier on this page, which explains what each status range means independent of any particular tool.

When "Broken" Isn't the Whole Story

An automated status check is a fast, reliable first pass, but it's not the final word on every result, and a small number of cases are worth a manual look before you act.

• A 403 might mean the site is blocking automated checkers, not that the page is gone. Some sites deliberately reject requests that look like they're coming from a bot or script, even a well-behaved one, while serving the same page normally to an actual browser. If a link comes back 403, open it in a real browser tab before assuming it's dead — there's a real chance it loads just fine for a human visitor.
• A soft-404 can come back as a 200. Some sites are configured to show a "page not found"-style message to visitors while still returning a technically successful 200 status code to any automated check, rather than the correct 404. An automated checker has no way to read the visible page content and recognize this — it can only see the status code returned, which is why an occasional manual spot-check on links that "pass" but seem suspicious (an oddly generic or unfamiliar-looking destination) is worth doing on your highest-value links.
• Anti-bot protection can produce a false broken result. Some sites run protection services that challenge unfamiliar or automated-looking traffic before letting a request through to the actual page — which can return a non-200 status to an automated checker even though the underlying page is perfectly healthy for real visitors. This is a real limitation of any automated link-checking tool, not specific to this one, and it's the main reason a quick manual look at anything unexpected is worth the extra minute before you remove or redirect a link.

None of this means the automated results aren't useful — the overwhelming majority of genuinely broken links (deleted pages, expired domains, real 404s and 5xx errors) show up exactly as broken, correctly, with no ambiguity at all. It just means the small handful of edge cases above are worth a manual glance before you make a change based on the result.

How to Fix Broken Links Once You Find Them

• Redirect to the closest live equivalent. If the content that used to live at the broken URL has a clear, current replacement — an updated version of the same guide, the current page for the same product, the same article under a new URL after a migration — a redirect is usually the best fix. It preserves whatever value (traffic, internal links, external backlinks) the old URL had accumulated, pointing it at something still useful instead of a dead end.
• Remove the dead link entirely. If there's no reasonable live equivalent — the source it pointed to is genuinely gone with nothing similar to replace it — the honest fix is often to simply remove the link (and, if it's an outbound reference, consider whether the surrounding sentence needs a rewrite so it doesn't read strangely without it) rather than leave a dead link in place or redirect to something only loosely related.
• Replace with an archive.org link as a last resort. When a source is gone for good but the specific content it contained is still relevant to what you wrote — a statistic, a quote, a resource you cited — the Wayback Machine at web.archive.org often has a snapshot of the original page. Linking to that snapshot preserves the reference for readers even though the live version no longer exists, though it's worth noting this isn't as good an experience as a working, current source, so it's a fallback rather than a first choice.
• Re-run the checker after fixing. Once you've redirected, removed, or replaced the broken links you found, paste the same list back in later to confirm the fixes actually resolved the problem rather than assuming they did.

One quick note on scope: this tool checks a list of URLs you already have in hand. If instead you want to discover every link on a single specific page — crawling that page's HTML to find every outbound link automatically, rather than checking a list you've already compiled — the site's separate Broken Links Checker tool does that page-crawl job instead; the two are built for different starting points, not different definitions of "broken."

Related Tools

• Redirect Chain Checker — when a URL isn't broken but seems to redirect through more hops than expected, or you suspect a redirect loop, this traces the full hop-by-hop path for a single URL so you can see exactly where it stalls.
• Website Links Counter — a useful before/after companion: count how many links are on a page before you start a cleanup pass, then again afterward to confirm how many you actually removed or fixed.
• Orphan Page Finder — after removing a broken internal link outright (rather than redirecting it), it's worth checking whether the page it used to point to has become an orphan with no other internal links pointing to it anymore.

Frequently Asked Questions

Does this tool crawl my whole website automatically?

No. You paste in the specific list of URLs you want checked — up to 2,000 lines, with the first 150 distinct valid ones actually checked per run. It doesn't discover URLs on its own or crawl a site's navigation to find links; see "How the Broken Link Checker (Cached) Works" above for exactly what happens with your pasted list.

Why does the tool say a link is fine when I know the page shows an error?

That's most likely a soft-404 — a page that returns a technically successful 200 status while still displaying a "not found"-style message to visitors. See "When 'Broken' Isn't the Whole Story" above; an automated status check can only see the status code, not the visible page content.

How long does a cached result stay valid?

One hour. After that, the next time you check that same URL, the cached entry is treated as expired and a genuinely fresh check runs automatically — see "Why This Tool Caches Results" above for the full explanation, including how the lazy expiry works.

What's the difference between this tool and the site's other Broken Links Checker?

This tool checks a list of URLs you already have, one per line, with results cached for an hour. The other Broken Links Checker tool instead crawls a single page you give it and finds every link on that page automatically. Use this one when you already have a list; use that one when you want a specific page's own links discovered for you.

Can I check more than 150 links at once?

Not in a single run — 150 distinct valid URLs is the per-run cap, and a truncation note appears in your results if your list had more. Paste in the remaining links as a second (or third) batch to check the rest.

Do redirects count as broken links?

No, as long as the redirect actually resolves to a working page — see "Broken Link vs. Working Redirect" above. The tool follows redirects up to 5 hops and judges the status at the final destination, not the first hop.