A before/after log pair showing the same bot and URL moving from failure to 200.
A robots.txt audit is not “open the file and look for Disallow.” You need to prove what the bot requested, what responded, and whether the visitor was genuine.
Read one log line completely
198.51.100.24 - [21/Jul/2026:10:00:00]
"GET /guides/ai-analytics/ HTTP/1.1" 403 150
"Mozilla/5.0 (compatible; GPTBot/1.2)"The 15-minute diagnosis
- Confirm scope
Is one URL failing, one directory, one bot, or every AI bot? A single URL suggests page/security rules; every URL suggests WAF or robots policy.
- Verify the bot
Use forward-confirmed reverse DNS. Do not whitelist a crawler based only on its user-agent.
- Check each layer
robots.txt → CDN/WAF → host firewall → WordPress security plugin → application response.
- Retest the exact pair
Same bot identity, same URL, then confirm the new status in raw logs.
Response-code decision tree
Three situations, three fixes
It is a map, not a permission layer. A blocked or failing URL stays blocked or failing.
Field assignment
GPTBot receives 403 on your articles, but robots.txt says it is allowed. The block is somewhere else.
Find the response layer: WordPress, security plugin, CDN/WAF or origin server.
Test one affected URL with the bot user agent and record the response.
Change one rule, retest, and verify a clean 200 response in the logs.
A before/after log pair showing the same bot and URL moving from failure to 200.
