Do agencies need a different llms.txt process than a single site does?

The file format is identical. The process is not. An in-house team writes one file and lives with it; an agency writes a file it will not maintain, deploys it to a stack it may not control, and hands it to a client who will forget it exists. Most agency llms.txt failures are handover failures rather than formatting failures, so the process has to be built around who edits the file in month six.

Can I reuse one llms.txt template across all my clients?

Reuse the structure and the checks, never the sentences. Headings, ordering rules and the audit loop are portable. The summary paragraph, the pricing line, the list of what the company does and every URL are client-specific, and a leftover sentence from the previous client is the single most common defect in agency-produced files. Ship a template with placeholders and a delete-before-launch list, not a filled-in example.

How do I prove the llms.txt work to a client?

Report only what you can observe: the file is live at a specific URL, it returns 200 with a text content type, a named number of listed URLs were fetched and returned real content, the validator passes, and which AI crawler user agents appeared in the client's server logs if they share them. Do not promise rankings, AI citations or traffic. There is no stable causal measurement for llms.txt in 2026, and a client who is told otherwise will measure you against a number you cannot control.

Content Strategy · November 2026

llms.txt for Agencies and Freelancers

An agency ships the same file twenty times and maintains it zero times. Every defect in a single-site llms.txt gets multiplied by the client list — the staging URL that survived launch, the description written for the previous client, the "our platform" paragraph in a file for a law firm. What follows is the process that stops that, from the onboarding audit to the handover document that decides who edits the file next quarter.

The Template Is the Problem, Not the Format

New client work usually starts from the last client's file, and that is where the damage enters. The structure travels well: an H1, a one-paragraph summary, four to seven H2 sections with links, an Optional section at the end. The sentences do not. Files produced this way carry a summary that names the wrong company, a "Pricing" section pointing at a URL that returns 404 on the new domain, and a line about "our API" on a site that has none.

The version that survives is a skeleton with hard placeholders and a delete list:

# CLIENT_NAME

> One sentence: what the company sells, to whom, and where it operates. REPLACE

DELETE BEFORE LAUNCH
- every URL from the previous client
- staging, preview and localhost hosts
- the previous client's summary paragraph
- any section header with nothing under it

## Core pages
- [ ] Replace all links with this domain
## Pricing
- [ ] Only include if a public pricing page returns 200

Two minutes with that list removes most of what a reviewer would otherwise catch at launch. The structural rules themselves are the same everywhere and are worth writing down once for the whole team — the order of sections, the summary paragraph, the Optional convention are covered in the generator workflow.

The Onboarding Audit: Twenty Minutes Per Client

Before writing anything, find out what the client already has. Roughly half of established sites have a file someone forgot about, and it is usually worse than nothing. Run one loop over the domains in scope:

while read -r host; do
  code=$(curl -s -o /tmp/f.txt -w '%{http_code}' "https://$host/llms.txt")
  type=$(curl -sI "https://$host/llms.txt" | grep -i '^content-type' | tr -d '\r')
  echo "$code $(wc -c < /tmp/f.txt) $host $type"
done < clients.txt

Read the result as a diagnosis, not a status code:

Result	What it usually means	Action
200, text/plain or markdown	A real file exists; audit its links	Keep the skeleton, rewrite the content
200, text/html	SPA or catch-all routing serves the homepage	Add an explicit route and a static asset
403 or 429	WAF or bot rule blocks the fetch	Allowlist the path before launch, not after
301 to another host	File lives on the docs or older domain	Decide the canonical host first
404	Nothing exists	Build from scratch, no legacy debt

The second half of the audit is the clients' own content: an out-of-date page inventory, a sitemap that still lists retired products, docs on a subdomain nobody mentioned. Every one of those becomes a wrong link in the file if you write it before asking.

One File Per Domain, Not One Per Client

Clients increasingly have a marketing site, a documentation host, a blog on a subdomain and two regional domains. The instinct is to write one file listing all of it. Resist it. An llms.txt file is scoped to the origin that serves it, so a file on the marketing domain that links into a docs host spends the agent's next fetch on a hop you could have avoided — and if that host blocks the crawler, the whole section dead-ends.

The workable arrangement is one file per origin that publishes content, with the root file delegating in a single line: documentation lives at a separate host and its index is published there. Which host owns the primary file, and how the pairs should differ, is the subject of root domain versus docs subdomain. For the client, the deliverable is a list: origin, file status, owner, deploy path.

Write Descriptions a Stranger Could Parse

Descriptions are the part clients rewrite. Every entry should say what the page answers, in one line, without adjectives. "Enterprise-grade solutions" tells an agent nothing and survives in files produced by committee. "Redirect rules for the v2 API, including deprecation dates" is the kind of line a model can act on, and it also happens to be the line a client can verify is still true.

Set the editorial rule for the whole engagement: no superlatives, no marketing claims, no numbers the client has not published on the page being linked. Those three rules also keep the file out of the territory described in what not to include in llms.txt.

Handover: Who Owns the File After Launch

The file has to live where the site is built. Not in a shared document, not in a CMS page that renders as HTML, not in an email attachment. Put it in the repository next to the content it indexes, add it to the deploy step, and confirm the production URL after the first release. Then name an owner — usually whoever writes the case studies — and write that name into the handover note.

A file with no owner gets one of two fates: it is never touched again, or it is edited by someone who does not know the format. Both show up as the same symptoms six months later — dead links, a summary describing a product that was renamed, sections that no longer match the site's navigation. The recurring maintenance routine that prevents this is in keeping llms.txt up to date.

The Handover Checklist

The file is 200 at the expected origin, with a text or markdown content type, and the body starts with a single H1.
A sample of ten listed URLs returns real page content, not a homepage shell or a login wall.
No staging, preview, localhost or previous-client URLs remain — grep the file before every release.
The source of truth is in the repository, and the deploy pipeline includes it.
The owning team member is named, and the review cadence is in the client's calendar.
The file passes the llms.txt checker, and the client has a copy of the final version.

The quarterly review is short: re-fetch a link sample, check that pricing and version claims are still true, drop retired pages, and re-run the validator. Report it in plain terms — what changed, what was removed, what still returns 200. If the client shares server logs, you can also show which AI crawlers requested the file, using the approach in measuring llms.txt traffic; that is a fetch count, not a revenue claim, and it should never be presented as one. When a client needs a file built from a sitemap in a hurry, the llms.txt generator produces a starting point worth editing — the editing is still the job.