A 403 means the request reached a responding system but access was refused. Check CDN rules, web application firewalls, bot protection, geographic restrictions, signed requests, application middleware, and origin permissions.
- Decide whether the URL should be public before changing a forbidden response.
- Compare edge and origin evidence to locate the layer that generates the 403.
- Verify Googlebot by IP ranges or forward-confirmed reverse DNS, not by user-agent text.
01
Preconditions

Confirm whether the URL is intended for the public internet. A private administrative route, paid resource, or network-restricted application may correctly refuse access. A public article that works for the owner but fails for Googlebot is a different problem.
Collect:
- the exact URL and response time;
- response headers and body;
- Search Console’s last crawl date;
- CDN, WAF, bot-management, and firewall events;
- application and origin access logs;
- geographic, network, and signed-request rules;
- a record of recent security or deployment changes.
Google’s Page Indexing report says a page returning 403 will not be indexed. If the page should be public, unauthenticated access or a safely verified crawler path must be restored. Page indexing report[1]
Keep a rollback path for every security-rule change and narrow the investigation to the affected public route, rule, and request class.
02
Ordered process
- Verify the exact forbidden response.
Run an uncached request through the public hostname. Record:
HTTP/2 403
content-type: text/html
server: edge
x-request-id: example-incident-idThe body may name a challenge, policy, or blocked geography. Preserve request IDs for operational review without publishing sensitive logs.
- Decide whether the restriction is intentional.
| URL state | Correct behavior |
|---|---|
| Public article or product page | Unauthenticated content is available |
| Admin, account, or confidential page | Access restriction remains |
| Staging environment | Restriction remains; discovery signals are removed |
| Public page with protected actions | Page remains public; sensitive actions enforce authorization separately |
Do not weaken private data exposure to satisfy indexing.
- Compare the edge and origin.
| Observation | Likely owner |
|---|---|
Edge returns 403; authorized origin test returns 200 | CDN, WAF, bot rule, geography |
Edge and origin both return 403 | application, web server, filesystem permission |
| Only one path or method fails | route or method policy |
| Only one network or region fails | geographic or IP rule |
Browser gets a challenge and crawler gets 403 | bot-management policy |
Use safe, authorized origin checks. Do not expose or bypass an origin merely for diagnosis.
- Review CDN, WAF, and bot-protection events.
Look for managed-rule matches, reputation scores, rate limits, JavaScript challenges, cookie requirements, IP lists, and automated security responses. A browser may pass a challenge and store a cookie, while Googlebot cannot complete that interactive flow.
- Check application and origin permissions.
Review route middleware, access-control lists, file permissions, signed URL checks, referrer rules, and proxy authentication. A deployment can accidentally inherit a staging policy or restrict a newly created directory.
- Verify crawler identity safely.
Do not trust a request merely because its user-agent contains “Googlebot.” Google documents two suitable methods: match the source IP against published crawler ranges, or perform reverse DNS and then forward DNS to confirm the hostname resolves back to the original address. Verify requests from Google crawlers and fetchers[3]
Avoid broad crawler allowlists that bypass application authorization. Fix the rule that wrongly classifies legitimate public requests.
- Review geography, network, and request assumptions.
Check whether access depends on:
- country or region;
- IPv4 versus IPv6;
- data-center network classification;
- missing cookies or JavaScript;
- request headers;
- method or content negotiation;
- signed query parameters;
- edge-versus-origin hostname.
One successful office-network request does not prove global public access.
- Restore the intended public response and retest.
For public content, the final URL should return stable intended content without an interactive challenge. Ordinary 4xx responses tell Google that content is unavailable and are not used for indexing. How HTTP status codes affect Google's crawlers[2]
Use Crawl Stats to see whether forbidden responses cluster in time and URL families. Crawl Stats report[4] Then run live URL Inspection on representative routes. URL Inspection Tool[5]
03
Failure cases
- A browser session passes a stored challenge. Googlebot still receives
403. - The user-agent is trusted. Spoofed crawlers inherit the exception.
- The entire WAF is disabled. A narrow rule defect becomes an unnecessary security regression.
- Only the origin is tested. The production edge remains broken.
- Only the edge is tested. The CDN cache hides an origin permission problem.
- Geographic restrictions are forgotten. Testing from one location misses the affected path.
- A public page requires signed parameters. Search and internal links expose a URL that expires.
- Rate limiting emits
403. Overload and forbidden access become indistinguishable. - A
robots.txtchange is used to fix access. Crawl preferences do not repair the HTTP response.
The 401 playbook covers a credential challenge. The Other 4xx explainer covers other client-error responses. If the edge cannot reach a healthy origin and emits a gateway failure, continue with Server Error 5xx.
Treat a security exception as a production change: identify the exact policy owner, preserve the prior rule, and verify that unrelated protected routes remain closed after the public route recovers.
When evidence differs between tools, prefer the response observed on the public production path at the recorded time. Then use edge and origin request identifiers to explain the difference instead of repeatedly loosening controls until one test becomes green.
04
Completion criteria
The repair is complete when:
- the public-versus-restricted intent is documented;
- public pages return intended content without credentials or interactive challenges;
- private pages remain protected and are removed from public discovery;
- edge and origin responses agree;
- WAF and bot events no longer flag representative public routes;
- geographic and network variants were sampled;
- no user-agent-only trust rule was introduced;
- verified Googlebot evidence and live URL Inspection show successful access;
- Crawl Stats no longer shows a continuing 403 pattern after recrawl.
Do not promise an immediate indexing change. The live response can be fixed before the Page Indexing report updates. Continue with the robots.txt guide only if a separate crawl rule also applies.
References
Sources behind this record
- Page indexing report — Google (accessed July 25, 2026)
- How HTTP status codes affect Google's crawlers — Google (accessed July 25, 2026)
- Verify requests from Google crawlers and fetchers — Google (accessed July 25, 2026)
- Crawl Stats report — Google (accessed July 25, 2026)
- URL Inspection Tool — Google (accessed July 25, 2026)
Corrections
Correction history
No corrections recorded.
To report an error, use the public corrections path.
A public page can fail only at certain edges, networks, or request patterns, so one successful local request does not close the investigation.