How do I find broken links on my website?

A broken links audit finds the URLs on your site that return an error instead of content. Broken links frustrate users and waste the crawl budget you spend on dead ends, and MDN notes such links are often called broken or dead links and are subject to link rot. You can find them with a crawler, your browser's DevTools, or a command-line spider, then decide whether each one should be redirected or removed.

Why this matters

Not all errors are equal, and treating them the same creates new problems. MDN defines 404 Not Found as the server being unable to find the requested resource: it says the resource is missing but does not say whether that is temporary or permanent. It defines 410 Gone as meaning the target resource is no longer available and that the condition is likely permanent, and it is cacheable by default. Both codes are defined by RFC 9110, HTTP Semantics. The practical distinction matters because a 410 tells clients, including search crawlers, not to keep requesting the URL, while a 404 leaves the door open. If a page has genuinely moved, an error is the wrong answer entirely: a permanent server-side redirect such as 301 preserves the link equity and sends users to the right place. Google's redirect documentation, citing Google Search, says to use a permanent redirect when you are sure the move will not be reverted, because Googlebot follows it and the indexing pipeline uses it as a signal that the redirect target should be canonical. A temporary 302 is for transient situations and keeps the original URL in search results. Choosing wrongly means either leaking ranking signals or telling search engines to forget a page you only meant to move temporarily.

How to fix it

Start by crawling the site and recording every response. GNU Wget's --spider option behaves as a web spider: it does not download page bodies, it just checks that pages are there, so it is safe to run against a site you do not own. Combine it with recursive retrieval to walk the link graph, write a log, then filter the log for 404 and 410. You can also watch loading in DevTools (Network tab, with "Preserve log" enabled) and scan the Status column for failing requests while you click through the site. Once you have a list, fix each case according to intent: 301 redirect URLs that moved and that you cannot update everywhere; replace links you control that point to dead URLs; and return 410 for content you have deliberately removed forever. Remember that redirects are not a license to accumulate chains — collapse a redirect so the first hop resolves directly to a 200. Also fix the source: update internal links, navigation, and your sitemap so the broken URL is no longer referenced.

# spider the site: check links without downloading page bodies
wget --spider -r -nd -nv -o wget.log https://www.example.com/

# then find the failures in the log
findstr /I "404 410" wget.log

# check a single URL's status code
curl -s -o NUL -w "%{http_code}\n" https://www.example.com/old-page

# 301 a moved page (nginx), resolving in one hop
location = /old-page { return 301 https://www.example.com/new-page; }

How to verify the fix

Re-run the same spider and confirm the log contains no remaining 404 or 410 entries for links you intend to keep. For redirected URLs, request the old path and confirm a single 301 resolves to 200 OK at the new path, with the final URL matching your canonical host. In DevTools, reload the page with the Network tab open and check that no request finishes in a 4xx or 5xx state and that no chain longer than one redirect appears.

# confirm the old URL redirects once and lands on 200
curl -sIL https://www.example.com/old-page | findstr /I "HTTP Location"

# re-spider and count remaining failures
wget --spider -r -nd -nv -o wget.log https://www.example.com/
findstr /I -C 0 "404 410" wget.log | find /C /V ""

Related issues