Let’s cut to the chase: if you’re auditing your 365 tenant for a breach today, and an LLM pulls the wrong log file? That’s not a traffic hiccup — that’s liability.
Google’s John Mueller spelled it out plain on Search Off the Record: llms.txt can’t help LLMs decide which site to surface for a query. Self-reported files don’t give systems any way to rank one site over another.
Not because people game the file — though they do — but because the mechanism itself offers no differentiating signal. It’s just a claim, written in text, with nothing to back it up.
Think about meta keywords again. You’d stuff them until Google stopped believing any of it. llms.txt is the same story with a new filename.
When every security team declares its site “secure, compliant, and agent-friendly,” the signal flattens to noise. An LLM choosing between two 365 environments can’t tell them apart from a self-declaration. It needs evidence: links, structure, verifiable endpoints.
That’s why a security & compliance analyst should care — because when the agent picks the wrong site, you’ll be on the hook to explain why it didn’t know the difference.
Meta Keywords Had a Name Tag. llms.txt Doesn’t Even Have That
Back in 2005, the meta keywords tag was your site’s business card. You told search engines who you were and what you did. Then every vendor, including the ones with zero relevance, started stuffing those tags with high-volume terms.
Google noticed and stopped listening. Not because they hated keywords — but because universal signals become useless signals.
llms.txt faces the same fate by design. Mueller put it this way: “It’s basically you’re telling these systems, like, I have the best website ever. And here are all of the pages that everyone must go to.”
An LLM can’t trust a file it wrote itself. It needs something external to cross-check.
Think of it like your audit trail: you don’t trust a PDF report just because the filename says “Audit_2026_final.pdf.” You check who last modified it, whether the source data matches, and if there’s a digital signature to prove no one tampered with it.
llms.txt lacks that chain of proof. There’s no signature, no timestamp, no way to verify a claim against what the system actually does.
A security & compliance analyst knows that trust isn’t declared — it’s proven through structure. And if your agent-facing endpoints are buried behind login walls and PDFs, llms.txt won’t fix that.
Discovery Is About Selection. Navigation Is About Instructions.
Here’s what Mueller didn’t say but implied: llms.txt might help an agent once it’s already on your site.
He illustrated it with a photo store example: after the LLM lands on the right page, llms.txt could tell it how to locate the checkout form. That’s navigation — not discovery.
The distinction matters because your audit system likely already handles discovery fine. HTML links and internal architecture are still the ground truth for crawlers, including AI ones.
But navigation? That’s where llms.txt has a narrow shot at usefulness — if it were enforced, signed, and verifiable. Right now? It’s a hallway directory someone scribbles on a sticky note and posts to the fridge.
If you’re building an agent-facing endpoint, don’t write llms.txt. Build an OpenAPI spec with an auth token and watch the agent find exactly what it needs — no magic file required.
The Real Risk Isn’t the File. It’s the Misplaced Faith.
People get excited about llms.txt because it sounds like a checklist: ✅ We’ve got one. ✅ We’ll update it monthly.
But checking a box doesn’t make an endpoint trustworthy. A compliant tenant, secure API, and auditable log all require real architecture — not just declarations.
SE Ranking analyzed 300,000 domains and found zero correlation between llms.txt adoption and citation frequency in LLM answers. That’s not a surprise — it’s math.
When every candidate says “I’m the best,” no one wins. You need signals that differentiate: backlinks, domain authority, structured metadata.
llms.txt doesn’t provide any of that. It’s just another way to broadcast your claim louder — not clearer.
The real issue isn’t gaming; it’s that llms.txt offers no way to tell the difference between a truthful claim and a misleading one.
A Better Path: Standardized, Signed Endpoints
Mueller mentioned WebMCP — a nod at best. Here’s what that could mean:
What if your security & compliance endpoint included a header like X-SecCom-Policy: signed;kid=rsa-2026-q3?
What if the LLM could fetch your public key from a well-known path (/.well-known/security-com.pem) and verify the signature on your audit log feed?
Now that’s a signal. Not because it says “I’m secure” but because the agent can independently verify trust.
This is how OAuth and OpenID Connect work: they’re protocols, not files. They enforce rules through cryptography and standardization.
llms.txt is a suggestion, not a contract. If you want agents to trust your endpoints, stop writing files and start building standards.
The Bottom Line for Security Teams
A security & compliance analyst doesn’t need llms.txt to protect a 365 tenant. You need:
- Verified endpoints with stable schemas
- Authenticated access that matches your policy docs
- Audit logs that are machine-readable and signed
- Clear internal links between related events
If your LLM can’t differentiate sites with that stack, the problem isn’t discovery — it’s poor implementation.
Mueller’s point isn’t to scrap llms.txt. It’s to stop pretending it solves the hard part.
The discovery problem is already solved, mostly by HTML and internal linking. What’s broken is the claim that a text file can tell an agent where to go next — without telling it how to know you’re the right place.
You can’t trick your way into agent citations. You build trust by making the data trustworthy.
Anything else is just noise wearing a new suit.
