Use when a library has hundreds of posts and someone has to decide what to keep, merge, redirect or remove.
content-inventory-prune-decisions.md
You are recommending what happens to each post in a content library. You are not rewriting anything and you are not removing anything, only deciding.
Inventory rows with URL, title, publish date, traffic, conversions and referring domains: {{INVENTORY_ROWS}}
What the site is for now: {{SITE_PURPOSE}}
Topics we still intend to own: {{PRIORITY_TOPICS}}
What we can maintain each quarter: {{MAINTENANCE_CAPACITY}}
Output:
1. Decision table: URL | Decision (keep, update, merge, redirect, noindex, remove) | Reason tied to a figure in {{INVENTORY_ROWS}} | Sits inside {{PRIORITY_TOPICS}} (yes/no) | Risk of acting (high/medium/low).
2. Merge groups: which URLs combine, which one survives, and what the survivor must gain from the others.
3. Leave alone: rows where the safe action is redirect rather than removal, with the referring domain or conversion figure that makes it so.
4. A sequenced plan sized to {{MAINTENANCE_CAPACITY}}, highest value first, saying what waits until next quarter.
5. Rows you cannot decide, each with the single figure that would settle it.
Rules:
- Never recommend removal for a URL with referring domains in {{INVENTORY_ROWS}}.
- Do not judge a post by age. An old post that still converts against {{SITE_PURPOSE}} is a keep.
- Recommend no more work than {{MAINTENANCE_CAPACITY}} allows.
Replace each placeholder with your own detail. The more specific you are, the less the model invents.
When should I use this rather than a content audit?
When someone has to decide, not describe. An audit tells you what exists and leaves the library exactly as large as it was. This commits to keep, update, merge, redirect, noindex or remove for every URL and ties each call to a figure in your own inventory rows.
What columns does the inventory need?
Inventory rows carrying URL, title, publish date, traffic, conversions and referring domains, what the site is for now, the topics you still intend to own, and what you can maintain each quarter. Include conversions and referring domains. Traffic alone produces decisions you will spend next year reversing.
What decisions come back?
A decision table with a reason and a risk level per URL, merge groups naming the survivor, rows where redirecting beats removing, a plan sequenced to your capacity, and rows it cannot decide with the one figure that would settle each. Keep that last list to re-run next quarter.
Which sequencing mistake causes damage?
Running the plan out of order. Merges come before redirects, because merging changes what the surviving page needs, and a URL with referring domains is never a removal candidate. Committing to more than your stated capacity is the other one, since a half-finished prune leaves the library worse than untouched.