Provide a URL and the checker pulls the links out of that page, then requests each one to flag any that return a 4xx or 5xx error or fail to respond at all.
Pro tip: It crawls the internal links on the one page you submit; run it per key page rather than expecting a full-site crawl.
After fetching your page, the tool gathers its unique links and sends a request to each destination. A link counts as working when the final response status lands between 200 and 399, which includes successful redirects that resolve to a valid page. Anything in the 400–599 range — a 404 Not Found, a 410 Gone, a 500 Server Error — is flagged as broken, and a destination that times out or cannot be reached is reported as unreachable.
To be polite and efficient, each link is first probed with a lightweight HEAD request. Some servers reject HEAD, so when one returns 405 or 501 the checker automatically retries with a small ranged GET before deciding the verdict.
Because the tool runs on a serverless edge with a limited number of outbound requests per execution, it checks up to the first 30 unique links found on the page, working through them a handful at a time. Duplicate URLs are collapsed so a link repeated in the header and footer is only tested once. If a page has more than 30 links, the rest are not tested in that run.
Run the check more than once before acting on an unreachable result, because timeouts and refused connections are often momentary. When a link is flagged, open it yourself: a real broken link will fail in your browser too, while a false positive from bot-blocking will load fine. If a page has more than thirty links, test it in sections — for instance, run the check on the page, fix what surfaces, then look at the deeper or paginated versions separately. Pay closest attention to 404 and 410 statuses, which are durable failures, rather than to a single transient timeout.
This is a single-page check, not a site crawler, so it never follows your internal links into other pages. The thirty-link ceiling exists because the tool runs on a serverless edge that allows only a limited number of outbound requests per execution, and it works through the links a few at a time to stay within that budget; on link-heavy pages the rest are not tested in a single run. To be efficient it probes each link with a lightweight HEAD request first and only falls back to a small ranged GET when a server rejects HEAD with a 405 or 501. Some hosts deliberately block automated probes or rate-limit them, which can make a perfectly good link look unreachable; in those cases a manual visit is the tiebreaker. Results reflect the responses returned at the moment you ran the check.
You submit one URL. Our edge fetches that page, extracts its links, and requests each destination as an anonymous visitor to read the status code — it does not store the page or the link list. Only publicly reachable pages can be checked, and destinations on non-public hosts are skipped for safety.
Input: https://example.com/resources
Output: Links checked 27 · Working 25 · Broken 2. Broken list: 404 — https://oldsite.example/whitepaper.pdf and 0/unreachable — https://defunct.example.
The 404 is a clear fix; the unreachable host is worth a manual retry before removing.
Input: https://example.com/sitemap-page
Output: Links checked 18 · Working 18 · Broken 0, with the note that all checked links responded successfully.
Every destination resolved with a 2xx or 3xx status, so nothing needs attention.
Input: https://example.com/link-directory
Output: Links checked 30 · Working 28 · Broken 2, with a note that only the first 30 unique links were tested to stay within free-tier limits.
The page has more than thirty links, so the remainder need a second pass to be covered.
Up to the first 30 unique links on the page. Duplicates are merged, and any links beyond that limit are not tested in a single run because of edge request quotas.
No. It only checks links found on the one URL you submit. It does not follow those links to discover and scan additional pages.
Some servers block or rate-limit automated requests, or the destination timed out during the check. When that happens the link is reported as unreachable even though a normal browser visit succeeds, so verify it manually.
No. The checker follows redirects, and a link that ends on a 2xx or 3xx final status is counted as working. Only a 4xx or 5xx outcome, or a failure to connect, is flagged.
A HEAD request asks only for the response status without downloading the body, which is faster and lighter on both servers. When a server rejects HEAD with a 405 or 501, the checker retries with a small ranged GET so the link is still judged fairly.
Zero is not a real HTTP code; it is shown when no response was received at all — usually a timeout, a refused connection, or a host that could not be reached. The accompanying note (timeout or unreachable) explains which case it was.
Our editorial and data-source notes explain how each check works and where estimates come from.