How to block fake ChatGPT bots in WordPress

If a visitor tells your WordPress site it is ChatGPT, should you believe it?

Most sites do. They read the User-Agent header, see something like GPTBot or ChatGPT-User, and treat the request as OpenAI. That instinct is exactly what a scraper, a price bot, or a content thief counts on. The header is not identity. It is a plain piece of text the caller typed, and it takes one line of curl to wear it.

Here is the entire toolkit for impersonating ChatGPT. No exploit, no special access, just a flag on a command anyone can run.

The naive server did nothing wrong by its own logic. It matched a name it recognized and let the request through. The problem is that the name proves nothing, so the real GPTBot and a bot pretending to be GPTBot look identical to it.

Why a block list does not work

The two reflexes most WordPress owners reach for both fail here.

The first is robots.txt. It is a polite request, not a control. A well-behaved crawler reads it and complies. An impostor ignores it, because nothing enforces it. If your goal is to stop bad actors, a sign on the door does not do it.

The second is a User-Agent allow list or block list, usually added through a security plugin or a few lines in .htaccess. This is worse than it looks. Block GPTBot by name and you punish the real OpenAI crawler you may actually want, while the impostor simply changes one string and walks in under a different name. Allow GPTBot by name and you have handed a skeleton key to anyone who types it.

Both requests carry the same header, so any name match treats them the same. The forgery is invisible to a check that only reads a string.

How to tell a real ChatGPT bot from a fake

There is only one reliable answer: verify a signal the caller cannot forge. The User-Agent then stops being proof and becomes a hint that tells you which check to run. Two of those signals exist today.

The strong one is a cryptographic signature. OpenAI now signs its crawler requests using Web Bot Auth, a scheme built on HTTP Message Signatures (RFC 9421). Each request carries an Ed25519 signature, and OpenAI publishes the matching public key at a well-known location on its own domain, chatgpt.com/.well-known/http-message-signatures-directory. To verify, you fetch that key, recompute its fingerprint so you never trust a self-reported key id, and check the signature over the request. A real GPTBot produces a valid signature. An impostor cannot, because it does not hold OpenAI's private key. GPTBot, OAI-SearchBot, and ChatGPT-User can all be proven this way.

The classic one is reverse DNS forward confirmation. Search engines like Google, Bing, and Apple do not sign requests, but they publish the domains their crawlers come from. You take the visitor's IP address, look up its hostname, confirm the hostname ends in the operator's domain, then resolve that hostname back and confirm it points to the same IP. An impostor can spoof a User-Agent, but it cannot make Google's DNS vouch for its IP. This is the same check that has separated the real Googlebot from fakes for years.

The flow below runs the same request through both an honest GPTBot and an impostor. Switch between them and watch where the two part ways.

Notice that the User-Agent is identical in both runs. The verdict comes entirely from what happens at the signature check.

Four verdicts, one decision

Once you verify instead of guess, every visitor lands in one of four states. Each state tells you how much proof there was, and each maps cleanly to an action you control.

The key move is separating spoofed from unverified. Spoofed means a proof was offered and it failed, a forgery you should block. Unverified means the agent is recognized by name but offered no proof, which is not an accusation, just an absence of evidence. Treating those two the same is how you either miss real attacks or block crawlers you wanted.

Who is actually knocking

Not every AI agent can be proven yet, and pretending otherwise leads to bad rules. The directory below is the set of agents worth recognizing, grouped by how their identity can be checked today.

Only the OpenAI crawlers and the major search engines can be verified right now. Perplexity, for example, does not publish a signing directory yet, so the honest move is to recognize it by name and decide your own level of trust, rather than claim a certainty you do not have. As more operators adopt Web Bot Auth, more of this list moves from "name only" to "cryptographically verified."

Do this in WordPress without writing code

You do not have to build any of this. The free AxioRank Agent Verification plugin puts the whole pipeline behind a settings page. It is a thin client: when a bot-like or signed request reaches WordPress, the plugin forwards a small envelope to AxioRank, which runs the signature and reverse DNS checks and returns a verdict, and the plugin applies it locally.

Getting started takes about five minutes.

1. Install and activate the plugin from your WordPress dashboard.

2. Create a free AxioRank account, register your site as a website surface, and copy the site key it gives you. It starts with axr_site_.

3. Paste the key into the plugin's Settings tab, or set it in wp-config.php so it lives outside the database:

   // wp-config.php
   define( 'AXIORANK_SITE_KEY', 'axr_site_your_key_here' );

4. Press Test connection, then leave the plugin in Monitor mode for a few days. It watches and logs, and it never blocks anyone while it learns.

5. Read the Activity tab. Every checked request shows who the visitor claimed to be, whether that claim held up, the verification method, the endpoint it hit, and a one click action to allow or block.

6. Add a rule or two, then flip the site to Enforce. Now spoofed agents get a clean block page and everyone else is served.

The plugin ships a full console, not just a switch. The Rules tab lets you allow, challenge, or block by agent, by category such as scrapers or training crawlers, by verification status, or by a risk threshold. There is a WordPress dashboard glance widget, a Site Health check, and WP-CLI support for anyone who lives in the terminal:

wp axiorank status
wp axiorank activity

What it protects, and what it does not

Being honest about the edges matters more than a bigger claim. A fully page-cached response, served by a caching plugin or a CDN, never boots PHP, so the plugin cannot see it. What it does see is every request that actually reaches WordPress: the REST API, admin-ajax.php, XML-RPC, the login page, on-site search, and any page load that misses the cache. For fully cached pages, run the same verification at your edge or CDN.

Two more guarantees are worth stating plainly. The plugin fails open: if AxioRank is slow or unreachable, requests are allowed, never blocked by accident. And it strips credentials before anything leaves your server, so cookies, passwords, and authorization headers are never sent for verification.

The takeaway

Blocking fake ChatGPT bots is not about maintaining a longer list of bad names. It is about refusing to treat a name as proof. Verify the signal an impostor cannot forge, a signature or a confirmed IP, and the fakes sort themselves out. On WordPress, that is a plugin and five minutes away.

Start with the AxioRank Agent Verification plugin, or read the WordPress verification guide for the full walkthrough.