A creator with a common name asked a reasonable question: if AI assistants keep confusing me with two more famous people who share my name, can I publish a small file that tells the models who I actually am? The proposed file was llms-author.txt — a plain-text declaration of author identity, sitting next to the better-known llms.txt, paired with Cloudflare's Content-Signal robots directive. It is an appealing idea because it feels like robots.txt for the AI era: drop a file, control how machines read you. Google's John Mueller answered plainly that Google uses neither llms.txt nor llms-author.txt, and that no crawler or LLM has confirmed reading them. This guide walks through where these files came from, exactly what Google said and when, why a self-declared identity file does nothing for AI attribution today, and — because the underlying problem is real — what actually moves how AI systems attribute and disambiguate you. That last part is where an AI content engine does the work a static file can't.
LLMs-Author.txt is a proposed file that would sit at the root of your site and declare who the author is, so AI models attribute your content to you rather than to someone who shares your name. It is a reasonable-sounding idea. It does not work. Google's John Mueller answered the question directly: Google uses neither llms.txt nor llms-author.txt, and no crawler or LLM he knows of has confirmed reading them. There is no official proposal for llms-author.txt, no adoption, and no measured effect on search or AI answers. The instinct behind it — "let me declare my identity in a file the machines read" — misunderstands how AI systems decide who you are. This guide explains what these files are, exactly what Google said, why a self-declared file carries no weight, and what to do about the genuine attribution problem underneath it.
The idea surfaced in a technical-SEO discussion. A creator explained that they struggle with discoverability because they share a name with two more prominent entities — ask an assistant about them and it answers about someone else. Their proposed fix was practical-sounding: publish an llms-author.txt file spelling out their identity (role, location, focus areas) and add Cloudflare's Content-Signal directives to robots.txt, then let AI models read those to disambiguate. They asked whether anyone had tested this. It is the natural question for anyone who has watched an AI assistant confidently attribute their work to the wrong person.
llms-author.txt is a spin on llms.txt, so it helps to know what that is. llms.txt was proposed by Jeremy Howard — co-founder of Answer.AI and fast.ai — on September 3, 2024, and documented at llmstxt.org. The original problem had nothing to do with rankings or attribution: LLM context windows are too small to swallow whole websites, and converting cluttered HTML into clean text is error-prone. So Howard proposed a curated Markdown file at /llms.txt that points a model at your most important pages in LLM-friendly form. The reference implementation was his own FastHTML developer documentation — a docs-and-APIs use case, not a marketing one. A handful of technical companies (Anthropic, Cloudflare, Stripe, Vercel among them) publish one. It was never designed as an SEO or generative-engine-optimization device, and the people who treat it as one have bent it away from its purpose.
llms-author.txt takes that unofficial-but-real file and invents a sibling that has no proposal, no specification, and no adoption at all. Whatever you think of llms.txt, llms-author.txt is a step further from anything a crawler recognizes.
John Mueller, a Search Advocate at Google, answered the question without hedging. His reply: "Google doesn't use llms.txt or llms-author.txt. I don't know of any other crawler / llm confirming they're using these (other than SEO tools)." On the Content-Signal half of the proposal he was equally blunt — the directive was, in his words, made up by a CDN, no crawler or LLM acts on it, and using it "has no effects whatsoever for any crawler or llm" while adding bloat and future maintenance.
This is not a one-off remark. Mueller had earlier compared llms.txt to the old keywords meta tag — a file where a site declares what it is about, when the model would rather just read the site. In July 2025 Google's Gary Illyes confirmed Google does not support llms.txt and had no plans to. And Google's AI-optimization guidance, updated June 29, 2026, now states it in the documentation directly: you do not need to create new machine-readable files, AI text files, markup, or Markdown to appear in Google Search — including its generative capabilities — because Search itself does not use them. Multiple independent checks back this up: site owners who publish llms.txt report that the major AI crawlers do not even request the file in their server logs. The signal that they are not being read is that they are not being fetched.
The keywords-meta-tag comparison is the whole point. A file where you assert who you are and what you are about is exactly the kind of unverifiable, self-interested signal search and AI systems learned to ignore two decades ago, because it is trivial to game and impossible to trust. Anyone can write "I am the definitive authority on X" in a text file. Models do not attribute you based on what you say about yourself; they attribute you based on what the corroborating web says about you. A declaration with no external verification is the least trustworthy input in the stack, not a shortcut past the rest of it. That is why "drop a file and control the machines," which felt like the robots.txt of the AI era, does not hold — robots.txt governs access to your own server, which you actually control; an attribution file tries to govern a model's beliefs about the world, which you do not.
The creator's frustration was legitimate. Entity disambiguation — the model figuring out which "you" a name refers to — is a genuine failure mode, and it hits anyone with a common name, a new brand, or a name that collides with a generic term or a bigger company. When the model cannot pin you to a distinct entity, it borrows a more prominent namesake's traits, or leaves you out entirely. The mistake is the proposed fix, not the problem. A file cannot solve a disambiguation problem, because disambiguation is decided by weight of evidence across sources, and a file is a single unverified source.
Answer engines assemble their picture of an author or brand from a spread of sources — your own pages, yes, but also bylines, author bios, reviews, editorial coverage, directories, forums, and social profiles. Large samples of AI citations repeatedly show that most of what a model says about an entity traces to earned and third-party media rather than the entity's own copy. Attribution follows corroboration: the same name attached to the same role and the same topics, repeated consistently across the sources the models genuinely crawl, and reinforced by structured data (Person and Article schema, linked and matching profiles). The way you win the namesake problem is to make your name and your subject co-occur so often, so consistently, across so many real pages that the model's weight of evidence tips to you. For the wider strategy this sits inside, see [SEO in the age of AI search](/guides/seo-in-the-age-of-ai-search) and [AI visibility beyond SEO](/guides/ai-visibility-beyond-seo); the messaging-consistency angle is covered in [clear messaging for AI optimization](/guides/clear-messaging-for-ai-optimization).
None of this is exotic. It is the boring, durable work that self-declared files were meant to skip. Use one consistent author byline and bio everywhere you publish, so the entity is stable rather than fragmented across a dozen slightly different framings. Add Person and Article structured data so the author is machine-legible in a format search actually parses. Link your profiles to each other so they reinforce a single identity rather than competing ones. And then produce enough on-topic content, across enough surfaces models crawl, that your name and your subject are inseparable in the training and retrieval data. That co-occurrence at volume is the disambiguation signal — not a declaration, but a pattern the model reads off the open web. If you want the measurement side of this, [how to measure Google AI visibility](/guides/google-ai-visibility-in-seo-tools) covers tracking whether you show up in AI answers at all.
Honestly: it is cheap, so if you run developer documentation and want a clean Markdown index of it for the models and tools that do consume it, there is no harm in publishing one. Just be clear-eyed. There is no measured ranking or AI-citation benefit, Google does not read it, and the major AI crawlers do not fetch it. Do not build a discoverability strategy on it, and do not spend real engineering time on an llms-author.txt file that no spec even defines. The opportunity cost — hours you could have spent producing corroborating content — is the actual risk.
The failure of llms-author.txt is instructive. It tries to compress your identity into one file and hand it to the machines. But AI systems attribute you based on presence and corroboration across the pages they actually read — which means the real lever is producing on-brand, on-topic, consistently-attributed content at a volume and spread that moves the weight of evidence. That is a production problem, and it is the exact problem Kompozy solves. Kompozy is an AI content generation and multi-platform publishing engine: its Persona Brief governs voice, claims, and identity, so every output — text posts, blog articles, newsletters, carousels, quote graphics, avatar and persona video, clips — carries the same author framing and positioning. Then it fans that content to nine social platforms plus blog and email on a schedule.
The practical effect is the opposite of a static file. Instead of one page where you declare who you are, you build hundreds of corroborating surfaces where your name, your role, and your subject co-occur consistently — the LinkedIn post, the blog article, the newsletter, the carousel, all saying the same clear thing, on the properties models crawl and cite. That is what tips entity disambiguation your way and makes an AI assistant describe you accurately: not a metadata declaration a crawler skips, but a durable, on-brand footprint it can't miss. For the distribution mechanics behind that footprint, see [the SEO shift from keywords to AI-driven discovery](/guides/seo-shift-keywords-to-ai-driven-discovery).
Google uses neither llms.txt nor llms-author.txt, and no crawler or LLM has confirmed reading them; Google's own June 2026 guidance says you need no special AI files to appear in Search or its generative features. llms-author.txt is not even a real standard. The attribution and disambiguation problem it was meant to fix is real, but the fix is corroboration, not declaration — a consistent, structured author identity repeated across the many sources models synthesize. You earn accurate AI attribution by being present and consistent everywhere the models read, which is a content-production job, not a file you drop at your site root.
It is a proposed plain-text file that would declare an author's identity — name, role, location, focus — so AI models attribute content to the right person. It is not an established standard; there is no official proposal or specification for it, and it grew out of a Reddit suggestion by a creator who shares a name with more prominent entities and wanted AI assistants to stop confusing them.
No. Google's John Mueller stated plainly that Google uses neither llms.txt nor llms-author.txt, and that he knows of no other crawler or LLM confirming they use them (other than some SEO tools). Google's own AI-optimization guidance, updated June 29, 2026, says you do not need to create any AI text files, markup, or Markdown to appear in Google Search or its generative features, because Search itself does not use them.
There is no evidence it improves rankings or AI citations. Google says its Search index does not read these files, and server logs from sites that publish them show the major AI crawlers do not even request the file. It costs little to publish one, but you should not treat it as a ranking factor or a substitute for the fundamentals — crawlable pages, quality content, and clean structure.
Content-Signal is a directive Cloudflare proposed for robots.txt (later repurposed as an HTTP response header for its "Markdown for Agents" feature) to signal how AI systems may use your content. Mueller's assessment is that no crawler or LLM currently acts on it, so it has no effect and mostly adds bloat and future maintenance. It is a proposal, not an adopted standard.
AI assistants build their picture of an author or brand by synthesizing many sources — your pages, bylines, reviews, editorial coverage, directories, and social profiles — not by reading a file where you declare who you are. Attribution follows corroboration: consistent name, role, and topic signals repeated across sources the models actually crawl, backed by structured author data (Article/Person schema, matching profiles). A self-declared file is the one thing they don't weight.
Make your identity consistent and corroborated everywhere models read: use the same author byline and bio across your content, add Person/Article structured data, link your profiles so they reinforce one entity, and publish enough on-topic content that your name and your subject co-occur across the open web. The lever is presence and consistency at volume, not a metadata file — which is exactly what an AI content engine like Kompozy is built to produce.
LLMs-Author.txt is a proposed plain-text file meant to declare an author's identity so AI models attribute content correctly. Google's John Mueller confirmed Google uses neither llms.txt nor llms-author.txt, and no major crawler or LLM has confirmed reading them. For SEO and AI attribution they do nothing today. What actually works is a consistent, corroborated author and brand identity across the many pages models genuinely read and synthesize.
Get started → · ← All guides · Compare Kompozy vs other tools