Pickrate
WordPress

See which AI agents read your WordPress site

Install the plugin, paste a key, done. It reports from the server after the page has gone out, so it never costs a visitor anything.

Why you can't see them today

Every analytics plugin on your site is a browser script — Google Analytics, Jetpack, whatever your theme bundles. An AI agent requests a post, reads the HTML, and leaves without executing any of it, so none of them ever see it. WordPress writes the request to the access log and nothing reads that log for agents.

The reason there's no script tag to paste. AI agents don't execute JavaScript. Every analytics tool you already run is a browser tag, so it never fires for an agent — which is why your dashboards show none of this traffic. The only way to see it is server-side, at the edge, or in your logs.

See yours before you install anything

Paste a chunk of your access log and we'll pull out the AI agents that crawled you, what they read, and the files they asked for and couldn't find. No account, nothing stored.

Check my log free →

Install: Plugin

No code required. Captures response status, so you also see the pages agents asked for and didn't get.

  1. Install the plugin. Download the latest release from the repo and upload it in Plugins → Add New → Upload, then activate.
    https://github.com/pickrate-io/wordpress/releases
  2. Paste a secret key. Settings → Pickrate. Use a secret (sk_) key from your Pickrate settings — publishable keys are rejected, because agent detection is server-side.
  3. Prove it works. Hit 'Send a test hit'. It reports exactly what Pickrate said rather than claiming success, so a wrong key fails loudly instead of silently.

Gotchas worth knowing first

Full-page caching hides traffic from it

If a page is served entirely from a static cache or a CDN edge, PHP never runs and the plugin never sees the request. On a heavily cached site this is the difference between partial and complete data — put the Cloudflare Worker in front instead, which sees every request regardless of caching.

It must be a secret key

A publishable (pk_) key is the most likely way to end up with a plugin that looks installed and records nothing. The settings screen refuses pk_ keys at the point of entry rather than letting them fail forever.

Keep the key out of the database if you can

Define PICKRATE_KEY in wp-config.php and it takes precedence over the settings field. On a site where several people have admin, that's the safer place for a credential.

It reports after the response, never during

On PHP-FPM it calls fastcgi_finish_request() before sending, so the visitor already has their page. Elsewhere it uses a non-blocking request. Human page views make no network call at all.

Questions

Why doesn't my analytics plugin show AI crawlers?

Because it's a browser script. It loads in the visitor's browser and reports from there. An AI agent never executes it, so no pageview is recorded. This is true of Google Analytics, Jetpack, and every client-side analytics plugin — it's not a configuration problem and there's no setting that fixes it.

Will this slow down my site?

No. Human page views cost nothing at all — no network call is made. Agent requests are reported after the response has already been flushed to the visitor.

What data does it send?

The request path, the user-agent, the response status, and a timestamp. No visitor IPs, no cookies, no post content, nothing for human traffic, and nothing from /wp-admin.

Does it work with WP Engine, Kinsta, or other managed hosts?

Yes. They run PHP-FPM, which is the path where the plugin ends the response before sending. Their page caching is the thing to watch: cached hits never reach PHP, so heavily cached sites see less than complete data.

Other setups

Agent-readable version: https://pickrate.io/install/wordpress.md