§ page indexing report

blocking

"Server error (5xx)" in Search Console

Google asked for the page and your server failed to produce it. Often intermittent, often only under crawl load, and the most urgent of the indexing errors.

This URL is not indexed and it should be. Something is in the way.

check a url →

§ check your url

Is it still happening?

Paste the URL. We request it as Googlebot and as a browser and show both status codes, so you can see whether the error is still live and whether it is specific to crawler traffic.

what this proves

Whether this URL is returning a server error right now, and whether the failure depends on who is asking.

what it cannot prove

A single check cannot rule out an intermittent failure. If the error was caused by load, a deploy, or a flaky dependency, a clean result here is a snapshot rather than an all-clear. Compare it against the Crawl stats report over time.

§ what google is telling you

What this error actually means.

Google requested the URL and the server returned a 500-range status: the request was valid and the server failed to fulfil it. An application exception, a timeout, an exhausted connection pool, a bad gateway between a CDN and an origin.

This is the most time-sensitive error in the Page indexing report. Google reduces its crawl rate for a site returning server errors, which slows the discovery of everything else you publish, not just the failing URL.

It is also the error most likely to have resolved by the time you look. A 5xx recorded during a deploy, a database failover, or a traffic spike is real but no longer reproducible. What matters is whether it is still happening and whether it happens under crawl conditions rather than in your browser.

§ causes

5 things that produce this error.

Ordered by how often they turn out to be the cause, not by how obvious they look.

An unhandled exception on specific inputs

The page works for the routes you tested and throws on a parameter combination you did not. Crawlers are thorough in a way manual testing is not: they find the archive page on the last page of pagination, the category with zero products, and the profile of the user who deleted their avatar.

Timeouts under crawl load

A page that takes several seconds to build is fine for one visitor and fatal when a crawler requests many of them in sequence. Serverless platforms return 504 at a hard limit, and an origin behind a CDN returns 502 when the connection pool is exhausted. The pattern to look for is errors clustered in time rather than by URL.

A deploy window

Requests landing mid-deploy, during a migration, or against a cold instance. Usually brief and self-correcting, and worth confirming as such rather than assuming: check whether the timestamps in the Crawl stats report line up with your deployment history.

A dependency that fails only sometimes

A database connection limit, a rate-limited third-party API called during render, an expired credential, a cache that returns an error on a miss. Intermittent by nature, which is why it survives a quick manual check.

A CDN that cannot reach the origin

A 502 or 522 from the edge, not from your application. Your application logs are clean because the request never arrived. Check the CDN status and the origin health check rather than the framework logs.

§ the fix

How to clear it.

step 1

Check whether it is still happening

Request the URL several times in a row before you start debugging. An error that no longer reproduces is a historical record, and the fix is to validate it in Search Console rather than to change code.

bash

for i in 1 2 3 4 5; do
  curl -sI https://example.com/page -o /dev/null -w "%{http_code} %{time_total}s\n"
done

step 2

Read the Crawl stats report for the shape of the failure

Settings > Crawl stats > By response. Errors clustered on one day point at a deploy or an incident. Errors spread evenly across many URLs point at capacity. Errors on one URL pattern point at a code path. The shape tells you where to look before you read a single line of a stack trace.

step 3

Never return a 5xx for a page that is simply gone

A removed page should return 404 or 410. A 5xx tells Google the failure is temporary and to keep trying, which wastes crawl budget on a URL that will never work and suppresses the crawl rate for the rest of the site.

step 4

Fix capacity before you fix symptoms

If the errors are timeouts, raising a timeout limit moves the failure rather than removing it. Cache the expensive render, move the slow dependency out of the request path, or serve statically. If crawl volume genuinely exceeds what the origin can serve, adjust the crawl rate in Search Console as a temporary measure while you address the capacity.

§ related

Next to check.

blockingBlocked due to access forbidden (403)Your server let Googlebot ask, then refused to answer. Usually a bot-management rule rather than anything you configured on purpose. Here is how to tell.blockingRedirect errorGoogle followed a redirect from this URL and never arrived anywhere usable. Here is what breaks a redirect chain, and how to see the whole chain the way a crawler does.blockingSoft 404Your server says 200 and your page says the content is gone. Google believes the page, not the status code, and refuses to index either.toolCore Web Vitals CheckerCheck the lab signals behind LCP, CLS, and a fast first byte.

→ Why Your Core Web Vitals Won't Improve (Even at Lighthouse 95)

LintPage rules covering this: ttfb-pro, performance

§ faq

Questions, answered.

Does a 5xx error hurt rankings?

Not directly and not immediately, but the second-order effects are real. Google lowers its crawl rate for a site returning server errors, which delays discovery of new and updated pages across the whole site. If the errors persist, affected URLs are eventually dropped from the index. A brief incident is survivable; a pattern is not.

How long before Google drops a page returning 5xx?

There is no published threshold. Google retries a URL returning a server error with decreasing frequency, and a page that was already indexed can persist for days or weeks. Sustained errors lead to removal. The safe assumption is that a few hours are harmless and a few days are not.

Should I use 503 during maintenance?

Yes. A 503 with a Retry-After header is the correct way to say the outage is deliberate and temporary. It tells Google to come back rather than to reassess the page, and it is much better than serving a broken page or a 500. Keep it genuinely short-lived, because a 503 that lasts for weeks is treated as a permanent failure.

Why does Search Console report errors I cannot reproduce?

Because the report is a record of past crawl attempts, not a live status. The error happened when Google asked, under whatever conditions applied at that moment: a deploy, a traffic spike, a cold start, an exhausted connection pool. The Crawl stats report shows when each failure occurred, and lining those timestamps up against your deploys and incidents usually identifies the cause faster than any amount of local testing.

Can crawling itself cause the server errors?

Yes, and it is more common than people expect. A crawler requests pages faster and more thoroughly than human traffic, hitting expensive uncached routes in sequence. If your errors correlate with crawl spikes in the Crawl stats report, the problem is capacity rather than a bug, and caching the expensive path fixes both the errors and the crawl rate.

§ before the next deploy

Catch this one before Search Console does.

Search Console tells you weeks after the fact. LintPage runs 60 checks against a URL in about 30 seconds. Free, no signup.

run a full scan →