Link checkers all answer the same question and disagree constantly, because the hard part is not fetching URLs — it is deciding what counts as broken. Here is how the main options differ on the things that actually determine whether you keep using them.
A single Rust binary, and the fastest of the bunch on large inputs. It reads Markdown, HTML and plain text as well as crawling live sites: lychee --max-concurrency 8 --cache --max-cache-age 2d './**/*.md'. Caching matters more than raw speed once you run it in CI on every commit, and lychee is the only tool here where the cache is a first-class flag. It handles fragment checking (--include-fragments) and has sane exclusion syntax. Non-zero exit on failures, so CI integration is one line.
Node-based, no install needed: npx linkinator https://example.com --recurse --skip "linkedin.com". It can also serve a local directory and crawl the built output, which is the right way to check a static site before deploying it. Slower than lychee on thousands of links, but the friendliest configuration and it reports the source page for every broken target, which lychee only does with the right flags.
Built for static site generators — point it at your public/ or _site/ directory and it checks internal links, images, scripts and anchors against the files on disk before anything is published. Internal checks are instant because nothing goes over the network. Configure external checking separately with caching, or it becomes the slow part of your build.
muffet is a Go crawler with good concurrency control and a compact report. And if you want zero dependencies at all, wget --spider -r -nd -nv -o links.log https://example.com still works and is installed on nearly every machine — you just get a log to grep rather than a report.
The GUI option, free up to 500 URLs per crawl. It is the only tool here that also gives you redirect chains, canonical conflicts and status codes in one table alongside the broken links, which makes it the right choice for a one-off audit rather than a CI check.
False positives dominate real-world runs. Bot protection returns 403 to anything without a browser fingerprint, LinkedIn famously answers 999, rate limiters answer 429 under concurrency you chose, and some servers reject HEAD but accept GET. Configure for this or you will start ignoring the report:
Two jobs, not one. Internal links get checked on every pull request against the built output, fail the build, and take seconds. External links get checked on a weekly schedule, open an issue instead of failing anything, and use a cache. Merging the two is why most teams end up with a red build they have learned to ignore.