Blocked due to access forbidden (403): causes and fix

Updated 25 October 2026

Search Console shows Blocked due to access forbidden (403) when Googlebot asked for a URL and your server answered HTTP 403. Google's help page is blunt about it: a 403 means the visitor sent credentials and was refused, and "Googlebot never provides credentials, so your server is returning this error incorrectly." The page will not be indexed until Googlebot gets a normal answer.

If the URL is private (an account page, an admin area, a staging copy), the 403 is doing its job: take the URL out of your sitemap and internal links and leave it. If the page should be public, something between Googlebot and the page is turning it away.

Step 1: reproduce it with the real Googlebot

Open URL Inspection in Search Console, enter the URL and click Test live URL. That request comes from Google's own crawler and Google's IP addresses, so it is the only test a firewall treats exactly like the crawl that failed. If the live test now succeeds, the 403 may have been temporary (a rate limit, a short-lived block rule); check Crawl stats for how often it happens.

Two quicker checks:

• Open the URL in a private browser window. If you get a login page or a 403 there too, the page isn't public. Google treats a login prompt as a separate status, Blocked due to unauthorized request (401), and the fix is the same idea.
• Run the form above. If our bot gets a 403 and your browser doesn't, your site is refusing bots, not people.

A curl request with a Googlebot user agent doesn't prove much either way. Most firewalls check where a request comes from, not just what it calls itself, so a fake Googlebot from your laptop can be blocked while the real one is let in, or the other way round.

Step 2: the usual causes, in order

1. A CDN or WAF rule. A custom rule that blocks "bots", certain countries or certain networks, or a rate limit, catches Googlebot along with the traffic it was meant for. Google crawls mostly from US addresses, so a rule that blocks or challenges visitors from outside your country can catch it.
2. Cloudflare Bot Fight Mode. See the next section: it doesn't obey the usual exception rules.
3. A hosting or plugin firewall. Security plugins and host-level firewalls have their own bot, country and rate-limit settings. Look at their block log for the URL and the time of the failed crawl.
4. A login wall. Membership plugins, password-protected pages, or a whole site behind basic auth while it was "under construction".
5. Server configuration. A Deny rule in .htaccess, an nginx deny or return 403, or file permissions the web server can't read. These usually block everyone, so your browser sees the 403 too.

Cloudflare: find the rule, and the Bot Fight Mode exception

In the Cloudflare dashboard, open the security Analytics page, select the Events tab and filter by the URL path or by user agent containing Googlebot. Each event shows the action taken and the security feature that took it (a custom rule, rate limiting, a managed rule). Cloudflare keeps a list of verified bots, Googlebot among them, so with default settings Googlebot usually gets through; the block is normally a rule someone added.

Bot Fight Mode, the free bot protection, is the exception. Cloudflare's docs say: "You cannot bypass or skip Bot Fight Mode using WAF custom rules or Page Rules." It runs in its own pipeline, where Skip, Bypass and Allow have no effect. An IP Access rule that matches first does stop it, and Super Bot Fight Mode (paid plans) accepts Skip rules. If Bot Fight Mode is the cause and you can't upgrade, turning it off is the clean fix.

Step 3: let Googlebot in safely

Google's fix for this status is to admit visitors who aren't signed in, or to explicitly allow Googlebot without authentication, after checking that the request really comes from Google. Don't allow by user agent alone: anyone can send Googlebot in that header. Google documents two ways to check:

• Reverse DNS on the IP address must end in googlebot.com, google.com or googleusercontent.com, and a forward lookup of that name must return the same IP.
• Or match the IP against Google's published list, https://developers.google.com/static/crawling/ipranges/common-crawlers.json.

Most CDNs and security plugins have a "verified bots" or "known crawlers" setting that does this for you. Use it rather than writing your own allow rule.

Step 4: confirm the fix

Run Test live URL again. When it succeeds, click Validate Fix on the status in the Page indexing report. Google says validation "typically takes up to about two weeks, but in some cases can take much longer". If the page was indexed before the 403s, you can also request indexing from URL Inspection.

Sources: Google Search Console Help, Page indexing report; Google Search Central documentation, Verifying Googlebot and other Google crawlers; Cloudflare documentation, Bot Fight Mode. Related: My site disappeared from Google · letting a monitoring bot through a firewall.