"Blocked Due to Access Forbidden (403)" in Google Search Console: Causes & Fixes

"Blocked due to access forbidden (403)" means Googlebot tried to crawl a page and your server actively refused it. Unlike a 404, where the page simply doesn't exist, a 403 is your server making a deliberate choice to say no. That choice is usually coming from somewhere you didn't expect: a security plugin, a firewall rule, or a CDN's bot-blocking feature.

Most guides on this error stop at the obvious suspects: .htaccess rules, WordPress plugins, misconfigured permissions. Those are real causes. But a growing number of reports point to CDN and WAF services like Cloudflare silently blocking Googlebot behind bot-management settings that were never meant to touch search engine crawlers, and it's largely absent from existing coverage of this error.

This guide covers every documented cause of "blocked due to access forbidden (403)," including that Cloudflare-specific pattern, plus a diagnosis workflow, fix instructions for each cause, and how to confirm Google can actually re-crawl the page once you're done.

Who this guide is for: SEO practitioners, developers, and site owners who see "Blocked due to access forbidden (403)" in the Google Search Console Page Indexing report and need to find the actual server-side cause.

How this guide was built: Cross-referenced Google's own Search Central Help Community threads on this exact error, reviewed Cloudflare Community reports where site owners traced 403s back to Bot Fight Mode and WAF rules, and analyzed the top-ranking guides on this topic to confirm which causes are already well covered and which are missing.

Sources & verification: Official Google documentation is cited for how GSC categorizes HTTP status codes. Cloudflare's own community and support threads are cited for the CDN-specific cause. Test any fix against your own server configuration before relying on it.

What "Blocked Due to Access Forbidden (403)" Means

When Googlebot requests a URL, your server responds with an HTTP status code. A 403 status code means the server understood the request and is refusing to fulfill it. Google Search Console reports this specific response as its own status: "Blocked due to access forbidden (403)."

You'll find it in Indexing → Pages → "Why pages aren't indexed."

The practical effect is simple: a URL stuck in this status cannot be indexed and won't appear in Google's search results, no matter how good the content is.

This Is Not the Same as "Blocked by robots.txt"

A common point of confusion: guides sometimes list robots.txt rules as a cause of the 403 status. That's incorrect. If Googlebot is disallowed by robots.txt, GSC reports that under a separate status, "Blocked by robots.txt." The 403 status only appears when your server actually returns a 403 HTTP response to a request Googlebot was allowed to make.

403 Has Its Own GSC Status — It's Not "Other 4xx"

Google Search Console gives 401 and 403 responses their own dedicated statuses ("Blocked due to unauthorized request (401)" and "Blocked due to access forbidden (403)"). Less common codes, like 400, 408, 429, or 451, get grouped under a separate catch-all: "Blocked due to other 4xx issue." If you're troubleshooting one of those codes instead, see our guide on Blocked due to other 4xx issue.

Why Your Server Is Returning a 403 to Googlebot

A 403 response comes from something on your server or in front of it actively denying the request. Here's every documented cause, ranked roughly by how often it shows up in the wild.

1. Security plugins. Wordfence, Sucuri, and iThemes Security all include bot-blocking or rate-limiting features that can misidentify Googlebot as a threat.
2. CDN and WAF bot management. Covered in detail below — this is the cause most existing guides skip entirely.
3. .htaccess or server-config restrictions. A Deny from all rule, an IP allowlist, or a Require directive in Apache/Nginx config that wasn't scoped to exclude search engine crawlers.
4. Hosting-level IP or ASN blocks. Some hosts run ModSecurity rules or fail2ban-style tools that block entire IP ranges, including Google's crawler ranges, after detecting unusual traffic patterns.
5. Authentication requirements returning the wrong code. Login-gated pages should return 401, but some server setups return 403 instead. Functionally it still blocks indexing.
6. Malware or a compromised site. Injected code or a host's automatic lockdown response to a hack can trigger blanket 403s across the site.
7. Hotlink or referrer-based blocking. Rules designed to stop content scraping sometimes catch bots that don't send the expected referrer header.
8. Geographic or country-level IP blocking. Blocking entire countries or hosting providers for security reasons can inadvertently catch the IP ranges Googlebot crawls from.

