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 | Type | 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 page links are not crawled — but embedded resources (images/CSS/fonts) and downloadable files are checked wherever they point when the corresponding checkbox is enabled; see below.
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 — every .js file is always loaded and executed (this is required for React, Vue, Angular, or any other framework to hydrate its DOM at all). Links added by client-side frameworks are extracted after the page reaches a network-idle state, so they are found just as reliably as server-rendered links.
What do 'Check page resources' and 'Check downloadable files' do?
Check page resources verifies that every image, stylesheet, and font referenced by each page actually loads — plus any JavaScript file that fails outright (rare, since JS is always executed for rendering). Check downloadable files verifies <a href> links to PDFs, Office documents, archives, video, and audio files — normally skipped entirely, so a broken download link (e.g. a missing driver on a support page) would otherwise never surface. Both are reachability checks only (a lightweight request that reads just the status code, never a full download) and apply regardless of where the file is hosted — including CDNs or other off-site hosts — since it's only checking a URL the page already references, not expanding what gets crawled.
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.