Content systems

Most content briefs are a word count, a keyword, and a list of headings copied from whatever currently ranks. That document produces a page which is structurally similar to four existing pages and differs from them in no way a reader would notice, which is the outcome it was designed for.

A brief earns its cost by removing ambiguity from decisions the writer cannot make alone. Which audience task is this, what already exists on the site, what original evidence has to appear, and who owns the claims that need a qualified person behind them.

It should not manufacture expertise. A brief that instructs a freelance writer to sound authoritative about Texas injury law is asking for something the writer cannot supply, and the resulting page will be confidently wrong in ways nobody on the team is equipped to catch.

A brief removes ambiguity. It does not prescribe length and it cannot invent expertise the organization does not have.

What a brief has to carry

The word count question is worth settling once. Length is an output of covering the task, not an input to it. A brief that specifies length gets a page padded to reach it, and padding is the most reliable way to make a page worse while appearing to have done more work.

Original evidence needs an owner, not a request

The line in a brief that says include original insights is a wish. The line that says the fee section will be supplied by the practice manager on Thursday is a plan, and the difference between those two decides whether the page ends up with anything a competitor cannot copy.

Name the person and the date, in the brief. Original evidence usually lives inside the business rather than in a research budget: how the process actually runs, what clients ask in the first call, which local details matter. Getting it requires somebody's twenty minutes, and twenty minutes is easy to schedule and impossible to conjure during a final review.

The same applies to claims requiring qualified review. Identify them at brief stage and route them early. A page held for two weeks in legal at the end of the process was usually a page that could have been reviewed in parallel with the drafting.

Define the success check before anyone writes

Write down what you will look at after publication, on which view, after how long, and what result would mean the page did not work. This is the field most briefs omit, and omitting it is how a content program accumulates pages nobody ever evaluates.

It also disciplines the brief itself. A page whose success check is hard to write usually has a soft purpose, and discovering that before the writing starts is considerably cheaper than discovering it a quarter later when somebody asks what the page was for.

Write the brief

Five fields, filled in this order. The first two come from earlier modules, which is the point of doing them earlier.

1. Attach the audience task and intent evidence.From module 3, unedited. Rewriting it here creates a second version that will drift from the first and neither will be authoritative.
2. Link the existing pages and name the overlap risk.Which page could this cannibalize, and what will keep them distinct. A brief that ignores this is how a site publishes its own competitor.
3. List the required evidence with owners and dates.Each item gets a person and a day. An unowned evidence requirement becomes a paragraph of generic filler under deadline.
4. Specify the page type, links, and reviewers.Including who reviews claims that need qualification. Routing that at the start runs it in parallel instead of at the end.
5. Write the success check.The view, the window, and the result that would mean this did not work. If you cannot write it, the purpose is not clear enough to brief.

Publishing is a release, not a save. Content, template, metadata, links, schema, tracking, and approvals all have to agree at the same moment, on the production URL, and each of them can be individually correct while the combination fails.

The most common version of that failure is approving a page because the copy is finished. Copy being final is one of eight conditions, and it is the one that has nothing to do with whether the page works for the person who arrives.

Approve the page on the production URL, rendered, with every control verified. Final copy is one condition of several.

Eight conditions, checked on the live URL

The calculator path is part of the guide's release. A guide that links to a tool depends on that tool working. Checking the page in isolation approves half a journey, and the half nobody checked is the one where the reader was going to convert.

Tracking verified, not assumed

Confirm the events fire before launch, by triggering them. An event that was configured but never tested is the standard reason a page launches with no measurement, and nobody notices for a month because absence of data looks exactly like absence of activity.

Assign the review owner at the same time, with the date from the brief's success check. A page with no named reviewer will not be reviewed, regardless of what the process document says, and the success check written so carefully at brief stage quietly becomes decoration.

Running this without becoming the bottleneck

Eight checks per page is affordable at four pages a month and impossible at forty. The way teams usually resolve that is by quietly dropping the checks, which is why release quality degrades exactly as a content program starts working.

