AX Protocol documentation — install and configure an agent-ready WordPress siteAX Protocol — Documentation

Working alongside your SEO, caching and CDN stack

Almost every site that installs AX Protocol is already running an SEO plugin, a caching layer and often a CDN. All three touch exactly the files the protocol generates, so it is worth settling the order of operations before you start rather than debugging it afterwards. Your SEO plugin owns sitemap.xml and the canonical tags. AX Protocol does not replace either; it adds a manifest layer above them. When two components write to the same path, the last one in the chain wins, so always verify the live file rather than trusting the settings screen.

Caching is the single most common source of problems that look like protocol bugs. A manifest cached before a settings change will keep being served to agents for hours, so the site ends up declaring a structure that no longer matches its content. The rule is simple: after any change, purge the full cache and check the live file in a private window. If you run a CDN, add an edge purge too, otherwise the origin serves the new version while visitors and agents still receive the old one.

The third component is your web application firewall. Several providers block requests without a recognised browser fingerprint by default, and AI agents fall squarely into that category. If local checks pass but the same request from the open internet returns a 403, suspect a blocking rule before you suspect the plugin. Add the manifest paths to the allow list first.

Manual verification checks

The dashboard reports what the plugin believes it has published. That is not the same as what an agent receives, and the two diverge more often than you would expect. Four checks take about five minutes and catch the majority of real-world failures.

First, request the manifest with a plain HTTP client rather than a browser and confirm you get a 200 and valid JSON, not an HTML challenge page. Second, fetch a key content page the same way and confirm the substantive text is present in the raw response — if the body arrives empty, your content is being injected by JavaScript and agents will never see it. Third, follow every URL declared in the manifest and confirm none of them redirect or 404, because a manifest that points at dead paths is worse than no manifest at all. Fourth, repeat the first check from outside your own network, ideally over a mobile connection, to rule out IP-based allow-listing that only makes your office look healthy.

Record the results somewhere. When something breaks in three months, the fastest route to a diagnosis is a record of what a working state looked like.

Updates, migrations and staying compatible

Moving host, changing domain or shifting to a subdomain are the events most likely to break protocol configuration, because absolute URLs stored in settings keep pointing at the old location. Document your configuration before a migration and walk every manifest path afterwards to confirm it resolves at the new address. If the site also moved from HTTP to HTTPS, check for duplicate redirects on the way: a long redirect chain causes some agents to abandon the request part-way through.

Plugin updates are less risky but not risk-free. The specification is versioned, and a major version change can alter field names in the manifest. Read the release note before a major upgrade, and if you have built anything that consumes your own manifest, test it against the new output before pushing to production.

If you only have time for three things

If this is a first implementation and you cannot work through every section, three items deliver most of the value: a valid manifest that resolves at the expected path, an accurate one-line organisation description that says what the site does and for whom, and a service catalogue containing the pages you actually want cited. Everything else — extended endpoints, permission settings, advanced discovery — can be added incrementally. A site with those three is already reasonably legible to agents, and you can improve it against what the server logs show rather than against guesswork.

Where AX Protocol fits in a multilingual site

If the site runs more than one language, decide early which language the manifest describes. The protocol emits one manifest per language variant, and agents follow the same hreflang signals search engines do, so a correctly wired translation set means an agent asking in Spanish reaches the Spanish page rather than the English one. A broken translation set means every language collapses onto the default, which is worse than having no translations at all.

The check is quick: fetch each language root and confirm the alternate links list every variant plus x-default, and that each variant points at a URL that returns a 200 in that language. Sites built by cloning pages between languages frequently fail this, because the copies were never bound into a translation group and each one presents itself to agents as an unrelated document.