Map: pick the few types that earn their keep
Mapping is how you decide, quickly, what is actually worth producing. For every content type you are weighing up, ask one question: does it genuinely help someone discover the product, judge whether it fits, get started, or stick around? If it does not, leave it for later. List out your channels and every type you can think of, then be ruthless about trimming the list. Most funded startups launch with four to six types, enough to cover the buyer's journey without overwhelming a small team and its agents.
Score each type on what matters
Don't build a taxonomy tree from scratch. List every content type you might make, then score each one against a few simple questions and let the scores make the cut for you.
- Journey stage: does it help someone discover, evaluate, adopt, or retain? Every stage needs at least one type; a stage with none is your first gap.
- Business leverage: does it drive pipeline, conversion, activation, or retention? If you can't name the lever, it's a "later" type.
- Sustainable cadence: can you realistically keep it current? A type that needs a fresh post every week, with no one to write it, will quietly die. Be honest about what you can keep up.
- Channel fit: how many places one source can feed, across search, LLM answers, sales decks, in-product and email (see the fan-out below).
The "don't boil the ocean" cut
Give each candidate type a 1 to 3 score for leverage and a 1 to 3 score for sustainable cadence, then keep the top 4 to 6 and park the rest in a backlog you revisit next quarter. The table below does exactly this.
If you ship nothing else: a Product/Feature page, a Use-case page, a Help/Doc article, and a Customer story. Those four cover discover → evaluate → adopt → trust. Add Blog and Release notes when cadence allows.
Resist "we need a glossary, a podcast, a newsletter, and a wiki" on day one. Volume without structure is the legacy debt you came here to avoid.
Worked example: score 10 candidates, keep the 4 to 6 that earn it
Illustrative for a B2B SaaS startup. Ten common content types, scored on leverage (business impact) and sustainable cadence (can you keep it current?), with whether it's already proven for you and what it costs to run. The six highlighted rows are the ones to ship first; the rest go to a backlog.
| Content type | Leverage | Sustain | Status | Cost | Verdict |
|---|---|---|---|---|---|
| Product / Feature page Evaluate | Proven | Low | Keep · core | ||
| Use-case / Solution page Discover → Evaluate | New bet | Med | Keep · core | ||
| Help / Doc article Adopt | Proven | Med | Keep · core | ||
| Customer story Evaluate → Retain | Proven | Med | Keep · core | ||
| Blog / Insight post Discover | Proven | Med | Keep · nextAdds search & LLM reach | ||
| Release note Retain | New bet | Low | Keep · nextCheap, steady cadence anchor | ||
| Comparison page Evaluate | New bet | Med | ParkOverlaps core, revisit | ||
| Glossary term Discover | New bet | Low | ParkLow leverage for now | ||
| Webinar / Event Discover | New bet | High | ParkToo costly to sustain solo | ||
| Newsletter Retain | New bet | Med | ParkHard to keep up early |
Leverage and Sustain are the two scores that decide the cut. Status and Cost are the tie-breakers: a proven, low-cost type is an easy keep, while a high-cost new bet has to really earn its place. Here that leaves a familiar core four, two cheap "next" additions, and four parked for later.
Scores are illustrative. Run your own ten through the same columns; the point is to make the cut visible and defensible, not to copy ours.
Model: give one type a shape, then grow
A content model is just the list of fields a content type has, each with a type, plus a bit of metadata that makes it findable and machine-readable. Define one type fully (usually your Customer story or Use-case) and sketch the rest. "Designed to grow" means you keep field names stable, add optional fields later as you need them, and map everything to schema.org from day one so search engines and LLMs can parse it.
Worked example: the Customer Story content model
One field is worth a plain word before you hit it. Schema.org is a shared vocabulary the whole web agrees on, so a machine never has to guess what your content is. Tagging this story as an Article (or a Review) tells Google and the LLMs that the headline is a headline, the customer is a real organisation, and the metric is an actual result, so they can quote it with confidence instead of scraping and hoping. You set it once, here, and every channel inherits it.
| Field | Type | What it holds |
|---|---|---|
| title | string · req | Headline outcome, e.g. "How Acme cut onboarding from 3 weeks to 3 days". |
| slug | string · req | URL-safe identifier; stable forever once published. |
| summary | text · req | 2 to 3 sentence abstract. Powers cards, meta description, and LLM snippets. |
| customer | ref → Company | Linked entity, not free text. Carries logo, industry, size. |
| body | rich text | Challenge → solution → result. Structured blocks, not a blob. |
| metric_result | number + unit | The headline number. Typed so it can render in a stat block. |
| audience | Persona / segment, e.g. RevOps, Eng leader. From your taxonomy. | |
| stage | discover · evaluate · adopt · retain. Drives where it surfaces. | |
| tags | Linked taxonomy terms (product area, use-case). Not loose strings. | |
| variant_of | If this is an audience variant, the one master story it derives from. Variants reference the source; they never copy it. | |
| schema_type | schema.org type → Article / Review. Machine-readable from day one. | |
| status | draft · review · published. The workflow spine for your guardrails. | |
| updated_at | Freshness signal for search, LLMs, and your own audit. |
Start with required fields only. Add locale, related_content, or review_rating later as optional fields. Existing entries stay valid, because you never rename or repurpose a field once it has shipped.
This is where an AI-native model earns its keep. You don't publish ten near-identical stories. You keep one master piece as the source of truth and have everything else point back to it, and two kinds of "variant" matter, which people often confuse. A channel render (web page, sales slide, email block) is the same source simply displayed differently; that's the fan-out shown below, not new content. An audience variant (a RevOps cut versus an Eng-leader cut) is genuinely different copy, so you create a new entry, set variant_of to the master, and change only what differs. Agents can then spin those variants up on demand from the source, and search and LLMs see one authoritative story with clearly-marked derivatives, not a pile of duplicates competing with each other for the same ranking.
Visual · the model as linked entities
Think of a content model as a graph. The Customer Story points at typed entities, and those links are what let you filter it, recombine it, and let agents reason over your whole library.
Visual · one structured source → many channels
This is the whole payoff: model once, render everywhere. One structured Customer Story can power the website, search, LLM answers, sales, and lifecycle email, with no copy-paste and nothing drifting out of sync.
One master, many variants, live
Pick what you want to generate. The master never changes; the guardrails decide what's allowed; only the variant on the right is new. That's the whole model in one view.
Illustrative. Same facts every time, the master is the single source; the variant is reframed for the audience or channel, never re-invented.
The principle
Structure beats volume. Model first; machine-readable from the start.
Ten well-modelled pages an agent can read, recombine, and keep fresh will out-perform a hundred unstructured posts that rot in a folder. Decide the shape before you fill it. Give every type a schema.org mapping on day one, so the moment you publish, search engines and LLMs can already understand and surface you. You're not really writing pages here. You're populating a structured system that other tools read.
Templates you can copy today
Worksheet Content-model worksheet
Run this once per content type. Half a page each.
- Name the type & its one job in the buyer journey (discover / evaluate / adopt / retain).
- List required fields: start with title, slug, summary, body. Resist optional fields for v1.
- Assign a type to each field: string, text, number, enum, ref, asset, datetime.
- Mark the links: which fields are references to other entities (Company, Taxonomy term)?
- Add metadata: audience, stage, tags, schema.org type, status, updated_at.
- Map to schema.org: pick the closest type (Article, Product, FAQPage, Review).
- Name the channels it fans out to, and who/what renders each.
Field set Recommended metadata field set
The minimum every type should carry. Copy verbatim; extend later.
- title · string · required: human + machine headline.
- slug · string · required: stable URL identifier.
- summary · text · required: abstract for cards, meta, LLM snippets.
- audience · enum: persona / segment from your taxonomy.
- stage · enum: discover · evaluate · adopt · retain.
- tags · ref[]: linked taxonomy terms, never loose strings.
- schema_type · enum: schema.org mapping for machine-readability.
- status · enum: draft · review · published (your workflow spine).
- owner · ref: the one accountable human.
- updated_at · datetime: freshness signal.
Don't add a field you can't fill consistently. Empty metadata is worse than none: it teaches your agents and filters to distrust the data.
Interactive · pick your starting set
Toggle the types you'd launch with. Aim for the lean zone of 4 to 6. The gauge tells you when you're boiling the ocean.
Tool behaviour is illustrative guidance, not a rule. Your business may justify a different set.
Before you move on
By the end of this page you should be holding four things. They're the output of a focused half-day, not a quarter, but the rest of the build assumes all four exist, so finish any that are missing before you turn the page.
What you should have now
- ✓ A one-page map of the 4 to 6 content types you're committing to, with everything else parked in a backlog.
- ✓ One type modelled in full, fields, types and metadata, with the others sketched.
- ✓ schema.org mapped on each type, so it's machine-readable from day one.
- ✓ A variant plan, one master source, audience variants via
variant_of, no duplication.
Why this sets up the next stage
Your content model is the contract everything else is built against. Next, The Team puts a lead owner and a set of AI agents to work producing against exactly this shape, and agents can only draft, tag and reuse content reliably when there's a defined structure to write into.
So the order matters: model first, then staff it. Skip the model and your agents are guessing; nail it here and the next chapter is mostly wiring people and agents to fields you've already defined.