The audit that fails, and the message that explains nothing

A site of mine was reporting 2/3 on Agentic Browsing with everything else at 100. The summary line said only "llms.txt does not follow recommendations", and the linked documentation says nothing more specific than "follow the llms.txt specification".

The actual reason is in the audit's details table, which the summary does not show:

File does not appear to contain any links.

The file had thirteen URLs in it. Every one was plain text — either a bare URL on its own line, or the - https://example.com/page — description form. Lighthouse parses llms.txt as Markdown and counts link nodes, and bare text produces none. The fix is the form the specification actually asks for:

## Pages

- [Home](https://example.com/): what the site is
- [Contact](https://example.com/contact/): enquiries

Worth saying plainly: this is a formatting conformance point, not a discoverability one. An LLM reading the raw text will follow a bare URL perfectly well. It is cheap to fix and the score is visible, so it is worth doing — but a 2/3 here does not mean agents cannot navigate your site.

Getting the category out of the API

This is the part that cost the most time. PageSpeed Insights' v5 API documents five categories — PERFORMANCE, ACCESSIBILITY, BEST_PRACTICES, SEO, PWA. Agentic Browsing is not among them.

It works anyway:

curl -sS -G "https://pagespeedonline.googleapis.com/pagespeedonline/v5/runPagespeed" \
  --data-urlencode "url=https://example.com/" \
  --data-urlencode "strategy=mobile" \
  --data-urlencode "category=agentic-browsing" \
  --data-urlencode "key=$PAGESPEED_API_KEY"

The trap is what happens if you leave it out. The request still returns 200, and the response simply contains no agentic audits at all — so it is easy to conclude a site has no agentic problems when what actually happened is that nothing was measured. I did exactly that twice before noticing the categories object only held performance.

Do not fall back to the web interface when the API misbehaves. pagespeed.web.dev hung on four consecutive runs from one workstation while the keyed API answered every time in under a minute — the UI shares the keyless quota, and on a machine that has already exhausted it, the UI is exhausted too.

What the six audits actually are

• llms-txt — parses the file, wants Markdown links. Not Applicable if you have no llms.txt at all, which means adding one is the only way to fail it.
• agent-accessibility-tree — whether the rendered accessibility tree is well-formed. This is the one that quietly rewards work you did for screen readers.
• cumulative-layout-shift — the same CLS as the performance category, reused here.
• webmcp-form-coverage, webmcp-registered-tools, webmcp-schema-validity — WebMCP integration checks, all three Not Applicable to a static site.

So on an ordinary site the score is out of three, and two of the three are things you either already do or can fix in an afternoon.

What I would gate on, and what I would not

Having fixed it once, the thing worth building is the check that stops it coming back. Two of these audits give the same answer on a busy afternoon as on a quiet one: llms-txt parses a static file, and agent-accessibility-tree reads the rendered tree. Those are safe to fail a deploy on.

The category score is not, and neither is anything scored as a fraction. A build that fails because a shared analyser was busy is a build people learn to retry rather than read — and a gate nobody believes is a gate that gets switched off.

The cheapest version of all of this is not a remote check at all: parse your own llms.txt at build time and refuse to ship one with no Markdown links. That catches the fault before a build, for free, and the remote check then only has to cover the case the local one structurally cannot see — a file that was correct in the repository and never made it onto the server.