Blocked Due to Access Forbidden (403)

What the "Blocked due to access forbidden (403)" status in Google Search Console's Page Indexing report means, why Googlebot gets a 403 when your browser doesn't, how it differs from 401, and how to diagnose, fix, and validate it.

First published: Jun 23, 2026 · Last updated: Jul 17, 2026 · Advanced
demand #18 in Indexing#53 in How Search Works#285 in Technical SEO#381 on the site
2 evidence signals on this page

"Blocked due to access forbidden (403)" in the GSC Page Indexing report means Googlebot crawled the URL and your server returned an HTTP 403. Google won't index it (and removes it if it was indexed). Google's Page Indexing help describes a 403 as credentials supplied but denied — that's Google's report wording, not the full HTTP definition; RFC 9110 defines 403 more broadly and it can be unrelated to credentials. If the URL is meant to be public and indexable, treat the 403 as a bug to find; if it's meant to stay private, the 403 may be doing its job — fix discovery signals instead. For URLs that should be public, a firewall, CDN, or WAF is a commonly reported culprit, which is why the page often loads fine in your browser but 403s for Google. Google treats 401 and 403 the same for indexing, and says don't use either to limit crawl rate — use 429 or 503. Verify the real Googlebot (reverse DNS / published IP ranges / correct client category) before allowlisting, scope any exception narrowly, then confirm a 200 in URL Inspection and Validate Fix.

TL;DR — A 403 in the Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. means GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. got an HTTP 403An HTTP 403 client-error status code meaning the server understood the request but refuses to fulfill it — access is denied, whether or not credentials are involved. For SEO, a 403 served to Googlebot on a page meant to be public and indexable usually points to a misconfigured rule; a persistent 403 keeps a page out of the index either way. on the URL, so Google won’t indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. it (and removes it if it was indexed). Google’s Page IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. help frames a 403 as credentials supplied but denied — that’s Google’s report wording, not the full HTTP definition; RFC 9110 defines 403 more broadly as “understood but refused,” with or without credentials, so treat Google’s framing as a heuristic, not proof of misconfiguration. Decide first whether the URL should be public and indexable at all — for URLs that should be public, a firewall/CDN/WAF unintentionally blocking GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. is a frequently reported cause, which is why the page often renders for you but 403s for Google, but a 403 on a URL meant to stay private can be working as intended. Google treats 401 and 403 the same for indexing, and explicitly says don’t use 401/403 to limit crawl rateCrawl rate is how fast a search engine crawler fetches pages from your site — the number of simultaneous requests it makes and the delay between them. Google sets it automatically based on your server's health; it's the supply side of crawl budget, not a ranking factor. — use 429429 Too Many Requests is an HTTP client-error status code that means a client sent too many requests in a given time window — a mechanism called rate limiting. Unlike other 4xx codes, Google treats 429 as a server-overload signal and slows crawling instead of removing content. (or 503503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime.). Verify the real Googlebot (reverse DNS / published IP ranges / correct client category) before allowlisting, scope any exception to the specific route and rule, then confirm a 200 in URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. → Test live URL and run Validate Fix.

What Google actually says about a 403 — and what HTTP actually says

The label reports the observed response, not the specific WAF, CDN, or access rule that caused it. Evidence for this claim The Page Indexing report identifies URLs where Google encountered a forbidden-access response. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: Page indexing report Its indexing consequence follows Google’s general 4xx handling. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: HTTP status codes

Google’s Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. documentation describes it this way: an HTTP 403 means the user agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. provided credentials but was not granted access — but Googlebot never provides credentials, so, in Google’s words, your server is returning the error incorrectly. The page will not be indexed. If you want it indexed, Google’s fix is to either admit non-signed-in users or explicitly allow Googlebot’s requests without authentication.

That’s Google’s Help-doc framing, though, not the complete HTTP definition. RFC 9110 (the current HTTP semantics spec) defines 403 more broadly: the server understood the request and refuses to fulfill it. Credentials can be part of that — but the RFC is explicit that a request can be forbidden for reasons unrelated to credentials entirely: policy, an access-control rule, an edge security decision, whatever the server owner decided. So the useful takeaway isn’t “a 403 to Googlebot always means a broken rule by definition” — it’s “figure out whether this URL is supposed to be reachable, then find the exact rule that returned 403.” For a page that should be public and indexed, a 403 to Googlebot is almost always something to fix. For a page that’s deliberately private or forbidden, the 403 can be a valid, working access decision — the problem there is usually that Google shouldn’t have discovered the URL in the first place (see the intent check below), not that the firewall is wrong.

Whichever case it is, Google’s separate HTTP status-codes documentation is blunt about the indexing consequence: it doesn’t use the content from URLs returning 4xx codes, all 4xx errors except 429 are treated the same (the crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. tells the next system the content doesn’t exist), and the indexing pipeline removes the URL from the index if it was previously indexed.

Decide what the URL is supposed to do before you fix anything

