Imedes AI Bot Verify

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.

1. Install and activate AI Bot Verify in WordPress.
2. Open AI Bot Verify in the WordPress admin menu.
3. Run the requirement test.
4. Resolve any detected upstream main-document caching that prevents reliable origin verification.
5. Click Enable AI Bot Verify.

Enabling ABV performs a fresh provider-data update before the verification gate becomes active.

1.0.0

• Initial release.