Does an Agent Know Your Three Sites Belong Together?

Your marketing site runs on WordPress. The store runs on Shopify. The documentation sits on Mintlify. All three platforms now write an llms.txt for you, a plain markdown index at the domain root telling an AI agent what the property is and which pages carry the answers. Three generators, three files, three positioning statements. Nothing in any of them says the three describe the same company. If you manage llms.txt for multiple client sites, that silence is the entire failure. Three architectures close it: canonical root, federated, and generated union, each named below with its tradeoff and the cross-linking rules that survive the next regeneration.

Key takeaways

• 36,120 sites published an llms.txt by May 2026, up 8.8x from 4,088 a year earlier, on Originality.ai data reported by PPC Land on 2 July 2026.
• 97% of those files received zero requests in May 2026, per an Ahrefs study of 137,000 domains. A broken multi-property set fails silently.
• Shopify has redirected /llms.txt to /agents.md since May 2026 and reads the override from templates/agents.md.liquid, so a file uploaded to the store root is discarded.
• Three architectures exist: canonical root, federated, generated union. Pick on ownership, not taste. The specification, published by Jeremy Howard in September 2024, says nothing about multiple properties.

Three generators, three companies

The three files disagree because nobody wrote them. On WordPress the usual source is the Website LLMs.txt plugin, at version 8.5.6 with more than 40,000 active installations. Network-activated on a multisite install, it gives each subsite its own rewrite rules and registers rules automatically for sites created later, so a five-property network silently produces five independent files with no shared header.

Shopify moved the ground in May 2026. On the Shopify Developer Community forum on 20 May 2026, a Shopify staff member confirmed that "the redirect from /llms.txt to /agents.md is expected" and that Shopify "now uses /agents.md as the primary storefront discovery file". agents.md is the sibling format describing what an agent may do on a site rather than what the site contains. For llms.txt for ecommerce websites the consequence is blunt: the only documented override is templates/agents.md.liquid inside the theme, so anything uploaded to the store root is no longer served.

Mintlify "automatically hosts an llms.txt file at the root of your project that lists all available pages in your documentation", a file that "is always up to date and requires zero maintenance". Zero maintenance also means zero knowledge of your other two properties. The platform detail sits in what each platform generates by default.

What an agent sees when the three disagree

An agent fetching all three files reads three companies. The WordPress file opens with the site tagline, the Shopify file with Shopify's generated commerce description, the Mintlify file with the docs.json line written by whoever set up the docs in week one. Three H1 values, three blockquote summaries, no shared entity.

Agencies that manage llms.txt for multiple client sites rarely catch this, because nothing bounces back when the set contradicts itself. The Ahrefs analysis of 137,000 domains found 97% of llms.txt files received zero requests in May 2026, and where requests did arrive, SEO audit tools accounted for 21.7% against 1.1% for AI retrieval bots.

Scarcity is why it still matters. Rankability's June 2026 scan of the Tranco top 1,000 domains found 8.7% publishing an llms.txt, rising to 15.8% among the 549 actually reachable. Coherence is cheap and almost nobody has bought it, which is also why the defaults describe the wrong thing.

Architecture one: the canonical root file

The canonical root architecture puts the full company description in one file on the primary domain and reduces every satellite to a short header plus a pointer back. The marketing domain carries the H1, the blockquote, and the section list. The store file says what the store is in two sentences, then links to the root file as authoritative.

Eoghan Henn documented the closest published precedent on Rebelytics on 19 January 2026: a root index file linking to 27 language-version files, modelled on the XML sitemap index. His split is the one to copy, since "the index file contains general, language-agnostic information" while each child file covers only its own version.

Choose canonical root when one domain genuinely carries the brand and the others are outbuildings. It is the cheapest way to manage llms.txt for multiple client sites, because only one file holds prose anybody maintains. Its failure mode is specific: satellites are what platforms regenerate, so the pointer home is the line most likely to be overwritten.

