How to use this playbook

What this is

This is an inventory, not an argument. It lists what a content-heavy site has to implement for search and for AI answer engines, in the order that makes sense to implement it, with the code that implements each item.

It was produced by auditing a production codebase: roughly 2,100 indexable URLs, 42 schema.org types in use, and a programmatic tier generating 1,689 of those URLs. Every claim in here traces to one of three things: code you can read in the Code Kit, published documentation from Google, Bing, OpenAI or Anthropic, or an explicitly labelled opinion. CLAIMS.md in the Code Kit maps them.

That constraint is the point. Most SEO writing is a plausible-sounding position with nothing behind it. The difference between "add structured data" and a tested factory that composes 42 types into a single @graph with stable @id anchors is about a day of work, and that day is what this document is for.

What this is not

This playbook does not promise rankings. Nobody can, and anyone who does is selling something they cannot deliver. It promises implementation completeness: after working through it, you will know what is done, what is not, and what each remaining gap costs you.

It is also not a beginner's introduction to search. It assumes you can read TypeScript, you own a codebase, and you can deploy it.

How the chapters are structured

Every subsection follows the same three blocks, in the same order:

1. The principle. Domain-neutral, two to five sentences. What the mechanism is and why it exists.
2. The implementation. Real code from the Code Kit, not pseudocode.
3. A worked example. Real numbers from the reference implementation, boxed and labelled, so you can see what the principle looks like at production scale.

Chapters also carry a Framework notes block covering Astro, SvelteKit and static site generators as short deltas from the Next.js implementation. They do not re-explain the principle for each framework.

The three ways to read this

You have two weeks. Read the Foundation chapter, the Metadata chapter, the Structured data chapter and the Bot economics chapter. Ship the 26 free checks. Stop. The Sequencing chapter explains why those four, and why doing anything else first is a worse use of the same fortnight.

You have a quarter. Work the checklist top to bottom, sorted by return on effort. The checklist app does that sort for you. Expect the programmatic and AI chapters to take most of the time, because they involve building data pipelines rather than adding tags.

You are auditing an existing site. Start at the checklist, mark everything you already do, and read only the chapters behind your failures. The checklist links each item back to the chapter that explains it.

What "verified" means here

Three levels, and this playbook distinguishes them everywhere:

• Verified against code. The mechanism is implemented in the Code Kit and covered by a test that would fail if it regressed.
• Documented. The behaviour is stated in a primary source: Google Search Central, Bing Webmaster documentation, OpenAI's bot documentation, Anthropic's crawler documentation.
• Opinion. Judgement calls where no primary source exists. These are labelled. There are fewer than you would expect, and they cluster in the AI chapters, because that surface has almost no published best practice yet.

Anything that is none of the three is not in this document.

A warning about freshness

Two chapters age faster than the rest: Bot economics and AI and answer engines. Crawler user agents change, engines are added, and citation behaviour shifts. Both carry a reviewedAt date at the top of the page and both are reviewed quarterly. If the date is more than 90 days old when you read it, verify the user agent list against the operators' own documentation before acting on it.

Everything else in here moves on a scale of years.