stillindexedStart monitoringOpen the app

Search Console Page indexing: Why pages aren't indexed

URL blocked due to other 4xx issue: what to check

The report does not say which 4xx code Googlebot got. How to find the code and the layer that sent it, and what each common one usually means.

Googlebot got a 4xx status other than 401, 403 or 404, so Google did not index the page. The report does not name the code, so find it first with a live test or your logs. Then fix the layer that sends it, or correct the links pointing at a malformed URL.

What "URL blocked due to other 4xx issue" means

Google: "The server encountered a 4xx error not covered by any other issue type described here." The report has its own statuses for 401, 403 and 404, so this one collects the rest. Google treats all 4xx codes except 429 the same way: the content is ignored, the URL is not indexed, and an indexed URL is removed. A 429 is handled as a server error instead.

Is it a problem?

Depends on the URL

It depends on the code and the URL. A malformed URL nobody links to is noise. A page you want in Search answering with a 4xx is a problem, because it will not be indexed until it returns 200.

Causes, most likely first

  1. A 400 Bad Request from the application or a proxy rejecting the URL: malformed parameters, an encoding problem, or a header or cookie size limit.
  2. A 410 Gone set deliberately for removed content.
  3. A 405 Method Not Allowed from a route built for form posts or an API, found by Google through a link.
  4. A 414 URI Too Long, often from faceted navigation or a redirect that keeps appending parameters.
  5. A 451 Unavailable For Legal Reasons from a legal or regional block.

How to confirm it

  1. Inspect a sample URL and run a live test. Google's only advice for this status is to debug the page with URL Inspection.
  2. Run the indexability checker or the redirect chain checker to see the exact code, including a redirect that ends on the 4xx.
  3. Search server and CDN logs for Googlebot requests to the URL to find which layer produced the code.

Indexability checkerRedirect chain checker

How to fix it

  1. Identify the code and the layer that sends it, then fix it there: the application route, the proxy limit or the firewall rule.
  2. If the URL is malformed, find where it is linked from, internally or in a sitemap, and correct the link.
  3. If the content was removed on purpose, a 404 or 410 is the right answer; take the URL out of your sitemap and internal links.
  4. When the URLs you want indexed return 200, click Validate fix.

How long recovery takes

Google stops using a URL that keeps returning a 4xx and crawls it less and less often. Once the page returns 200 again it has to be recrawled, which Google says can take "anywhere from a few days to a few weeks". Request indexing in URL Inspection asks for one URL sooner but does not guarantee 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?

Any 4xx on a monitored URL that used to return 2xx or 3xx is a critical change, re-checked after 60 seconds before it alerts. The alert carries the status code before and after, which is the detail this report leaves out.

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

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.