Content Planning: How to Decide What to Publish Next

A content plan is the set of decisions about what to publish next and why. The calendar is where those decisions get dates, and confusing the two is how teams end up with a schedule nobody can justify. This guide is for people who already have a library: a year or more of published pages, a list of candidate topics, and no reliable way to choose between them. It covers what has to exist before planning starts, where candidates come from, how to decide whether a topic should be a new page at all, what order to publish in, and how much to publish.

The short version

• Creating a new page is the last answer, not the first. Check every candidate against what you already own, and most of them route to an update, an expansion, or a merge instead.
• A content plan is a sequence of decisions. A content calendar is the output. Teams that start with the calendar skip the reasoning.
• Finish clusters before starting new ones. A cluster at seventy percent completes cheaply. Five clusters at twenty percent each cover their subject partially, which is the state search engines have least reason to reward.
• Publishing cadence is set by what you can research and maintain, not by a number from someone else's blog. Every page you publish creates ongoing work.

What is content planning, and how is it different from a content calendar?

Planning is the decision layer. It answers which topics are worth doing, whether each one becomes a new page or a change to an existing page, and what order they ship in. The calendar records the results, and it is the easy part.

The distinction matters because the two fail differently. A bad calendar is a scheduling problem and it fixes itself in a week. A bad plan produces pages that compete with each other, clusters that never finish, and a library that gets larger without getting stronger. Those take months to unwind.

Most published advice on this subject moves straight from keyword research to a calendar template. That works for a site with nothing on it. It stops working at roughly the point where your own back catalogue becomes the biggest thing standing between a topic and a good decision.

What has to exist before you can plan anything?

An inventory. Not a list of URLs, but a list of what each page is actually about, what state it is in, and which query family it serves. Without that, every planning decision is a guess about your own site.

Three things are worth recording per page, and they are enough:

• The subject: the one thing the page is about, written as the query it should win. Not the title.
• The state: thorough, thin, or stale. A page can be long and still thin if it never commits to a subject.
• The overlap: which other pages of yours touch the same subject, and whether any of them are competing for it. Search Console answers this better than your own memory: the query dimension of the Performance report shows which page already collects impressions for a query, which is harder evidence than two titles looking similar.

Our guide to running a content audit covers building that inventory properly. Competitor coverage is a separate input and a separate method: our competitor analysis guide covers content gap analysis and how to score which gaps are worth closing, and this article assumes you have already done that rather than repeating it.

Where do candidate topics come from?

Five sources, and four of them are inside things you already have.

• Phrases your own pages keep using: a concept that appears across six articles and has no page of its own is usually a page waiting to happen.
• Questions your headings ask without answering: subheadings that raise something and move on mark the edge of your coverage.
• Entities you name without explaining: the terms you assume readers know are the terms other people are searching for.
• Pages too thin to carry their subject: these are candidates for expansion, not for a sibling.
• Modifier expansion on what you sell: the standard keyword work, which our keyword research guide covers in full.

The order matters. Starting from a keyword tool produces candidates disconnected from what you have already built, which is exactly the input that leads to duplicate pages. Starting from your own library produces candidates that connect to something.

Should this topic be a new page at all?

Usually not, and this is the decision the rest of the plan depends on. Run every candidate through four routes before it gets anywhere near a date. This is the routing we apply before a topic reaches a calendar.

Route	When it applies	What ships
Create	Nothing you own treats this as its subject	A new page
Update	A page's subject already is this topic, but it is stale or thin	A revision at the same URL
Expand	A page covers it as a section, and the topic has its own question space	A new page, plus a trim of the parent, plus a link between them
Merge	Two pages already compete for it	One consolidated page, one redirect

Update beats create more often than people expect: a page with existing history, existing links, and an existing crawl pattern starts from somewhere. A new URL starts from zero. If a page whose subject genuinely is the topic already exists, improving it is almost always the stronger move, even when rewriting most of it.

Expand is the route that gets skipped: when a topic currently lives as one section inside a broader page, and that section has enough of its own question space to stand alone, it can become its own page. The condition is that you also trim the parent and link the two, so they do not end up competing. An expansion without the trim is just cannibalization with extra steps.

