Keyword Set to Content Production Plan
Decide what to write new, what to update and in what order — with owners and briefs attached.
Converts a prioritised keyword set and an existing content inventory into a sequenced production plan: new pages, page updates, merges and retirements, each with a brief stub, dependency order and the internal links the new page will need on day one.
Ready-to-use prompt
The prompt
Copy it as-is, then swap the bracketed placeholders for your own details before running it.
Role: You are a content operations lead turning a keyword set into a production plan.
Context:
- Prioritised keywords or clusters: {{keywords}}
- Existing content inventory (URL, title, target term): {{inventory}}
- Monthly publishing capacity: {{capacity}}
Task: For every keyword or cluster, decide one action — NEW, UPDATE, MERGE or SKIP — and return:
1. The action and the target URL (existing or proposed)
2. A three-line brief stub: angle, must-answer questions, required proof
3. Dependency order (what must publish first for internal links to work)
4. Two internal links the page needs on day one, from the existing inventory
5. Sequenced month against capacity
Rules:
- Prefer UPDATE over NEW whenever an existing page already targets the intent.
- MERGE requires naming the surviving URL and what happens to the other.
- Do not schedule a page before its dependency.
- Never propose a URL that is not in the inventory unless the action is NEW.
Output: a month-by-month plan table, then the dependency chain, then anything you had to SKIP.
- Add a proposed owner role to each scheduled action; mark ownership as unconfirmed unless supplied.
- State the capacity unit and count every scheduled action against it.
- Label day-one links as incoming or outgoing; flag any shortfall instead of inventing sources.
- For each SKIP, state the reason and what input would allow reconsideration.
Estimated results
Editor's note
Why this prompt matters
A prioritised keyword list still does not say what to write on Monday. The missing step is deciding, per keyword, whether an existing page should be updated instead — and in what order things must publish so the internal links exist when the page goes live. This prompt makes those calls explicitly, with a preference for updating over writing new, which is where most of the fast wins actually are.
Anatomy
Prompt engineering breakdown
Role
Context
Goal
Constraints
Output format
What you'll get
Expected output
Scenario and planning assumptions
A generic HR resource site has prioritised employee onboarding, new-hire checklists, remote onboarding and payroll software comparisons. Capacity is two editorial packages per month; an update or merge consumes one package, just like a new page. Redirect implementation requires separate technical approval rather than being silently absorbed into writing capacity.
The supplied inventory contains /guides/onboarding, /guides/new-hire-checklist, /guides/first-week-checklist, /templates/onboarding-checklist and /guides/buddy-program. Owners below are proposed roles, not confirmed assignments. These are planning recommendations, not claims about measured performance.
Month-by-month plan
| Month | Cluster and action | Target URL | Proposed owner | Day-one incoming links | |---|---|---|---|---| | 1, first | Employee onboarding — UPDATE | /guides/onboarding | Content editor | Checklist template; buddy guide | | 1, second | New-hire checklist — MERGE | /guides/new-hire-checklist | Content editor + technical owner | Onboarding guide; checklist template | | 2 | Remote onboarding — NEW | /guides/remote-onboarding | HR writer | Onboarding guide; surviving new-hire checklist |
Link-source labels refer to the inventory paths above. Each source needs an actual contextual link edit; listing it here does not make that link exist. The merge retires /guides/first-week-checklist: preserve useful first-week tasks in the survivor, redirect the retired URL and replace internal links pointing to it. Neither future links nor the retiring page count as day-one sources.
Brief stubs
UPDATE: employee onboarding Angle: Make the existing overview the navigation hub, not another checklist. Must-answer questions: Who owns each stage? Where should readers go for task-level instructions? Required proof: HR reviewer approval of the stage definitions and ownership guidance.
MERGE: new-hire checklist Angle: Combine overlapping task lists into one chronological checklist. Must-answer questions: What happens before arrival, on day one and during week one? Which tasks belong to managers? Required proof: A source-by-source comparison showing which unique tasks were retained.
NEW: remote onboarding Angle: Cover remote-specific handoffs without duplicating the general checklist. Must-answer questions: How are equipment, access and introductions coordinated remotely? Who resolves failed handoffs? Required proof: An operations-reviewed equipment and access workflow; no unsupported productivity claims.
Dependency chain
Overview update → checklist merge → remote guide. The overview establishes the navigation structure; the merge establishes the stable checklist destination. Schedule link edits alongside each release. If the merge slips, move the remote guide rather than linking through a planned retirement.
Skipped and unallocated
SKIP: payroll software comparisons. The supplied inventory and evidence do not support product evaluation; assign no target URL. Month two’s remaining slot stays unallocated rather than inventing another assignment.
Under the hood
Why this prompt works
The update-first rule is the important constraint: models default to proposing new pages, which is how sites end up with three near-identical posts. Requiring day-one internal links from the real inventory means the plan produces connected pages rather than orphans, and the dependency chain keeps pillar-and-supporting sequences in a workable order.
Model fit
Best AI models for this prompt
ChatGPT
Best at sequencing against capacity and producing usable brief stubs quickly.
Claude
Most reliable at respecting the update-over-new rule and the dependency ordering.
Gemini
Strong when the inventory includes current performance so it can favour updates with existing traction.
When to use
- After clustering and prioritisation, before committing the next production calendar.
- During backlog review when updates could replace proposed new articles.
- When sequencing a hub, supporting articles and their launch links.
- Before an editorial handoff that needs owners, evidence requests and merge tasks.
When not to use
- Before keyword intent and priority have been established.
- For mature-site keyword-to-URL assignment; use the mapping workflow first.
- For campaign positioning or channel allocation decisions.
- To approve retirements without analytics, backlink data and human review.
Get more from it
Pro tips
- 1
Supply the full inventory, including templates and older guides; omitted pages become accidental NEW recommendations.
- 2
Treat dependencies as binding, but require a reason for each edge; not every supporting article must wait for a pillar.
- 3
Expand brief stubs into writer briefs by naming the evidence source and reviewer for each proof requirement.
- 4
Re-run when capacity changes; specify whether capacity counts pages, editorial packages or hours.
- 5
Include redirect implementation and source-page link edits in MERGE handoffs, not just copy consolidation.
- 6
For a second pass, challenge every NEW against the closest existing URL and ask what intent differs.
- 7
Check both day-one link sources exist and survive the plan; reject retired pages as link sources.
Don't ship this
Common mistakes
✗ Defaulting to NEW for keywords an existing page already targets.
Fix — State the update-first rule and check every NEW against the inventory.
✗ Scheduling supporting posts before the pillar.
Fix — Require and follow the dependency chain.
✗ Planning without day-one internal links.
Fix — Demand two links per page from the existing inventory.
People also ask
Frequently asked questions
Q.How is this different from keyword-to-URL mapping?
Mapping assigns one owner page per keyword on an existing site. This decides what to build or update and in what order, against capacity.
Q.What if I have no content inventory?
Export URLs, titles and target terms first. Without the inventory the plan will propose new pages you already have.
Q.Are the brief stubs enough to write from?
They are a starting point. Pair them with the content brief prompt for anything competitive.