Chrome’s Lighthouse 13.3.0 introduces an Agentic Browsing audit category that treats your llms.txtcodecodecodecode file as a markdown document, whether you intended it that way or not. If that file uses anything other than markdown link syntax — plain-text URLs, descriptive lines, even perfectly functional links — the audit will fail, returning the error “File does not appear to contain any links.” The fix is mechanical: five characters per link. But the gap between passing the audit and having a genuinely useful llms.txt is far wider than a passing score suggests.
The new Agentic Browsing category shipped with Lighthouse 13.3.0 alongside the familiar Performance, Accessibility, SEO, and Best Practices panels. It contains six audits in its default set: accessibility tree well-formedness (agent-accessibility-treecodecodecodecode), cumulative layout shift (cumulative-layout-shiftcodecodecodecode), llms.txt discoverability (llms-txtcodecodecodecode), and three WebMCP checks (webmcp-registered-toolscodecodecodecode, webmcp-form-coveragecodecodecodecode, webmcp-schema-validitycodecodecodecode). Unlike other Lighthouse categories, Agentic Browsing returns a fractional pass ratio rather than a 0-to-100 score — a reflection that the standards for the agentic web are still evolving and no fixed scoring rubric has been established.
Six Audits Ran on Nohacks.co. Two Passed. Three Were Not Applicable. One Failed.
Running the audit via the Lighthouse CLI — npx lighthouse@latest https://nohacks.co --only-categories=agentic-browsingcodecodecodecode — produced six results. Three WebMCP audits came back as not applicable: webmcp-registered-toolscodecodecodecode, webmcp-form-coveragecodecodecodecode, and webmcp-schema-validitycodecodecodecode. Lighthouse provides no explanation for a not-applicable verdict; it simply marks the audit and moves on. Nohacks.co does expose WebMCP, but only through the experimental imperative navigator.modelContextcodecodecodecode API, with no declarative form annotations. The scan ran in a default headless Chrome 150 with no WebMCP flag active, so the not-applicable result could mean the site exposes nothing these audits recognize, or that the scan environment lacked a functional WebMCP API. Lighthouse does not specify which.
Two audits passed cleanly. agent-accessibility-treecodecodecodecode reported “All audits passed,” confirming the semantic HTML and ARIA structure is well-formed enough for agents to navigate. cumulative-layout-shiftcodecodecodecode returned a score of zero — no unexpected layout movement. One audit failed: llms-txtcodecodecodecode. The verbatim error message: “File does not appear to contain any links.” The overall category score settled at 0.67.
That was the first surprise. The file at nohacks.co/llms.txt contains many links: navigation paths to articles, episodes, guests, the glossary, RSS feed URLs, audio file patterns. The file is over five kilobytes of structured content. Lighthouse reported zero links.
Why Lighthouse Parses a .txt File as Markdown and Rejects Plain-Text Links
The file extension is .txtcodecodecodecode. The HTTP server returns it with a text/plaincodecodecodecode MIME type. Open it in a browser, and you see plain text. But the llms.txt specification at llmstxt.org defines the format as a markdown document. The spec is explicit: “Each section contains a markdown bullet list of links. Each list item has a link followed by optional notes about the link, separated from the link by a colon.” Lighthouse’s parser enforces that strictly. Every link must be encoded as markdown link syntax — [text](url)codecodecodecode — with square brackets around the link text and parentheses around the URL.
The original file used a natural plain-text format:
- Homepage: / - Publication masthead, cornerstone series, latest articles and episodescodecodecodecode- Articles: /blog - All articles on AXO, the agentic web, and AI agentscodecodecodecode- Episode: /episode/[slug] - Full show notes, transcript, audio playercodecodecodecode
Same destinations. Same descriptions. Same information. Lighthouse’s parser did not register any of those lines as links. Across the entire file, it registered exactly zero. Audit fails.
This is the mismatch the audit layer is going to have to be more honest about. The extension says .txtcodecodecodecode. The MIME type says text/plaincodecodecodecode. The parser demands markdown. The file format and the audit expectation are not aligned, and the parser is the source of truth.
The Fix: Five Characters Per Link, Five Minutes of Editing
The correction is straightforward. Wrap each link target in markdown bracket-paren syntax — [text](url)codecodecodecode — and replace the -codecodecodecode separator before each description with : codecodecodecode. Five characters per link. Mechanical conversion, repeated across the file.
- [Homepage](/) : Publication masthead, cornerstone series, latest articles and episodescodecodecodecode- [Articles](/blog) : All articles on AXO, the agentic web, and AI agentscodecodecodecode- [Episode](/episode/[slug]) : Full show notes, transcript, audio playercodecodecodecode
After making the edit and re-running the audit, the score moved from 0.67 to 1.0. The audit title flipped from “llms.txt does not follow recommendations” to “llms.txt follows recommendations.” No detail items in the after-report. Clean pass.
The file is still served as text/plaincodecodecodecode. The file extension is still .txtcodecodecodecode. The file content is still the same content. Only the link encoding changed.
What the Audit Actually Measures: Parseable Link Syntax, Not File Quality
The audit checks whether your file is mechanically parseable. It does not check whether the file describes your website usefully. Both statements are true at the same time.
On one hand, the audit measures something real. Markdown link syntax is mechanically parseable. Plain-text descriptive lines are not. If an AI agent — or the Lighthouse parser standing in for an agent — needs to extract links from the file programmatically, the markdown format is required. The audit is correct that the file before the fix could not be parsed for links by standard tooling. The conversion to markdown link syntax fixes a genuine interoperability gap.
On the other hand, format compliance is not the same as file quality. A thoughtfully written, accurate, comprehensive llms.txt that uses plain-text descriptions fails this audit. A thin, auto-generated llms.txt with markdown link syntax passes. The audit cannot tell the difference between the two.
The WordPress plugin AIOSEO, used by over three million websites per its WordPress.org listing, generates llms.txt files with markdown link syntax by default — a default-on behavior the plugin’s own documentation confirms. Those auto-generated files use markdown link syntax because that is what the generator emits. Most of them probably pass this audit. Most hand-curated, owner-aware llms.txt files probably fail it. That gap is worth thinking about before treating the audit’s pass or fail as a measurement of how agent-ready your website really is. The audit checks whether your file is parseable. It does not check whether your file is useful.
Should You Care About Lighthouse Agentic Browsing’s llms.txt Check?
Yes, but with a narrow understanding of what the check means. Lighthouse can tell you whether your llms.txt is parseable as markdown. It cannot tell you whether the file describes your website honestly. That check is yours.
Open Chrome DevTools, click the Lighthouse tab, verify the Agentic Browsing category is checked, and run Analyze on your URL. The audit takes under a minute. If it fails on the no-links error, the fix is five characters per link and five minutes of editing. If it passes, the harder question is the one Lighthouse cannot ask: was the file auto-generated by a plugin you did not configure, or did you write it yourself, and either way, does it describe what your website actually is?
The llms.txt audit is a narrow check at the machine-readable layer of your site. The bigger structural question — whether your machine-readable surface describes your website honestly and comprehensively — is yours to run. Format compliance is table stakes. File quality is the work that follows.
