AX Protocol support — diagnose and fix agent access problemsAX Protocol — Support

Self-diagnosis in three steps

Most tickets we receive are resolved by the person who raised them, once they know where to look. Work through three layers in order and you will usually find the cause before you need us. Start at the network layer: request your manifest with a plain HTTP client and read the status code. A 403 or a challenge page means something in front of WordPress is blocking the request, and no amount of plugin configuration will fix that.

If the status is fine, move to the content layer. Compare what the plugin dashboard says it published against the file that is actually being served. A mismatch here is nearly always caching, at the WordPress layer, the host layer, or the CDN. Purge all three and re-check before concluding anything else.

Only if both layers are clean should you look at configuration. At that point the question is usually not whether the protocol works but whether it is describing your site correctly — wrong organisation type, an empty catalogue, or endpoints pointing at pages that no longer exist.

Common failures and what causes them

Response times and severity

Not every issue carries the same weight, so classify it before you write. A fault that stops agents reading the site at all — a manifest returning a server error, for instance — is urgent, because every day it persists is a day the site is misrepresented in the sources agents rely on. A missing catalogue field or an imprecise service description is an improvement rather than a failure, and can wait for the next update cycle.

That classification also decides what to do while you wait. With a blocking fault, return the site to a stable state first — temporarily disable the offending component — and continue the investigation afterwards. With a non-blocking one, leave things exactly as they are: reproducing a fault that has been partially fixed takes longer than diagnosing a live one.

What to include when you contact us

Four things turn a two-day exchange into a one-reply answer: the exact URL you tested, the raw response you received including the status code, the date and time the behaviour started, and a list of what changed on the site in the days before that. The last one matters more than people expect — the great majority of sudden failures trace back to a plugin update, a hosting change or a new security rule rather than to the protocol itself.

If you manage several sites on the same stack, keep a shared one-line log of every incident and its resolution. It will show you quickly that most of your problems come from three or four recurring causes, and you can then fix the root rather than repairing each site in turn.

Keeping an implementation healthy over time

A protocol implementation is not a one-off task. Sites change: plugins are added, themes are updated, hosts introduce new optimisation layers, and each of those can quietly alter what agents receive. The sites that stay healthy are the ones that treat the manifest as part of the deployment checklist rather than as something configured once and forgotten.

A useful habit is a monthly five-minute review: fetch the manifest from outside your network, confirm the status code and structure, spot-check two content pages for text presence in the raw response, and glance at the error rate in the server log. Anything that has broken will show up in one of those four. Anything that has not is almost certainly fine.

Keep a short log of every incident and its resolution — what happened, when, what changed, what fixed it. One line per event is enough. If you manage several sites on the same stack, a shared log will quickly reveal that most problems come from three or four recurring causes, at which point you can address the root instead of repairing each site individually.

What support does not cover

It is worth being explicit about the boundary. We support the protocol: whether the manifest is generated correctly, whether the plugin behaves as documented, and whether an agent can discover and read what your site publishes. We can also tell you why an agent is being blocked, and usually which layer is doing the blocking.

What we cannot do is act as general WordPress support. If the underlying problem is a theme conflict, a broken permalink structure, a host-level resource limit or a security plugin misconfigured across your whole site, we will identify it and tell you what to change, but the change itself belongs to whoever maintains the site. Similarly, we cannot make guarantees about how any particular AI system will treat your content. The protocol makes a site legible; it does not compel anyone to read it, and no honest supplier can promise otherwise.

For anything commercial — licensing, invoicing, migrating a licence between domains — that is a separate route from technical support and usually resolves faster if you say so up front.

Before you open a ticket

Most reports we receive resolve themselves once the reporter re-runs the check with caching disabled and confirms the request actually reached the origin server. A CDN edge node holding an old copy of a manifest file will look exactly like a broken installation, and no amount of work on our side will change what the edge is serving. Purge the cache, request the file with a cache-busting query string, and compare what you get against what the plugin believes it is publishing.

If the two still disagree after a clean purge, that is a real defect and worth reporting. Include both responses in full, along with the exact time each request was made, so the behaviour can be reproduced rather than inferred from a description.