Getting cited by AI search, for a site with ten pages

This site ships four machine-readable artifacts. One of them is load-bearing, two are cheap and sensible, and one is a bet on a standard that may not land. I would rather say which is which than sell all four as the same thing.

That is the whole post, really. What follows is the detail.

What actually reads llms.txt today

llms.txt is a proposed convention: a Markdown file at the root of your site that summarizes what the site is and points at the pages worth reading, so a language model gets the shape of your business without crawling forty pages to infer it.

The honest status is that no major AI company has committed to reading it. It is a proposal with real adoption among people who publish documentation and no confirmed consumption by the models it is written for. Anyone who tells you it is how you get into ChatGPT is describing a hope.

I ship one anyway, and the reasoning is worth stating because it applies to the whole category.

It costs nothing. Mine is generated from the same data the site is built from, so the rates in it come from the same file the pricing table reads and cannot drift. There is no maintenance burden, because there is no second copy of anything. If the convention is adopted, the file is already there. If it is not, I have lost a build step.

One detail if you write one: make it real Markdown. A list of bare URLs reads fine to a person and is not a set of links to a parser. Mine is one H1, a blockquote summary, then H2 sections of - [name](url): note.

Structured data as the load-bearing part

Of the four artifacts, this is the one doing actual work, and it is the one that was already worth doing before any of this.

The reason is mechanical. A language model reading your page has to work out what kind of business you are, what you sell, where you are and who wrote the page. It can infer all of that from the prose, badly and expensively. Or it can read a ProfessionalService node with a service catalog attached and know.

This is the same markup that has been earning breadcrumb trails and FAQ expansions for a decade. Nothing about it is new. What is new is that a second category of reader now benefits from it, which makes the case for doing it properly rather than emitting a bare Organization and calling it done. Structured data for a services business covers which types apply and the rating markup that will get you a manual action.

The third artifact, a correct robots.txt and sitemap, is in the same bucket: old, unglamorous, and the difference between being read and not. Naming the model crawlers explicitly (GPTBot, ClaudeBot, PerplexityBot and the rest) is worth the four lines, if only because it makes the decision deliberate rather than inherited from a default.

Writing to be quoted

The part of this with no file attached, and the part that matters most.

An assistant answering a question about your field is looking for a passage it can lift with attribution. That is a different target from a page optimized to rank, and the differences are specific.

The practical version: write sentences that survive being cut out of the paragraph around them. "Webflow's collection list renders 100 items before you need pagination" can be quoted. "It can only handle so many before you run into trouble" cannot, and it is the same fact.

Dating things matters more than it looks. A model deciding between two pages that contradict each other has very little to go on, and a stated verification date is one of the few signals available. Several posts on this site carry one for that reason.

What is speculative, and why I ship it anyway

The fourth artifact is a WebMCP manifest at /.well-known/mcp.json: the site's actions described as tools an agent could call. Booking a call, fetching current rates, fetching the service list.

This is the most speculative thing on the site. The standard is moving, adoption is early, and I cannot point at a thing that reads it today.

What makes it defensible rather than decorative is that every tool in it points at something that actually responds. get_pricing returns the real rates as JSON, generated from the same source as the pricing table. An agent that reads the manifest and follows it gets real data, not a 404. The manifest is a description of endpoints that exist for their own reasons.

That is the test I would apply to any of this. Does the artifact describe something real, and does it cost anything to keep true? A generated file pointing at live endpoints passes. A hand-written summary that quotes a rate from eighteen months ago fails, which is not hypothetical: mine did exactly that before it was generated, which is why it is generated now.

If you are a ten-page services site wondering where to spend an afternoon, the order is: structured data, then the writing, then the cheap files. The first two would be worth doing if none of this existed. The performance page shows all four artifacts with a sample of each.