Topical authority on a small budget: planning clusters when you publish 10 posts a month

Ten posts a month is not a lot. It is also not nothing. The trap most small teams fall into is treating those ten slots as ten independent bets, one keyword each, scattered across whatever the research turned up that week. Six months later the site has sixty posts, a flat traffic line, and no theme a search engine can attach to the domain.

Topical authority is the fix, and it is achievable at ten posts a month. It just requires you to stop thinking in posts and start thinking in clusters.

What a cluster actually is

A cluster is one pillar post plus a set of supporting posts that all sit under the same reader intent. The pillar covers the topic at the broadest useful level. The supporting posts each answer a narrower question a reader would ask on the way to, or just after, the pillar.

A worked example. Say you run content for a payroll tool aimed at small agencies. Your pillar might be How to run payroll for a small agency. Supporting posts would cover contractor vs employee classification, state tax registration for remote hires, paying international freelancers, first-payroll checklists, and so on. Each supporting post links up to the pillar. The pillar links down to each supporting post. Internally, the cluster reads like a small book on one subject.

That internal shape is the point. Search engines infer what a site is about partly from how densely a topic is covered and how tightly the pages reference each other. A single 4,000-word pillar sitting alone rarely signals authority. A pillar with eight tight supporting posts pointing at it does.

Pick one pillar, maybe two. Not five.

At ten posts a month, the honest math looks like this. A working cluster is usually one pillar plus six to ten supporting posts. Call it eight on average. If you run one cluster at a time, that is a little under one month of production. Two clusters in parallel is about two months. Five clusters is half a year of scattered output with nothing finished.

So pick one. If you cannot bear to pick one, pick two, but only if they share almost no audience overlap and you have a real reason to hedge (for example, two distinct customer segments each big enough to justify their own theme).

How to choose the pillar:

• Business relevance first. The pillar should map to something you actually sell or something your buyer researches immediately before buying. Ranking for a theme that does not convert is a vanity exercise.
• Winnable, not aspirational. Look at who currently ranks for the pillar term. If page one is dominated by category-defining sites with hundreds of posts on the theme, you are not going to muscle in with eight posts. Pick a narrower pillar where the top results are thinner, older, or off-intent.
• A real cluster shape. Before you commit, list ten supporting questions off the top of your head. If you cannot get to ten without straining, the pillar is too narrow to sustain a cluster. If you get to fifty easily, it is probably too broad and needs to be split.

The research agent can do the winnability check for you and surface supporting-question candidates, but the business-relevance call is yours. Do not outsource it.

Sequencing the posts inside a cluster

Order matters more than most people think. A common mistake is to publish the pillar first, then trickle supporting posts out over months. The pillar goes live pointing at nothing, and by the time the supporting posts arrive, the pillar has already been indexed as a thin page.

A better sequence for a ten-post-a-month cadence, spread over roughly one month:

1. Posts 1 to 3: supporting posts on the highest-intent, narrowest questions. These are the ones with the clearest search intent and the lowest competition. They will start pulling in impressions quickly and give the pillar something to link to when it lands.
2. Posts 4 to 6: more supporting posts, filling in the middle of the topic. By now you have a feel for which sub-topics have real search demand and which were guesses. Adjust.
3. Post 7: the pillar. It goes live already surrounded by supporting posts it can link down to, and that link up to it. From day one it looks like the hub of a real cluster.
4. Posts 8 to 10: the remaining supporting posts, chosen partly from what you have learned. Search Console will already be showing you queries the earlier posts are ranking for on page two or three. Some of those are new supporting-post ideas you did not originally plan.

That last point is the one small teams underuse. The first half of a cluster teaches you what the second half should be. Do not lock the full editorial calendar in stone on day one.

If you are running the sequence inside RankMill, the live agent log helps at this step as well. Because the research agent shows its reasoning per candidate, you can see which supporting posts are drifting toward the same intent and merge or drop them before they get slotted into the calendar.

Writing rules that hold the cluster together

A cluster only works if the posts feel like they belong to the same body of work. Three practical rules:

