Broken Link Checker

Server assisted New Website & HTTP Diagnostics

The Mutqan server fetches the page, extracts its http(s) links in document order — all of them, or only internal or external ones — and requests as many as your per-minute allowance permits: at most 30, currently 9 per check when you are not signed in and 29 when you are. Each link gets a HEAD request, or a GET when the server does not support HEAD, without following redirects. The result lists broken links (4xx and 5xx) first, then links that gave no answer, redirects with their targets, and the links that work, with status and response time.

Privacy: The Mutqan server sends the small, fixed test requests described on this page to the host you name, and nothing is stored. Use it only against systems you are authorised to test.
Loading tool…

How are a page's links found and checked?

A link is an a (or area) element whose href resolves, against the page URL or its base element, to an absolute URL; crawlers discover pages through exactly these links, not through buttons or script code. A link is checked by requesting its URL and reading the status: 2xx works, 3xx moves elsewhere, and 4xx or 5xx is broken — though 401, 403 and 429 often mean the server refused an automated client rather than that the page is gone.

How to use Broken Link Checker

  1. Enter the URL of the page whose links you want to check.
  2. Choose all, internal or external links, and how many to check (up to 30; the server checks at most 9 per run when you are not signed in and 29 when you are).
  3. Press Check links and wait — the server requests the links four at a time, within about 20 seconds.
  4. Fix or remove the Broken links, check the No answer rows in a browser, and point redirected links at their final URL.

Broken Link Checker features

  • The Mutqan server fetches the page, extracts its http(s) links and requests them in page order: at most 30 per check, currently 9 when you are not signed in and 29 when you are
  • Each link gets a HEAD request, or a GET when the server answers HEAD with 405 or 501; the body is never downloaded
  • Redirects are not followed but reported with their target, so a moved link is told apart from a broken one
  • Broken links (4xx and 5xx) are listed first, then links with no answer (timeout, unknown host, refused address), redirects and working links
  • Shows each link's status code, response time, anchor text and internal or external type, downloadable as CSV
  • Spends the link requests you have where you need them: all links, internal only or external only
  • Flags answers that usually mean "automated client refused" (401, 403, 429, 999) rather than a dead link

Inputs and outputs

Inputs

  • Page URL — the public page whose links are checked; it is fetched by the Mutqan server.
  • Links to check — all links, internal only (same registrable domain, by the Public Suffix List) or external only.
  • Maximum links to check — 1 to 30, in document order. The server may check fewer — 9 per check when you are not signed in, 29 when you are — and counts the rest as not checked.

Outputs

  • Summary — links found, checked and not checked, and the OK, Broken, Redirected and No answer counts.
  • Link check — every checked link with URL, status, result, redirect target, time, link text and type; broken first; downloadable as link-check.csv.
  • Findings — what to fix, what to verify by hand, and why links were skipped when they were.
  • Checked page — the page URL, the final URL after redirects and its HTTP status.

Broken Link Checker example

A blog post with a dead guide link

Input:

https://www.example.com/blog/post · Links to check: All links · Maximum: 30

Output:

Links found 6 · Checked 6 · Not checked 0 · OK 2 · Broken 2 · Redirected 1 · No answer 1
https://www.example.com/guides/old-guide — 404 — Broken
https://www.linkedin.com/company/example — 999 — Broken
https://partner.example.net/offer — Timed out
https://www.example.com/pricing — 301 — Redirect → https://www.example.com/plans
Findings: 2 links answer with an error (4xx or 5xx): fix or remove them. · Some links answered 401, 403, 429 or 999: many sites refuse automated requests from data-centre addresses, so open these in a browser before calling them broken.

How to read the Broken Link Checker results

Broken with 404 or 410: the target is gone — update or remove the link. 500–599: the target's server is failing; check again later before removing it.

Broken with 401, 403, 429 or 999: often the target refusing automated clients, not a dead page. Open it in a browser before acting.

Redirect: the link works but takes a detour. Point it at the URL in "Redirects to" — especially for internal links, which you control.

Timed out, Host not found or Connection failed: the request got no answer from the Mutqan server. The host may be down, slow or blocking data-centre traffic; a host that is not found usually means a mistyped or expired domain.

When to use Broken Link Checker

  • Check an article, a documentation page or a landing page for dead links before and after publishing.
  • Find links that still point at old URLs after a migration and now redirect.
  • Review the external references of a long-lived page for link rot.
  • Verify a navigation or footer change did not break internal links.

