Check this page with an assistantOpens a chat asking it to summarise this article and name the evidence behind each claim.
Claude opens with the prompt on your clipboard: Anthropic does not support prefilled prompts on the web, and we would rather copy it than ship a button that drops it.
The Default Nobody Chose
Every content process has a default action, and in every one it is to write something new. Not because anyone decided that, but because it is frictionless: a brief, a writer, an output to report. The alternatives all require someone to look at what already exists first.
Refreshing requires deciding which page and reading it. Merging requires a redirect, a decision about which URL survives, and somebody's approval. Skipping produces nothing to show in a weekly update. Three of the four options carry friction and one does not, so the frictionless one wins by default rather than on merit.
The consequence compounds. Libraries accumulate pages faster than they accumulate value, competing pages appear on subjects already covered, and the maintenance burden grows against a fixed team. None of that is a writing problem, and no amount of writing quality fixes it.
Four Options, Decided Before Drafting
The gate is short and it belongs before the brief rather than after it. Once a brief exists, the decision has already been made implicitly, and reversing it means throwing away work somebody did.
| Decision | When | What it looks like |
|---|---|---|
| Create | Genuinely distinct question, nothing covers it | A new page with its own reason to exist |
| Refresh | A page covers it and has a content fault | Improve in place, per updating old posts |
| Merge | Several pages circle it, none answers it | Consolidate, per the consolidation playbook |
| Skip | No demand, no angle, or no commercial route | A recorded decision not to write it |
Skip is the option most processes have no slot for, and it is frequently the correct one. A topic with no real demand behind it, or where you have nothing distinctive to say, produces a page that competes for nothing and needs maintaining forever. Recording the decision is what stops it being reproposed next quarter.
The Distinction That Prevents a Bad Queue
Only content faults should send a page into the writing queue. Template faults belong to whoever owns the layout, and confusing the two is how a single template defect turns into hundreds of content tickets.
Content faults are properties of the page: thin coverage, stale facts, a weak or missing title or description, duplication with another page. Fixing them requires someone to read and rewrite that specific page, which is what a content queue is for.
Template faults are properties of the layout: a missing viewport tag, absent structured data, no canonical, a broken heading hierarchy. Every page on a badly-templated site carries them identically, and they are fixed once in the template. Running them through a per-page content process means paying a writer to look at four hundred pages that all have the same defect and none of which they can fix.
Running the Gate
Five minutes per proposed topic, before anything else happens. The output is a decision with a reason, which is also the record that prevents the same topic returning.
- Search your own site for the target query.
Use a site: search rather than memory, per search operators. Most teams are surprised at least once a quarter by something they already published.
- Check Search Console for the query.
If a page already receives impressions for it, you have a page on this topic whether or not it was written for it. Improving that page starts from an established position rather than zero.
- Test whether the questions are genuinely distinct.
State what the existing page is for and what the new one would be for, in one sentence each. If the sentences overlap, you are proposing a competitor to your own page, per cannibalization.
- Ask what you would say that is not already published.
If the answer is nothing, the decision is skip regardless of search volume. A page that restates the available consensus competes with the consensus.
- Record the decision and the reason.
Especially for skips. Without the record the topic returns, someone proposes it again, and the reasoning is redone from scratch.
Leave Changed Pages Alone for a While
One more rule prevents a subtler waste: do not re-edit a page inside its settling window. A page changed last week has not been reassessed yet, so changing it again means you will never know which edit did anything.
The practical effect of ignoring this is a page that gets touched three times in a month by people responding to noise, after which no one can attribute anything. It also wastes the only opportunity you had to learn something, because a change made in isolation is the closest thing to a readable result available outside a controlled test, per SEO split testing.
Keep a record of what was changed on which page and when, and refuse new work on a page inside the window. That record doubles as the answer to whether previous changes worked, which is the question every content programme eventually gets asked and very few can answer.
Questions About the Content Decision
- Should I write a new page or update an existing one?
Search your own site for the target query first. If a page already covers it, improving that page is almost always better than adding a competitor to it. New pages are worth creating when the question is genuinely distinct from anything you have, which is less often than a content calendar assumes.
- Why do content libraries sprawl?
Because writing something new is the cheapest action available and nothing in a normal process objects to it. Refreshing requires deciding which page and reading it. Merging requires a redirect and someone's approval. Skipping produces no output to report. The default wins by being frictionless, not by being right.
- What should trigger a refresh?
Content faults specifically: thin coverage, stale facts, a missing or weak title or description, duplication with another page. Not template faults. A missing viewport tag or absent schema is fixed once in a layout, and treating it as a page-level content problem pushes every page on a badly-templated site into the writing queue.
- When is merging the right answer?
When several pages circle the same question without any of them answering it fully. The test is whether you can state what each page is for in one sentence without the sentences overlapping. If you cannot, they are one page that got written three times, and consolidating usually outperforms improving any single one.
- Is skipping ever the right decision?
Frequently, and it is the option no process makes room for. A topic with no real demand, no distinctive angle available, or no route to anything commercial should not be written at any quality level. Recording a deliberate skip is more valuable than producing a page nobody needed.
