Content strategy document

Why the document exists

A content strategy that lives only in someone's head lasts about six weeks. The first two writers ship close to it, then the next hire ships in whatever direction their instincts pull, and by month four the site is a pile of unrelated posts.

The document I ship is the fixed reference the team writes against. It says what the site is trying to rank for, which pillars carry which topics, which cadence the calendar runs on, and which channels every published piece feeds. Every writer, editor, and freelancer reads the same page.

What the document covers

Content strategy is a fuzzy label. In this document it names five specific artifacts.

1. Topic architecture (pillars, clusters, canonical URLs).
2. Editorial calendar (what publishes, when, at what length).
3. Voice and format standards (cross-referenced from the brand guide).
4. Distribution plan (which channels a piece feeds, in what order, in what form).
5. Measurement (what counts as success, at which timescale).

The document is short. Twelve to twenty pages depending on scope. Everything longer is an appendix.

Topic architecture

Topic architecture is the load-bearing part of the document. Everything downstream depends on it.

The architecture maps to a pillar-and-cluster shape. Three to seven pillar pages sit at the top. Each pillar owns a domain the site wants to rank for. Every article the site publishes attaches to one pillar as a cluster piece, links up to the pillar, and links laterally to a few sibling clusters.

The value of the shape is that it turns publishing decisions into a graph question. A proposed article either fits an existing pillar, extends a cluster, or expands the graph. If it does none of those, it usually should not ship.

The document names, per pillar:

• The target search intent and the primary query it wants to own.
• The canonical URL and the intended length (pillar pages are typically 6,000 to 12,000 words).
• The cluster topics that support it, listed.
• The internal-link contract (every cluster piece links to the pillar with a specific anchor).

Editorial calendar

The calendar is the operational half of the document. Two views ship.

The strategic view runs pillars across the top, months down the side, with each cell listing the piece planned for that pillar in that month. This is what a founder or CMO opens.

The production view runs rows as individual pieces and columns as production stages (draft, review, edit, art, publish, distribute). This is what an editor opens.

Cadence sits inside the calendar. Most projects I run land on one pillar update every quarter and one cluster piece per pillar per month. That is a defensible rate for a small team and enough for the graph to compound.

Cadence gets the most pushback from marketing leads who want to publish more. The document answers the pushback with a specific rule: two mediocre pieces do less for the graph than one considered piece, because search surfaces and LLMs both punish thin content, and internal links from a thin piece to a pillar do more harm than good. If the team wants a higher rate, the document says, hire another writer or shorten scope on the existing schedule. It does not compress the review pass.

Distribution

A publish event is not the last step. The document names, per format, exactly what happens after a piece ships. The rule is that no distribution channel is optional and none is decided in the moment. Every piece of the same format has the same downstream steps.

A typical long-form article publishes on the site, feeds the Thursday newsletter with the TL;DR and a link, gets a LinkedIn post the following morning with a specific hook, and gets an X thread with the three most quotable lines staggered across a week. Three older related pieces get cross-links added to the new one within seven days.

Format ladder

Not every published piece needs to hit every channel. The document sets a per-format ladder. A long-form article rides the full distribution stack. A news commentary hits fast channels only (LinkedIn, X, newsletter roundup). A framework or template hits everything including a video adaptation because the format is inherently reusable. A case study hits prestige channels first (newsletter, LinkedIn, RSS) and skips X unless a specific quote earns a thread.

Making these decisions once at document time saves roughly an hour of "what should we do with this piece" per week and stops distribution drift.

Measurement

The document names what counts as success at three timescales.

• Week one. The page indexes, AI Overviews cites it, distribution steps all completed.
• Month one. Organic sessions land in the expected order of magnitude for the intent, referring domains start attaching, the piece is cited in at least one LLM answer for its target query.
• Quarter one. The piece contributes measurably to its pillar's aggregate ranking, and at least one other piece has been written that links to it.

Vanity metrics stay out of the measurement section. Impressions and unique users are noise unless mapped to a pipeline event.

How the document actually gets used

The document is not read cover to cover. It is opened at four specific moments, and the document says so up front.

• At sprint planning. The strategic view of the calendar goes up on the wall. Missing cells become the sprint's writing queue. Cells already filled become progress checks.
• At piece kickoff. Whoever is drafting a new article opens the topic architecture, confirms which pillar it attaches to, reads the intent statement for that pillar, and lifts the cluster naming convention.
• At publish time. The writer or editor opens the distribution plan, walks the channel matrix for that format, and drops the piece into the scheduled queue for each channel.
• At quarterly review. The measurement section opens next to the analytics dashboard. Every piece published in the previous quarter gets marked against the three-timescale target.

Naming these four moments in the document tells the team when it is supposed to be looked at. A document nobody knows when to open is a document nobody opens.