What to build

What to actually build, and the rule that decides whether any of it counts.

None of this is difficult. The difficulty is that several of these fail silently: they are present, they look correct, and nothing consumes them. Each section below ends with a way to check rather than assume.

The rendering rule, which comes before everything

If the content is not in the served HTML, you have not published it. Not "published it badly" — not published it. Every other element on this page is subject to this rule, including your navigation, your main text and anything you were planning to load in.

curl -s https://your-site/ | wc -c
curl -s https://your-site/ | grep -c "a sentence you expect to be there"

This is also the rule that decides your framework. Client-rendered pages can be made to work, but the burden of proof is on the output, not the intention.

llms.txt

A plain-text file at your root describing what the site is. It is a proposed convention rather than a standard, and support is uneven — Google does not consume it. Write it anyway: it is cheap, and it is the only place you get to state context in prose rather than in fields.

One rule matters more than the rest.

[measured]

A field written as an instruction to AI readers — text that addressed them directly and told them what to do with the page — was flagged by a model as a manipulation attempt. It was deleted. Rewritten as plain third-person description of the same facts, it drew no such reaction across every subsequent trial.

[reasoned]

Write about the thing, never to the reader. No second person, no imperatives. The test is mechanical: if a sentence would be strange in a printed catalogue, it does not belong.

grep -inE '\b(you|your|we|us|our|please)\b' llms.txt     # should be empty

That check is necessary and not sufficient. A sentence can contain no second person and still narrate the reader's job — "so it can be explained in whatever terms someone asks for" has no "you" in it and is still addressed at the reader. Grep for the nouns and verbs of asking, too.

Structured data

JSON-LD in the head, and the thing most sites get half-right: declaring that a collection has six members without saying what any of them are.

[measured]

A site published a rich manifest of its contents at its own URL, and search systems had no structured view of it at all — one of the major ones does not read arbitrary JSON files. Its own structured data said the collection had six parts and enumerated none. It could be seen that six things existed and not what they were.

Enumerate the parts, with a name, a URL and an identifier each. Keep it a subset rather than a mirror — enough to be indexable, small enough that drift is obvious.

Use disambiguatingDescription if your name collides with a common noun or another product. And note that it is a plain description field with no conditional behaviour: it can surface in any answer, so every clause has to be something you would want said in a context where nobody was confused.

The head

What every crawler reads by default and what most sharing surfaces use. Title, description, canonical, and social tags on every page — not just the home page. If pages can be shared individually, each one is an entry point.

Sitemap and robots

Both trivial, both noticed by their absence. The only thing worth saying about a sitemap is that lastmod is a claim like any other.

[reasoned]

Bump the date for files that changed and leave the others alone. A sitemap that reports everything as freshly modified is a small lie in the one document whose entire job is reporting change.

Small things that quietly break

[measured]

A site's favicon was an inline data: URI. Search results showed a generic globe for months. The favicon is fetched as a separate crawlable resource — an inline one gives it nothing to request — and the fallback path, /favicon.ico, was returning 404. Both routes dead-ended.

[measured]

The same icon was an SVG <text> element containing an emoji character, so the glyph was drawn in whatever emoji font the client had. It looked like three different logos on three different platforms, and had done since launch.

Ship real image files at real paths. Ship the character only if you do not mind which picture people see.

The checklist

Everything above, in the order it fails. Each line is checkable in about a minute, which is the point — none of this needs a tool or a subscription.

A plain fetch of your page returns your actual content, not a shell.
The same is true of every source you cite as evidence.
Your navigation is in the served HTML, not assembled in the browser.
llms.txt exists, is written in third person, and addresses nobody.
Structured data enumerates its parts rather than only counting them.
Every page carries its own title, description and canonical — not just the home page.
Social tags are on every page, since any page may be the one that gets shared.
sitemap.xml exists, and each lastmod moves only when that file does.
robots.txt exists and permits what you want read.
The favicon is a real file at a real path, not an inline data: URI.
An address that does not exist returns 404, not your home page with a 200.

Ten of those are hygiene. The first two are the ones that decide whether any of the rest counts.

Next: how to test — how to tell whether any of this did anything.