AMDT AI Traffic Analytics
AMDT AI Traffic Analytics

AMDT AI Traffic Analytics

0/5 (0 ratings) 20 active installs Updated Nov 10, 2026
Dashboard: visits of AI bots by bot and by day, how many were verified, and the people who arrived from an AI assistant.

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:

  • The AI bots that read your pages (GPTBot, ClaudeBot, PerplexityBot, Googlebot, Bingbot and the rest), and whether each one is who it says it is. It checks the bot’s IP address against the lists its operator publishes and against its reverse DNS, and flags as an impostor any visitor that uses another bot’s name. The Bot catalog shows how big each list is and the date its operator gave it, so you can tell a list kept up to date from one left untouched for a year. Agents that sign their requests with Web Bot Auth (Google-Agent, and ChatGPT agent, which uses the User-Agent of an ordinary Chrome) are verified by their signature, which cannot be forged the way a User-Agent can; IP analysis lists each signed visit with its three headers.
  • The people who arrive from an AI assistant (ChatGPT, Claude, Perplexity, Gemini, Copilot…) after clicking a citation, and the page they land on.

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:

  • scores from 0 to 100 what such an agent relies on: real buttons and links, the heading outline, the landmarks, labelled form fields, image alternatives and how much of the page is bare div;
  • approximates Lighthouse’s «Agentic Browsing» audits as far as the server can tell them: the 33 accessibility rules of its accessibility-tree audit, the WebMCP ones, llms.txt and the ARD manifest. Visual stability (CLS) needs a browser: each result links to PageSpeed Insights for it;
  • says how much of the text reaches the initial HTML and how much needs JavaScript;
  • explains how to fix it with your page builder (Elementor, Divi, Bricks, Beaver Builder, WPBakery, the block editor or your theme), and exports everything to Markdown or CSV.

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.

What it stores

In your own database, for the retention you choose (30, 60 or 90 days):

  • For the bots in its catalogue and for whoever reads your llms.txt: the IP address, the User-Agent and the page requested.
  • For people who arrive from an AI assistant: only the network of their IP address (IPv4 up to the third block, IPv6 the first 48 bits), never the full address, plus the User-Agent, the page and the address of the assistant they came from.
  • For automated browsers that pretend to be an iPhone (possibly Grok): the request, with its IP address.
  • For requests signed with Web Bot Auth: also their three signature headers (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.

What it leaves in your visitors’ browsers

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.

External services

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.

OpenAI (GPTBot, OAI-SearchBot, ChatGPT-User, OAI-AdsBot)

Anthropic (ClaudeBot, Claude-User, Claude-SearchBot)

Perplexity (PerplexityBot, Perplexity-User)

Google and OpenAI (the keys of Google-Agent’s and ChatGPT agent’s signatures)

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.

Reverse DNS

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.

Your own site

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.

Third-party libraries

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