Skip to main content

Broken Link Checker

What it does

The Broken Link Checker fetches a URL, extracts every <a href> link from the page, and HEAD-checks up to 50 destinations to verify they return 2xx. Results are reported per link with status code, anchor text, and response time. A summary shows the count of OK, redirected, broken, and unreachable destinations.

Common situations

You are auditing a long-form article that has been live for years and want to confirm the external citations are still alive. Drop the URL in; the checker reports broken external links in seconds. Old articles often have dead citations because external sites move or disappear.

A page has been receiving complaints about “broken links” without specifics. Run the checker; the broken links list tells you exactly which links to fix or remove.

You are migrating a site and want to verify that internal links updated correctly to point at new URLs. The checker shows the status of each link — if the migration left old internal links pointing at retired URLs, the broken-links count surfaces it.

A new piece of content has been written and links to several external sources. Verify each one returns 200 before publishing. Bad citations are an embarrassment that’s easy to prevent.

You suspect a CMS is generating broken links — typically when content is imported from an old system and inline links retain the old paths. The checker gives a count of broken links per page so you can prioritise which content needs cleaning up first.

What you need to know

The checker works in two stages. First, it fetches the page and parses the HTML to extract every <a href> link. Then it sends HEAD requests to each link (capped at 50 to keep the operation fast and stay within fetch budgets) and reports the status.

What gets checked:

  • Internal links to the same domain.
  • External links to other domains.
  • Anchor links (#section) — skipped, since these don’t make HTTP requests.
  • Mailto / tel — skipped, not HTTP.
  • JavaScript URLs (javascript:) — skipped.

What’s reported per link:

  • HTTP status: 200 (OK), 301/302 (redirect, follows automatically), 404 (broken), 5xx (server error), 0 (network error or timeout).
  • Final URL after redirects, where applicable.
  • Response time.
  • Anchor text for context.

What gets flagged:

  • Broken (4xx, 5xx, network error): the link doesn’t resolve.
  • Slow (5+ seconds): not technically broken but degraded UX.
  • Redirect chain (multiple redirects): the link works but inefficient.

The 50-link cap is intentional — pages with hundreds of links would either slow the tool considerably or push past acceptable fetch volumes. For pages with more links, run the checker on the first 50 (typically the most-trafficked ones) and use the WP Beacon Plugin for site-wide ongoing monitoring.

The checker uses HEAD requests (which fetch only headers, not body) by default for speed. Some servers reject HEAD; the checker falls back to a small GET request automatically when this happens.

Frequently asked questions

Does the checker follow redirects?

Yes. A 301 or 302 is followed automatically; the final URL and status are reported. A redirect that ultimately lands on a 200 is counted as OK. A redirect chain ending in a 404 is counted as broken.

What’s the difference between a 404 and a network error?

404 means “the server is up and explicitly says this URL doesn’t exist”. Network error (status 0) means “the server didn’t respond at all” — could be DNS failure, connection refused, or timeout. Both are broken from the user’s perspective.

Why are some links reported as broken when they work in my browser?

Several causes. The destination might be blocking bot traffic via user-agent or IP rules; the destination might require cookies the checker doesn’t send; or the destination might be intermittently unreachable due to load. Verify by visiting the URL with a regular browser — if it works there, the destination is fine but bot-restricted.

How long does a broken-links check take?

For 50 links, typically 30-60 seconds. Each link gets a HEAD request with a 6-second timeout, run in parallel. Network conditions and destination responsiveness affect total time.

Does the checker count rel=nofollow links?

Yes — nofollow is an SEO attribute, not a “skip this link” instruction. Broken nofollow links are still broken from the user’s perspective.

What about images and other resources?

Not checked — only <a href> links. For broken images and other resources, the page audit reports image dimensions and HTTP status as part of its overall report.

Why HEAD instead of GET?

HEAD requests fetch only the response headers, not the body. They’re faster and cheaper than full GETs, especially for large pages. Some servers reject HEAD with 405; the checker falls back to GET in that case.

Does the checker affect rate limits at the destination?

Each destination URL gets at most one or two requests during a single check run. For most sites, this is well within their rate limits. Aggressive sites might block bot traffic regardless; in that case the link reports as broken even though it works for users.

Common problems

Problem: Many internal links report 404 but I haven’t deleted any pages.

The internal links may have stale URL formats — old WordPress post IDs after a permalink change, retired path structures, or links to staging-only URLs. Spot-check a few; the pattern is usually consistent.

Problem: External links to a known-good site report broken.

The destination is blocking bot user-agents. Verify by visiting in browser. Fix is on the destination side (their bot policy), not yours; if it matters, contact them.

Problem: Checker times out before finishing.

The page has many links and several are very slow. The 50-link cap is the working maximum; sites with hundreds of links per page will hit the cap. For broader auditing, the WP Beacon Plugin crawls the whole site systematically.

Problem: Reports redirect chain on a link that should be direct.

The destination has its own redirect logic — HTTP-to-HTTPS, www normalisation. The link itself is fine; the destination just has a chain of its own.

Problem: All links report broken even on a known-good page.

Network or DNS issue between our infrastructure and the destinations. Try again in a few minutes; if persistent, the issue is our side, not yours.

Tips

  • Run the checker on the most-trafficked URLs first. Broken links matter most where users encounter them most.
  • Old articles drift — external citations decay over time. Run the checker on evergreen content periodically (every 6-12 months).
  • A 301 redirect is not a broken link, but a chain over 3 hops is worth fixing. The status report tells you which.
  • For wildcards-affected URLs (filter pages, archive URLs), the broken-link rate is often artificially high because the destinations themselves are low-quality. Audit content URLs first.
  • Don’t fix broken links by removing them. The replacement is usually finding an updated URL or an equivalent destination — silently dropping citations weakens the article.

Related tools in this suite

The Internal Link Audit is the inventory side — what links does the page have? — while this is the validation side — do they work? Run them together for the full picture. The Page SEO Audit summarises link counts as part of its overall report.

What this looks like at scale

For a single page, the checker is fine. For a content set, broken-link auditing becomes a continuous monitoring job — links that work today break tomorrow as external sites change. The WP Beacon Plugin crawls every page on every visit and flags newly-broken links so you find them before users do.

Take it further

If a content set has many broken links surfaced by an audit, the right next step is sometimes a structured cleanup — replacement URLs for valuable citations, removal of broken links to retired sources. Talk through the audit and we can scope the cleanup.