Turn a content plan into a calendar with a date and an owner on every page
Sequences an existing content plan into dated slots, orders the pages by dependency, and refuses to schedule anything whose evidence does not exist yet.
- Works in
- ChatGPT, Claude, Gemini
- You need
- A content plan that already exists, one line per page · How many pieces a week you can actually finish · Any dates that are already fixed
- Written for
- seo topics
Scored by our own engine
This page, run through the audit we sell. Measured 4 August 2026.
A content plan tells you what to publish. It does not tell you what to publish next, and the gap between those two is where most plans quietly stop. The prompt below takes a plan that already exists and turns it into dated slots with an owner on each, cut to the number of pieces you can genuinely finish rather than the number the plan contains.
A plan is a set, a calendar is a sequence
A plan says which pages should exist. A calendar says in what order, on what date, and what has to exist before writing starts. The second is a scheduling problem, and it is where a plan meets an actual team.
Deciding the pages is a different job, and the content plan prompt does it. Once that is settled, order stops being a formatting detail. A supporting page published two months before its pillar links upward to nothing, gets no internal links pointing at it, and sits alone for the whole period a search engine is deciding what your site covers.
Cadence is a capacity question
Publish at the rate you can hold for six months. There is no correct frequency, and every number quoted at you was measured on a different team with a different approval chain.
Rule 1 stops the model offering one, which it will otherwise do, fluently and with no basis. This is the part where honesty costs something: three good pages a quarter beats a twelve month grid that produces four. A calendar cut to real capacity looks unambitious in a meeting and is the only kind anybody keeps.
What actually makes a calendar slip
Evidence that does not exist yet, not writing speed. The page waiting on a customer interview nobody has booked is what moves every date after it.
That is what rule 4 is for. Pages needing something you have not confirmed you have go on a blocked list with a name against each, rather than onto a date where they look handled. Read that list before the dates, because a plan where half the pages depend on unbooked interviews is not a scheduling problem and no calendar will fix it.
The last thing is the smallest and it undoes the rest when it is missed. Dated publishing only counts if the dates reach the page: run a live URL through the content freshness checker to confirm the publish date, the modified date and a date a reader can actually see all made it into the markup. An undated page is not read as new, it is read as unknown.
You are turning a content plan that already exists into a publishing calendar.
The plan is settled. Do not add pages, do not rename them and do not redesign
the plan. Your job is order, dates, and what has to exist before writing.
Rules you must follow:
1. Cadence comes from the capacity I state and from nothing else. Do not
recommend a publishing frequency because it is typical, common or best
practice. You have no information about my team beyond what I gave you.
2. One page per slot. If I have three slots a week you schedule three pages
that week, however much longer the plan is.
3. Order by dependency, not by importance. A pillar is scheduled before the
supporting pages that link up to it, and a page that refers to another page
is scheduled after the page it refers to. Name the dependency you used on
every row where one applied.
4. Any page needing evidence I have not confirmed exists goes on a BLOCKED
list rather than on a date, with the specific thing missing and who has to
produce it. Never schedule a page in the hope the proof turns up.
5. Reserve the update slots I asked for and fill them only from pages I told
you are already published. If I gave you no such list, leave those slots
empty and labelled rather than filling them with new pages.
6. Do not extend the calendar past the plan. When the plan runs out, stop, and
say on what date it ran out.
7. Never estimate traffic, search volume, difficulty or how long a page will
take to rank, and never sequence anything on a predicted result. You have
no data on any of it. Sequence on dependency, on the fixed dates I gave
you, and on what a reader has to understand first.
8. Schedule anything with a fixed date backwards from that date, and state the
date writing has to start, not only the date it publishes.
Output as week blocks, in this exact shape, with no table anywhere:
WEEK OF <date>
Slot 1: <page>
Why this week: <one line, dependency or fixed date>
Needed before writing starts: <the inputs, or "none">
Owner: <who, or "unassigned">
Slot 2: <page>
...
After the blocks, give me four things:
- BLOCKED: the pages you could not schedule, what is missing from each, and
who has to produce it.
- The first date this calendar slips if one input arrives late, and which
input that is.
- What the first month publishes, in one sentence, so I can judge whether it
reads as one topic or as a scatter.
- The pages still unscheduled when the calendar ends.
My business: [ONE SENTENCE ON WHAT YOU SELL AND TO WHOM]
The plan: [ONE LINE PER PAGE: TITLE, PILLAR OR SUPPORTING, AND WHAT IT LINKS TO]
Capacity: [HOW MANY PIECES A WEEK YOU CAN ACTUALLY FINISH, AND WHO WRITES THEM]
Update slots: [HOW MANY SLOTS A MONTH GO TO UPDATING PAGES YOU ALREADY PUBLISHED]
Start date: [THE DATE THE CALENDAR STARTS]
Fixed dates: [LAUNCHES, EVENTS OR SEASONS WITH THEIR DATES, OR WRITE "none"]What to change
Everything in square brackets is yours to replace. Nothing else needs editing.
[ONE SENTENCE ON WHAT YOU SELL AND TO WHOM]- Decides what a reader has to understand first, which is the tiebreak when two pages have no dependency between them. "We sell payroll software to accountancy firms" puts the compliance page ahead of the explainer. Without it the model sequences alphabetically and calls it a strategy.
[ONE LINE PER PAGE: TITLE, PILLAR OR SUPPORTING, AND WHAT IT LINKS TO]- The plan as it stands, for example "Internal linking for category pages, supporting, links up to the ecommerce SEO pillar". The link column is what makes rule 3 work: without it nothing has a dependency and the calendar is just your plan in date order.
[HOW MANY PIECES A WEEK YOU CAN ACTUALLY FINISH, AND WHO WRITES THEM]- The honest number, counting review and publishing rather than writing time. "One a week, written by me, reviewed by our head of product who takes three days" is the input that produces a calendar you keep. "Three a week" from a team that published five things last quarter produces a sheet you stop opening in March.
[HOW MANY SLOTS A MONTH GO TO UPDATING PAGES YOU ALREADY PUBLISHED]- Pick a number and defend it, because nobody else can pick it for you. Teams with a large back catalogue and flat traffic put more here than teams with eleven pages. Setting it to zero is a choice too, and it is the choice that leaves your 2024 articles ranking on advice you no longer give.
[THE DATE THE CALENDAR STARTS]- A real Monday, not "next quarter". A concrete start date is what makes rule 8 usable, since a launch on 14 October means nothing to the model unless it knows which week is week one and can count backwards from there.
[LAUNCHES, EVENTS OR SEASONS WITH THEIR DATES, OR WRITE "none"]- Anything the calendar has to hit: a product launch, a conference you sponsor, the month your buyers set budgets. These are the only rows that override dependency order, and getting them in up front stops the whole calendar being rebuilt in week three when somebody remembers the launch.
How to run it
- 01Start from a plan, not from a topic
This prompt sequences pages that have already been decided. If what you have is a subject rather than a list of pages with distinct questions against them, map it first: sequencing an unfiltered list only schedules the duplicates in a tidier order.
- 02Write down the capacity you actually hit last quarter
Count what you published in the last three months and divide. Use that number rather than the one you intend to reach, because the calendar is only useful if it survives a normal month with a holiday and a launch in it. You can always add a slot; removing one means rebuilding.
- 03List what each page needs before writing starts
Go through the plan and mark the pages that need something you do not have: an interview, a screenshot from a customer, data somebody has to pull, legal sign off. This is the input rule 4 works from, and it is the difference between a calendar and a wish list.
- 04Run the prompt and read the BLOCKED list first
The blocked pages are the real output. A plan where half the pages need evidence nobody has been asked for is not a scheduling problem, and finding that out now is worth more than the dates. Assign each blocked item to a person with a date, or cut the page.
- 05Put the slip date in front of whoever owns the inputs
The prompt names the first date the calendar slips and the input that causes it. Send that line to the person holding that input rather than the whole calendar. One date and one name is actionable in a way a twelve week grid never is.
- 06Publish, and make the dates visible on the pages
A calendar produces dated pages, and the dates have to survive into the markup. Run a published URL through the content freshness checker to confirm it carries a publish date, a modified date and a date a reader can see. Change the content when you change the date, never the other way round.
Questions people ask
What SEO topics should I publish about?
The questions your buyers have to get answered before they can buy, and nothing else. There is no universal list, because the topics are a property of your audience rather than of SEO. Deciding them is a planning job; this prompt starts after that decision, when the pages exist and need dates.
How often should I publish?
At the rate you can hold for six months. There is no correct frequency, and any number quoted at you was measured on somebody else with a different team, a different approval chain and a different back catalogue. The prompt forbids the model recommending one for exactly that reason.
How is this different from asking for a content plan?
A plan decides which pages should exist and what question each one answers. A calendar decides the order, the dates and what has to be true before writing starts. Running them as one request produces a plan padded to fill twelve months, which is the usual reason a calendar has rows nobody ever writes.
Why does the prompt refuse to schedule some pages?
Because some pages are only worth publishing with evidence behind them: a customer story, original data, a screenshot of something real. Putting those on a date assumes the proof will appear. Listing them as blocked, with a name against each, turns a silent assumption into a task somebody can accept or refuse.
Should the calendar include updates to old pages?
Usually, and the share is yours to choose rather than the model to guess. Once a site has a back catalogue, updating a page that already ranks tends to be cheaper than writing a new one. The rule that matters is to change the content before you change the date, since a date bump with identical text reads as manipulation over time.
Unsubscribe in one click. We never pass your address on.