Content writing

What a content calendar is

A content calendar is a list of decisions already made, each with a date on it. It solves one problem and only that one: "what do we publish now" is the most expensive decision in this work, and taken under time pressure every time, it is taken badly every time.

  • Lesson 5 of 8
  • Beginner
  • Free, no signup

The life of one topic, from decision to review

Most calendars are written up to the fifth station, and nobody puts the sixth one in the table.

  1. 1

    The question turns up

    From a customer message, a phone call, something you explained three times.

  2. 2

    It joins a pillar

    If it fits no pillar, either a new pillar is needed or the topic is not yours.

  3. 3

    It takes a slot in the queue

    This is where it becomes clear whether the question is a duplicate.

  4. 4

    It gets written and edited

    Editing has its own place in the plan, otherwise it is the first thing dropped.

  5. 5

    It goes out

    And from there it links to its pillar and to its neighbouring pieces.

  6. 6

    It gets reviewed later

    Is it still true? The station almost no calendar has, and the one worth the most.

The gaps between stations are not fixed and depend on the topic. The figure shows the order, not the duration.

Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.

What exactly a content calendar solves

A content calendar is a table saying what gets published, for whom, and when. It is simpler than what is usually sold under the name, and it has one job: it moves the decision away from the moment of publishing and into a moment when you are not busy.

That move matters. Somebody asking at five on a Thursday "what do we put out today" always arrives at one answer: whatever can be produced fastest. Somebody who made the same decision two weeks earlier and unhurried asked a different question: "which customer question still has no answer". The two answers are entirely different, and the difference does not come from the writer talent, it comes from when the decision was made.

A calendar that works has two columns most calendars do not. First, which question this piece answers; second, which main page it connects to. Without the first, the calendar is a list of titles, and a title is not yet content. Without the second, every piece becomes an island.

The tool really does not matter. A spreadsheet is enough and we do not suggest anything more complex; a tool that takes more time to maintain than the calendar saves costs more than the calendar itself.

A glass calendar with a steady green rhythm of dots, one red burst followed by a gap, and a blue marker

Why a steady rhythm beats a burst

The common pattern is this: one enthusiastic month, ten pieces in two weeks, then three months of silence. The other pattern is one a week that carries on for a year. The second one wins, and not for the reason usually given.

We do not claim that an algorithm rewards publishing frequency; we have not measured such a thing, and anyone handing you a number for it made it up. The practical reason is three other things. First, quality: in a burst, pieces five to ten go out unedited, because the burst itself ate the editing time. Second, habit: work done once a week settles into a team, and work done for one month never settles. Third, accumulation: the value of content comes from piling up, and piling up needs time rather than intensity.

There is a hidden side effect that gets less airtime. A burst always leaves a half finished queue behind it: four drafts that never got done. That queue does not get published later either, but for a long time it gives the team a sense of debt, and that feeling is what delays the start of the next round.

There is an exception and denying it would be silly: launching a product or running an event naturally wants focus and a burst. This section is about the base state, not about the day you introduce something.

The loop that repeats every week

Four jobs; if one of them gets skipped, the loop stops in the second month.

A rhythm that survives next monthA loop that does not close is not a calendar
  • 1 Refill the queue
  • 2 Write
  • 3 Publish
  • 4 See what happened

The job usually dropped is refilling the queue, because nothing about it is urgent. Its consequence shows up two months later, not that week.

How many a month for a team of one

A number from us would be wrong for your business, but the method for arriving at one is not. Choose a number you could still meet in your worst week, not your best. The worst week means the week a client has an urgent problem and half your day is gone.

Halve your first estimate. Almost every team we have seen overestimated its initial capacity, and the cost is asymmetric: publishing less than you promised yourself does little harm, while stopping after three heavy weeks tires the team and leaves a page whose last piece is dated three months ago.

Then measure for two months. Not views, something simpler: how many of the things you promised actually went out. If all of them did, you can raise the number a little. If not, lower it and draw no conclusion about the team; the first estimate was simply optimistic.

One thing that makes a real difference in small teams: do not schedule the writing in the calendar, set aside a fixed weekly block for it. Work without a specific hour is the first thing dropped in a busy week, and that is what breaks the rhythm, not a lack of motivation.

Arrange the topics around a pillar

A calendar with random topics produces random content. There is a simple way to give it an order: pick one main, complete page, and then several smaller pieces that each answer a sub question of the same topic and link back to it.

The benefit is twofold. For the reader, every piece is an entrance and afterwards they know where to go. For you, the calendar stops being an open ended list: when you ask what to write next month, the answer comes out of the pillar itself and you do not have to think from scratch.

There is an important rule here, and breaking it ruins the work: two pieces must not answer the same question. If two rows in the calendar really carry one question, those two compete with each other in search results and usually neither takes the place of the other. The fix is to delete one right there in the calendar, not three months later. The article on keyword cannibalisation covers this in detail.

Choosing what the pillars should be is SEO work, not calendar work: keyword research says what people actually look for and content SEO says how a topic gets covered completely. The calendar only spreads that decision out over time.

One pillar and the pieces that sit around it

The example uses a hypothetical topic so the shape of the arrangement is visible, not the content of one industry.

One pillar: the main, complete page

  • What to ask before ordering

    The question of somebody who has not decided yet.

  • What pushes the cost up

    The question of somebody who got a quote and was surprised.

  • The most common mistake in this work

    Where your experience has something new to say.

  • How long it takes

    The question everybody asks and few answer honestly.

There is no rule for the number of branches; it depends on the topic. There is only one rule: two branches must not answer the same question.

What a calendar does not fix

