You have the cluster planned. Pillar chosen, spokes listed, everybody nodding. Then the calendar swallows it, and six weeks later three spokes are live, the pillar still says "coming soon," and nothing links to anything.
That's normal. It happens because a content calendar for topic cluster work is not the same thing as a list of article dates. It's a delivery plan for one connected resource.
This guide gives you the mechanics. What ships when, how to group the spokes, when to add the links, and how to know the cluster is actually finished. We're assuming the cluster itself is already planned, so we won't argue about which spoke deserves to go first.
Here's the good news: you only have to sequence pillar spokes once, and the pattern works on every cluster after this one.
Ready? Let's build the schedule.
Put the whole cluster into one calendar view
Start by making the cluster visible as a unit. One record for the pillar. One record for every planned spoke. All of them tagged with the same cluster name so you can filter the build and see it whole.
At a minimum, each row records the cluster it belongs to, the content title, the type (pillar or spoke), the status, the owner, a due date, and a publish date.
That's the floor. A few more fields make the build much easier to run:
- Page slug or ID
- Draft owner, reviewer, publisher
- Batch or wave
- Pillar destination for the return link
- Planned links (source, destination, section, anchor)
- Link QA status
- Maintenance review date
Notice what those extra fields have in common. They make the connections schedulable, not just the articles. That's the whole difference between a cluster and a pile of posts.
How you know it's done: filtering your calendar by the cluster name returns the complete planned set. Every row has a type and an owner. Every item has a due date and either a publish date or an honest "unscheduled" status.
Where people go wrong: treating the due date as the publish date. They're two different jobs. The due date protects your production and review time. The publish date is when the page goes live. Collapse them into one and every review gets squeezed on the day it matters most.
If you use DeepSmith, this lives in Content Studio. Ideas sit in New Ideas until you give them a date, and giving an idea a date is what moves it into Planned Content. You can date them one at a time or in bulk, which is handy when you're dropping a twelve-piece cluster onto a calendar in one sitting.
Set a content cluster timeline you can actually hold
Now pick a window. Not "sometime this quarter." A real start and a real end, sized to what your team can support without cutting review.
Then place the pillar and every spoke inside it. Release waves work better than scattering pages across unrelated future slots. A simple operating model looks like this:
- Prepare the pillar and the link map.
- Release the pillar.
- Release related spokes in batches.
- Reserve a final completion and QA slot.
Weekly, fortnightly, something else: pick the rhythm you can keep. There's no magic frequency here, and anyone selling you one is guessing. What decides the cadence is your review capacity, your link QA time, and your honest ability to finish. A pillar and spoke publishing schedule that ends is worth far more than a fast one that stalls.
Give the last slot a name. Something like "all planned spokes live and linked." That's a cluster-level milestone, and it does a job no article status can do.
One more thing to write down while you're here: the shape of the waves. How many spokes ride in each one, and roughly how far apart they land. That single line turns a pillar and spoke publishing schedule from a vague intention into something a teammate can pick up when you're on holiday.
How you know it's done: the content cluster timeline has a finite end date. Every spoke belongs to a batch. Production and review owners are assigned. A protected cluster-QA slot exists on the calendar, not in your head.
Where people go wrong: trusting article-level statuses. Twelve rows marked "published" can still add up to a broken cluster, because "published" says nothing about whether the pages found each other. The milestone is what catches that.
Pro tip: work backwards from the completion date, not forwards from today. Forwards produces a schedule that keeps sliding. Backwards produces one with a finish line, and a finish line is what makes fan-out coverage land together instead of dribbling out over a year.
Prepare the pillar as your navigation layer
The pillar isn't just the longest page in the cluster. It's the map. Every spoke gets found through it, so it needs to be ready before the spokes start arriving.
Three things to confirm before you publish it:
- The central topic is explained clearly and completely.
- The structure is usable. A hyperlinked table of contents helps a lot on a long pillar.
- There's a planned home for every spoke link.
That third one is the part teams skip. Before publication, write down the intended section and destination for each spoke. Which part of the pillar will hold the link to spoke four? What will the anchor say?
If a spoke isn't live yet, mark the destination as pending. Don't guess the URL and publish it. A guessed URL becomes a broken link the moment someone changes the slug, and nobody notices for months.
Forget word count targets. Comprehensive coverage and clear navigation matter, length doesn't. And make sure the content is reachable by both readers and crawlers, not sitting behind a form or a password.
How you know it's done: the pillar structure is approved, every planned spoke maps one-to-one to a section or link placement, and no link points at a destination that doesn't exist yet.
Where people go wrong: shipping the pillar with a promise to add the spokes later, then never going back. The spokes go live, the pillar never updates, and readers land on a map with half the roads missing.
Batch related spokes into release waves
Here's where the calendar starts paying you back. Instead of writing one spoke, publishing it, and starting the next, you group related spokes and move them together.
Why batch? Because related pages share context. When you write four spokes from the same corner of the cluster in one pass, you carry the same pillar destination, the same anchor language, and the same awareness of what's already live. That consistency is hard to fake one article at a time.
Give every spoke in a batch the same shared context before writing starts:
- The pillar destination
- The relevant pillar section
- The planned anchor wording
- Any already-live related pages it should know about
Then review the batch as a set, not as four separate drafts. You're looking for overlap, contradictory claims, four near-identical introductions, and any missing handoff back to the pillar. Reading them together is the only way to catch that.
How big should a batch be? Whatever your team can review properly. There's no defensible universal number, so size the wave to your capacity rather than to a rule you read somewhere.
Record real dependencies when a later page genuinely needs an earlier one to exist. Don't invent dependencies that aren't there. Fake dependencies turn a flexible cluster publishing order into a fragile chain where one late draft blocks five pages.
Most spokes have no dependency at all. When you sequence pillar spokes into waves, group them by how related they are, not by an imaginary order of operations. Related pages reviewed together catch each other's overlaps. Unrelated pages forced into the same wave just make a longer review.
How you know it's done: each batch has defined membership, a review owner, a link map, and a release checkpoint.
Where people go wrong: treating batching as permission to publish faster. It's a production efficiency, not a quality discount. If the batch produces near-duplicates, you needed fewer spokes, not a bigger wave.
This is also the step where scheduling can carry some of the load. In DeepSmith, an article configured at planning time can write itself on its scheduled date through Autowrite, then land in Produced Content for review. The dates you set in the previous step are what drive it, so the batch keeps moving during the week your calendar falls apart. You still decide what goes in the wave and you still review it.
Add links as pages go live
This is the step that separates a cluster from a folder of related articles, and it's the one most often left to the end. Don't leave it to the end. Make linking part of every release.
Each time a spoke goes live, run the same short loop:
- Confirm the live URL actually resolves.
- Verify the spoke links back to the pillar.
- Update the pillar's relevant section, table of contents, or related-resources block.
- Add spoke-to-spoke links only where the destination is live and the link genuinely helps.
- Recheck any page the release touched for broken or placeholder destinations.
Five minutes per page. That's it. Compare that to the afternoon you'll spend untangling twelve pages at the end, and the trade is obvious.
A few craft notes on the links themselves. Use crawlable HTML links: a real anchor with an href pointing at a URL that resolves. Write descriptive, reasonably concise anchor text that makes sense for both the source and the destination, and let the surrounding sentence carry the context. Skip the keyword stuffing, and avoid stacking several links next to each other where a reader can't tell them apart.
Keep a link log while you're at it. Source page, destination page, direction, section, anchor text, live URL, owner, date checked, QA status. Mark a link verified only after you've seen the destination load.
How you know it's done: every live spoke links back to the pillar. The pillar links to every relevant live spoke. Every extra cross-link has a reason a reader would recognize.
Where people go wrong: building a full mesh. Spokes do not all need to link to every other spoke. The required architecture is pillar-to-spokes and spokes-to-pillar. Everything else is optional, and forcing it makes pages read like a link farm.
If you'd rather not do this by hand every time, internal linking is part of the writing pipeline in DeepSmith rather than a step bolted on afterwards, along with heading structure, metadata, and schema. It won't replace the cluster-level check, because only you know which live destination a given spoke was meant to reach. It does mean fewer links to place manually per article.
Run cluster-completion QA
The last batch is live. You're close, but you're not done. Block the slot you protected earlier and audit the cluster as one system.
Filter your calendar to the cluster and walk the list:
- Every planned record has a final status.
- Every URL resolves to the page it's supposed to.
- The pillar links to each relevant spoke.
- Every spoke links back to the pillar.
- Cross-links are relevant, not forced.
- Anchor text is descriptive.
- Links use crawlable anchors.
- The pillar's navigation reflects what actually shipped.
- No page is orphaned.
- Titles, headings, metadata, schema, and visible content match the approved briefs.
Then have a human read across the set. Not for typos. For factual accuracy, overlap between pages, voice drift, and whether the handoffs between pages make sense to somebody arriving cold.
While you're here, it's worth checking that each page reads well for answer engines: clear headings, a direct answer near the question it addresses, and sections that stand on their own when read out of context. Those are structure and usability practices. They make a page easier to use and easier to extract from. They are not a promise of citations, and anyone who tells you otherwise is overselling.
In DeepSmith, this review happens in Produced Content, where you can preview the live article, revise the body and metadata, and publish straight to your CMS. The cluster-level judgement is still yours.
How you know it's done: the cluster has a completion date, a named QA owner, no unresolved critical link or publishing issues, and a written record of anything you deliberately deferred.
Where people go wrong: calling the cluster complete because the drafts exist. A cluster is complete when the pages are published, the links point at live destinations, the links are crawlable, and nothing planned is stranded on its own.
Schedule the maintenance review
One more row before you close the file. Put the next cluster review on the calendar now, while you still remember how everything connects.
At the review, check four things:
- Do the links still resolve?
- Does the pillar still represent its supporting pages?
- Are there new pages that belong in the cluster?
- Is any spoke outdated, redundant, renamed, redirected, or deleted?
Six to twelve months is a commonly published rule of thumb for that gap. Treat it as a starting point, not a deadline handed down from anywhere. A fast-moving topic wants a shorter loop.
How you know it's done: the next review date, the owner, and the checklist are all recorded on the calendar.
Where people go wrong: assuming a finished cluster stays finished. Slugs change, pages get merged, redirects pile up, and the link graph quietly rots. Ten minutes twice a year prevents most of it.
What to do next
Take the cluster you already have planned and give it one calendar view today. Add the type, owner, and publish date columns. Pick a completion window. Name the final QA slot.
That's an afternoon, and it's the whole difference between a cluster that ships and a cluster that stalls. Then reuse the same operating model on the next one, because the second time is much faster.
If the production side is what's actually blocking you, DeepSmith plans, writes, links, and publishes from the same calendar, so a dated cluster keeps moving even in a busy week. You can start a free trial and put a real cluster through it before you decide.
