AI content strategy: planning for a reader who might be an assistant

An AI content strategy plans for two readers at once: the buyer, and the assistant that will summarise your page for them. In practice that means fewer and more specific pages, one buyer question each, with the answer in the first paragraph and a checkable fact in every claim. It also means choosing page types deliberately, because some kinds of page get cited in AI answers repeatedly and others are never quoted at all. The plan below is a question inventory, a page type mix, a brief template and a measurement loop.

Start from questions, not keywords

Keyword volume still tells you what people type into a search box. It does not tell you what they ask an assistant, because those questions are longer, more specific and often phrased as a situation rather than a term.

Build the inventory from five places: recorded sales calls, your support tickets, your site search log, the People Also Ask boxes on your main queries, and the assistants themselves. For the last one, ask your category question in ChatGPT or Perplexity and read what it assumes, what it recommends and what it asks you to clarify. Those clarifying questions are a content plan in disguise.

Thirty to sixty questions is a working inventory for most businesses. The method we use for scoring and ordering them is in a buyer question topic map.

The page types that earn citations

Page type	Why it gets cited	What it must contain
Definition and explainer	Assistants need a clean statement of what something is	The definition in the first two sentences, then the distinctions
Comparison	Buying questions are comparison questions	A table, named alternatives, accurate description of each
Cost and pricing	Very few sites publish real numbers, so the ones that do get used	Figures, what changes them, and the date they were checked
Original data	Nothing else can be substituted for it	Method, sample size, date, and the raw figures
Specification and coverage	Counts answer questions a model can verify	Numbers, formats, integrations, limits, regions
Step by step how to	Procedural answers are quoted as lists	Numbered steps and a copyable example
Method led list page	List questions are asked constantly	Stated inclusion criteria and a date

Three kinds of page rarely get quoted, and it is worth knowing before you commission them. Brand manifestos, because there is no fact to lift. Benefit listicles with no numbers, because every competitor has the same five benefits. And anything behind a form, because a fetcher that hits a gate reads the gate.

The mix

A programme that is all explainers gets cited and never converts. A programme that is all product pages converts and never gets cited. A workable split for a quarter of twelve pages:

• Four question pages on the highest value buyer questions, answer first.
• Three comparison or alternative pages covering the choices your buyer is actually weighing, with competitors described accurately.
• Two evidence pages: pricing, coverage, specifications or a dated dataset. These are the hardest to write and the most quoted.
• Two how to pages with a copyable artefact, a template, a checklist or a code block.
• One list page with your inclusion method stated at the top.

A brief that produces a quotable page

• The question, in the buyer's words, as the working title.
• The answer, written out in two sentences before anyone drafts anything. If it cannot be written, the page is not ready.
• Three facts from your own records: counts, prices, dates, versions. With sources.
• The named alternatives to describe fairly, and how each one genuinely differs.
• The sub questions that become H2 headings, each with its own self contained answer.
• The artefact the page gives away: table, checklist, template, calculator.
• The scope line: what this page covers and which page covers the next thing.
• Four to six questions for the FAQ section, taken from real enquiries.

Facts, and where they come from

Keep one file of your real numbers: client counts, coverage figures, founding year, response times, prices with the date each one was last checked. Every brief draws from it. This matters more when a model helps with drafting, because a model asked to write about your business will fill a gap with a plausible specific, and those are exactly the claims an assistant will later try to verify. Let a model shape a page and let your own records supply every fact.

Publishing and refreshing

• Date every figure on the page. "Checked October 2026" makes a number usable and tells a model how fresh it is.
• Refresh evidence pages on a schedule. Pricing and coverage pages lose their value the moment they go stale, and they are the pages most likely to be quoted.
• Link the cluster together. Each question page links to the two nearest questions. An assistant that lands on one page should be able to reach the rest.
• Keep the text in the HTML. If a key sentence appears only after JavaScript runs, treat it as a sentence a fetcher may never see.

The measurement loop

The point of the loop is that the engines tell you what to write next. Run your prompt set across assistants before the batch ships and again a few weeks after. Record which of your pages were cited, and which other domains were cited instead. Pages that got cited tell you which format works in your category. Domains that got cited instead are your third party target list.

A content brief assumes a reader who arrives. Increasingly the reader is an assistant that reads the page once and repeats a version of it to somebody who never visits. Before the first brief goes out, it is worth knowing what those answers already say about your category and who they name. AI Knows Us takes that baseline and shows the sources behind each answer, so a strategy starts from a measurement rather than a guess.

This page is the programme level plan. For the structure of a single page, see how to write a page an assistant will quote. For measurement design, see how to report AI search visibility.

What people ask about AI content strategy

Should I write for assistants or for people?

The same page serves both when it is specific. Answer first, evidence underneath, one question per page. People scan and assistants extract, and both reward the page that gets to the point.

How many pages do I need?

Ten specific pages beat a hundred vague ones. Start with the ten questions a buyer asks before choosing, then extend into the sub questions that come back when you test the engines.

Can I use a model to write the pages?

Use it for structure, outlines, editing and finding every claim that lacks a number. Supply every fact from your own records. That split gives you the speed without the invented specifics.

Does length matter?

Specificity matters and length follows it. A page long enough to answer one question with evidence is the right length, which in practice is usually between one and two thousand words.

What about updating old posts?

Rewriting ten vague old posts into five specific pages, with redirects, is usually a better quarter than ten new ones. Start with the posts that already get impressions on buying questions.

What to do first

• Write the question inventory from sales calls, tickets and site search. Thirty questions, in the buyer's words.
• Ask your top five category questions in two assistants and save what they assume and which domains they cite.
• Build the one file of your real numbers, each with a source and a date.
• Commission the first twelve pages against the mix above, one question per page.
• Diarise the same prompt run for six weeks after the batch, so the engines tell you what to write next.