Building topic clusters when you only have one writer

Most topic-cluster advice assumes you have a content team, a content calendar spreadsheet with 47 tabs, and a CMS workflow with three approval layers. You don't. You have one writer, maybe part-time, or you're the founder writing on weekends. The question isn't whether to build clusters. It's how to build them without stalling for six months.

I'm going to show you a minimum-viable cluster structure that works for small teams, gets you cited in AI answers, and doesn't require a content factory.

Why topic clusters matter for AI search

AI engines don't just crawl your site. They evaluate whether you have depth on a subject. A single blog post on "customer retention strategies" might rank. But if that post sits alone, with no supporting content on churn analysis, lifecycle emails, or retention metrics, an AI engine has less reason to cite you as an authority.

Clusters signal depth. A pillar page that links to three to five supporting posts tells ChatGPT, Perplexity, and Google's AI that you own a topic, not just a keyword.

The problem is that most cluster frameworks were designed for publishers or agencies with five writers. You need a structure that works when you publish once or twice a month.

Start with one pillar, not three

The fastest way to kill momentum is to plan three clusters at once. Pick one topic that:

• You already have some authority on (customer proof, case studies, or internal expertise).
• Your target audience asks about in sales calls or support tickets.
• Has commercial intent or sits close to a buying decision.

For a B2B SaaS company, that might be "reducing customer churn." For a D2C brand, "choosing the right [product category] for [specific use case]." For a fintech startup, "getting approved for a business loan in Indonesia."

You're not building a content library. You're building one tight cluster that earns citations and drives pipeline.

The minimum viable cluster structure

A working cluster has one pillar and three to five supporting posts. That's it.

The pillar page is comprehensive (2,000 to 3,000 words), answers the high-level question, and links out to each supporting post. Think of it as the page an AI engine would cite if someone asks the broad question.

Each supporting post is narrower (1,000 to 1,500 words), goes deeper on one subtopic, and links back to the pillar. These are the pages an AI engine cites when someone asks the specific question.

Example structure for a customer-retention cluster:

Pillar: "How to reduce customer churn for SaaS startups"

Supporting posts:

1. How to calculate and benchmark your churn rate
2. Five early warning signals that a customer is about to churn
3. Building a win-back email sequence that works
4. When to discount to save a customer (and when not to)

Four posts total. If you publish twice a month, that's two months of work. Doable.

How to sequence the work when you only have one writer

Don't write the pillar first. That's the instinct, and it's wrong.

Start with the supporting posts. Here's why: writing the pillar before you've thought through the subtopics leads to a shallow, generic page. You end up with a 2,500-word listicle that tries to cover everything and cites nothing.

Write the three to five supporting posts first. As you write them, you'll discover the structure of the pillar. You'll know which sections need more depth, which questions come up repeatedly, and which subtopics deserve their own treatment.

Once the supporting posts are live, write the pillar. Pull key points from each supporting post, add original analysis or a framework, and link to the deep dives. The pillar becomes a map, not a thesis.

Timeline for one writer publishing twice a month:

• Month 1: Supporting post 1, Supporting post 2
• Month 2: Supporting post 3, Pillar page
• Month 3: Optional fourth or fifth supporting post, or move to a new cluster

Internal linking rules that actually matter

AI engines follow links. If your pillar doesn't link to the supporting posts, or the supporting posts don't link back to the pillar, the cluster doesn't exist in their eyes.

Three rules:

1. Every supporting post links to the pillar once in the intro or first section. Use natural anchor text. "This is part of our broader guide to reducing customer churn" with a link to the pillar.

2. The pillar links to each supporting post at least once, ideally in a dedicated section. A "Deep dives" or "Related guides" section works. Don't bury these links at the bottom of a 3,000-word post.

3. Supporting posts can link to each other if it's relevant. If your post on churn signals mentions win-back emails, link to that supporting post. You're building a web, not a hub-and-spoke diagram.

Don't overthink this. Five internal links per post is plenty. I've seen teams spend two hours debating anchor text for a link that will get clicked twice. Link, move on.

Schema markup for clusters (the 10-minute version)

If you want AI engines to understand your cluster structure, add basic schema. You don't need a developer. You need 10 minutes and a schema generator.

For the pillar page, use Article schema with a headline, author, datePublished, and description. Add a mentions property that lists the URLs of your supporting posts.

For each supporting post, use Article schema and add an isPartOf property pointing back to the pillar.

This tells AI engines "these posts are related" in structured data they can parse. It's not required, but it helps, especially for newer sites without strong domain authority.

If schema feels like a bridge too far right now, skip it. Get the content and internal links right first. You can add schema in month four.

What to do after your first cluster is live

Let it breathe. Too many teams publish a cluster and immediately start planning the next one. Give it 60 to 90 days. Watch what gets cited, what ranks, and what converts.

Use ChatGPT, Perplexity, and Gemini to search the questions your pillar and supporting posts target. Are you getting cited? If not, look at who is. What structure are they using? What depth are they going to?

Update the pillar and supporting posts based on what you learn. Add a section, swap in a better example, tighten the intro. Clusters aren't static. The best ones evolve.

Once the first cluster is working, start the second. Same process. One pillar, three to five supporting posts, two to three months of work.

By month six, you'll have two tight clusters. That's more depth than 90% of your competitors, and you did it with one writer.

When to stop adding supporting posts

I see teams turn clusters into content hoarding. They start with five supporting posts, then add three more, then five more, and suddenly the cluster has 18 posts and no one can find anything.

Stop at five supporting posts unless you have a very good reason to go deeper. If a subtopic is big enough to deserve its own cluster, split it off. Don't bolt it onto an existing pillar.

A tight cluster of six posts (one pillar, five supporting) will outperform a sprawling cluster of 20 posts. AI engines reward depth and coherence, not volume.

The one-writer content calendar

Here's what a realistic 12-month calendar looks like for a single writer publishing twice a month:

Months 1 to 3: Build cluster one (four to five posts). Months 4 to 6: Build cluster two (four to five posts). Months 7 to 9: Update both clusters, add one new supporting post to each if needed. Months 10 to 12: Build cluster three, or go deeper on the first two.

That's two to three strong clusters in a year. It's enough to move the needle on AI citations, organic traffic, and pipeline. It's also enough to prove the model works before you hire a second writer.

If you're a founder doing this yourself, cut the timeline in half. Two clusters in 12 months is a win.

Tools you actually need (and tools you don't)

You need:

• A spreadsheet to track the cluster structure (pillar, supporting posts, internal links).
• A way to check if you're getting cited (manual searches in ChatGPT and Perplexity, or a citation-tracking tool if you want to pay for one).
• A CMS that makes internal linking easy (WordPress, Webflow, Framer, anything modern).

You don't need:

• A content calendar tool with Gantt charts and dependency tracking.
• A topic research platform that costs $200 a month.
• A dedicated content strategist (yet).

Most teams over-tool and under-ship. A Google Sheet and a bias toward publishing will beat a $10,000 content stack every time.

If you want help

If you're stuck on which cluster to build first, or you want someone to audit your existing content and tell you where the gaps are, book a call. I do this for Series A and Series B founders every week. It's a 30-minute conversation, and it's free.

If you'd rather train your team to do this themselves, the workshop walks through the entire cluster-building process, including brief templates and schema setup.

And if you want someone to just build the first cluster with you, the consultancy retainer includes strategy, briefs, and review. You write, I shape and pressure-test.

Most companies will still be planning their first cluster when you ship your second. That's the advantage.