Blocked Due to Access Forbidden (403): What It Means + How to Fix It

A 403 is your server actively saying no. Googlebot made the request, something server-side evaluated it, and decided to refuse — not "I don't have this page" (that's a 404), but "I'm not letting you have it." Something between your origin server and Googlebot decided the crawler wasn't welcome.

That's the important distinction from a robots.txt block: robots.txt is a polite, voluntary instruction Google chooses to follow. A 403 is a hard server-level refusal, usually issued by infrastructure that has no idea it's turning away the search engine you want indexing your site.

First, confirm it's real and find where it's coming from

Open Pages → Why pages aren't indexed, click into "Blocked due to access forbidden (403)," and pull an affected URL. Run URL Inspection → Test live URL to see what Google gets right now, since firewall and bot-protection rules change independently of GSC's report.

Then check the page yourself, in an incognito window, logged out of everything. If it loads fine for you but 403s for Google, the block is specifically targeting the crawler — not a general access problem — which points straight at bot protection rather than a real auth requirement.

Find your cause

1. A WAF or bot-protection service is blocking the crawler

Services like Cloudflare, Sucuri, Wordfence, or a hosting provider's built-in firewall ship with rulesets meant to stop scrapers, credential-stuffing bots, and scanners. Rules based on request rate, missing browser fingerprints, or failed JavaScript challenges can catch Googlebot in the net, since a crawler behaves differently from a normal browser session.

Tell: the page loads normally in a real browser, but fails specifically for automated or crawler-like requests. Your CDN or security plugin's activity log shows blocked requests from Google's published IP ranges or the Googlebot user agent.

2. A CDN or hosting-level rule is geo- or rate-limiting

Some CDN configurations rate-limit by IP range or restrict access from certain data-center ASNs, and Google's crawl infrastructure can fall inside a range that gets caught by an overly broad rule.

Tell: the 403s aren't isolated to a few pages — they're widespread or intermittent across the whole site, correlating with crawl volume rather than any specific URL.

3. The page is genuinely behind an access wall

Some pages are meant to require login, IP allowlisting, or another gate — member content, an internal tool, a staging environment accidentally left crawlable.

Tell: the page requires credentials for a real user too, and that's intentional.

4. A misconfigured server rule is too broad

A rewrite rule, .htaccess directive, or reverse-proxy config meant to block one narrow thing (an admin path, a bad user agent) is written broadly enough that it also matches Googlebot's requests.

Tell: checking the exact server or CDN rule that fired shows a pattern clearly meant for something else, catching Googlebot as unintended collateral.

The fix

1. Decide first: should Google be able to reach this page?

   Same fork as any access-control status. If the page should be crawlable and indexable, you're removing or narrowing a block below. If it's genuinely private, leave the 403 (or better, use a proper auth flow) — this status isn't a problem for pages that should never be public.

2. Allowlist verified Googlebot traffic

   For WAF, bot-protection, or rate-limiting rules (causes 1 and 2): in your CDN or firewall dashboard, add an explicit allow rule for Google's published crawler IP ranges, or for requests that pass reverse-DNS verification as genuine Googlebot. Don't just trust the user-agent string — verify the requesting IP resolves to a googlebot.com/google.com hostname and back again, since user agents are easy to spoof and you don't want to open the door to anything claiming to be Google.

3. Narrow an overly broad server rule

   For a misconfigured rewrite or .htaccess rule (cause 4): find the exact directive matching the URL (check your server config, reverse proxy, or CDN rule list) and tighten its pattern so it only catches what it was meant to — not Googlebot's requests as collateral.

4. Leave intentional access walls alone

   For a genuinely gated page (cause 3): there's nothing to fix. If you'd rather keep the URL out of Google's crawl attempts entirely instead of repeatedly serving a 403, add a Disallow in robots.txt — see Blocked by robots.txt — so Google stops trying and the report stops flagging it.

5. Re-test before requesting indexing

   After changing a rule, re-run URL Inspection → Test live URL. You want a clean 200. If it's still 403, check for a second layer doing the blocking — it's common to fix the CDN rule and discover a separate server-level firewall doing the same thing underneath.

Platform notes

• WordPress — check security plugins (Wordfence, Sucuri, iThemes Security) for bot-blocking or firewall rules, and any hosting-provider-level WAF (common on managed WordPress hosts like WP Engine or Kinsta) separately — plugin-level and host-level firewalls both need checking, since fixing one doesn't touch the other.
• Shopify — 403s are uncommon on Shopify's own infrastructure since it's fully hosted, but can occur if you've added password protection to the storefront (Online Store → Preferences) while the site is still meant to be crawlable, or if a custom app is intercepting requests.
• Next.js (React) — check middleware (middleware.ts) for any request-filtering logic that could reject requests based on user agent or missing headers, and your hosting platform's edge/firewall rules (Vercel's Web Application Firewall settings, or a fronting CDN) separately from application code.
• Webflow — password-protecting a site or specific pages (Project Settings → Site access) returns a 401/403-style gate to everyone, including Googlebot, by design — this is intentional for staging sites, but confirm it's off before launch if the site is meant to be public.

How to verify it's fixed

1. URL Inspection → Test live URL — the definitive, immediate check. Confirm a clean 200, and ideally re-test a few times since bot-protection rules can be triggered by request patterns that don't fire on every single attempt.
2. Crawl stats → Host status — over the following days, confirm the 403 rate for your site has actually dropped, not just for the one URL you spot-checked.
3. Pages report — request indexing once the live test is clean. Clearing from the report can take days to a few weeks; Google re-crawls on its own schedule and doesn't guarantee a specific turnaround.

When to ignore it

If the 403 is on a page that's genuinely meant to require access — a login-gated dashboard, a staging environment, an internal tool — this status is correct behavior and not worth chasing. It only needs fixing when it's stopping Google from reaching pages you actually want ranking.