Content Calendar: What Goes In One, and What It Cannot Fix

A content calendar is the schedule: what publishes, when, and who owns it. It is not the plan. The plan is the argument for why these topics and in what order, and a calendar built before that argument exists is a commitment to fill slots. Our guide to deciding what to publish next covers the planning half; this page is only about operating the artifact.

We know the shape of the failure because we produced it. Over nine weeks from 27 July to 26 September 2026 this blog published 149 posts. Through 29 September they had earned 15 clicks between them, and 139 of the 149 had earned none. The calendar was never the problem; it worked perfectly.

This is for whoever has to keep a publishing schedule honest: the columns we run, how many weeks carry dates, how the ratio of updates to new posts has actually landed on our own calendar, and the habit that stops the thing decaying.

What is a content calendar?

A dated list of what you will publish, with an owner and a status against each item. At minimum it answers three questions for any given week: what is going out, who is finishing it, and what state is it in right now.

It is an operational artifact. Its job is to stop two people writing the same post, to make a missed deadline visible before the deadline, and to let somebody who is not you answer "what is shipping this month". It is not supposed to tell you whether a topic is worth writing, which is the job it most often gets handed by mistake.

What goes in a content calendar?

Eight columns. These are the settings we run rather than a finding: we have not tested this against a seven-column or ten-column version, and no such test exists that we know of. What the eight are chosen for is that each one answers a question somebody asks out loud in a weekly meeting.

Column	Why it earns a column
Working title	Not the final one. A title that changes during the draft is normal.
Target query	One per piece. If it is blank, the planning has not been done.
Owner	A person, not a team. Shared ownership is no ownership.
Status	Four values: briefed, drafting, in review, scheduled. More values get guessed at.
Publish date	The commitment. Changing it should be visible, not silent.
Stage	Which part of the funnel the piece serves, so the calendar does not quietly fill with top-of-funnel explainers.
Internal links planned	Which existing pages this will link to, and which will link back to it.
Review date	When somebody checks whether it worked. We set ours 30 days out.

The last column is the one teams drop first and should keep longest. Without a review date nothing in the calendar is ever evaluated, and a calendar that is never evaluated turns into a production line measured by output. More on what ours shows below.

What does not belong: word-count targets, a keyword density figure, and anything the writer will ignore. Length is an outcome of the evidence, not an input to the brief.

How many weeks of the calendar should carry dates?

About a month. Beyond that you are scheduling work against assumptions that will change before you reach them, and the row goes stale while still looking committed.

This is the same rule our planning guide states from the other side: plan the decisions one quarter out and the dates one month out. The calendar is where that second half lives. Three horizons in practice:

• Committed. The next four weeks or so, with dates and owners. These are promises.
• Queued. The rest of the quarter, with target queries but no dates. These are decisions already made.
• Candidate. An unordered list of topics that survived the planning pass but have not been ordered.

A twelve-month calendar is almost always a document somebody built once and nobody reopened. If an annual view is genuinely needed for a stakeholder, build it from themes rather than from titles, because the themes survive and the titles will not.

How often should you publish?

Less often than most calendars assume, and the number should come from your own record rather than from a benchmark.

Google's own position is worth reading before you set a cadence. Its guidance on creating helpful, reliable, people-first content lists questions where answering yes is "a warning sign that you should reevaluate how you're creating content". One of them asks whether you are adding a lot of new content primarily because you believe it will help rankings "by somehow making your site seem 'fresh?'" The page answers itself in brackets: "(No, it won't)".

Ours came from a failure rather than from that guidance. Publishing 149 posts in nine weeks produced 15 clicks, so on 30 September 2026 we capped ourselves at three published posts a week. It works as a ceiling rather than a quota: the first four-week plan under it filled 11 of the 12 to 13 slots available, and the discipline is in what did not get written. The full account is in what 149 posts earned us.

To set your own ceiling, start from your existing pages: how many took a click in the last 90 days, how many only appeared in search, and how many did neither. If most of your library is in the third group, your constraint is not cadence.

How much of the calendar should be updates rather than new posts?

On an established site, most of it. A page with impressions already has something to build on; a new page starts at zero. We can put a number on our own split, because every post we have published or changed since 28 October 2026 has been written to an append-only ledger, one line per page touched.

As of 31 October 2026, with this post counted in it, that ledger holds 32 rows: 15 content refreshes, 15 new posts and 2 factual corrections to live posts. Counting the corrections, 17 of the 32 rows are changes to pages that already existed, against 15 new ones, on a corpus of 181 published pages that is three months old. New work and old work are running level, which is not where we would want them.

Two things that number is not. It is not a recommendation, because four days of logged activity is not long enough for a ratio to mean anything, and we chose the refreshes deliberately rather than discovering the ratio. And it is not evidence that the refreshes worked: every one of those 32 rows carries a review date, the earliest falls on 27 November 2026, and none has been closed yet. We are reporting the input, not the result.

Give refreshes their own rows with the same columns, target query and review date included, because an update made without a named query is a cosmetic edit. Treat a refresh that changes nothing substantive as a failure rather than as throughput: every edit moves the visible updated date, and moving it without changing the substance is a false signal to a reader and to a crawler. Deciding which pages deserve a refresh row is covered in auditing the posts you already have.

What tool should you use?

Whatever your team already opens daily. The tool is the least consequential decision here, and teams spend more time choosing one than the choice is worth.

Option	Works when	Breaks when
A spreadsheet	One to three people, simple process	Status has to be visible to people who never open it
Your project tracker	Content work is already scheduled alongside other work	The board has no date view anyone trusts
A dedicated content tool	Many contributors, formal approvals	It becomes a second place where truth lives

For the record, ours is the least sophisticated option available: a plain append-only text file in the repository, one line per published or changed page, with the target query, the prediction and the review date on the line. It is not a recommendation for a team of eight. It is a demonstration that the format does not matter as much as whether anyone writes the review date down.

One rule regardless of tool: one calendar. The moment a second copy exists, the two diverge, and the one you are not looking at is the one somebody else is working from.

How do you keep it from decaying?

Give it a weekly review with one question: what slipped, and why. Decay is never a sudden event; it is three weeks of nobody changing a status field.

Two habits do most of the work. Move the date rather than letting it pass, so a slip is a decision somebody made rather than a row that quietly went red. And close the loop on the review date, even when the answer is that nothing happened. A calendar where half the review dates are in the past has stopped being a calendar and become a list.

We are not yet entitled to claim we do the second one. Our 32 review dates are all still in the future, so the habit is written down and untested, and the first honest test of it falls on 27 November 2026. That is the position most calendars are in on the day they are built, and it is why the review column is the one to protect when something has to give.

The thing worth protecting underneath all of it is the link between a row and a reason. Every item should trace back to a query somebody believed in. When a row cannot answer "why this", it is not a scheduling problem, it is a planning one, and adding it to the calendar will not fix it.