Split the list by what actually varies. Metadata uniqueness, rendered content, canonical and robots behavior, and schema output are template properties. Verify them once when the template changes and they hold for every page built on it. Claims, qualified review, task completion, and the links in and out are page properties and have to be checked every time.

That split usually takes an eight-point manual check down to four, and it puts the other four somewhere they belong: in module 4's technical queue, attached to the template rather than repeated per URL. It also means a template regression is caught once rather than being rediscovered by whoever happens to publish next.

Give somebody authority to hold a release. Not a committee, one person with the standing to say this is not shipping today. A checklist nobody can enforce becomes a record of what was skipped, and the pages that skip it are always the urgent ones, which are always the ones that matter most.

Run the release

Seven checks on the production URL. The order matters less than the rule that none of them happens in a preview.

1. Verify the claims and their sources.Anything a reader could challenge needs something behind it. This is also the last cheap moment to remove a claim rather than defend it.
2. Complete qualified review where the topic needs it.Legal, medical, financial, or safety content needs the person whose name is attached to have actually read it. A review recorded but not performed is worse than none, because it creates a false record.
3. Read it through as the intended reader.Somebody uninvolved in the writing, doing the task the page promises. This finds the missing step that everyone close to the page has been mentally supplying.
4. Check the rendered page, not the draft.Production URL, real templates, real scripts. Everything module 4 covers about rendering applies here, and this is the moment it is cheapest to catch.
5. Verify metadata, links, canonical, robots, and schema.Five controls that each ship independently and each fail silently. A canonical pointing at staging is the classic, and it survives for months.
6. Trigger the tracking and watch it arrive.Fire the events yourself and confirm they land. Configured is not the same as working, and the gap between them is invisible until you need the data.
7. Record the review owner and date.From the brief's success check. Without a name against it, the check does not happen and the page joins the set nobody evaluates.

A declining line does not prescribe a rewrite, and the reflex to refresh anything that drops is how content teams spend a quarter improving pages that were never the problem. The diagram above separates the three shapes. This lesson is about what to do once you know which one you have.

The stakes are asymmetric. Refreshing a page that lost demand costs the work and changes nothing. Refreshing a page that was converting can cost the conversions, because a rewrite for search rarely preserves the specific paragraph that was doing the persuading.

Diagnose the shape, then check the outcome. Only position erosion is reliably a content problem.

Before the diagnosis: is this even decay

Decay is a sustained decline against a valid comparison. Three weeks is not sustained, and last month against this month is not valid when the topic is seasonal. The first job is establishing that something real happened, because a meaningful share of decay reports are a normal fluctuation compared against an unusually good period.

Check the query mix before anything else. Average position can worsen while every individual query improves, if the page picked up impressions for a set of harder terms. The page did not get worse. Its measured audience changed, and a refresh aimed at the metric will be aimed at nothing.

Then check what changed on the page and the template. A section removed in a redesign, a script that stopped rendering, a canonical that moved during a migration. Technical and editorial changes explain a large share of what gets filed as decay, and they are much cheaper to reverse than to rewrite around.

The page that still converts

This is the case that breaks the reflex, and it is common. Traffic to a page falls by half over two quarters, and the page still produces qualified leads at the same rate. The instinct is to treat that as an emergency. The correct response is usually to protect it.

Traffic is the middle layer of the measurement tree and conversions are the top. A page whose outcome is intact has not failed, whatever the graph says, and rewriting it puts the working part at risk in order to fix the part that was not paying anybody. Note it, monitor it, and spend the effort on a page whose outcome is genuinely gone.

The reverse case deserves the same attention. Traffic holding steady while the page stops converting is a real failure that no decay report will surface, because the metric it watches never moved. Content maintenance that only looks at traffic will never find it.

Six actions, and the honest use of monitor

Remove needs the most evidence of the six. Absent traffic and absent outcome, both confirmed, and no reasonable redirect target. A page with no traffic still holds links and still answers somebody's question, and deleting it converts a small ongoing benefit into a dead end.