The Cause Most Guides Miss: Cloudflare and Other CDN/WAF Services

If you've ruled out .htaccess, plugins, and permissions and you're still seeing 403s, check your CDN before anything else. This is the single most under-documented cause of this specific GSC status, confirmed across dozens of reports in Cloudflare's own community forum and even a Google Search Central Help thread where site owners traced the error directly back to Cloudflare.

Why it happens: Cloudflare (and comparable CDN/WAF providers) sit in front of your server and evaluate every request, including Googlebot's, against their own security layer. A request gets blocked when it trips one of these:

• Bot Fight Mode or Super Bot Fight Mode. Designed to challenge automated traffic, but it can misfire on legitimate crawlers, especially on lower-tier plans where the "Verified Bots" allowlist is less configurable.
• WAF managed rules. Broad rulesets built to catch generic attack patterns sometimes flag Googlebot requests as suspicious.
• Rate limiting. If Googlebot crawls faster than your rate-limit threshold allows, it gets throttled and blocked like any other high-frequency requester.
• Custom firewall rules. Overly broad rules (blocking by country, ASN, or user-agent pattern) that weren't tested against Googlebot's actual request signature.

How to check if Cloudflare is the cause:

1. In Cloudflare, go to Security → Events and filter for requests from Googlebot's user agent or IP ranges. If you see blocked or challenged requests, you've found your cause.
2. Temporarily pause Cloudflare (Overview → Advanced Actions → Pause Cloudflare on Site) and re-test the URL with the GSC URL Inspection tool. If the 403 disappears, Cloudflare is confirmed as the source. Multiple site owners in Cloudflare's community forum report exactly this pattern: the error clears when Cloudflare is paused and returns when it's re-enabled.
3. Once confirmed, don't leave Cloudflare paused. Instead, go to Security → Bots and turn off Bot Fight Mode, or configure a custom rule that explicitly skips WAF checks for verified bots.

The fix, in order of what to try:

1. Confirm "Verified Bots" are allowed under Cloudflare's bot management settings rather than assuming they're automatically exempted.
2. Turn off Bot Fight Mode / Super Bot Fight Mode if either is active, or downgrade to a less aggressive bot-management tier.
3. Add a WAF custom rule that skips security checks specifically for verified Googlebot traffic, scoped narrowly by verified-bot status rather than a wide IP allowlist.
4. If rate limiting is the trigger, exempt verified bots from the rule instead of raising the threshold for all traffic.

This is worth checking even if you're confident your CDN settings haven't changed recently. Cloudflare periodically updates its managed WAF rulesets, and a rule that didn't affect Googlebot last month can start blocking it after an update.

How to Diagnose the Exact Cause on Your Site

The GSC report tells you a 403 happened. It doesn't tell you which of the causes above is responsible. Work through these methods, fastest first.

Method 1: GSC URL Inspection Tool

Paste the affected URL into the URL Inspection tool and click "Test Live URL." The "Page fetch" result confirms whether the 403 is still happening in real time and rules out a stale report.

Method 2: curl with Googlebot's user agent

This is the fastest way to reproduce the error yourself and see exactly what your server returns:

curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://yoursite.com/affected-url

Look at the HTTP/ line in the response. If it shows 403, you've confirmed the server (or whatever sits in front of it) is actively blocking that request.

Method 3: Server or CDN access logs

If curl reproduces the 403, your logs will show what handled the request and why. For self-hosted servers:

grep "Googlebot" /var/log/nginx/access.log | grep "403"

If you're behind Cloudflare, check Security → Events as described above instead — the block happens before the request ever reaches your origin server, so your own server logs may show nothing at all. That gap is itself a useful diagnostic signal: no server log entry plus a confirmed 403 almost always means a CDN or WAF is intercepting the request upstream.

Method 4: Disable security layers one at a time

If logs don't point to a clear cause, isolate the layer causing it:

1. Temporarily disable your security plugin and re-test with curl.
2. If that doesn't resolve it, temporarily pause your CDN/WAF and re-test.
3. Whichever step resolves the 403 identifies your cause. Re-enable it once you've applied the narrower, Googlebot-specific fix rather than leaving protection off.

