An XML sitemap and an llms.txt file serve different purposes. A sitemap helps communicate preferred website URLs to search engines; llms.txt is a proposed format for guiding agents to useful information. Neither should be treated as a substitute for accurate public pages.
For a SaaS directory, the practical question is not which file “wins.” It is whether each representation solves a real discovery problem and can remain consistent with the underlying product records.
Start with the search-indexing workflow
A sitemap should identify the canonical URLs the publisher wants search engines to discover. Google's documentation describes supported formats and recommends meaningful modification dates rather than changing every date whenever a sitemap is generated. [1]
For IndieTools, a proposed publishing workflow would add a new article only after the public route is ready and its canonical destination is settled. Drafts, redirecting aliases and accidental filter combinations should not be treated as equivalent to finished editorial pages.
Understand the llms.txt proposal
The llms.txt proposal describes a curated Markdown overview that points agents toward relevant material. Version 2 also describes standard link relations for finding Markdown alternatives and the covering llms.txt document. [2]
That makes it useful to think in terms of navigation and information quality: which pages are authoritative, what each one explains and where details can be retrieved. An unreviewed dump of every sentence on the website is not automatically a better guide than a concise, maintained index.
Do not attach an unsupported Google ranking claim
Google's current guidance explicitly says that Search does not use llms.txt for visibility or ranking, including its generative AI features. [3] Publishing the file should therefore not be presented as a Google ranking improvement or a requirement for AI Overviews.
There may still be a practical use for documentation clients or other systems that consume it. Evaluate that use directly: can an intended client find the correct product information more reliably? That is a different experiment from claiming additional organic traffic.
Keep every representation tied to the same facts
A directory may expose HTML product pages, Markdown summaries and a read-only API. These should not disagree about the official URL, current name or availability of a feature. Use a shared reviewed record where feasible and carry a meaningful update timestamp.
For changing data such as speed measurements, include the measurement scope and date with the value. A score without its test conditions can become misleading when copied into another format. The representation should preserve context, not strip it away to make the file shorter.
Test the maintenance path
Choose one product and make a controlled editorial correction in a staging environment. Check which representations update and whether cached versions remain stale. Also test a renamed product, a removed listing and a link that changes destination.
These cases reveal maintenance risk more clearly than checking whether a file exists. Assign responsibility for broken references and conflicting descriptions. When a format cannot be maintained accurately, simplify its contents rather than publishing a second source of contradictory facts.
Prioritize work by the user's problem
An inaccessible article, an outdated pricing claim or a broken canonical URL usually deserves attention before a new export format. The goal is a coherent information system: readable pages for people, appropriate discovery signals for search and well-scoped interfaces for clients.
IndieTools already documents a public MCP catalog interface. [4] That provides a separate integration context to consider, but it does not eliminate the need for public editorial pages or establish that every search system will call the interface.
Frequently asked questions
Should llms.txt contain every product description?
Not necessarily. A curated index with accurate links may serve the intended client better than a very large file. Test the retrieval task and maintenance cost.
Does a sitemap guarantee indexing?
No. It communicates discovery information; it does not compel a search engine to index or display every submitted URL.
Should Markdown replace HTML?
Not by default. Maintain a useful human-facing page and provide an alternate representation only when it supports a real client or documentation workflow.
Explore related IndieTools resources: reported technology collections.
Continue your research
- AI Crawler Access: Search vs Training
- MCP Product Catalogs vs Search-Indexed Pages
- Product Directory Schema: Choose the Right Type
Sources and verification
Sources consulted for this article on October 1, 2026. Product capabilities are documented claims unless an actual test is explicitly described.