Troubleshooting

  • "You have reached the request limit": link checks are limited to 10 per 10 minutes per IP address. Wait and try again; the limit protects the sites being checked.
  • Fewer links checked than found, with a note: each check is sized to your per-minute allowance for link requests — currently 9 links when you are not signed in, 29 when you are — and a check earlier in the same minute has used part of it. The note says how many were skipped; sign in, run the check again a minute later, or narrow it to internal or external links.
  • Checked 0 and a warning that no link was checked: the allowance was already spent by an earlier check, or the server was busy. The findings give the wait in seconds, and Checked page shows it as Try again after.
  • Links found is 0: with internal or external links only, the page may simply have no links of that type, so choose All links. With All links, the page builds its links with JavaScript, or the URL returned an error or a non-HTML file; open the page source in a browser to see what the server sends.
  • Many 403 answers from one site: that site blocks automated requests. Verify those links manually.

Frequently asked questions about Broken Link Checker

How many links does one check cover?

At most 30, and often fewer. Every link is a request the Mutqan server sends in its own name, so each check is sized to your per-minute allowance for link requests: currently 9 links when you are not signed in and 29 when you are, after one request for the page itself. A second check within the same minute draws on the same allowance and may check fewer links or none; people who share your IP address also share a per-address allowance. The result's note says how many links were skipped and when to try again, and each IP address may run 10 checks per 10 minutes. For a whole site, run it page by page or use a crawler you operate yourself.

Is a redirect counted as broken?

No. Redirects are not followed: a 301, 302, 307 or 308 is reported as Redirect with its target, because the link still leads somewhere. Updating it to the final URL saves visitors and crawlers a round trip. Only 4xx and 5xx answers count as broken.

A link works in my browser but shows 403 or 429 here. Why?

Many sites refuse requests from data-centre addresses or from clients that are not browsers, and some rate-limit them. Those answers are reported as they came, with a note — open the link in a browser before deciding it is broken. 999 is LinkedIn's usual answer to automated requests.

Which links are checked?

The http(s) a and area links in the HTML the server sends, in document order, without duplicates, #anchors, mailto:, tel: or the page itself. Links built by JavaScript are not seen. Choose internal or external only to spend the link requests you have where you need them.

Why is a link "Not checked (address refused)"?

Its host resolves to a private, loopback or reserved address, or uses a port the Mutqan server may not contact. Such links (intranet pages, local test servers) are never requested from the internet; check them from inside your network.

Technical notes

The page is fetched with up to five redirects followed (10 s); its a and area links are extracted, resolved against the final URL, stripped of #fragments and de-duplicated, and mailto:, tel:, javascript: links and the page itself are skipped.

Each link is requested once from the Mutqan server with a fixed header set: HEAD, then GET with the body discarded when HEAD answers 405 Method Not Allowed or 501 Not Implemented (RFC 9110 requires general-purpose servers to support HEAD, but some applications do not). Four requests run at a time, 8 seconds each, 22 seconds for the whole check. Every hop passes the same address checks as the page: private, reserved and refused addresses are never contacted.

A status below 400 counts as working (a 3xx is reported as a redirect, not followed); 4xx and 5xx count as broken; no status means the request failed, with the reason in the Result column.

Limitations and methodology

At most 30 links per check — currently 9 when you are not signed in and 29 when you are, shared by the checks you run within one minute — and 10 checks per 10 minutes per IP address; this is a page checker, not a site crawler.

Requests come from the Mutqan server on Cloudflare's network, not from your browser or your country. Sites that block data-centre traffic, require a login or vary by region may answer differently for real visitors.

Only the status is checked: a page that answers 200 with "not found" text (a soft 404), or with the wrong content, counts as working. Links built by JavaScript are not seen.

Security and privacy

The page URL is sent to the Mutqan server, which fetches the page and sends one HEAD (or GET) request to each checked link with a fixed header set. Nothing is stored; the analytics record only that the endpoint was used.

The requests carry none of your cookies or credentials, so pages behind a login answer as they would to a stranger. Check only pages and sites you are allowed to test.

References

  • HTML Standard — 4.6 LinksWHATWGHow a and area elements create hyperlinks: the href, target and rel attributes, link types such as nofollow, noopener and noreferrer, and how a link's URL is resolved against the document base.
  • SEO Link Best Practices for GoogleGoogle Search CentralWhich links Google can follow (a elements with an href that resolves to a real URL), how to write anchor text, and how to qualify outbound links with rel="nofollow", "sponsored" and "ugc".
  • RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.