Blocked due to access forbidden (403) is the Page indexing status where Google’s help documentation stops being neutral and tells you directly that your server is wrong. The entry says HTTP 403 means the user agent provided credentials but was not granted access, then adds: “However, Googlebot never provides credentials, so your server is returning this error incorrectly.”
That sentence is the whole diagnosis, and it is easy to read past. Googlebot does not log in. It has no cookies, no session, no password to be wrong about. So when your server answers Googlebot with 403, the refusal was not triggered by failed authentication. Something on your side decided, before authentication was even a question, that this visitor does not get the page. Finding that something is the entire job of fixing this status.
What a 403 does to indexing
Google’s crawling documentation puts 403 in the same bucket as almost every other 4xx: the crawlers “inform the next processing system that the content doesn’t exist”. A URL that answers 403 will not be indexed, and if it was indexed before, it gets removed from the index. Any content served alongside the error, a branded access-denied page for instance, is ignored.
Two details in the documentation are worth more than the headline rule:
- 4xx errors have no effect on crawl rate. Unlike a 5xx, which slows crawling across the site, a 403 only kills the URL that returns it. Google even carries a specific warning about the difference: do not use 401 or 403 to try to slow Googlebot down, because it does not slow anything down, it just deindexes the pages. The 401 half of that warning has its own status and its own suspect list, which I cover in blocked due to unauthorized request (401).
- A 403 is not a noindex. The outcome looks similar, page out of the index, but the mechanism matters. A noindex is read from a page Google can fetch, and Google keeps crawling it and re-reading the directive. A 403 means Google gets nothing at all: no content, no directives, no canonical, no links. The page becomes a dead end.
Where the block actually lives
In the audits I do, a 403 in this report almost never comes from the application that serves the site. Pages that “work fine when I open them” and still show this status are being filtered by something that sits in front of the application, and the candidates are a short list:
- The firewall or bot protection layer. CDN and WAF products ship rules that score visitors on user agent, IP reputation and request rate, and crawlers score badly on all three by nature. A challenge page served to a crawler frequently resolves to a 403, because a crawler cannot pass a browser challenge. This is the most common cause I meet, and the site owner usually never turned the rule on themselves; it arrived as a default or with a “under attack” toggle someone flipped during an incident and forgot.
- Hosting-level IP or geo blocks. Some hosts block ranges wholesale after abuse from a network neighbourhood. Googlebot crawls mostly from US-based IPs, so a geo rule that fences off non-customer countries can fence out the crawler too.
- Hotlink and referrer rules written too broadly. A rule meant to stop image hotlinking that matches empty referrers will match crawlers, which send none.
- Genuinely private areas leaking into discovery. Staging subdomains, members-only paths and admin routes return 403 by design. Those belong in this status, and the right response is to leave them there. Not every row in a not-indexed status is a problem, which is the same reading discipline the Page indexing report rewards everywhere else.
The fix follows from which one it is. Google’s advice for pages you do want indexed is to admit non-signed-in users, or to explicitly allow Googlebot requests without authentication, with the caveat that you should verify Googlebot’s identity by reverse DNS or Google’s published IP ranges rather than trusting the user agent string, which any scraper can wear.
How to confirm it, step by step
The report tells you what Googlebot experienced at last crawl, which may not be what it would experience now. The confirmation sequence:
- Open the status, pick an affected URL, and note the last crawled date. A cluster of dates around one incident reads very differently from a spread.
- Run the URL Inspection live test. This fetches as Googlebot from Google’s own infrastructure, so it passes or fails the same gauntlet of WAF rules and IP filters that real crawls do. Your own browser, or even a command-line fetch from your machine, proves nothing here, because the block is usually keyed to who is asking, not what is asked for.
- If the live test fails, pull your server or CDN logs for the failing path, filter to the 403s, and look at what issued them. On most stacks the security layer logs its block reason; that reason is the fix, named.
- After allowing verified Googlebot through, request indexing on a couple of representative URLs and validate the fix in the report. Validation runs on Google’s schedule, typically up to about two weeks, and I treat the live test as the real confirmation and the validation as paperwork.
One pattern from client work worth flagging: the block and the report disagree in both directions. I have seen pages sit in this status for weeks after a WAF rule was fixed, because nothing forced a recrawl, and I have seen fresh blocks not appear in the report for days because Googlebot had not been back yet. The report is a history book, not a monitor. When a 403 matters, the live test and the logs are the present tense.
A 403 is the loudest way to be invisible: the server is up, the page is fine, and Google is told, politely and repeatedly, that it is not welcome. The good news is that of all the not-indexed statuses, this one has the shortest causal chain. Something in front of your site said no. Find it, show it Googlebot’s verified identity, and the rest is waiting for a recrawl.
Sources
- Google Search Console Help, Page indexing report, the Blocked due to access forbidden (403) status, checked 1 September 2026
- Google crawling infrastructure documentation, how HTTP status codes affect Google’s crawlers, for the 4xx handling, the no-crawl-rate-effect rule and the warning against 401/403 for rate limiting, checked 1 September 2026
- Google Search Central, verifying Googlebot and other Google crawlers, for reverse DNS and IP range verification
- Google Search Console Help, URL Inspection tool, for the live test behaviour