Merge is the one nobody wants to do: two pages targeting the same query split their signals and neither performs as well as one consolidated page would. Consolidating means picking the stronger URL, folding the better material from both into it, and redirecting the loser. Google's documentation on consolidating duplicate URLs covers the canonical side of that.

When create is genuinely right: nothing you own treats the topic as its subject, the topic has its own demand and its own question space, and it does not overlap the query family of an existing page. That is a smaller share of any candidate list than most calendars assume.

How do you decide what to publish first?

Finish clusters before starting new ones. A cluster covering most of its subject needs only a few more pages to cover it properly, and clusters tend to perform as a set rather than page by page. Several half-built clusters each cover their subject partially, and partial coverage is the state search engines have the least reason to reward.

In practice that produces a rough priority order:

• First: the missing pages in whichever cluster is closest to complete.
• Second: the commercial questions buyers ask that have no page at all. These are usually low volume and disproportionately valuable.
• Third: pages in clusters that are roughly half built.
• Last: new clusters, which are the most expensive thing on the list because a pillar with two supporting pages is not a cluster yet.

Our guide to topical authority covers how a cluster is structured in the first place, and why depth across a subject beats isolated posts.

When not to follow this: a genuinely new commercial priority beats cluster tidiness. If the business starts selling something new, the pages that support it go first regardless of what that does to your completeness percentages. Cluster completion is also not a reason to write a page nobody is looking for. A missing node with no demand and no commercial value is missing for a good reason.

How much should you publish, and how far ahead should you plan?

As much as you can research properly and maintain afterwards, which for most small teams is less than they plan for. The publishing rate is the visible half of the decision. The invisible half is that every page you ship creates permanent work: links that go stale, facts that age, and a subject you now have to defend against everyone else writing about it.

A team producing four thin posts a month with no capacity to maintain them is worse off than a team producing one good page and keeping the library healthy. Google's guidance on creating helpful content is explicit that volume produced primarily for search engines is not the goal, and the maintenance argument is the practical version of the same point.

On horizon: plan the decisions one quarter out and the dates one month out. A quarter is long enough for cluster completion to mean something and short enough that you have not committed to topics chosen against conditions that no longer hold. Anything scheduled six months ahead is a wish.

How do you keep a plan from becoming a backlog?

By deciding, on a fixed cadence, what to remove from it. A plan that only grows is a list of things you feel guilty about, and the guilt does not make any of them better ideas.

Review monthly and ask three questions of every item still waiting. Has anything changed about the demand or the competition since it was added? Did we publish something in the meantime that now covers it, which happens more than you would think? Is it still connected to something we sell? Anything failing all three comes off the list rather than moving down it.

The signal that a plan is being used is that it changes. A quarter that ships exactly what was planned in week one usually means the plan was never reconsulted, not that the planning was unusually good.

What are the most common content planning mistakes?

Five, and the first one causes the most lasting damage because it compounds silently.

• Manufacturing cannibalization through the calendar: a planning process whose only output is new posts will eventually schedule a page that competes with one you already have. Nobody notices, because both pages look fine on their own.
• Planning from a keyword list instead of an inventory: the keyword tool does not know what you have already published, so it cannot tell you the honest answer, which is often that you already covered this.
• Starting clusters instead of finishing them: new subjects feel more productive than completing an old one. They are not.
• Setting cadence by benchmark: publishing frequency copied from a company with a different team size and a different library.
• Treating the plan as fixed: a plan that survives a quarter unchanged was not being used.

The pattern under all five is the same: treating content planning as a production question when it is a portfolio question. What matters is not how many pages you add this quarter but whether the library covers its subjects more completely at the end of it than it did at the start. Our guide to content marketing for SEO covers how that library is meant to serve search in the first place, and our content marketing engine is where that planning work sits as a service.

The habit worth building is a single question asked before any topic reaches a date: does something we already own cover this? It takes a minute, it changes the answer surprisingly often, and it is the one check that prevents the failure mode nobody spots for six months. This week, take the next five topics on your list and route each one to create, update, expand, or merge before you schedule any of them.