Google's PageSpeed Insights now audits llms.txt for agents
Summary
PageSpeed Insights now audits llms.txt, and a passing row shows only that the file exists and is formatted the way Lighthouse expects. The audit sits in the Agentic Browsing category and says nothing about whether Google Search or any AI vendor reads the file.
Count requests to /llms.txt in server logs to find out whether any named agent actually fetches it.
Google’s PageSpeed Insights now runs an llms.txt audit, and it sits in the Agentic Browsing category rather than under SEO. The check turned up in a post on r/TechSEO from u/azangru, who shared a screenshot of the report.
Lighthouse 13.3 added the category in May, but PageSpeed Insights was still on an older Lighthouse build at the time, so the check has now reached the tool most practitioners run.
In the thread, where the line sits mattered more than the line itself. “Notice how it’s under Agentic Browsing category instead of the SEO category,” wrote u/cinemafunk, who went on to ask which search and AI companies state they parse the file for training data or retrieval. Nobody in the thread named one.
The audit does not answer the question either. Its source code on GitHub shows what it tests. The file is fetched from the site root and fails when it lacks a Markdown H1 heading, contains no links, or runs under 50 characters. A site with no file at all is marked not applicable rather than failed. Passing means the file is there and formatted the way Lighthouse expects, which is a different claim from the one practitioners have been arguing over. Nothing in the audit can show that a crawler or an assistant consumes the file.
The category name is the stronger signal, and the better bet is that Google’s tooling is describing agent readiness rather than anything to do with ranking. Agentic Browsing groups checks about whether software can read and operate a page. That is why another commenter, u/cinematic_unicorn, pointed at an “Accessibility tree not well-formed” finding in the same report and said it deserved more attention than the llms.txt line. That finding has a real consumer. A malformed accessibility tree breaks the structure an agent walks to find buttons and form fields.
The distinction also splits by bot type. A page-load audit speaks to AI browsers and user-action fetchers, the ones that render a page when somebody asks them to do a task. Training crawlers and retrieval bots do not need a PageSpeed Insights pass to find a text file at a known path, and whether any of them requests it is a log question rather than a Lighthouse one.
What to do
Treat the audit as a checklist item for agent access and verify the rest yourself.
- Do not add the file for the score. A missing llms.txt is marked not applicable, so the audit itself gives no reason to create one.
- Add it anyway if it costs minutes. On WordPress with Yoast, one commenter, u/teeham88, said the plugin has a toggle for llms.txt generation and that it works well enough for the use the file gets. If you keep a file, give it an H1 heading and at least one link so the audit passes.
- Count requests to /llms.txt in server logs, the test u/alvares169 raised in the thread. Hits from a named agent user agent are evidence. A flat zero is also an answer, and it is the one to quote when someone asks for a content rewrite to feed the file.
- Clear the other findings in the category before this one, starting with any accessibility tree error, since those affect whether an agent can use the page at all.
- Do not carry a green llms.txt audit into a client deck as proof that Google Search reads the file. The audit checks presence and format, and presenting it as a ranking signal is a claim that will be hard to walk back.