• Consistent terminology. Pick your terms for the core concepts and use them the same way in every post. If the pillar calls them "supporting posts" and one of the supporting posts calls them "child articles," a reader (and a search engine) has to reconcile the mismatch. Configure the vocabulary in your writing rules, and put the off-brand alternatives on the banned words list, so every run in the cluster comes back using the same terms without you re-editing draft by draft. If more than one person is drafting inside the cluster, the case for encoding voice in the writer agent gets stronger; the same brand voice rules that keep multiple contributors on the same page across a whole blog, covered in how to run a team blog people actually read, are what keep a single cluster reading as one voice.
• Explicit internal links, not hopeful ones. Every supporting post should link to the pillar at least once, in body copy, with anchor text that describes the pillar. Every supporting post should link to at least two sibling supporting posts. The pillar should link out to every supporting post it has, ideally grouped by sub-theme rather than dumped in a list at the bottom.
• No accidental cannibalization. Two supporting posts should never compete for the same query. If you are drafting a post and realize its search intent overlaps with an existing one, the answer is almost always to expand the existing post, not to publish a near-duplicate. Cannibalization is the fastest way to stall a cluster.

Knowing when a cluster is done

The hard part of cluster planning is not starting one. It is knowing when to stop.

A cluster is done when three things are true at the same time:

1. The pillar is ranking on page one or two for its primary query, and holding. Not spiking, not decaying. Sitting.
2. The supporting posts are collectively pulling steady impressions, and new supporting-post ideas are getting harder to find without stretching the theme.
3. You have run out of questions a real buyer would actually ask. If the next post idea feels like padding, or you are inventing questions no one is searching, the cluster is finished.

None of those individually is enough. A pillar can rank while the supporting posts starve; that usually means the pillar caught a lucky link and the cluster underneath is thin. Supporting posts can rack up impressions while the pillar sits on page five; that usually means the internal linking is weak or the pillar is written for the wrong intent.

The "holding" test is a specific one, and worth running on a fixed cadence rather than eyeballing charts each week. Our framework for telling whether your AI blog posts are actually working covers how to read a pillar's real trajectory without over-reacting to weekly noise, and it is the same check you should use later to decide when a pillar needs a refresh.

When all three are true, you are done. Stop adding posts. Move the maintenance work into a lighter cadence: refresh the pillar every six months, update supporting posts as facts change, and let the cluster compound.

When to start the second cluster

The temptation is to start cluster two the moment cluster one shows any life. Resist it for a bit. A cluster that starts ranking is not the same as a cluster that has finished ranking. Pull the plug on production too early and you lose the last 20 percent of gains, which is usually the part that actually converts.

A workable rule: start planning cluster two once cluster one's pillar is ranking somewhere on page one or two and the supporting posts are producing more impressions each month than the month before. Start publishing cluster two once cluster one's pillar has held its position for at least one full month without new posts propping it up. That last condition is the real test. It tells you the cluster is standing on its own and no longer needs your ten monthly slots.

A visible run budget makes that discipline easier to hold. When you can see that this month's post slots are still committed to cluster one, and the pricing is per post rather than per seat, there is no artificial pressure to open cluster two early just to feel productive. The budget is the same either way; you may as well spend it finishing what you started.

In practice, on a ten-post-a-month budget with clusters of roughly eight posts, this usually means you finish a cluster every 4 to 6 weeks of production, then leave it alone for another 4 to 8 weeks before you know it has held. So one cluster per calendar quarter is a realistic ceiling, and four clusters a year is a strong outcome for a small site. That is a whole theme owned, not sixty scattered posts hoping something sticks.

Mapping this to your own cadence

Ten posts a month is a useful anchor, but the shape scales. The unit is the cluster, not the calendar.

• At 5 posts a month, a cluster takes closer to two months to finish. Run one cluster at a time. Aim for two to three completed clusters a year.
• At 10 posts a month, run one cluster at a time, finish roughly one per month of production, and expect three to four fully compounding clusters by the end of the year once you factor in the settle-and-hold periods.
• At 20+ posts a month, you can run two clusters in parallel without losing focus, provided the audiences are distinct enough that the writer is not context-switching every draft.

Whatever the cadence, the discipline is the same. Pick a theme you can actually finish. Sequence supporting posts before and after the pillar, not all after. Link tightly. Stop when the cluster is done. Do not start the next one until this one is standing on its own.

Small budgets punish scatter. They reward focus. Ten posts a month spent on one theme is a better shot at owning a topic than a hundred posts a year spread across ten.

That is the workflow RankMill is built for. Your post budget is fixed, so cluster discipline is the constraint that decides what gets shipped. The research agent surfaces supporting-post candidates and shows its reasoning in the live log, the writer agent keeps voice and terminology consistent across every post in the cluster, and nothing goes live until you approve it. Pick the pillar, sequence the run, and let the loop finish the theme before you open a new one.