Should You Fix Every 403?

Not necessarily. Run each affected URL through this check before spending time on a fix:

Fix it if:

• The URL is public content you want indexed and ranking
• It appears in your XML sitemap
• It previously received organic traffic
• It has backlinks pointing to it

Leave it if:

• The page is intentionally gated (staging environment, internal tool, members-only area)
• It's paywalled content — for this case, Google recommends using structured data (isAccessibleForFree) alongside a lead-in preview rather than granting Googlebot full access
• It was never meant to be public

How to Verify the Fix Worked

1. Re-test with curl. Confirm the same request now returns 200 OK using the Googlebot user-agent string from earlier.
2. Request indexing in GSC. Paste the URL into URL Inspection, click "Test Live URL" to confirm Google can now access it, then click "Request Indexing."
3. Update your sitemap for bulk fixes. GSC caps manual indexing requests at roughly 10 URLs per day. For larger batches, refresh the <lastmod> timestamp in your sitemap so Google prioritizes recrawling.
4. Check back over 2 to 4 weeks. The Page Indexing report reflects Google's last crawl, not real time. Affected URLs should move from "Blocked due to access forbidden (403)" to "Indexed" once Google recrawls and confirms the fix.

Preventing It From Coming Back

• Re-test after any security or CDN change. A plugin update, a new WAF ruleset, or a Cloudflare setting change can silently reintroduce the block. A 10-second curl check after any change catches it before it shows up in GSC weeks later.
• Document which layer allows Googlebot through. Keep a record of your verified-bot exceptions across your security plugin, CDN, and server config, so you know where to look first if the error returns.
• Review Security → Events (or your plugin's equivalent log) monthly if you're on Cloudflare or a similar service, even without an active problem. Managed rulesets change on their end, not just yours.

Frequently Asked Questions

What does "blocked due to access forbidden (403)" mean in Google Search Console?

It means Googlebot requested a page and your server (or a service in front of it, like a CDN or firewall) returned an HTTP 403 status code, actively refusing the request. The page cannot be indexed while this status persists.

Is this the same as being blocked by robots.txt?

No. Robots.txt blocking is a separate GSC status ("Blocked by robots.txt") that stops Googlebot from requesting the page at all. The 403 status only applies when Googlebot was allowed to make the request but the server responded by denying it.

Can Cloudflare cause "blocked due to access forbidden (403)" errors?

Yes. Cloudflare's Bot Fight Mode, Super Bot Fight Mode, WAF managed rules, and rate-limiting settings can all misidentify Googlebot as suspicious traffic and return a 403. Site owners have confirmed this by pausing Cloudflare and watching the error disappear, then reappear when it's re-enabled. The fix is to explicitly allow verified bots rather than disabling protection entirely.

How do I check which HTTP code my server is actually returning?

Run curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://yoursite.com/affected-url and check the HTTP/ line in the response. You can also use the URL Inspection tool's "Test Live URL" feature in GSC.

Should I fix every URL reported under this status?

No. Fix it if the URL is public content you want indexed. Leave it if the page is intentionally gated, such as a staging site, internal tool, or members-only area. For paywalled content specifically, use structured data to mark it as such rather than removing the 403.

How long does it take for GSC to reflect the fix?

Typically one to four weeks. After confirming the fix with curl, request reindexing through the URL Inspection tool, then check the Page Indexing report weekly. GSC only updates this status after its next crawl of the affected URL, not immediately.

Why does my server log show nothing even though I confirmed a 403 with curl?

This usually means a CDN or WAF in front of your server is generating the 403 before the request ever reaches your origin. Check your CDN's own security event log (in Cloudflare, that's Security → Events) instead of your server's access log.

Can a security plugin and a CDN both be blocking Googlebot at the same time?

Yes, and it's worth checking both rather than stopping at the first cause you find. Disable each layer one at a time and re-test with curl after each change to confirm which one (or both) was responsible.

If you're already digging through the Page Indexing report to chase down errors like this one, SEO Heatmap turns that same Search Console data into a visual map so you can spot clusters of blocked or under-performing pages at a glance instead of exporting a spreadsheet. Give it a try, it's free.