Editorial Calendar Planning

You turn a pile of content ideas into a calendar the team actually ships: every slot tied to a business goal and a reader need, sized to real capacity, with owners and deadlines worked back from the publish date. The calendar is a living sheet, reviewed weekly, and it includes updating old content, not only making new pieces.

When to use

• "What should we publish next quarter?"
• "Our content is random. Get it organised."
• "Build us a content calendar."
• "We have a list of 80 ideas. Which first?"
• Planning content around a launch, a season or an event.

What you need

• Business goals and priority audiences for the period (from the marketing plan if there is one).
• Positioning and brand voice guide, if they exist.
• Capacity: who writes, edits, designs, films; hours per week each; approval steps and how long they take.
• Existing content inventory: URLs, titles, publish dates, traffic. Google Search Console and Google Analytics through connected apps or the owner's signed-in browser; or a crawl of the sitemap with web_extract.
• Keyword research and customer questions (see also seo-keyword-research), sales and support FAQs (ask_teammate).
• Key dates: launches, events, seasonal peaks, industry moments.
• Where the calendar should live: Google Sheets, Notion, Trello, Asana or a CSV.
• If none of these tools are connected or signed in, ask the owner with clarify for a content list and traffic exports, and build the inventory from the public sitemap meanwhile.

Method

1. Set 3 to 5 content pillars. Each pillar is a topic area where the business has expertise, the audience has demand, and the content leads naturally to the product. Write one line per pillar: what it covers, who it is for, which product it supports.
2. Organise pillars into topic clusters. For each pillar, one pillar page (the broad guide) and 5 to 15 supporting pieces answering narrower questions, all linking to the pillar page and to each other where relevant.
3. Audit what exists. Map existing content to pillars. Mark each piece: keep, update, merge (two pieces competing for the same query), or retire (redirect to the best related page). Pages that have lost 30 percent or more of their clicks year on year in Search Console go into the refresh queue.
4. Build the backlog. Pull ideas from keyword research, sales and support questions, customer interviews, competitor gaps, and the team. Write each as a working title plus the reader question it answers.
5. Score and rank the backlog. Use the scoring sheet in references/calendar-template.md: business value (0 to 3), audience demand (0 to 3), ability to win (0 to 3), and effort (1 to 3). Priority = (value x 2 + demand + win) / effort. Value is weighted double because traffic that never converts is a cost.
6. Set a sustainable cadence. Calculate capacity first: hours available per week divided by hours per piece (a typical long article takes 6 to 12 hours across brief, draft, edit, design and upload; measure your own). Plan to about 80 percent of capacity. A steady cadence the team can keep beats an ambitious one it abandons in week five.
7. Balance the mix. Across a month, cover the funnel: pieces for people learning about the problem, comparing solutions, and ready to choose. Mix new pieces and refreshes; a common split is 1 refresh for every 2 to 3 new pieces once a library exists.
8. Schedule with backward deadlines. For each slot, set brief due, draft due, edit due, design due, approval due and publish date, working back from the publish date with the team's real turnaround times.
9. Plan distribution per piece. Which newsletter issue it goes in, which social channels, which sales sequences, which internal pages will link to it. Content without distribution is half-finished.
10. Run it weekly. Set a cronjob for a weekly calendar check: what is late, what is blocked, what ships next. Post a short status with brief_team. Once a month, review results (organic clicks, conversions, newsletter clicks) per piece and per pillar, and re-score the backlog.

Output

• Pillar and cluster map (one table).
• Content audit with keep / update / merge / retire decisions.
• Scored backlog.
• The calendar sheet with the columns in references/calendar-template.md, filled for the period, in the owner's tool or as a CSV written with write_file.
• Capacity maths showing the cadence is achievable.
• A one-screen show_card with the next four weeks.

Checks before you finish

• Every scheduled piece maps to a pillar, a reader question and a goal.
• Planned hours are at or below 80 percent of real capacity.
• Every slot has an owner and backward deadlines.
• Refreshes of decaying pages are in the plan, not only new content.
• No two scheduled pieces target the same primary query.
• Key dates and launches are covered with lead time.
• Distribution is planned for each piece.

Pitfalls

• Idea lists posing as calendars. A calendar without owners, deadlines and capacity maths is a wish list.
• Volume over value. Publishing more low-value pieces does not help. Rank by business value and ability to win.
• Ignoring the archive. Updating a page that already ranks on page two is often faster than writing a new one.
• Cannibalisation. Two pieces for the same query split clicks. Merge them or change one's angle.
• Forgetting approval time. If legal or the owner reviews everything, add that time to every deadline.
• Set and forget. Without a weekly check, slippage compounds. Run the review.