Plan Content Backwards From Demand, Not Forwards From a Calendar
Why calendars run the wrong way
Content calendars are built forwards from whenever the plan was written, which means anything aimed at a seasonal peak gets published during the peak and indexed after it. The work is sound, the timing wastes it, and next year the same plan produces the same result because nobody records why it missed.
Running the calendar backwards from demand is arithmetic rather than insight: find the weeks when interest rises, subtract the time a page needs to be discovered and gain position, and publish there. The subtraction is the part people underestimate, and it is usually two to three months rather than two to three weeks.
Publishing during the peak is publishing too late.
The timing problem
Content needs time to be crawled, assessed and to accumulate engagement before it performs. Publishing in the week demand peaks means arriving after the decisions were made.
Paid campaigns have the opposite constraint and can be switched on late, which is why the two plans should be built together.
Working backwards
Find your real demand curve from your own data, not from a generic seasonality chart. Count back the weeks a page needs to mature in your category. That is the publishing date.
Refresh last year’s page rather than publishing a new one each cycle, so the history compounds.
After the peak
Keep the page updated rather than letting it decay for ten months. The page that holds position between peaks is the one that wins the next one.
Planning backwards from demand
Most content calendars run forwards from whenever the plan was written, which means a piece aimed at a seasonal peak gets published during the peak and indexed after it. The correction is arithmetic rather than clever: find the weeks when demand actually rises, subtract the time a new page needs to be discovered and gain position, and put the publish date there.
The lead time is the part people underestimate. A new page on a competitive seasonal query is not a contender in a fortnight. Eight to twelve weeks before the rise is a working default for something new, less for a refresh of a page that already has history, and that difference is itself a reason to refresh rather than to write fresh wherever a page exists.
Building the calendar
- Pull three years of search interest for your core queries and mark the weeks demand rises.
- Work backwards by the lead time: eight to twelve weeks for a new page, three to four for a refresh.
- Check whether an existing page should be refreshed instead; it is nearly always cheaper and faster.
- Publish, then build internal links to the page during the run-up rather than after.
- Review the page the week after the peak while the data is fresh, and note what to change next year.
Writing a new page when a refresh would win
A page with two years of history, some links and an established position will usually beat a new page written this month on the same subject, and refreshing it costs a fraction as much. Teams write new because it feels like progress and because the old page is embarrassing, which is an argument for editing it rather than for abandoning the history it carries.
Common questions
How far back should we look at demand?
Three years, so you can see whether a pattern is a pattern or a one-off.
What if our seasonality is unusual?
Use your own analytics rather than a public trend tool. Industrial and B2B cycles frequently look nothing like consumer ones.
Should paid cover the gap?
That is exactly what it is good for: buying presence during a peak you were too late to earn organically, while the page accumulates history for next year.
Does evergreen content have a season?
Often a mild one. Even content with no obvious cycle tends to move with the budget year of the people searching for it.
