Blocked due to access forbidden (403)

Where you see it: Search Console → Indexing → Pages → Why pages aren’t indexed

When Googlebot requested this URL, your server answered 403 Forbidden, so Google couldn’t read the page and won’t index it. A 403 is meant for a visitor whose credentials were refused, and Googlebot never sends any, so Google’s help says your server is answering wrongly. On WordPress, a firewall, security plugin or host rule is usually behind it.

Fix it if the page should be public; keep Google away if it never should be.

Open the URL in a private window. If it loads for you, something is singling out Googlebot or bots in general, and Google drops pages that answer with a 4xx, so a post or product here is urgent. A members-only area, admin path or protected file doesn’t belong in Google anyway.

Check a URL now Can RankHive fix it? No

Check the URL Search Console listed

Paste the URL Search Console listed. The checker requests it from a server, follows any redirects and shows the status code at every hop, so you see whether the 403 comes from the URL or from a redirect target. It identifies itself as RankHiveTools, not Googlebot.

Redirect report

Enter a URL to see every hop it passes through, with the status code at each step.

Reading the result

Final status 403 with no redirects: the server, or something in front of it, refused this exact URL. URL Inspection’s live test shows whether Googlebot gets the same answer.
A redirect chain that ends on 403: the URL is fine, but it sends visitors to a blocked address, for example an old rule pointing into a protected folder. Fix the target.
Final status 200: the checker got through. If Search Console still says 403, the block has since lifted, or it targets Google’s user agent or IP addresses.
Final status 401: a password prompt, such as host-level directory protection. Search Console files that under Blocked due to unauthorized request (401).

The same tool with its full guide: Redirect Checker

Why it happens on WordPress

A published WordPress post or page doesn’t answer 403 by default. When Google gets one, a layer in front of WordPress, or a plugin, decided the request shouldn’t come in.

A security plugin rule that misfired

Wordfence answers a request that trips a firewall rule with a 403 page saying a potentially unsafe operation was detected. A rule tuned for attacks can catch an ordinary URL with an unusual parameter. Wordfence’s Live Traffic view shows which rule fired.

Cloudflare bot and WAF rules

Cloudflare’s bot and WAF rules can challenge or block crawlers, and a custom rule that blocks by user agent, country or IP range can catch Googlebot. A custom rule’s Block action answers 403 unless someone set a different code. Cloudflare’s Security Events show requests it blocked or challenged, with the rule that acted.

Country blocking and Google’s US addresses

If you block countries, remember that Google’s crawlers send requests mainly from US IP addresses. Wordfence serves its own block page to visitors stopped by country blocking, its IP blocklist or rate limiting, so run a listed URL through the redirect checker and see which status that page sends.

Blocks at the host or server

Managed hosts and server firewalls refuse requests before WordPress loads: bot filters, blocked IP ranges, rules against unknown user agents. No WordPress screen shows these; your host’s logs do.

Folders the server won’t serve

A folder the web server can’t read, or one with no index file while directory listings are off, answers 403. When the listed URLs are images or PDFs in one upload folder, permissions on that folder are the first suspect.

Hotlink rules written by hand

Hotlink protection refuses image requests that come from other sites. Cloudflare’s version lets requests with no referrer through and says it doesn’t affect crawling, so look at a hand-written .htaccess rule that also refuses empty referrers.

How to fix it

Verify before you allowlist anything. Plenty of bad bots call themselves Googlebot, and a rule that trusts the name opens the door to them.