Not every row in this report needs the same fix. Sort the URL into one of four buckets first:

  1. Public and meant to be indexed. The 403 is unintended — work through the diagnose → fix → validate loop below.
  2. Public but not meant to be indexed. Don’t reach for robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. to solve this — a robots.txt disallow is a separate crawl gate with its own Page Indexing reason (“blocked by robots.txtA Google Search Console Page Indexing status: the URL was excluded from indexing because your robots.txt disallows crawling it. Usually intentional and benign — robots.txt blocks crawling, not indexing.”); it doesn’t itself produce the HTTP 403 this status reports. Serve the normal 200 response and use a noindex directive (or a proper redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't./removal) instead.
  3. Deliberately private or forbidden. A 403 can be the correct, intended outcome for a resource the requester shouldn’t reach. If it’s showing up in this report, the actionable problem is usually that the URL is discoverable — in your sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing., internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them., or elsewhere — not that the access rule is wrong. Clean up the discovery signal rather than opening the door.
  4. A URL that shouldn’t exist, or whose existence you don’t want to confirm. Choose the response based on your application’s security policy, not an SEO shortcut — a 403 (or a 404, if you don’t want to confirm the URL exists at all) can both be legitimate here.

Everything from here on assumes case 1: a URL you actually want crawled and indexed.

403 vs 401 — how to tell them apart

These two are siblings in the report and most write-ups blur them with a rule of thumb (“403 = no credentials asked, 401 = login wall”) that isn’t reliable on its own — a misconfigured auth layer can return 403 too, and still land in this row. The response itself is the real signal:

  • 401 (unauthorized) — per RFC 9110, a 401 specifically means valid authentication credentials are missing, and the response is required to carry a WWW-Authenticate challenge header (HTTP auth, a login wall). Google was told it needed to authenticate and couldn’t.
  • 403 (access forbidden) — a broader refusal. RFC 9110 defines it as “the server understood the request but refuses to fulfill it,” with or without credentials. In practice this row is most often a firewall/CDN/WAF or security-rule block, but it can also be an application returning 403 from a broken auth check, a rate limiter, or a deliberate access-control decision.

To actually tell them apart on a given URL, check the returned status and headers — does the response carry a WWW-Authenticate header? — rather than assuming a mechanism from the report label alone. They share the outcome (not indexed) and often the fix (let verified Googlebot through, or open the content to anonymous users), so once you know which one you’re looking at, the same diagnosis loop below applies to either row.

What a 403 does to indexing

Three things follow once Googlebot gets a 403:

  1. The content is ignored. Google doesn’t use content from 4xx URLs, so nothing on the page can be indexed.
  2. The URL is removed if it was indexed. A 403 can deindex a page that was previously ranking — this isn’t a “won’t get added” problem only, it’s a “drops out” problem.
  3. Crawl frequencyCrawl frequency is how often a search engine comes back to re-fetch a page it already knows about. Popular pages that change often get refreshed many times a day; stable pages can go weeks or months between crawls — and you influence it indirectly, not by setting a dial. decays. Google gradually crawls 4xx URLs less often over time, so a long-standing 403 gets visited less and recovers more slowly once you fix it.

Why Googlebot gets a 403 when your browser doesn’t

This is the question that sends people in circles. The page loads in your browser, so the content is obviously fine — but Google reports a 403. The likely explanation is that your browser and Googlebot make very different-looking requests, and a bot-management rule built to stop scrapers can fire for the crawler while serving humans normally — but treat that as a hypothesis to confirm, not a foregone conclusion, because the attribute that actually matters varies by site:

  • Your browser sends cookies, a real browser user-agent, and can solve a JS or CAPTCHA challenge; Googlebot’s request typically carries none of that — no cookies, a crawler user-agent, and it can’t solve an interactive challenge (though Google-InspectionTool does render JavaScript and report the rendered output, so “Googlebot has no JavaScript” isn’t accurate for every part of this).
  • Beyond client-side differences, the two requests can also differ in source IP/category, geography, method, referrer, cache state, and which rule actually fired — any one of those can be the real trigger.

Don’t guess which attribute caused it. Compare the exact edge and origin logs for a real blocked request against a normal browser hit — same rule ID, response headers, method, UA, source IP and its verified category, geoGenerative Engine Optimization — visibility inside AI answer engines., cookies, referrer, cache status, and challenge outcome — and change one attribute at a time until you find the one that flips the response. That’s how you confirm the 403 is selective rather than just assume it.

Common causes

  • CDN / WAF bot management. Cloudflare (Bot Fight Mode / Super Bot Fight Mode, Browser Integrity Check, Managed Challenge), Akamai, Imperva/Incapsula, Sucuri, AWS WAF — these can challenge or 403 non-browser clients, including Googlebot. For URLs that should be public, this is one of the most frequently reported causes, and almost always unintended — though there’s no independently verified figure for what share of cases it accounts for.
  • Server firewall / security rules. mod_security / the OWASP CRS, fail2ban, or host-level firewalls flagging Googlebot’s pattern as abusive.
  • User-agent / referrer / hotlink rules. Rules that 403 any request lacking a browser-like user-agent or referrer.
  • Geo / IP blocking. Excluding the IP ranges Googlebot crawls from (Googlebot crawls primarily from US IPs), so a country block can silently catch it.
  • Login / credential walls. Requiring cookies or a login to view content that should be public — this overlaps with the 401 case.
  • Rate-limiting rules that 403 after N requests. Don’t do this — see below.

Don’t use 403 to throttle Googlebot

This is the one anti-pattern worth calling out by name. People (and some CDNs) return 403s or 404s to slow Googlebot down and reduce server load. Google has been explicit that this doesn’t work and shouldn’t be done: don’t use 401 and 403 status codes for limiting the crawl rateCrawl rate is how fast a search engine crawler fetches pages from your site — the number of simultaneous requests it makes and the delay between them. Google sets it automatically based on your server's health; it's the supply side of crawl budget, not a ranking factor.. They have no effect on crawl rate — they just deindex the page. If you genuinely need Googlebot to back off, return 429 (or a 5xx like 503); those are the codes Google reads as “slow down,” and the effect is temporary, not permanent.

How to diagnose

  1. URL Inspection → Test live URL. Run an affected URL through Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. and use Test live URL to confirm Google is currently getting a 403 (not a stale report). Keep in mind this test is Google-InspectionTool, a specific Google client — a passing live test tells you InspectionTool got through right then, not that scheduled common Googlebot will take the identical WAF, geo, cache, or rate-limit path on its next crawl.
  2. Reproduce as Googlebot. Don’t test from your normal browser — fetch the URL with Googlebot’s user-agent, ideally from outside your network and from more than one region (Google mostly crawls from US IPs but can shift to other countries if US requests get blocked, so a single-region pass doesn’t prove global access), to trip the same rule. (Commands are in the Scripts tab.)
  3. Read the CDN / WAF / firewall logs. Find the exact rule that fired on Googlebot’s request — compare its response headers, rule ID, and trigger (user-agent, IP, challenge, rate limit) against a normal browser hit’s log entry, rather than assuming which attribute caused it.
  4. Verify the real Googlebot — and its category. Before you allowlist anything, confirm the requests are genuinely Googlebot via reverse + forward DNS or Google’s published IP ranges, and check which Google client made the request — common Googlebot, special-case crawlers, and user-triggered fetchers (like Google-InspectionTool) use different host masks and IP lists, so verifying against the wrong list can make a real request look spoofed.
TIP Verify the claimed crawler before changing a firewall rule

The same user-agent can be sent by a real crawler or an impostor. Confirm the request identity before allowlisting it, then trace the rule that returned 403.

Spot-check the source IP against published crawler ranges with my free Googlebot Verifier Free

  1. Copy the source IP and claimed user-agent from the blocked WAF or access-log event.
  2. Verify the IP against the crawler operator’s published ranges instead of trusting the user-agent string.
  3. Allow only verified crawler traffic on the specific route and rule that blocked it, fix that rule, and confirm the URL now returns 200 in a live test.
A mismatch is a reason not to open the firewall for this request—not evidence that every blocked Googlebot claim is fake.

The Googlebot Verifier result lists IP address 203.0.113.9 with a Googlebot user-agent claim. The published-range result is mismatch, and the row is labeled for a spot-check.

How to fix it

  • Scope a narrow exception for verified Googlebot in your WAF / firewall — by verified identity (reverse + forward DNS, matched to the correct client category) or Google’s current published crawler IP ranges, not by trusting the user-agent string alone. Keep the exception narrow: the specific route(s) that need it and the specific rule that’s blocking, rather than a blanket allow-all-Google exception — leave your other security controls, rate limits, and logging in place, and set an expiry/review date so a stale allowlist doesn’t quietly outlive its reason. Ask your CDN/firewall vendor to confirm Googlebot is allowed, and automate a check of your block rules against Google’s current published IP subnets so a future IP-range update doesn’t silently re-block you.
  • Open public content to anonymous users. If the 403 comes from a login/cookie requirement on content that should be public, remove that requirement (this is also the shared fix with the 401 sibling).
  • Swap 403 rate-limits for 429. If a rule 403s after a request threshold, change it to return 429 (or 503) so Googlebot reads it as “slow down” instead of “go away.”

Validate the fix and get re-indexed

Once the rule is fixed, the URL should return 200. Then:

  1. URL Inspection → Test live URL to confirm the live response is now 200.
  2. Request indexing for high-priority URLs, and/or click Validate Fix on the “Blocked due to access forbidden (403)” row in the Page Indexing report.
  3. Re-indexing follows automatically once Google re-crawls a 200 — there’s no official guarantee of exactly how fast, and the URL still needs to clear a normal crawl before it can reappear. You don’t need to trigger anything manually beyond removing the block, confirming the healthy response, and giving Google time to recrawl.

For the bigger picture of which not-indexed reasons show up here and how the report groups them, see the Page Indexing report overview; for the sibling status, “Blocked due to unauthorized request (401)” is the 401 version of this same problem.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.