Imedes AI Bot Verify
Imedes AI Bot Verify
Description
AI Bot Verify (ABV) verifies whether supported AI bot requests really come from the provider they claim to represent.
A User-Agent such as GPTBot, ClaudeBot or PerplexityBot is only a claim. User-Agent strings can be changed freely, so they do not prove that a request actually came from OpenAI, Anthropic or Perplexity.
ABV checks supported AI bot claims against provider-published network information and, where available, cryptographic HTTP Message Signatures. Verified requests are allowed to continue normally. Requests that claim a supported identity but fail verification are blocked with HTTP status 403.
ABV is not a general-purpose bot blocker or web application firewall. It focuses on one question:
Is this request really coming from the AI agent it claims to be?
Why verify AI bots instead of simply blocking them?
Blocking all AI bots is a valid policy for a site that does not want any AI access.
ABV is intended for sites that want to distinguish legitimate AI traffic from impersonation. A site owner may want to allow a legitimate AI crawler or user-directed AI agent while rejecting requests that only copy a known AI bot name.
Verification also matters when legitimate AI agents receive different treatment from generic crawlers or scraping tools. For example, a site may intentionally permit a verified AI agent to access content that is restricted for ordinary scrapers. Without verification, a scraper could simply copy that AI bot’s User-Agent and attempt to receive the same access.
ABV does not create special access rights and does not decide which content an AI provider may access. It verifies the identity claim so that other access rules do not have to trust the User-Agent alone.
Why isn’t a firewall or security plugin enough?
Using Cloudflare, Wordfence or another CDN, web application firewall or WordPress security plugin does not by itself mean that AI bot identities are being verified.
Traditional security tools are primarily designed to detect malicious requests, exploits, abusive behavior and other known attack patterns. A request that simply presents itself as GPTBot, ClaudeBot or another recognized AI agent may not look malicious at all.
The identity problem is different: a request can behave normally while still using a false User-Agent.
Some infrastructure and security providers offer their own verified-bot features, depending on the service, plan and configuration in use. Other bot-detection features may identify AI crawlers primarily from their User-Agent or general request behavior.
ABV performs identity verification directly for its supported AI bot claims at the WordPress origin. It checks whether the claimed identity can actually be validated against provider-published verification data instead of assuming that an AI bot name in the User-Agent is genuine.
ABV therefore complements a firewall, security plugin or CDN rather than replacing one. These tools answer different security questions.
Can fake AI bots create unnecessary server load?
Yes. Fake AI bot traffic is not only an identity problem. It can also cause unnecessary work at the WordPress origin.
A request using a supported AI bot User-Agent can target normal pages, outdated URLs, random paths or non-existent resources. If such a request is routed to PHP and WordPress, WordPress may still bootstrap, load plugins and process routing before eventually returning a 404 response.
ABV verifies supported AI bot claims before the normal WordPress request continues. If the claimed identity fails verification, ABV blocks the request with HTTP status 403 at the verification gate. This can reduce unnecessary WordPress processing caused by spoofed AI bot requests, including requests for URLs or resources that do not exist.
If a web server, CDN or other upstream layer handles a missing resource before the request reaches WordPress, ABV is not involved in that request. In that case there is also no WordPress execution for ABV to avoid.
ABV is not a rate limiter or DDoS protection system. Its performance benefit is limited to spoofed supported AI bot claims that actually reach the ABV verification gate.
How ABV works
For supported AI bot claims, ABV performs identity verification before the normal request continues.
Depending on the supported agent, verification can include:
- checking the request IP address against network ranges published by the provider,
- validating supported OpenAI HTTP Message Signatures using provider-published Ed25519 public keys.
If verification succeeds, the request is allowed to continue normally.
If a supported identity is claimed but verification fails, ABV records the event, sends no-cache response headers and blocks the request with HTTP status 403.
Requests that do not claim a supported AI bot identity are ignored by the verification gate.
Supported AI bot claims
ABV currently verifies network claims for:
- OpenAI OAI-SearchBot
- OpenAI GPTBot
- OpenAI ChatGPT-User
- OpenAI OAI-AdsBot
- Anthropic ClaudeBot
- Anthropic Claude-User
- Anthropic Claude-SearchBot
- PerplexityBot
- Perplexity-User
ABV also verifies the supported OpenAI Secure Agent HTTP Message Signature using provider-published Ed25519 public keys.
ABV does not attempt to identify or verify every AI bot on the internet. Unsupported bots and unrelated traffic are outside its verification scope.
Request logging
ABV records supported AI bot requests so that verified and rejected requests can be reviewed in WordPress.
Normal visitor requests and unrelated bots are not logged by ABV.
Relevant requests are written to a local log file first. They are imported into the WordPress database once per day instead of causing a database write on every request.
Imported request records are retained for 30 days. Expired records are removed automatically during the daily or manual import. Administrators can also delete all stored and pending request data manually from the ABV request view.
The request table can distinguish between:
- verified requests that were allowed,
- fake or impersonated claims that were blocked,
- verification errors.
Stored request information can include the request time, method, URI, IP address, User-Agent, detected agent/provider, verification result, action and verification reason.
Provider data updates
ABV retrieves public network information and signature verification keys from the supported providers.
A fresh provider update is required when ABV is enabled from its admin page. Provider data is then refreshed once per week through WP-Cron and can also be updated manually from the Provider Data tab.
If a scheduled update fails, ABV keeps the last valid provider data instead of replacing it with incomplete or invalid data.
If no fresh valid provider data can be obtained when ABV is being enabled, ABV remains disabled.
Activation model
Activating the WordPress plugin does not automatically enable verification or modify the active request path.
ABV is enabled separately from its own admin page. Before ABV can be enabled, its requirement test checks whether upstream main-document caching would prevent reliable origin verification.
A successful requirement test unlocks the ABV enable action. When ABV is enabled, it:
- performs a fresh provider-data update,
- installs a small Must-Use Plugin loader for the early verification gate,
- adds origin-side page-cache compatibility rules for supported AI bot requests,
- schedules the daily request-log import,
- schedules the weekly provider-data update.
Disabling ABV from its admin page removes the active MU loader and cache-bypass rule and unschedules the ABV cron events. Uninstalling the plugin also removes ABV’s stored data.
CDN and cache compatibility
Using a CDN is not inherently incompatible with AI Bot Verify.
ABV performs verification at the origin server. The important requirement is therefore that a request which needs verification actually reaches the origin with the information required for verification.
CDN functions that do not prevent the main document request from reaching the origin do not interfere with ABV. This can include, depending on configuration:
- caching of static assets such as CSS, JavaScript, fonts and images,
- DNS services,
- security and filtering features,
- other CDN or proxy functions that still forward the relevant main document request to the origin.
The problematic case is upstream caching of the main document. If a CDN or reverse proxy serves the requested HTML document directly from its edge cache, WordPress and ABV never receive that request. ABV cannot verify or block a request it never sees.
ABV’s compatibility concern is therefore not the presence of a CDN itself. It is whether upstream handling can serve the relevant main document before the request reaches the origin.
External Services
ABV depends on public data published by OpenAI, Anthropic and Perplexity to verify supported AI bot identities.
These external requests occur:
- when ABV is enabled,
- when an administrator manually requests a provider update,
- during the weekly provider-data update cron.
The requests contain the normal HTTP metadata required to fetch the public provider files and an ABV updater User-Agent. ABV does not send stored request logs or WordPress content to these services.
OpenAI
ABV retrieves bot network data and Secure Agent signature keys from:
- https://openai.com/searchbot.json
- https://openai.com/gptbot.json
- https://openai.com/chatgpt-user.json
- https://openai.com/adsbot.json
- https://chatgpt.com/.well-known/http-message-signatures-directory
OpenAI terms and privacy information:
- https://openai.com/policies/terms-of-use/
- https://openai.com/policies/privacy-policy/
Anthropic
ABV retrieves supported Claude bot network data from:
- https://claude.com/crawling/bots.json
Anthropic terms and privacy information:
- https://www.anthropic.com/legal/consumer-terms
- https://www.anthropic.com/legal/privacy
Perplexity
ABV retrieves supported Perplexity bot network data from:
- https://www.perplexity.com/perplexitybot.json
- https://www.perplexity.com/perplexity-user.json
Perplexity terms and privacy information:
- https://www.perplexity.ai/hub/legal/terms-of-service
- https://www.perplexity.ai/hub/legal/privacy-notice
Privacy
ABV processes request information only for supported AI bot identity claims and the supported OpenAI Secure Agent signature mechanism.
ABV can store request IP addresses, User-Agent strings, requested URIs and verification metadata locally on the WordPress installation for the purpose of displaying verified, fake and error events in the plugin interface. Imported request records are automatically retained for 30 days unless they are deleted manually earlier.
ABV does not send these stored request records to OpenAI, Anthropic or Perplexity.
Site owners are responsible for ensuring that the plugin’s 30-day maximum retention period, or earlier manual deletion, complies with the laws and policies applicable to their site.
Installation
- Install and activate AI Bot Verify in WordPress.
- Open AI Bot Verify in the WordPress admin menu.
- Run the requirement test.
- Resolve any detected upstream main-document caching that prevents reliable origin verification.
- Click Enable AI Bot Verify.
Enabling ABV performs a fresh provider-data update before the verification gate becomes active.
Screenshots
Faq
No. A supported AI bot request that verifies successfully is allowed to continue normally.
ABV blocks requests that claim a supported AI bot identity but fail the corresponding verification.
Blocking all AI bots is a valid policy if a site does not want AI access.
ABV is for sites that want to distinguish legitimate AI traffic from impersonation. This makes it possible to allow genuine supported AI agents without automatically trusting every request that uses their names.
Yes. A User-Agent can be changed freely and is not proof of identity.
A scraper can send a request using a known AI bot User-Agent. ABV verifies supported claims instead of trusting that string by itself.
An identity claim is only worth faking if it is worth something. Someone impersonating an AI bot picks the identity most likely to grant the desired treatment — meaning the most recognized and most trusted names, not obscure or low-traffic crawlers.
ABV therefore focuses verification on the AI bot identities most likely to be impersonated, rather than attempting to cover every crawler that claims to be AI-related.
Yes. That is one reason to verify identity before applying access rules.
A site may choose to allow a verified AI agent where generic crawlers or scraping tools are restricted. Without verification, a scraper could attempt to obtain the same treatment simply by copying the AI bot’s User-Agent.
ABV itself does not grant special content permissions. It only verifies the supported identity claim. The site’s own rules still decide what a verified agent may access.
Yes, depending on configuration.
The presence of QUIC.cloud does not by itself make a site incompatible with ABV. Using QUIC.cloud for asset caching or other services that still allow relevant main document requests to reach the origin does not prevent ABV from operating.
The incompatible case is QUIC.cloud CDN caching of the main document. ABV’s requirement test checks the public main document for the QUIC.cloud cache header. If that cache layer is active for the main document, the requirement is blocked because the request can be answered before WordPress and ABV receive it.
The issue is main-document caching before the origin, not QUIC.cloud itself.
The same principle applies.
Cloudflare or another CDN is not inherently incompatible with ABV. Asset caching, DNS, security features and other proxy services can be used normally as long as the relevant main document requests still reach the origin.
If an upstream cache is active for the main document, ABV cannot reliably guarantee that every supported AI request reaches the verification gate. The requirement test therefore checks for main-document cache indicators rather than treating CDN presence alone as a failure.
No.
ABV verifies the main request handled by WordPress/PHP. Cached CSS, JavaScript, fonts, images and other static assets do not need to pass through ABV and do not interfere with identity verification.
The underlying issue is the same: ABV cannot verify a request that is answered from page cache before the verification gate runs.
ABV therefore installs origin-side compatibility rules for supported AI bot claims and the supported OpenAI Signature-Agent. LiteSpeed/LSCache receives a native no-cache flag. Apache rewrite-based page caches are bypassed by routing matching main-document requests to WordPress before their static cache rules can serve HTML.
This covers the rewrite-cache modes used by WP Rocket, WP Super Cache Expert mode, W3 Total Cache Disk: Enhanced and WP Fastest Cache, in addition to LiteSpeed/LSCache.
If ABV blocks a request, the 403 response is also sent with no-cache headers.
An upstream CDN cache is a separate layer. ABV cannot control an edge cache in the same way, so main-document caching at that layer must be configured so that requests requiring verification still reach the origin.
Yes.
Spoofed AI bot requests can target valid pages as well as outdated, random or non-existent URLs. When those requests reach PHP and WordPress, they can still trigger WordPress processing even if the final result is only a 404 response.
ABV blocks failed supported identity claims at its early verification gate before the normal WordPress request continues. This can avoid unnecessary WordPress execution for those fake AI bot requests.
Requests that are answered by the web server, CDN or another upstream layer before they reach WordPress are outside ABV’s request path.
No.
Supported AI bot requests are written to a local log file first and imported into the database once per day. This avoids a database write on every verified AI bot request.
A manual import is also available from the ABV admin page.
Imported request records are retained for 30 days.
Expired records are removed automatically whenever the daily or manual log import runs. The request view also provides a Delete all request data action that removes both imported database records and pending ABV request-log entries.
ABV performs a fresh provider-data update when verification is enabled, then refreshes the data once per week through WP-Cron.
A manual update is also available from the Provider Data tab.
ABV will not enable if the required fresh update fails.
Once ABV is already running, a failed scheduled update does not replace previously validated data with an incomplete or invalid data set. The last usable provider data remains available until a later update succeeds.
Yes. The PHP Sodium extension is required for the supported OpenAI Ed25519 signature verification. ABV cannot enable the verification gate if the required Sodium function is unavailable.
No.
ABV contacts provider endpoints only to retrieve public network data and signature verification keys. It does not send stored ABV request logs, WordPress posts, pages or other site content to those providers.
No.
ABV verifies the supported AI bot identities listed above. It is not intended to classify, rate-limit or block every crawler, scraper or malicious request on a WordPress site.
Reviews
Changelog
1.0.0
- Initial release.