llms.txt is an optional Markdown file for giving agents an organized introduction and links to a site’s content. Google says it ignores these files for Search visibility and rankings. Decide whether a named reader or tool needs one, then check its accuracy and maintenance cost.
A file can be well formed and still describe outdated pages. A tool can request it without using it in an answer. A citation can appear without showing that the file caused it. Keep those questions separate.
Does llms.txt help SEO?
Google’s current guidance says publishing llms.txt neither helps nor harms visibility or rankings in Google Search, including its generative AI features. It may still be maintained for another system that uses it. This is Google’s stated behavior, not a conclusion about every provider. Google’s AI optimization guide.
There is a separate Lighthouse check under agentic browsing. Its documentation says a server error retrieving the file is flagged; a missing file returning 404 is marked Not Applicable because provision is optional. A Lighthouse check is not evidence of a Search ranking signal. We read the documentation for this guide; we did not run that audit. Lighthouse’s llms.txt documentation.
For a service-business website, the first useful question is: who will use this file, to complete which task? “Find our current implementation documentation in a named agent workflow” is testable. “Make every AI trust us” is not an implementation requirement.
What the file contains, and what the current proposal says
The llms.txt v2 proposal describes a Markdown overview with a site or project H1, optional summary and organized resource links. The H1 is its only required section. Root and scoped-path files are supported; the most specific applicable file covers its path.
The August 2026 revision also describes discovery relations for a page’s Markdown alternative and its relevant llms.txt file. These can appear in HTML or HTTP headers. An Optional section remains a useful convention for secondary material, rather than a special processing instruction. The v2 changes.
Follow the proposal directly if conformance matters to your consuming workflow. A checker that finds a heading and several links has not certified the whole file, its destinations or that workflow.
Different files have different jobs
| Resource | Job in our implementation | What its existence does not establish |
|---|---|---|
| Public HTML page | The reader-facing explanation, evidence and working features | That an agent has used its content |
| XML sitemap | A list of page URLs supplied for discovery | Guaranteed crawling or indexing |
| robots.txt | Published crawler access instructions | That every type of request obeys the same controls |
| llms.txt | A concise index of page names, summaries and links | A Google Search benefit or universal agent support |
| llms-full.txt | Our generated text export, with page URLs and content | A mandatory second file, complete feature parity or measured citation gains |
This table describes roles, not a sequence every search engine follows. For crawler-specific decisions, use the ChatGPT search-readiness guide. To see what your robots.txt currently allows each AI crawler, and whether a page’s text arrives without JavaScript, run one page through our free AI Crawler Checker; it leaves llms.txt alone, because the access controls the crawlers document live in robots.txt. For observing answers, use the citation-tracking log.
What we found in our published files
On 6 October 2026, between 07:05 and 07:06 UTC, we fetched our public llms.txt, llms-full.txt and five selected live HTML pages. These were public HTTPS responses, not local preview files. The retained capture excludes articles that were only under local review at that time.
Both files returned HTTP 200 with a plain-text content type. The index contained 73 Markdown link entries with 73 unique destinations. Its URL set matched the 73 page URL records in the full export. The index was 20,389 bytes; the full export was 829,941 bytes. These are captured decoded file sizes, not transfer sizes or token counts.
| Selected live page | Comparison we made | Result in this capture |
|---|---|---|
| What is AI SEO | Index name/summary, first article table and first article list | Matched H1/meta description; selected table/list text present |
| AI SEO tools | Index name/summary, first article table and first article list | Matched H1/meta description; selected table/list text present |
| AI SEO statistics | Index name/summary and first article table | Matched H1/meta description; selected table text present; no body list in this check |
| Answer-source format | Index name/summary, first body table and first body list | Matched H1/meta description; selected table/list text present |
| Service, location and industry pages | Index name/summary, first article table/list and both code blocks | Selected text present; both code payloads matched |
All five selected page requests returned 200 without redirects. Across their first body tables, all 89 cell texts were present in the corresponding export sections. All 20 items in the selected lists were present. Prose comparisons normalized whitespace and Markdown decoration. The two code comparisons preserved payload characters, apart from a terminal newline.
That is a bounded text-preservation check. It does not prove that all 73 destinations work, every sentence is current, a table has preserved every semantic relationship, or any provider read the files. We did not inspect private server logs, measure rankings or test citation effects.
The limitation our own example exposes
Our captured index links to HTML pages, while v2 recommends links to agent-friendly resources such as page-level Markdown. None of the five captured HTML pages or their HTTP headers exposed the Markdown-alternative or llms.txt discovery relations described above.
So this is a working index and full-text export with a disclosed scope. We do not present it as complete v2 implementation. Adding page-level alternatives and discovery links would be a separate implementation decision, with a named use and its own checks.
The retained audit report keeps the per-page checks. The evidence bundle includes the original public files, selected HTML responses, response metadata, comparison script and hashes. They are a historical snapshot, not a live check of today’s site.
Our public pages supply the source. The concise index keeps their names, descriptions and URLs. The full-text export keeps selected page content and structure. Check the outputs against their sources before calling them current. This diagram describes our implementation, not a required engine pipeline.
Open the full-size diagram · Read its text equivalent.
Check a file in two passes
1. Inspect the pasted text
Use the working section above to record a file URL and paste the index. The aid counts headings and simple Markdown list links, identifies repeated destinations and flags syntax it cannot assess. It ignores fenced examples so an example title is not mistaken for the file’s title.
This is a text review. It does not request your URL, test HTTP status, follow a redirect, confirm a source date or inspect provider behavior. A recorded URL is just a label until someone checks it.
If you change the text after a check, run the check again. The exported record keeps the actual checked text separately from later edits. A clean-looking result should never silently describe a different file.
2. Compare selected statements with their sources
Choose material whose meaning matters: the scope of a service, a limitation next to a statistic, a table header and row, a code example, or a dated policy statement. Copy the relevant source passage and exported passage into separate fields. Record the source URL, capture date, evidence reference and your result.
Start with the current public response. A correct local build does not establish what the live server returns. If you encounter a redirect, unavailable page or contradiction, retain it and assign a next action instead of marking the row matched.
The manual record is your assessment. Its confirmation box does not verify the source for you. Unfinished rows remain in exports, because missing evidence is useful information for the next reviewer.
Decide to defer, maintain or implement
Defer when the only proposed benefit is a promised search lift, no consuming workflow is named, or the team cannot keep the material accurate. Spend the effort on a documented user or search problem.
Maintain when a file already supports a useful task. Keep an owner, the source of each section, a refresh trigger and a simple way to compare outputs after changes. For our implementation, source/output review belongs with a website release; this guide’s capture is one dated review, not evidence of every past release.
Implement when a specific workflow needs the convention and the team can test it. Begin with a small scope, verify the linked destination a person or tool actually receives, and document how changes reach the file. Use the proposal’s current requirements, rather than copying an old template unquestioningly.
An illustrative decision could read: “Maintain this documentation index for our support team’s chosen agent workflow. The documentation owner reviews changed links and examples on release. Search improvement is not the acceptance test.” This is a suggested record, not a claim about our customers or a measured result.
Keep the evidence beside the decision
Download the blank record before a review, or export your working copy from this page. Keep the file version, tested text, source checks, unresolved items and responsible person together. If you later study citations, record that work separately using a repeatable sample. A correct file and a visible citation are separate observations until evidence connects them.
Primary guidance was reviewed on 6 October 2026: Google’s guide, updated 10 July 2026; Lighthouse’s audit documentation, updated 5 May 2026; and the llms.txt v2 proposal and August changes. Recheck those sources when your implementation decision changes.