I put llms.txt on the six sites I run. It is not a magic file that gets you read by AI, and adding one did not make anything start citing me.
It is still worth trying — as a signpost that helps an AI agent or agentic browser grasp the shape of a site. But the thing that actually matters sits elsewhere: whether your published pages are hard to misread in the first place. Turning that into a checklist is far more useful than arguing about one text file.
This is my own operation log, dated July 2, 2026, with link states re-verified in September 2026.
Originally published in Japanese on July 2, 2026. This English version was written in September 2026.
What llms.txt actually is, per the official framing
Do not over-invest here. Chrome’s Lighthouse agentic browsing audit describes llms.txt as an emerging convention for providing a machine-readable summary of a site’s content, aimed at LLMs and AI agents. The same documentation states that if the file is absent and the server returns 404, the audit is marked Not Applicable, because providing the file is optional at the moment.
So: not having one is not a defect, and having one is not a ranking signal. Google’s own AI-optimization guide goes further than Lighthouse does, stating that you do not need to create machine-readable files, AI text files, markup or Markdown to appear in Google Search, and that such files neither harm nor help a site’s visibility or rankings. The original proposal treats llms.txt as a Markdown summary of the site and its important links.
It is not a replacement for robots.txt or a sitemap. Read as a supporting hint for AI comprehension, it makes sense. Read as “the new mandatory file for AI SEO,” it does not.
Six sites, published and checked
You cannot judge it without running it, so I published /llms.txt on all six sites I operate: isLog, moss.fish, taupe, ojicra, monoomoi, and monoerabi.
All six returned 200 OK with a text/plain content type when checked on July 2, 2026, and again when re-checked in September 2026. That is a reachability check on my own sites, not evidence that anything consumed them.
The contents are not a full article index. Each holds the site description, main categories, representative articles, the operator and official-site route, and notes on what to be careful about when summarizing.
The rule I set for myself: never show AI a different story than the site shows. Nothing in llms.txt may contradict a published page. It is a signpost, not the record of truth. The record is the published HTML, the article body, the structured data, and the internal links.
The real work is ordinary publishing quality
Google’s guidance on optimizing for generative AI features says basic SEO continues to matter, because Google’s AI features build on the search index and crawlable public pages. Being findable, having a clear technical structure, and being useful to readers remain the preconditions.
OpenAI’s crawler documentation separates OAI-SearchBot, GPTBot, and ChatGPT-User: the bot that surfaces sites in ChatGPT search, the crawler whose content may be used to train foundation models, and the agent that fetches a page because a user asked. Collapsing all three into “AI crawlers” is how people end up making the wrong policy decision.
So the thing to inspect on your own site is not a trick for feeding AI. It is whether the published URL returns 200, whether the canonical is right, whether the subject is clear from the H1 and the opening, whether the Article JSON-LD matches the body, whether breadcrumbs expose the category hierarchy, whether internal link anchors are specific, and whether volatile information carries a verification date.
The mini-check I actually run
- Does the URL return 200 OK?
- Do
canonicalandog:urlpoint at the intended URL? - Is it accidentally
noindex? - Is there Article or BlogPosting JSON-LD?
- Is there a BreadcrumbList?
- Are author, publication date, and updated date discoverable?
- Do the H1 and the opening make the subject obvious?
- Are personal experience and verified fact kept distinguishable?
- Does volatile information carry a verification date?
- Are internal link anchors specific?
- If
llms.txtexists, does it contradict any published page?
This is a pre-publication check rather than an AI tactic. Easy for a human to read, easy for a search engine to parse, and hard for an agent to over-generalize when summarizing: those three overlap far more than they differ.
Running it against one of my own articles
I ran the check on a taupe article about using a Mac mini as the always-on machine for Codex work (in Japanese). As a single page it held up well: canonical and og:url agreed, Article and BreadcrumbList JSON-LD were present, H1 and title matched, and the H2 structure split cleanly enough that a summarizer could pick up the context of each section.
One small defect did show up: in places, the article title had been reused as the alt text on product and measurement images. It does not hurt the reading experience much. But for machine reading, body images, product images, decorative images, and screenshots of measurements deserve to be treated differently — and this is exactly the kind of thing a conventional SEO pass skips over.
Have your own criteria before you buy a scoring tool
Tools that score how AI-readable a site is, audit it as an agent skill, or extract pages into an AI-friendly form are appearing. I built a CLI in that last category myself and wrote it up in Public Source Extractor.
The direction is interesting. But rather than dropping one into my production Chrome or Codex environment, I would rather first translate its output into my own checklist — because a score on its own often does not tell you what to fix.
With your own criteria, you can sort a tool’s findings: is this a real defect, or something to absorb into the template later? Is it specific to this article, or a site-wide problem? That sorting is most of the value.
Split it into per-article and per-site
Auditing the whole site before every post means never posting. So I run two lists at two cadences.
At publication time, per article: title, H1, and description match the content; canonical and og:url are correct; not noindex; Article JSON-LD present; BreadcrumbList present; author and dates visible; at least one or two internal links; a verification date on anything volatile; primary or official sources cited.
Monthly, or after a large change, per site: robots.txt, sitemap, feed, llms.txt, About and author pages, main categories and entry-point articles, AI crawler policy, and the routes to the official hub and contact.
AI-readable is publishing quality with two extra lines
Publishing llms.txt across six sites was a useful exercise, mostly because it forced me to articulate how each site should be described. But that is where its usefulness stops.
If you want a site that is hard to misread, look at the published pages: canonical, JSON-LD, breadcrumbs, internal links, author, updated date, verification date. All old elements. What changes is that AI search and AI agents now read them too.
Findable by a search engine, clear to a reader, and hard to distort in a summary — treat those as one problem, not three. AI-readable is not a new kind of magic; it is a few extra items on the pre-publication checklist.