Link led to a page returning a server error

The same principle as SIT-03, with a different status code: the finding is raised on a page that contains a link pointing at a URL which, at crawl time, answered with a 5xx error, an error on the server's side. The report lists the count and example targets.

Why is this a separate code rather than a variant of SIT-03? Because the difference between 4xx and 5xx is not cosmetic; it is about what we are entitled to tell you. 4xx is a permanent defect: the page does not exist and will not. 5xx is a single observation at a single moment. The server may have had an outage, a restart, a spike in load or a deployment in progress, and may be answering perfectly an hour later.

If we reported both the same way, we would be saying the same thing about a momentary blip as about a page that does not exist. So SIT-04 is an informational finding and costs you no score at all; you get to know about it and can verify it, but we do not deduct for something we cannot demonstrate is a permanent state.

What the check does not do:

• It does not retry. We see one attempt at one moment. You will not learn whether the error is permanent; that part is yours to check.
• It never leaves your domain, same as SIT-03.
• It does not distinguish which 5xx it was. 500, 502, 503 and 504 share one finding, though each points at a different cause.
• It cannot tell you whether the fault was on your server or at your provider. Only somebody with access to the logs can.

The finding attaches to the page holding the link.

This badge refers to the mechanism, not to our observation, and that has to be said first, so nobody takes it as confidence in the diagnosis.

The mechanism is a necessary condition and the best-documented thing in the audit: a page returning an error does not get indexed, and without the index it will not appear 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

Our observation, however, is weak, and that is why the finding is informational. We saw one request at one moment. From that it is impossible to tell whether you have a permanently broken page or whether we simply hit the thirty seconds during which a new version was being deployed.

Which is exactly why we do not throw it away. A 5xx we see is a 5xx every other visitor and every other crawler saw at that moment. When it recurs, it is more serious than any 404, because it concerns a page that does have content. The judgement of whether it is an outage or a state belongs to you, because only you can see the logs.

An honest closing line: this is the one finding in the whole set where we ask you to verify it yourself before acting on it.

The first step is not a fix but a check. Try loading the target again, ideally several times with a gap:

for i in 1 2 3; do curl -s -o /dev/null -w "%{http_code}\n" https://your-domain/target; sleep 20; done

Decide by the result:

When the error is real, the specific code tells you where to look:

• 500: an application error. An exception, a missing database record, bad input. The answer is in your application log at that timestamp.
• 502 and 504: the application answered the proxy late, or not at all. Typically a slow database query, exhausted worker processes, or a background service that is down.
• 503: service unavailable. Either maintenance or overload. When it appears under load, it is capacity rather than a bug.

And one thing that follows more broadly: if a 5xx on your own site came as a surprise, you are missing uptime monitoring. An audit walks the site once; a service watching it continuously tells you about an outage before a customer does. You need not act on it for this one error, but it is worth considering.