Dead Link Checker
Crawl your website and surface every broken internal link. Renders JavaScript pages with a headless browser so React, Vue, and Angular sites work correctly.
Broken links
| URL | Status | Found on |
|---|
Monitor this automatically
NetTests can run this check on a schedule, preserve historical results, compare changes over time, and alert you the moment something breaks.
Start monitoring free → See all monitoring productsFrequently Asked Questions
What counts as a broken link?
Any internal page that returns an HTTP 4xx or 5xx status code, or fails to connect entirely (connection refused, timeout, DNS failure). Redirects (3xx) that ultimately resolve to a successful page are counted as OK. External links are not checked.
Why are external links not checked?
External links are on servers outside your control and may be temporarily unreachable, require authentication, or implement bot protection. Checking them would generate false positives and could get your IP flagged for abuse. By default, only links on the exact same host as your seed URL are crawled — enable Include subdomains to also crawl other subdomains of the same registrable domain (e.g. blog.example.com and www.example.com are both in scope from a seed of example.com), while a genuinely different site is still excluded.
How does it handle JavaScript-rendered content?
The crawler uses a headless Chromium browser to fully render each page, including JavaScript-driven content. Links added by React, Vue, Angular, or any other framework are extracted after the page reaches a network-idle state, so they are found just as reliably as server-rendered links.
What is the delay setting for?
The crawl delay (default 0.5 s) inserts a pause between page fetches so the target server isn't hammered with rapid requests. Increase it for shared hosting or smaller sites; decrease it for large sites you control.
What is the max pages limit?
The crawler stops after checking the configured number of pages (default 500, maximum 1000) to prevent runaway crawls on very large sites. Pages are processed in breadth-first order, so shallower pages are always checked first.
Are query-string URLs treated as different pages?
Yes. /search?q=foo and /search?q=bar are treated as distinct URLs because they may return different content. Only URL fragments (#section) are stripped — they refer to the same page resource.