Diagnose one declining page

Six steps, and the first three establish whether there is anything to diagnose at all.

1. Confirm the decline is sustained and the comparison is valid.A long enough window and a period worth comparing against. Seasonal topics need the same weeks last year, not the previous quarter.
2. Compare impressions, position, CTR, and query mix together.The combination identifies the shape. Any one of them alone is compatible with several different causes and will point you at the wrong fix.
3. Check page and template changes against the timeline.Deploys, redesigns, migrations, and removed sections. A change that lines up with the decline start is the most likely explanation and the cheapest to test.
4. Look at the result page as it is now.New competitors, a new feature above the results, or a shift in what the query means. The page can be unchanged and the market around it different.
5. Check whether the outcome actually moved.Conversions, not sessions. This is the step that stops you rewriting a page that is still doing its job on fewer visits.
6. Choose one of the six actions and write the reason.The reason is what makes the decision reviewable in six months, and it is what stops the same page being rediagnosed from scratch every quarter.

Content maintenance fails as a project and works as a habit. The quarterly audit that produces a spreadsheet of two hundred pages is a familiar shape: it takes a week, it recommends work for a month, and the spreadsheet is stale before half of that work happens.

The alternative is a recurring workflow that keeps the evidence, the decision buckets, the qualified tasks, and the run history in one place. What matters is not the automation. It is that the same criteria run on a schedule, and last quarter's decisions are visible when this quarter's run disagrees with them.

Same criteria, same place, on a cadence. Evidence that does not fit a rule stays visible instead of being forced into a decision.

Cadence and scope are the whole configuration

Pick a cadence the content can actually change within. Monthly review of evergreen editorial pages produces mostly noise, because two quarters is roughly how long it takes a content change to show a trustworthy signal. Quarterly suits most editorial libraries, and semiannual suits reference material that rarely moves.

Scope should be a page group somebody can name. Established editorial pages is a scope. The site is not, and a workflow scoped to everything spends most of its evidence budget on pages that were never candidates for a decision.

Seven buckets, including two that admit ignorance

Rows that match no rule stay visible too. A not-matched bucket is where the criteria get improved from. Forcing those rows into the nearest available decision hides the fact that your rules do not describe part of your library, which is the most useful thing a run can tell you.

Approval gates on anything irreversible

A workflow that can publish, redirect, or delete without a human decision is a workflow that will eventually do one of those things wrong at scale. Require approval before spend, before publishing, before redirects, and before removal. Recommendations can be generated freely; consequences need a person.

This is also what makes the automation trustworthy enough to leave running. A system that only proposes can be given a wide scope, because the cost of a wrong proposal is somebody reading it and disagreeing.

Read the history before changing the criteria

When a run produces results that look wrong, the temptation is to adjust the rules immediately. Look at the previous runs first. A criterion that worked for three quarters and failed once is usually reacting to a real change in the library rather than being wrong.

Keeping the run history in the same place as the decisions is what makes that check possible. A workflow whose output is exported and whose history is discarded cannot be debugged, and it slowly loses the trust of everyone expected to act on it.

Configure the workflow

Five decisions, made once and revisited rarely. The discipline is in what you refuse to let it do unattended.

1. Choose the cadence and the page scope.Both narrow enough to be meaningful. A named page group on a quarterly cycle beats the whole site monthly, and costs a fraction as much to run.
2. Write the diagnostic instructions.Which evidence to combine and what each combination means. This is the module's diagnosis logic written down so it runs the same way every quarter.
3. Define the buckets and their criteria.Including needs data and not matched. A bucket set with no room for missing evidence will manufacture confident decisions from nothing.
4. Gate every irreversible action behind approval.Spend, publishing, redirects, removal. Proposals can flow freely; anything that changes the site or the bill waits for a person.
5. Review the living section and history before editing rules.Compare this run against the last few. A rule that suddenly disagrees with three quarters of decisions is usually detecting something real.