SIT-03

Link points to a page that does not exist

WarningStructure

What the check measures

The finding is raised on a page that contains a link pointing at a URL which answered us with a 4xx error. The report lists how many such links there are and gives examples of the actual targets, so you know what to look for.

An important detail: the finding belongs to the page holding the link, not to the page that does not exist. That is where the fix happens. The error status of the target page itself is ACC-04's business; this is the view from the other side.

Three status codes are excluded, and that is a decision rather than an oversight:

  • 401 and 403: content behind a login, or bot protection. For a person the page may be perfectly fine and answer 200; we see an error because we come with our own User-Agent. Calling the link broken would be a guess.
  • 429: “too many requests”. The crawler runs at no more than 2 requests per second per domain, but we can still produce this status ourselves. Reporting a broken link because we clicked it too fast would be a lie.

So only those 4xx codes are reported where “the target does not exist” is a verified fact: 404, 410, 400, 405 and the like.

What the check does not do:

  • It never leaves your domain. The crawler does not go outside, so you will not see broken links to other sites. That is a deliberate limit; we have no reason to load someone else's server.
  • It does not check links on pages it never visited. On a sample crawl you therefore see only part of the picture.
  • It does not care where on the page the link sits. A footer link weighs the same as one in the body, and footers are usually shared, so one fix clears the whole site.
  • It cannot see links created by JavaScript unless the page was sampled through a browser.

The finding attaches to the page holding the link; severity is warning.

How strong the evidence is

Necessary condition

Without this, AI search has no way to show you at all. Google states it in its own documentation: a page must be indexed and eligible to be shown with a snippet. The strongest class we have.

This is an observed fact, not an estimate: we sent a request to the URL and the server answered with an error. No heuristic, no threshold.

Why it matters for what this audit is about: a page returning 4xx does not get indexed, and being in the index is a necessary condition for appearing in Google's AI features:

To be eligible to be shown as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown in Google Search with a snippet. There are no additional requirements.Google Search Central, AI features

Where we are precise, though: this holds for wherever the link points, not for your whole site. Broken links do not make a site invisible to language models. That is why the severity is only warning; critical is reserved in this product for things that shut off content entirely AND that we detect with certainty (ACC-01, ACC-03, ACC-07).

What we do not claim: that broken links reduce your “authority” or your ranking. It is a widespread SEO claim we found no support for, and in the context of AI visibility, none at all.

The real reason to fix this is more prosaic and needs no AI at all: a link that leads nowhere is a promise you made to a visitor and did not keep. The rest is a bonus.

How to fix it

For each broken target, decide which of three situations applies:

  1. The content moved. Fix the link to point at the new URL. Do not rely on the redirect alone; a permanent 301 on the old URL is a safety net, not a substitute for a correct link.
  2. The content is gone for good. Remove the link, or replace it with one to the nearest meaningful page. Leaving a link to a 404 “so there is something there” is the worst option.
  3. The URL is a typo. Most often a missing slash, a doubled // mid-path, or http instead of https in a hand-written link.

Before fixing them one by one, look at the list as a whole. If you see the same broken target on dozens of pages, it is in a template: the footer, the header, a sidebar or a product card. One template fix clears them all, and that is nearly always the case.

Verify the target with a command rather than a click; a browser shows you the result after redirects, so you would miss the difference between a 404 and a 200 three hops later:

curl -sIL https://your-domain/target | grep -i '^HTTP/'

And two notes on prevention:

  • When you change URLs, create the redirects before you publish. Broken links nearly always appear during a rebuild, not during writing.
  • A 404 page should offer a way onward: search, a link home, your most-read content. It will not clear the finding, but the visitor will not leave.

What the report says about it

Finding description

On this page we found links ([the count]) to addresses that responded with an error during the crawl: [examples of the actual links]. Visitors and crawlers get an error page there instead of content. The addresses are shown as the crawl resolved them: if a link goes through a redirect, the page's HTML contains a different address. We verified the link is broken by fetching it; that says nothing about visibility in AI assistant answers.

Recommendation

Fix the link to the correct address, or remove it from the page. If the target page existed and was moved, set up a permanent redirect (301) on the server from the old address to the new one. The same link is often present on other pages too (we report it on the page where we first saw it), so check shared templates as well: navigation, footer and hub pages.

Sources

Text verified 2026-09-12