Architecture two: federated files with explicit cross-references

The federated architecture keeps each property authoritative for its own job and adds one section, usually last, naming the sibling properties and what each is for. The store file describes the catalogue, then states that documentation lives at docs.example.com and the company description at www.example.com. Every file carries the same sibling block.

Henn's implementation shows the mechanic at scale: "each language-specific llms.txt file also links to all other llms.txt at the end of its content". Reciprocity is the point. A one-way link tells an agent A knows about B; a reciprocal pair tells it A and B are one operation.

Federated is what most teams that manage llms.txt for multiple client sites reach by accident, then formalise. Choose it deliberately when the properties serve different buyers, because one merged description would serve none of them. The cost is duplicated prose in three places, and duplicated prose drifts within two quarters unless somebody owns the check.

Architecture three: a generated union from one source

The generated union architecture treats llms.txt as a build artefact rather than a document. One source of truth, usually the CMS or a checked-in YAML file, holds the company description, the property list, and the page inventory. A build step writes one file per property from it, each scoped to its own job, each carrying the same company block and the same sibling list.

This is the only architecture that survives beyond roughly ten properties. Pulling llms.txt content from a CMS also removes the staleness the other two carry: the file regenerates on the deploy that changes the page it describes, so programmatic llms.txt generation at scale becomes a CI concern rather than an editorial one. On Next.js, Nuxt, or SvelteKit the build step is a route handler reading whatever already produces sitemap.xml.

It costs a pipeline. Teams that manage llms.txt for multiple client sites this way inherit one new failure mode: when the build breaks, every file goes stale at once and nothing in the site output looks wrong. Add the file to the deploy smoke test. Broader tradeoffs sit in the hub view on generation.

Choosing an architecture when you manage llms.txt for multiple client sites

Three columns decide it: when to choose each one, what it costs to keep running, and how it fails.

Ownership decides more than architecture does when you manage llms.txt for multiple client sites. If nobody can name who edits the Shopify theme, federated will not hold, because that sibling block will never be updated. Pick the architecture matching who actually has commit access.

Cross-links that survive the next platform regeneration

Platform regeneration is where cross-references die, and each platform drops them somewhere different. Four rules hold across all three.

Put the sibling block inside the override the platform reads, never in a file uploaded beside it. On Shopify that is templates/agents.md.liquid, since the documented redirect sends /llms.txt to /agents.md and a root upload is not served. On Mintlify it is a committed llms.txt at the project root, because "adding a custom file overrides the automatically generated file of the same name". On WordPress it is the plugin's settings, not a file a rewrite rule will shadow.

Use absolute URLs. A relative path resolves against whichever host served the file, so /docs/llms.txt in the store file points at a page on the store.

Keep the block last and short, but never inside an Optional section. The specification says URLs there "can be skipped if a shorter context is needed", the wrong bucket for links proving your properties are one company.

Accept that there is no standard signal. GitHub issue 18 on the AnswerDotAI/llms-txt repository asked how a crawler should discover a file at a non-root path and proposed a <link rel="llms.txt"> tag. It is still open with no maintainer answer, so teams that manage llms.txt for multiple client sites are writing conventions, not implementing a spec. Framer gates well-known file uploads behind a paid plan, and Webflow permits no arbitrary files at the domain root at all.

The monthly consistency check

Run this on the first working day of the month, across every file in the set. Teams that manage llms.txt for multiple client sites should budget about ten minutes per brand.

1. Fetch every file in one pass. Request each URL directly, and confirm a 200 with a text content type, not a redirect to an HTML page.
2. Compare the H1 and the blockquote. The specification makes the H1 "the only required section". Three H1 values naming three different things give an agent no basis to merge them.
3. Count the cross-references. Every file names every sibling, with absolute URLs, or the architecture has degraded to three unrelated files.
4. Diff against last month's copy. Keep each file in the repository. A regeneration that silently rewrote your override shows up here and nowhere else.
5. Read the server logs for the file path. With 97% of files receiving zero requests, one log line from GPTBot, which drew 4.51% of observed requests, beats any audit score.
6. Reread each description as a buyer. What ships is usually a page list with no argument in it, and the monthly consistency check covers scoring beyond conformance.

