The topical cluster builder

Topical clusters are how modern SEO is won. A pillar page covers the head term broadly, spokes target long-tail variants and link back to the pillar, and together they signal authority and rank in aggregate far better than any single post could. The bottleneck has always been production: even a tight cluster is nine posts, which is a week of writing aimed at one keyword. An assistant compresses that to design-and-draft in one sitting, leaving you with review-and-publish — the part that genuinely needs your judgment. This is the most generative recipe in the set and the one most likely to compound: build a cluster a month and you have a dozen tight clusters and a hundred-plus posts in a year.

What you need

• Specter synced to your blog
• An AI assistant you already use
• A seed keyword and a sense of your brand voice

The recipe

1. Pull. Run a Specter pull so the assistant can internal-link new spokes into your existing archive.
2. Design the cluster (plan only). Run the design prompt to produce a pillar-and-spokes outline. Then spend ten minutes editing it — remove off-brand spokes, merge overlaps, add what’s missing. This is the highest-leverage step in the recipe.
3. Draft the cluster. Run the draft prompt to write the pillar and every approved spoke to posts/drafts/ with status: draft.
4. Dry-run and push. Confirm Specter sees the new drafts as creates, push, then review them in your normal editor and publish on your own schedule.

The prompt

First, design — no drafting:

Design a topical cluster for the seed keyword provided, using my existing posts
for internal-link targets and to avoid duplicates. Output a plan only: a pillar
(working title, ~2500 words, H2 outline, 3–5 existing posts to link to) and 8
spokes, each with a long-tail target query, search intent, target length, why it
links to the pillar, and existing posts to link from. No two spokes may target
the same query; skew toward "how to" and "vs" intents over "what is". Include an
internal-link graph. Draft nothing.

Then, after you’ve edited the plan, draft it:

Draft the approved cluster. For each item (pillar + spokes), create
posts/drafts/<slug>.md with frontmatter status: draft (never publish), a
140–158 char meta description, a cluster tag, and the seed as a `cluster` field.
Body: answer the target query in the first two paragraphs, follow the planned H2
structure, use specifics over filler, and add the planned internal links with
natural anchors. Each spoke links prominently to the pillar in its first third;
the pillar ends with a "Related reading" section linking all spokes. Hit each
target length ±20%. Log slug, word count, and link counts per draft.

Cost and time

Add a couple of hours of human review per cluster — worth it.

Pitfalls

• Drafts only, always. Even a strong cluster needs human review for tone, facts, and links. The status: draft constraint is non-negotiable.
• Spokes that compete. If two spokes target overlapping queries they’ll cannibalize — catch this when you edit the plan.
• Thin pillars. A pillar under about 2000 words rarely ranks for a head term. If one came in thin, push back and re-draft just that one.

Where to go next

Feed it the priority queue from the competitor gap mirror to execute discovered gaps as full clusters, and run the internal link engine afterward to weave the new cluster into the rest of your archive.