llms.txt Checker and Generator Guide: Validate Your AI File

Writing an llms.txt file is only half the job. The other half is checking it, because a file that links to moved pages, describes content that no longer exists, or contradicts your site's own navigation does more harm than no file at all. The llms.txt Checker and Generator exists for that second half: it reads a draft file, flags problems, and can generate a fresh version from the pages you actually have. Used well, it turns a document that quietly rots into one that stays trustworthy. Used carelessly, it becomes a button you press once and forget, which is how stale files happen in the first place.

A checker typically looks at several things. First, structure: does the file open with a title and description, are links grouped under headings, and does each link carry a description? Second, link health: does each listed URL resolve to a real page, or does it return an error, redirect somewhere unexpected, or point at a page that has since been removed? Third, description quality: are descriptions present, specific, and roughly one sentence, or are they missing, duplicated, or padded with marketing language? Fourth, consistency: does the file list pages that your site itself has retired, blocked, or replaced? None of these checks can judge whether your descriptions are true in a deeper sense; a checker can tell you that a link works and a sentence exists, but only a human who knows the site can tell whether the sentence still describes the page. Treat the checker as a proofreader, not an editor.

Generating a file from scratch is a different task from checking one. A generator starts from a list of pages you supply, or from a sitemap, and drafts the structure: title, description, sections, and one line per page. The draft is a starting point, not a finished document, because generated descriptions tend to be generic. They often repeat the page title in slightly different words, which adds nothing for a reader. The valuable work happens after generation, when you rewrite each description in your own words, cut the pages that do not belong, and group the rest by topic rather than by whatever order the generator produced. Budget more time for that editing pass than for the generation itself; if you do not, you will publish a file that looks finished but reads like a sitemap with extra punctuation.

What to check, in order

Work through a file in a fixed order so nothing is skipped. First, read the introduction and ask whether it still describes the site as it is today, not as it was at launch. Second, click or verify every link, watching for errors, redirects to unrelated pages, and pages that now require a login. Third, read every description against its page, asking whether a stranger who read only that sentence would arrive at the right page with the right expectation. Fourth, look for what is missing: a major new guide or tool that belongs in the file but is not there yet is as much a defect as a broken link. Fifth, check the file's location and encoding: it should sit at the site root, be served as plain text, and contain no characters that break a simple parser, such as unescaped markup pasted in from another document.

A useful discipline is to keep the checker in your publishing routine. When a new guide goes live, the file gains a line; when a page is retired, the file loses one. Teams that do this in the same session as the content change almost never have stale files, because the cost of one line is trivial while the details are fresh. Teams that schedule a quarterly cleanup usually discover, at cleanup time, that three months of changes have piled up and the file needs a rewrite rather than a touch-up. The difference is not diligence in the abstract; it is whether the update happens at the moment of change or at a later moment that competes with everything else.

Worked example

Consider a site with an llms.txt file listing 24 links. A check finds the following: 3 links return 404 errors because those guides were retired, 2 links redirect to different guides after a URL restructure, 4 descriptions are duplicates of the page titles and add no information, and 1 major new guide, published two months ago, is missing entirely. That is 10 defects in a 24-link file, or about 42 percent of the entries needing attention, which is a file that misleads more often than it helps. Fixing it takes a predictable amount of time: removing 3 dead links and updating 2 redirects takes about 10 minutes, rewriting 4 descriptions takes about 20 minutes, and adding the missing guide takes about 5 minutes, for a total of roughly 35 minutes. After the fix, the file has 22 links: 24 minus 3 retired, plus 1 new guide. Running the same check monthly would have caught each defect when it appeared, at a cost of a few minutes per month, instead of a 35-minute repair. The arithmetic is the argument for routine: small, frequent checks are cheaper than rare, large ones, and they keep the file trustworthy in between.

Mistakes to avoid

The first mistake is trusting a clean checker report as proof that the file is good; a checker verifies form, not truth, and a well-formed file can still describe pages inaccurately. The second is generating a file and publishing the draft without editing, which produces generic descriptions that help nobody. The third is listing pages that are blocked to crawlers or require login, which sends contradictory signals. The fourth is stuffing the file with every page on the site, turning a curated guide back into a sitemap. The fifth is expecting the file to guarantee citations, traffic, or rankings from AI systems; it is a courtesy to readers, not a lever that controls them, and no checker can change that.

Putting it into practice

Run a check on your existing file today, fix the defects in the order above, and then attach the check to your publishing routine: new page in, retired page out, in the same session. For related tools, the llms.txt Builder drafts the file by hand, the Sitemap Checker verifies the crawler-facing list it should roughly agree with, and the companion guide on LLM evaluation rubrics covers how AI outputs get judged once they are produced. A checked, current llms.txt file will not make an AI system love your site, but it will make sure that when a system does read it, it reads something accurate.

Key points

• A checker verifies structure, link health, description quality, and consistency, but only a human can judge whether descriptions are still true
• Treat generated drafts as starting points and rewrite every description in your own words before publishing
• Attach file updates to your publishing routine so new pages enter and retired pages leave in the same session
• A clean report proves form, not truth, and no llms.txt file can guarantee citations, traffic, or rankings

In short: check the file in a fixed order, edit generated drafts properly, update it at the moment of change, and remember that accuracy, not length, is what makes it useful.