Broken Link Checker – Find Dead Website Links
Find links that lead visitors and crawlers to missing pages, failed servers, or error responses.
A broken-link report identifies failed destinations and the page that sends users there
The checker first crawls a bounded set of pages on the submitted hostname, extracts unique HTTP links, and records the source page for each target. It then requests those targets and reports connection failures plus 4xx and 5xx responses. That source-to-target relationship matters: repairing the link in the page template is usually more valuable than adding another redirect at the destination.
Fragments such as #pricing are removed for the HTTP check because the fragment never reaches the server. The tool therefore confirms whether the document loads, not whether the named element exists inside it. A browser or HTML validator is needed for missing in-page anchors.
Not every non-200 response represents the same failure
| Result | Likely meaning | Repair decision |
|---|---|---|
| 404 | The server cannot find the target. | Correct the URL, restore the page, or link to a true replacement. |
| 410 | The publisher says the resource was intentionally removed. | Remove or replace the reference rather than retrying it. |
| 401/403 | The target requires credentials or blocks this request. | Verify in a browser and avoid linking users to inaccessible content. |
| 429 | The remote site rate-limited automated requests. | Recheck later; do not assume the page is gone. |
| 500–599 | The destination server or gateway failed. | Retry and contact the owner if the failure persists. |
| Connection or TLS failure | DNS, routing, certificate, or protocol negotiation failed. | Test independently and inspect the detailed error. |
Protected websites can create false positives during automated checks
Some servers reject HEAD even though a normal GET works. The checker retries common 403 and 405 responses with a lightweight GET, but bot defenses, geographic policies, consent walls, and intermittent rate limits can still differ from a human browser. Treat an external failure as a prompt to verify, especially when the target is important evidence.
Internal failures are less ambiguous because you control both ends. Test the URL without a logged-in session and from a clean browser. A page that only works through cached credentials is broken for public visitors even if it works for the editor.
Fix internal links at their source instead of relying permanently on redirects
If a page moved, create one permanent redirect for old external links, then update every internal reference to the final canonical URL. Leaving internal links on the old path slows navigation, hides future redirect mistakes, and can create chains after the next redesign. A chain of A to B to C should become A to C at the server and C in all current templates.
Do not redirect every missing page to the homepage. That produces a soft 404: the user does not receive the promised resource, and search engines may ignore the redirect. When no close replacement exists, remove the link and let the retired URL return a clear 404 or 410.
External references need an editorial replacement, not only a technical one
When a cited source disappears, first search the same publisher for the new canonical location. If it is gone, choose another primary or authoritative source supporting the same claim. An archived snapshot can preserve historical evidence, but it should not silently replace a living standard or current policy. Re-read the surrounding sentence: the claim itself may now be outdated.
Prioritize repairs by user impact and template reach
- Fix links blocking purchase, login, download, contact, or other primary tasks.
- Repair navigation, footer, and shared-component links because one edit fixes many pages.
- Restore broken canonical, stylesheet, script, and image references.
- Update internal editorial links and citations.
- Verify external failures before replacing them.
- Re-run the same bounded scan and confirm the failed targets disappear.
How this free checker stays bounded and safe
The crawl respects robots.txt, stays on the submitted hostname for page discovery, checks at most one hundred unique HTTP targets, and limits redirects, response size, request time, and concurrency. Every hostname and redirect is validated against private and reserved address ranges. The tool does not log in, execute JavaScript, submit forms, or store the one-off scan as site content. Use the website crawler when the repair also requires title, H1, canonical, and page-status evidence.
Broken-link questions that change the repair choice
Are redirected links broken?
Not necessarily, but internal links should normally be updated to the final destination. Review temporary redirects, long chains, loops, and redirects to unrelated content even when the final response is 200.
Why is a working external page reported as blocked?
The publisher may treat automated requests differently, require a region or cookie, or rate-limit the checker. Verify the exact URL in a private browser session before editing the page.
Does this check images and scripts?
The current scan follows hyperlinks extracted from anchor elements. It does not claim full asset validation; inspect browser network errors or use a local site crawler when missing CSS, JavaScript, images, and source maps are in scope.
HTTP standards used to classify each failed or redirected link
The technical claims on this page are drawn from the primary specifications and vendor documentation below.
- RFC 9110 — HTTP status codes RFC Editor
- W3C Link Checker W3C