AI Bot Access Report (Pro)
Gain operational visibility into recognized AI bots and LLM clients fetching your WordPress content. Track requested paths, local timestamps, response formats, HTTP status codes, and cache states with bounded local retention and a strict Zero-PII policy.
1. How AI Bot Access Reporting Works
The AI Bot Access Report monitors incoming HTTP requests handled by your WordPress origin. When a client matches standard signatures for recognized AI crawlers or LLM retrieval agents (such as OpenAI's GPTBot, Anthropic's ClaudeBot, or PerplexityBot), the plugin logs key technical telemetry into a dedicated local database table.
User-Agent header pattern matching. It does not perform cryptographic signing verification or reverse-DNS lookups. In open HTTP protocols, User-Agent strings can technically be simulated by third parties.
2. Recorded Data Fields & Zero-PII Architecture
The logging mechanism is engineered with a strict Zero-PII (Personally Identifiable Information) standard. It captures only operational telemetry necessary to evaluate content delivery performance:
- Bot Name: Recognized crawler token identifier (e.g.,
GPTBot,ClaudeBot,PerplexityBot). - Sanitized Path / URL: The normalized site path requested by the bot (e.g.,
/articles/ai-overview/). Tracking parameters, session identifiers, tokens, passwords, and all non-whitelisted query values are discarded; only valid pagination parameters namedpaged,page, orcpagemay remain in the sanitized URL. - Response Format: Content format served (
Markdown,HTML,llms.txt, orError). - HTTP Status Code: Origin HTTP response status (e.g.,
200 OK,304 Not Modified,404 Not Found). - Cache State: Plugin caching status at delivery time (
HIT,MISS, orBYPASS). - Timestamp: Stored internally in universal coordinated time (UTC) for reliable sequence sorting, and automatically converted to your WordPress site's local timezone for dashboard display.
paged, page, or cpage may remain in the sanitized URL.
3. Retention Periods & Capacity Bounding
To prevent unbounded database growth and maintain peak MySQL performance, the access log operates with configurable retention schedules and automatic capacity caps:
Configurable Retention Window
The default retention window is 30 days. Site administrators can customize this setting to 7, 14, 30, 60, or 90 days according to their compliance and auditing needs.
Staggered Automatic Pruning
Non-blocking scheduled routines clean up expired log rows in controlled batches, ensuring routine maintenance does not impact front-end visitor response times or lock database tables.
Capacity Safety Thresholds
Hard limits prevent runaway log size if a site experiences heavy bot traffic. If the maximum capacity threshold is reached before expiry, older entries are gracefully pruned first.
Manual Log Clearing
Administrators can wipe all recorded access logs at any time with a single click in WP-Admin using the dedicated "Clear Access Logs" action.
4. Dashboard Navigation, Filters & Daily Volume Insights
Access the reporting interface directly within your WordPress administrative dashboard under Settings → SEOries Markdown Generator → Bot Access Report.
Summary Metrics & 7-Day Daily Breakdown
The top of the report presents high-level summary cards showing total logged events, Markdown deliveries, HTML fallbacks, and active crawler families. Directly below, a Daily Volume Breakdown summarizes activity over the last up to 7 local days (displaying Date, Total Accesses, and Markdown Deliveries). When no crawler requests have occurred yet, an honest empty state is displayed.
Interactive Filtering Controls
Narrow down access history using multi-dimensional filters:
- Date Range: Choose a start date and end date in your WordPress site timezone to narrow the recorded access history.
- Bot Family: Filter by individual recognized crawler (e.g.,
GPTBot,ClaudeBot,PerplexityBot). - Response Format: Focus on
Markdown,HTML,llms.txt, orErrorresponses. - Path Filter: Search by specific post slugs, documentation paths, or content directories.
5. Testing & Simulating Bot Requests
You can verify that your WordPress server is logging recognized crawlers by sending a simulated request from terminal using curl:
# Send request with recognized GPTBot User-Agent and Accept header
curl -i -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot)" \
-H "Accept: text/markdown" \
https://your-site.com/my-post/ - Request reaching WordPress origin is logged in the Bot Access Report table.
- Shows
GPTBotas the bot name,/my-post/as path, andMarkdownformat. - Timestamp reflects access time converted to your WordPress local timezone.
- Traditional search engines (like
Googlebot) are not AI LLM clients and are excluded from this report. - Logging an access event does not guarantee third-party indexing, AI ranking, or retrieval citation.
- Requests served by upstream CDN edge caches before hitting origin do not appear in this log.