

Dashboard: visits of AI bots by bot and by day, how many were verified, and the people who arrived from an AI assistant.
AMDT AI Traffic Analytics watches; it does not touch. It records two things your usual analytics do not show:
With that it gives you a dashboard (its chart of content consumption also as a panel of the WordPress Dashboard), a log you can filter and export, and an analysis of the addresses it could not identify, with blocking rules already written for Apache, Nginx, Cloudflare or Wordfence. You apply those rules in your firewall: the plugin does not block anyone.
It also publishes your site’s llms.txt (an index of your content for language models), counts who reads it, and lets you leave posts out of it from the editor.
And with Agent-Readiness it tells you whether an AI agent that navigates and acts on pages (it fills in forms, presses buttons, opens menus) can use yours. It reads the HTML your server gives for the home page, a sample post, up to 8 pages and a sample product, or for any page of your site you paste, and for each one:
div;llms.txt and the ARD manifest. Visual stability (CLS) needs a browser: each result links to PageSpeed Insights for it;It only analyses your own site, and it never changes your pages.
A complete edition, with more modules, also serves your content to AI agents through an API and an MCP server, publishes the files that announce them, declares AI usage permissions, protects that API and analyses your content. Both editions share the same tables and settings: you can move from one to the other without losing data.
In your own database, for the retention you choose (30, 60 or 90 days):
Signature-Agent, Signature-Input, Signature) and the result of checking them.Nothing is stored about ordinary visitors. If you turn on the debug log (Settings Diagnostics), its entries also contain IP addresses and User-Agents. It is written to its own folder in uploads, amdt-ai-traffic-analytics/, in a file with a random key in its name; the folder denies direct access on servers that read .htaccess, such as Apache. It is deleted on uninstall if you choose to delete the data. Settings Privacy Policy guide has a suggested text for your privacy policy.
Nothing: no cookies, nothing stored in the browser. Pages carry a small script that, only when the visitor comes from an AI assistant, tells your own server about it.
The plugin sends nothing to its author and has no telemetry. It connects to the services below. The IP lists and the signing keys are off on a new install until you turn them on.
Why the IP lists. To confirm that a visit from GPTBot, OAI-SearchBot, ChatGPT-User, OAI-AdsBot, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot or Perplexity-User really comes from its operator, the plugin can download, once a day, the lists of IP addresses those operators publish. It is off until you turn it on: a notice asks you when you activate the plugin, and Settings has the switch.
What is sent, and when. Once a day while the switch is on, and once when you turn it on, the plugin makes a plain HTTPS GET request for each public file below. The request carries the plugin’s name and version as its user agent and nothing else: no data about your site, your visitors or you.
Google-Agent and ChatGPT agent sign some of their requests (Web Bot Auth, an IETF draft based on HTTP Message Signatures, RFC 9421). To check such a signature the plugin downloads the public keys of the agent that signed it. It does so only when a signed visit from one of them arrives and the keys it keeps are out of date (they are kept as long as the response allows, between five minutes and a day), only from the two addresses below, never from an address a visit names, and only while the switch of the IP lists is on (Settings Operator IP lists). The request is a plain HTTPS GET with the plugin’s name and version as its user agent and nothing else.
To tell which network a bot’s address belongs to, the plugin asks the DNS resolver your server uses for the name of the IP address of the bots and of whoever reads your llms.txt (never of the people who arrive from an assistant). This goes through your server’s own resolver, as any reverse lookup does.
When you open the Dashboard or Settings, the plugin requests your own home page, at most twice a day, to find out whether a cache sits in front of WordPress, and your own /llms.txt, at most once a day, to check that visitors get it. Both are requests to your own server; the “Check again” buttons repeat them on demand.
When you run Agent-Readiness, the plugin requests the pages of your site it analyses and, for the Lighthouse audits, your site’s /llms.txt, /robots.txt and the addresses where an ARD manifest can be (/.well-known/ard.json, /.well-known/ai-catalog.json and any your pages announce). Only your own site, with its certificate checked; nothing else is contacted. The PageSpeed Insights link next to each result is an ordinary link: the plugin sends nothing to Google, and what PageSpeed Insights receives is what you send it if you open the link.
The charts of the plugin’s Dashboard, and its panel on the WordPress Dashboard, use Chart.js 4.6.1 (MIT license), bundled in admin/js/chart.umd.min.js: the minified build its authors publish on npm, without the line that points to its source map. Its source code: https://github.com/chartjs/Chart.js
The accessibility rules of Agent-Readiness use the WAI-ARIA tables of axe-core 4.14.0, Copyright (c) Deque Systems, Inc., under the Mozilla Public License 2.0, which is compatible with the GPL. They are in includes/data/aria-standards.php, generated from its lib/standards folder; the rules are written in PHP following its own, and the texts of each rule are based on its help texts. Its source code: https://github.com/dequelabs/axe-core