1. Test it as yourself and as Google
Open the URL in a private window, then run Test live URL in URL Inspection. Loads for you but Page fetch fails: the block targets Googlebot. Both fail: it is protected for everyone.
2. Find the refused request in a log
Search Wordfence’s Live Traffic, Cloudflare’s Security Events or your host’s access log for the URL around Google’s crawl time. Note the IP address, user agent and blocking rule.
3. Confirm the IP belongs to Google
Google’s own method is a two-way DNS check.
- Run host on the IP, for example host 66.249.66.1, and check the name ends in googlebot.com, google.com or googleusercontent.com.
- Run host on that name and check it returns the same IP. Both steps matter, because anyone can point reverse DNS at a googlebot.com name.
- Or compare the IP with the IP range files Google publishes for its crawlers.
- If it isn’t Google’s IP, the block was right. Leave it.
4. Allow verified Googlebot in the tool that refused it
Change the rule where it lives, not with a new rule somewhere else.
- Wordfence: for a firewall rule, allow the URL or parameter it blocked. Check that country blocking doesn’t cover the United States, and that rate limiting gives verified Google crawlers unlimited access.
- Cloudflare: filter Security Events for Googlebot or Bingbot requests that were blocked or challenged, note the rule or bot setting that acted, and change that one.
- Host or server firewall: send your host the blocked IPs and times, and ask them to allow verified Googlebot.
5. Fix the URL when the block is about the file
For images and PDFs refused to everyone, ask your host to correct the folder permissions or the hotlink rule. For a redirect that ends on a 403, point it at a public page.
Redirect checker
6. Keep private URLs away from Google
Members-only pages, staging folders and admin paths are right to refuse Google. Stop linking them from public pages and leave them out of your sitemap. If Google keeps requesting them, a robots.txt Disallow line stops the crawling.

Don’t use a 403 to slow Googlebot down

Google says not to use 401 or 403 to limit crawling, and that 4xx answers other than 429 don’t change crawl rate at all: they drop the pages from search. When your server struggles, a short spell of 503 or 429 tells Google to back off without losing the pages.

A 403 on robots.txt itself backfires differently: Google treats it as if no file existed and assumes it may crawl every URL.

Check the fix in Search Console

Confirm the fix with Google’s own fetch. The checker on this page can’t pass itself off as Googlebot.

Run Test live URL on a listed URL. Page fetch should read Successful.
Click Request indexing for the most important pages that were blocked.
Validation passes only when no rechecked URL still answers 403, and stops with Failed at the first one that does, so one members-only path in the list sinks it.
With only public pages listed, open Blocked due to access forbidden (403) in Indexing → Pages and click Validate fix. Google’s help warns a run can take around two weeks, sometimes much longer.
If it fails on a page you meant to open, look for a second layer: a request Cloudflare lets through can still be refused by a plugin behind it.

When private URLs share the list with fixed pages, skip validation. The fixed pages drop off as Google recrawls them, and the private ones stay listed, as they should.

Can RankHive fix this?

No. The block lives in a firewall, security plugin, CDN or host setting, and RankHive touches none of them. It can tidy the WordPress side: links to private URLs, and robots.txt lines for paths Google shouldn’t request.

What it writes, once you approve

Edits to links inside posts and pages that point at a private URL, removing or repointing them.
A Disallow line in the virtual robots.txt WordPress generates, for a private path. A physical robots.txt file in the site root overrides it.

What it can’t do here

Change Wordfence or other security plugin settings, allowlists or country blocks.
Change Cloudflare bot settings or WAF rules.
Change host or server firewall rules, file permissions or .htaccess.
Check IP addresses or read your server logs.
Run Request indexing or Validate fix; it only reads Search Console.

Every change is drafted next to the current value and waits for your approval. Each one written is logged in the Change Log, with Revert.

Check the rest of your site while you’re here

The free site check reads your public pages for titles, meta descriptions, headings, canonical tags and schema, and shows what needs fixing. If you sign up, RankHive reads your Google Search Console data every week, drafts the fixes, and writes the ones you approve to WordPress. Nothing changes on your site until you say yes.

Related issues

Common questions

Is a 403 in Search Console bad for SEO?

Yes, for pages you want found. Google drops URLs that answer with a 4xx. For private areas that should never rank, the 403 is correct.

Why does my page load for me but Googlebot gets 403?

Because the block judges the visitor, not the page: a bot rule, a country block or a user-agent filter. Your browser passes; Google’s crawler doesn’t.

Should I allowlist Googlebot by user agent?

No. Anyone can send a Googlebot user agent. Allow verified Google crawlers, checked by DNS or Google’s published IP ranges.

Does Cloudflare block Googlebot?

It can. Bot and WAF rules can challenge or block crawlers, including a custom rule that matches a user agent or country. Look in Cloudflare’s Security Events for Googlebot or Bingbot requests it stopped.

Sources

Checked against these pages on 17 October 2026.