Blocked Due to Access Forbidden (403)

What’s actually happening

Search Console flags the URL under Page Indexing, and the page drops out of (or never enters) the index. Open it in your own browser and it loads normally — that's the trap. Googlebot is being served a 403 that you never see, usually by a security layer that decided the crawler looked hostile. The URL Inspection tool's live test will reproduce it: it comes back "Page cannot be indexed: blocked due to access forbidden."

Common causes

• A WAF or security plugin (Wordfence, Sucuri, Cloudflare bot-fight) treating Googlebot's request pattern as an attack and returning 403
• An .htaccess or Nginx deny rule — a too-broad user-agent or IP block that happens to catch Googlebot or Google's IP ranges
• Rate limiting / DDoS protection throttling the crawler once it requests more than a few pages per second
• The URL sitting behind login or an IP allowlist (staging, member-only area) that returns 403 to anonymous clients
• A CDN or origin firewall blocking Google's published IP ranges

How to fix it

1. Reproduce it as Googlebot, not as yourselfcurl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -I https://yourdomain.com/the-page . A 403 here confirms the block is user-agent driven. Then run the live test in URL Inspection — it crawls from Google's side and tells you exactly what it got.
2. Verify the IP really is Googlebot before you trust the user-agentAttackers spoof the Googlebot UA constantly, so don't whitelist by name. Pull the IP from your access log and run host <ip> ; a genuine Googlebot reverse-resolves to googlebot.com, google.com, or googleusercontent.com. Confirm with a forward lookup on that hostname back to the same IP.
3. Whitelist verified Googlebot in the security layerIn Wordfence/Sucuri, enable the verified-crawler allowlist instead of an open UA rule. In Cloudflare, turn off Bot Fight Mode for known good bots (or add a WAF skip rule for cf.client.bot). The goal is to let verified search crawlers through while still blocking spoofers.
4. Hunt down explicit deny rulesGrep .htaccess and the Nginx config for Deny from, deny all, and any SetEnvIf / map blocking on User-Agent or IP. A rule written to stop a scraper six months ago is the usual culprit. Remove or narrow it.
5. Confirm the URL is meant to be public, then validate the fix in Search ConsoleIf it's a staging or member URL, it shouldn't be in the sitemap at all — drop it. If it's public, once curl-as-Googlebot returns 200, hit "Validate Fix" on the issue in Page Indexing so Google re-crawls the set.