Content Planning and Briefs

Content Refresh Brief

Define a focused update from obsolete claims, changed reader needs, performance evidence, search intent, product changes, and maintenance risk.

Free editable Markdown · Editors, SEO specialists, and content owners · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Asset and baseline

Page title and URL: [Enter]
Current version or last material update: [Enter]
Owner: [Name/team]
Primary reader task: [Describe]
Current unique value: [Evidence, tool, process, example, other]
Measurement period and comparison: [Enter dates]
Search query/page evidence: [Summarize]
User feedback or support evidence: [Summarize]
Indexing, canonical, and technical status: [Record]

Refresh diagnosis

Obsolete or unverifiable claims: [List exact passages]
Changed product or policy behavior: [List]
Unanswered reader questions: [List with evidence]
Intent or audience drift: [Describe or None]
Internal overlap: [URLs and task comparison]
Weak structure or examples: [Describe]
Discovery or engagement concern: [Describe without assuming cause]
Maintenance risk: [Owner, source, or review gap]
Decision: [Refresh / Merge / Redirect / Retire / Leave unchanged]

Change map

Duplicate for each material section.

Section or element: [Enter]
Action: [Keep / Update / Add / Remove / Verify]
Reason: [Reader, evidence, product, search, accessibility, other]
Required source: [Owner and due date]
Proposed contribution: [What useful change will result?]
Risk if changed incorrectly: [Describe]
Reviewer: [Name/role]
Acceptance condition: [Observable result]

Publication plan

Title, description, or heading changes: [List]
URL decision: [Keep / Migrate with plan]
Internal links and navigation: [Updates]
Canonical, redirect, sitemap, and schema: [Updates or None]
Localization impact: [Locales and source-lock date]
Fact and expert review: [Owners]
Accessibility and responsive QA: [Owner]
Release date and final approver: [Date, name]

Measurement and maintenance

Baseline reference: [Saved report or notes]
Expected reader outcome: [Describe, not a ranking guarantee]
First and second review dates: [Enter]
Search, engagement, or completion signals: [List]
Confounding changes to annotate: [Campaign, release, season, migration]
Next maintenance trigger: [Product, source, policy, or scheduled date]
Responsible owner: [Name/team]

How to use this template

Restate the page's intended reader task and collect current content, source, product, and performance evidence.
Diagnose accuracy, usefulness, intent, overlap, discovery, and maintenance problems separately.
Define the refresh's original contribution and a line-by-line keep, update, add, remove, and verify scope.
Assign sources, reviewers, dependent technical changes, QA, and a versioned release plan.
Publish, inspect the live result, and monitor against a dated baseline and update trigger.

Diagnose the page before rewriting it

Open the live page, its sources, change history, internal links, and available performance data. Restate the reader task the page is supposed to complete. Then separate possible problems: facts may be obsolete, search intent may have shifted, the product may behave differently, examples may no longer help, the page may duplicate another URL, or discovery may have fallen while the answer remains strong. Look at query and page patterns, feedback, support questions, conversion or completion signals, and competing internal routes. A traffic decline is a prompt to investigate, not an instruction to add words or replace the entire draft.

Scope the refresh around verified value

List every time-sensitive claim and the source or product behavior needed to revalidate it. Identify material that remains correct and should not be disturbed. Define the new contribution before outlining changes: a tested workflow, clearer limitations, updated data, a better example, or a direct answer to a question readers now ask. If the page and another URL serve the same task, decide whether consolidation is more honest and maintainable than refreshing both. Avoid changing the title, path, and core intent simultaneously unless evidence supports the migration and dependent links, redirects, canonicals, locales, and analytics are planned.

Publish with a measurable change record

Turn the brief into a change map that states what to keep, update, add, remove, or verify. Assign every evidence gap and specialist review. Record the pre-change metrics, query period, index state, and qualitative evidence so the team does not attribute every later movement to the refresh. After release, verify the live page, links, structured data, canonical, date labels, and localized equivalents. Monitor search and user outcomes at suitable intervals, recognizing that recrawling, seasonality, campaigns, product changes, and external competition can affect results. Schedule the next review using a concrete trigger rather than an empty promise to “keep updated.”

See the fields in context

Fictional example: file-upload help page

The product behavior and observations below are invented and do not describe GPTHuman upload limits.

Diagnosis: A fictional help page still names an old file type, buries the current size limit, and lacks recovery steps for a failed upload.
Keep: The tested three-step upload sequence, which remains accurate.
Update: Verify supported formats with the fictional product owner and put the limit beside the file picker instructions.
Add: A small error table based on three imaginary support questions; do not add an unsupported success-rate claim.
Trigger: Recheck after any uploader release or six months from the fictional publication date.

Frequently asked questions

How often should content be refreshed?

Use the rate of change, reader consequence, source expiry, product releases, and observed problems. A fixed site-wide schedule can under-review risky pages and over-edit stable ones.

Should the publication date be changed after every edit?

Follow a transparent site policy. A material update may justify a visible updated date; a typo correction should not be presented as a newly researched page.

Does adding more text improve a declining page?

Not inherently. Add material only when it resolves a demonstrated reader or evidence gap. Extra words can bury the answer and increase maintenance risk.

When is consolidation better than a refresh?

When two pages serve substantially the same task and maintaining both creates duplication, inconsistent facts, divided links, or confusing search results.