Guide 16 · Agents
Is your plugin site ready for AI agents? What Lighthouse’s new audit found on ours
Mostly yes, if your forms have real labels, your buttons are real buttons and nothing jumps while the page loads: that is what Lighthouse can score today. AI agents are starting to use websites for people: they fill in forms, run tools and read results. Lighthouse now has an Agentic browsing category that checks whether a page is ready for that, and Chrome is testing WebMCP, a way for a site to hand agents named tools instead of making them guess at buttons. We built both into this site and measured it before and after. Our contact page went from 3 of 3 checks, with the WebMCP audits not applicable, to 5 of 5. Here is what the audit checks, what it cost us, and what it does not tell you.
What does “agent-ready” mean for a website?
An agent is software that acts in a browser for someone: it opens your page, reads it, and tries to do a task, such as checking a plugin or sending a contact form. Today most agents do this the hard way. They read the page’s accessibility tree, guess which field is which, click, and hope the layout does not move under them.
Being agent-ready means two things. First, the page is easy to operate without eyes: every field has a real label, every button is a real button, and nothing jumps around while it loads. Second, and newer, the page can say outright what it can do. That second part is what WebMCP is for. Chrome describes it as a proposed web standard for exposing structured tools to AI agents. It is experimental and runs as an origin trial from Chrome 149.
What does Lighthouse’s Agentic browsing category check?
The category shows a fraction, such as 4/4, rather than a 0–100 score. Google’s documentation says that is deliberate, because the standards are still emerging and the aim is to give signals, not a ranking. It needs Chrome 150 or later, and the WebMCP checks only run when the page is registered for the origin trial. On our pages it ran these checks:
| Audit | What it looks at | Scored? |
|---|---|---|
| Accessibility tree is well-formed | Labels, roles and names an agent reads instead of pixels | Yes |
| Cumulative Layout Shift | Whether things move while the agent is about to click | Yes |
| llms.txt follows recommendations | Whether an llms.txt file exists and is well-formed | Yes |
| WebMCP schemas are valid | Whether each registered tool’s input schema is correct | Yes, with the trial |
| WebMCP form coverage | Whether forms carry WebMCP annotations | Scored on some pages, a note on others |
| WebMCP tools registered | Lists every tool the page offers | No, informative |
| ai-catalog.json schema is valid | An optional catalog file | Not applicable to us |
One of those needs a note. Lighthouse checks llms.txt here, but Google Search ignores llms.txt, and we found no evidence that it changes AI answers. It is in this category because agents may read it, not because it helps you rank. What our llms.txt test found.
What did our pages score before and after?
Before building anything we checked our three forms (contact, the retrievability check and the leaderboard search). All three already had labels tied to their fields and real buttons, so /contact/ passed the three checks that could run: accessibility tree, layout shift and llms.txt. The WebMCP audits showed as not applicable.
We then added three WebMCP tools and registered the site for the origin trial. The re-run on 25 September 2026:
| Page | Tools it offers | Agentic | Perf. |
|---|---|---|---|
| /contact/ (mobile) | Plugin check, plus the contact form as a tool | 5/5 | 95 |
| Retrievability check (mobile) | Plugin check | 4/4 | 95 |
| /leaderboard/ (mobile) | Plugin check, plus leaderboard lookup | 4/4 | 96 |
| Homepage (desktop) | Plugin check | 4/4 | 98 |
Accessibility, Best Practices and SEO scored 98 to 100 on every page. The WebMCP schema check passed everywhere, and form coverage passed on /contact/, the one page where it was scored. Performance stayed in the mid-90s on mobile: the tools are one small script.
How do you give an agent a tool?
WebMCP has two routes, and we used both.
- Declarative, for an existing form. You add attributes to a normal HTML form: toolname and tooldescription on the form, and toolparamdescription on each field. That is how our contact form became the tool request_free_ai_visibility_check.
- Imperative, for anything else. A script calls document.modelContext.registerTool with a name, a description, an input schema and a function. Our check_plugin_retrievability tool is registered this way on every page, and lookup_plugin_ai_answers only where the leaderboard search exists.
Lighthouse still flags the retrievability and leaderboard forms as “missing annotations”. We left them that way on purpose. Those forms are already covered by the script tools, and annotating them too would show an agent the same action twice under two names.
What should you not hand to an agent?
Anything a person should confirm. The declarative API has a toolautosubmit attribute that lets the agent send the form by itself. Without it, the agent fills the form and the person clicks Submit. We did not add it to our contact form: an agent can prepare the request, but a human sends it. Our two script tools only read data, so there is nothing for them to break.
For a plugin business the same rule applies to checkout, licence activation, refunds and account changes. Chrome’s documentation says sensitive actions such as purchases can ask the user for confirmation. Start with read-only tools: a compatibility checker, a pricing calculator, a documentation search.
Does any of this help your plugin get cited by AI?
Not that anyone has shown. Google has not said the Agentic browsing results feed Search rankings, and its own documentation calls the category experimental. In our 17 September measurement this site was cited in zero of 72 unbranded AI answers, and we would not claim that tools will change it.
What it does change is what happens after the citation. If an agent is sent to your site to check whether your plugin fits, a site with a working tool gives it a straight answer. A site without one leaves it scraping your pricing page. Agents doing that at scale are early, and the WebMCP trial ends in November 2026 unless Chrome extends it. So we treat this as cheap preparation, not a growth channel.
What should a plugin site do first?
- Run PageSpeed Insights on your pricing, contact and trial pages and read the Agentic browsing section. Fix any accessibility tree failure first: it is the same fix that helps screen-reader users.
- Keep layout shift under 0.1, especially around buttons.
- Give every form field a real label and every action a real button, not a styled div.
- If you have a free tool or a search, register it as a read-only WebMCP tool, then register your origin for the trial so Lighthouse can check the schema.
- Leave anything that spends money or changes an account for the person to confirm.
How this was made: WebMCP and Lighthouse details come from Chrome’s developer documentation on WebMCP, its declarative API and Agentic browsing scoring, read on 25 September 2026. Scores come from PageSpeed Insights runs on this site on 24 and 25 September 2026, and tool registration was checked in Chrome 153. Drafted with an AI assistant (Claude) and reviewed by Alauddin Chowdhury. Method and AI use.
Want to know how your plugin shows up across all three engines?
Send me your wordpress.org slug. I will run your category on Google AI Mode, ChatGPT and Perplexity, and show you which domains each engine reads and whether yours is one of them. Free, no call, usually within a day.