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, 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.
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):
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 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.
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.
The Dashboard charts 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