A calendar does not fix a positioning problem, it only schedules it. If you do not know who you are writing for and what you want to be known for, the calendar publishes that same confusion tidily and on time. The output does not get better; it just gets a date.

The sign is obvious: a calendar whose date column and title column are full and whose "which question does it answer" column is empty. That table is finished and that project has not started.

So the right order is: first write one sentence saying who this content is for and what you want to be known for, then draw a few topic pillars out of that sentence, then fill the calendar from them. A calendar built before that sentence only puts the work in order, not the right work.

The fast path, with AI

What you should not do is ask a model for "thirty content ideas for my business". The answer you get is the same list a thousand other people got, and a calendar built from it competes with everybody from day one. The right move is the reverse: you bring the questions and the model only groups and orders them. What makes this pass worth running is rule five: the model has to say which two questions are actually the same one.

  1. Collect the raw questions from where they actually are: customer messages, direct messages, phone calls, and the questions that repeat in a sales meeting. They need no order and no tidying.
  2. Prepare the list of pages you have already published as well. Without it, the model will suggest a topic you wrote three months ago.
  3. A cheap, fast model is enough for this pass, because the work is grouping rather than judging. The current ranking is listed in this site AI section.
  4. Take the output as a queue, not as a calendar. You set the order and the dates yourself, because the model does not know which topic you can write from experience and which you cannot.

Copy-ready recipe

Raw questions from our customers:

{the list of questions, one per line, as they were asked}

Pages we already have:
{title and URL of each published page}

Reader: {the reader in one sentence}

1) Group these questions by the question behind them, not by shared words.
2) Give each group a name that is itself a question.
3) For each question, say whether it is asked by somebody who has not decided yet, is comparing, or has decided and is stuck.
4) Separate out any question already answered by one of the pages above and say which page.
5) Bring together any pair of questions that are really one question and say which of the two should stay.
6) Do not add any new topic of your own. If a group is thin, say so.
7) Write no number, no date, no seasonal occasion and no claim about trends.

Before you trust the output: The output of this pass is a queue and not yet a calendar. Finish three things yourself: the order, because the model does not know which question is more urgent for your business; the volume, which comes from your real capacity and not from the number of questions; and rule four, which has to be checked against the site itself, because the list you gave the model may have been incomplete.

AI in this kind of work

Our position here is strict: AI is excellent at ordering questions you have and bad at producing a topic list out of thin air. The difference is not only quality. A list a model builds from nothing is the same list it gave your competitor, so a calendar built on it is competing from the start with texts no different from it. A queue that came out of your own customers real questions does not have that problem at all.

Tools that actually help

  • Claude It holds the "add no new topic" constraint across a long list, and that constraint is the whole difference between a real queue and a generic one. Iran is on neither of Anthropic two supported country lists; we read that on Anthropic own page.
  • Gemini It understands Persian itself, so the raw questions can go in exactly as the customer wrote them, with no translating and no tidying. Google own page says the app works in over 230 countries and territories and more than 70 languages, and Iran is not on that list.
  • NotebookLM It earns its place when the questions are spread across several files and places, because it works only on the sources you gave it and does not add topics of its own. Google own help says it runs in the same regions where the Gemini app runs, and Iran is not on that list.

Where it backfires

Two risks, and the first is specific to this job. A model speaks confidently about time: which month is the season for this product, which occasion is coming up, what is trending this year. Those come either from stale data or from nowhere, and because a calendar is full of dates, that kind of error slips into the work more easily here than anywhere else. Your calendar should carry no date you did not confirm yourself. The second risk is the one Google spam guidance targets: a calendar that produces pieces only to fill its cells is exactly the scaled production of unhelpful content, and it does not matter whether a person or a model wrote them.

Sources: Google Search Central: spam policies for Google web search Google Search Central: creating helpful, reliable, people-first content Anthropic: supported countries and regions Google: where Gemini Apps are available

Where this advice stops

A calendar does not fix a positioning problem, it only schedules it; if you do not know who you are writing for, the calendar publishes that same vagueness on time. It has two other boundaries. First, there is no number for the right volume in this lesson and there should not be: the right number comes out of your team real capacity and the only way to find it is two months of measuring. Second, a calendar is about order and timing rather than quality; a piece published on time with nothing to say is the same useless piece, now with a date on it.

From our own work

The Learn section you are reading runs on a content calendar, and that calendar is code rather than a table. The publishing plan is written in includes/dates.php: three slots a day at 09:40, 14:50 and 20:10 Tehran time, with a deterministic jitter of up to twenty minutes either way, derived from the hash of that lesson slug. The order is round robin across the tracks so that all of them fill together, rather than one finishing while the others sit empty. Two things we learned here and have not seen in any content calendar guide. First, the hardest part was not the table: the order of the queue was decided before the first slot, and that decision was the whole job. Second, that twenty minute jitter is deliberate, because publishing exactly on the hour three times a day does not look like human work; which means that even when a machine runs the calendar, you still have to do something so it does not look machine made.

Real follow-up questions

How many months ahead should I lock the calendar?

Lock the near weeks precisely and keep the further ones as a pool of topics. A calendar with three months of fixed titles usually goes stale in the second month, because new customer questions have nowhere to land. One specific month plus an open pool lasts longer in practice than a closed quarter.

What should I do if I fall a week behind?

Drop one and keep the rhythm; do not publish two to catch up. Catching up is exactly what ruins the following week as well, and step by step you return to the burst and silence pattern. Falling a week behind costs nothing; three consecutive weeks of trying to catch up does.

Should old pieces go in the calendar, or only new ones?

Both, and reviewing an old piece usually pays better. A piece that already had readers and now has one stale section is put right with an hour of work; a new piece starts from zero. Every few months give one calendar row to a review and write down there which page it is.

Keep learning