How the broken link checker works
Enter the address of a page and press Check links. Our server loads the page, collects every <a href> link (skipping mailto:, tel:, JavaScript links and jumps within the same page) and merges duplicates, counting how many times each one appears. It then requests up to 100 unique links, links to your own site first, six at a time. Each link gets a quick HEAD request; if the server refuses that, it tries a normal GET, the way a browser would. Redirects are followed up to five hops.
The report is split the way you fix things. HTTP errors (the server answered 4xx or 5xx) come first, then links that got no answer at all, then links we could not verify, then redirects and working links. Each tile also shows how many of those links point to your own site and how many to other sites, because you fix the two differently. Every link comes with its anchor text, so you can find it on the page with Ctrl+F (Cmd+F on a Mac), and you can download the list as a CSV for your developer or your content team.
In sitemap mode the checker reads your XML sitemap instead (from the Sitemap: line in robots.txt, or /sitemap.xml) and requests up to 50 of the page URLs listed there. That catches a different problem: pages you are asking Google to index that no longer load.
What the results mean
| Result | Status codes | What to do |
|---|---|---|
| HTTP error | 404, 410, other 4xx, 5xx | Fix or remove the link. A 5xx can be temporary, so check it again later before you change anything. |
| No answer | Timeout, DNS, TLS or connection failure | The domain may be gone or the server down. Open it yourself before you remove it. |
| Could not verify | 401, 403, 429, 999 | Usually fine. The site refused an automated check. Open it in your browser to confirm. |
| Redirect | 3xx, then 2xx | Works. Update internal links to the final URL when you next edit the page. |
| OK | 2xx | Nothing to do. |
| Not checked | None | The link points to a private network address (for example an intranet or a staging server), so we did not request it. Nobody outside that network can open it either. |
Why some links show 403 or 429 but open fine
Many large sites put a firewall or bot protection in front of every page. They answer automated requests with 403 Forbidden, 429 Too Many Requests or, in LinkedIn's case, a non-standard 999, while serving people normally. Our requests carry the same headers as desktop Chrome, but the request still comes from a cloud server, and that alone is enough for some sites to refuse it. A 401 means the page needs a login.
That is why this checker reports those links as "could not verify" and never as broken. If you click one and it opens, the link is fine. If you see a lot of them for your own site, your firewall may also be turning away legitimate tools, such as uptime monitors or the previews that social networks build when someone shares your link.
Why broken links matter
Broken links do not trigger a Google penalty. Google says plainly that a URL on your site returning 404 does not, on its own, count against you in search results, and that 404s are a normal part of the web. The real costs are more practical, and they fall on three things:
- Visitors: a broken link is a dead end. Someone clicked because they wanted the next step, got an error page instead, and many leave rather than search your site for it.
- Discovery: Google uses links to find new pages to crawl and as a signal of how pages relate. A broken internal link is a path that leads nowhere, and if it was the only link to a page, that page becomes harder for crawlers and people to find.
- Crawling: every request a crawler spends on a dead URL is one it does not spend on a page you care about. On a small site this rarely matters; on a large one with thousands of dead links it adds up.
Links to other sites break all the time, as sources move, rebrand or close. On a blog or a resources page that has been live for a few years, expect to find some in the older articles. They make the page look neglected to the reader, which is the part that costs you trust. Checking your most visited pages a few times a year keeps the problem small.
How to fix broken links
- Internal link to a page that moved: change the link to the new address. Then add a 301 redirect from the old URL, because other sites and bookmarks may still use it. The redirect checker confirms it works.
- Internal link to a page you deleted: point the link at the closest live page, or remove it. Only redirect the old URL if there is a page that really replaces it; redirecting everything to the homepage is a poor experience.
- External link that is gone: search for the new address of the same content, link to another good source, or remove the link. The Internet Archive's Wayback Machine can show what the page said, which helps you find a replacement.
- Typos: a missing letter, a stray space or
htp://are more common than you would think, especially in links pasted into a CMS. - Redirected links: not broken, but each one costs an extra round trip. Update internal links to the final URL when you are editing the page anyway.
Methodology and limits
- What we read
- Our server loads the page you enter, follows its redirects and reads up to 2 MB of the HTML it sends. Only
<a href>links count. Images, scripts, stylesheets and links added later by JavaScript are not checked. - What is skipped
mailto:,tel:,javascript:anddata:links, and jumps within the same page (#section). Fragments are dropped from other links, and duplicates are merged and counted.- How each link is checked
- A
HEADrequest first. If the server answers 400, 403, 405 or 501, or the connection fails, we try again with a normalGETand discard the body. Redirects are followed up to 5 hops. - Timeouts
- 10 seconds per request. A link that does not answer in time is listed under No answer, not under HTTP errors.
- How many
- Up to 100 unique links per page, links to your own site first, then links to other sites, 6 at a time. Links beyond 100 are counted but not checked, and the report says how many. In sitemap mode, up to 50 page URLs from the sitemap (found through the
Sitemap:line in robots.txt, then/sitemap.xml, then/sitemap_index.xml; a sitemap index is opened one level down). - Could not verify
- 401, 403, 429 and LinkedIn's 999 are never reported as broken. Our requests carry the same headers as desktop Chrome, but they come from a Cloudflare data center, and Cloudflare adds a header to each one that marks it as sent by a Cloudflare Worker, which we cannot remove. Firewalls and bot protection refuse many such requests while serving people normally.
- Not covered
- Soft 404s (a "page not found" message served with a 200 status) look fine to any checker. Private network addresses are never requested. A 5xx can be a passing server problem, so recheck before you change anything.
- Daily limit
- 100 free units per day per IP address, reset at midnight UTC. A page check uses 5 units and a sitemap check 8, so about 20 page checks or 12 sitemap checks a day.
Sources
- Google Search Central Blog, Do 404 errors hurt my site?
- Google Search Central, SEO link best practices for Google
- Google Search Central, How HTTP status codes, and network and DNS errors affect Google Search
- IETF, RFC 9110, HTTP Semantics, section 15: Status Codes