A disagreement is not a formatting problem. Two properties are telling an agent two different things about who you are, and the agent has no tiebreak rule. Fix the source of truth, then regenerate.

FAQ: multi-property llms.txt

How do I manage llms.txt for multiple client sites without a build step?

Use the canonical root architecture. One file on the primary domain carries the full company description and the section list, and each satellite carries two sentences plus an absolute link back. Only one file holds prose anybody maintains, so the monthly check is a comparison rather than a rewrite. It holds to about ten properties before manual sibling blocks start drifting.

Does the llms.txt specification define an index file?

No. The specification published by Jeremy Howard on 3 September 2024 defines a file at the root path, "or, optionally, in a subpath", with a required H1, a blockquote summary, and H2-delimited lists of markdown links. It says nothing about multiple files, subdomains, or an index. The root index pattern is borrowed from XML sitemap indexes, so no crawler is obliged to follow your pointer.

What happens to my Shopify file now that agents.md is primary?

It stops being served. Shopify confirmed on 20 May 2026 that /llms.txt redirects to /agents.md and that /agents.md is the primary storefront discovery file. The single documented override is templates/agents.md.liquid in your theme. Move your sibling block there, then refetch /llms.txt and confirm the redirect resolves to content you wrote.

How often should the files be regenerated?

Match the cadence to how fast the underlying pages change. The Website LLMs.txt plugin exposes immediate, daily, and weekly settings plus a manual trigger, and a generated union regenerates on every deploy. Whatever the cadence, the consistency check stays monthly, because drift comes from platform-side regeneration rather than from your own publishing rhythm.

How La Boétie helps you manage llms.txt for multiple client sites

La Boétie runs the same problem on its own domain. The file at laboetie.io/llms.txt opens with an H1, a blockquote, and six sections, Company, Products, Tools, Lab, Insights and Data, each carrying one to four links, because a page list without an argument gets nobody cited.

The llms.txt Generator. Self-serve, one job, paid once at 20 € or 25 dollars a run, no account and no call. Run it per property, then hand-edit the sibling block.

Generated union, built into your stack. Five to six engineers ship the route handler, the source of truth, and the deploy smoke test alongside your existing CMS. You keep ownership of everything built, which is the studio's founding constraint rather than a policy line.

Properties already shipped. More than ten client properties run on studio-built stacks, from france-epargne.fr to llb-auction.com and rubashkinshouse.com.

Start with the generator: run it on your first property.

Conclusion

Three files that never mention each other cost nothing to fix and almost nobody fixes them, which is why the fix is worth making while only 8.7% of the top 1,000 domains publish anything at all. Canonical root is right when one domain carries the brand. Federated is right when three buyers need three descriptions. Generated union is right past about ten properties.

Pick one, write it down, and check it monthly. The teams that manage llms.txt for multiple client sites and get cited are not the ones with the longest files; they are the ones whose files agree on who the company is.

Sources

Further reading

• what each platform generates by default
• why the defaults describe the wrong thing
• the monthly consistency check
• the hub view on generation

References

• The /llms.txt file : Jeremy Howard, 2024
• Llms.txt and agents.md : Shopify, 2026
• llms.txt and llms-full.txt : Mintlify, 2026
• Website LLMs.txt plugin : WordPress.org, 2026
• llms.txt adoption rises 8.8x : PPC Land, 2026
• LLMS.txt adoption tracker : Rankability, 2026
• Scalable international llms.txt structure : Rebelytics, 2026
• Multiple llms.txt files at multiple paths? : GitHub, AnswerDotAI
• Static files : Framer, 2026
• Upload an llms.txt file : Webflow, 2026
• La Boétie llms.txt : La Boétie, 2026