Search Console Page indexing: Why pages aren't indexed

Server error (5xx) in Search Console: causes and fix

What "Server error (5xx)" in the Page indexing report means, why Googlebot got a 500-level response, how to confirm it and how recovery works.

Googlebot requested the page and your server answered with a 500-level status, timed out or was too busy, so Google abandoned the request. One failure can be transient. Check the host status in Crawl stats, reproduce it with a live URL test, fix the server or the rule rejecting Googlebot, then validate the fix.

What "Server error (5xx)" means

Google's definition: "Your server returned a 500-level error when the page was requested." Its troubleshooting notes widen that to cases where Googlebot "couldn't access your URL, the request timed out, or your site was busy" and had to abandon the request. Google ignores any content sent with a 5xx response and slows its crawling of the site while the errors continue.

Is it a problem?

Usually a problem

Yes, for any URL you want in Search. Google keeps already indexed URLs in the index for a while after a 5xx, but its documentation says they are "eventually dropped", and URLs that persistently return a server error are removed. A spike that has already cleared is less urgent than a URL that fails every time.

Causes, most likely first

The origin was down, restarting or overloaded when Googlebot called, often during a deploy or a traffic peak.
A firewall, DoS protection or bot management rule answering Googlebot with an error. Google names this case: protection systems are often set to block unusually high request levels, and Googlebot makes more requests than a person does.
An application error on this template only: a missing database row, an exception in a plugin, or a dependency the page needs at request time.
Slow dynamic pages, for example URLs with long parameter lists, that time out before the server answers.

How to confirm it

Open the URL in URL Inspection and click Test live URL. Google warns that server errors can be transient, so a live test that passes now does not prove the crawl did.
Open Property settings, Crawl stats, and read the host status. It shows whether Google had availability problems with the whole host in the past 90 days, not only this URL.
Run the indexability checker on the URL to see the status a crawler receives right now, then the crawler versus browser checker to see whether Googlebot gets a different status from a browser.
Search your server or CDN logs for Googlebot requests to the URL around the last crawl date shown in URL Inspection.

Indexability checker Crawler versus browser checker

How to fix it

If the host status in Crawl stats shows a recurring problem, fix capacity first: the server, the database, or the plan limits at your host.
If only Googlebot gets the error, find the layer blocking it (firewall, CDN bot rules, DoS protection) and allow verified Googlebot. Verify by reverse DNS on the requesting IP or against Google's published IP ranges, not by the user agent string.
If one template fails, fix the application error your logs show for that URL and deploy.
Confirm with a live URL test that returns the page, then click Validate fix on the issue in the Page indexing report.

How long recovery takes

Google says that once the server responds with 2xx again, it "gradually increases the crawl rate for the site". A recrawl of a given URL can take "anywhere from a few days to a few weeks", and Request indexing asks for one URL sooner without guaranteeing it.

After a fix, Validate fix on the issue asks Google to recheck the affected URLs. Google says validation "typically takes up to about two weeks, but in some cases can take much longer". Without it, the count still updates as Google recrawls, and an issue leaves the table once 90 days pass with no instance.

Would monitoring have caught it?

A monitored URL that starts returning a 5xx after returning 2xx or 3xx is a critical change. It is re-checked after 60 seconds and alerts if the status holds. Timeouts and refused connections are covered too: three failed checks in a row raise a critical "unreachable" change. It sees what our crawler is served, so a firewall rule that rejects Googlebot alone needs the crawler versus browser checker.

stillindexed checks each monitored URL every 30 minutes on Starter and every 15 minutes on Agency, so the change is found on the next check and confirmed before it alerts, rather than waiting for this report to update.

See what monitoring covers

Six checks when a site disappears from Google

Sources

Every claim above about how Google behaves is from Google's own documentation, read on 2026-10-06. If Google has changed a page since, Google's page wins and we would like to know.