Evergreen Content Refresh Framework: Update One Retained URL With Evidence

A content refresh should improve a page that has already been selected to remain at its current canonical URL. It is not the process for deciding whether a portfolio should keep, merge, or remove competing pages.

If that decision has not been made—or if another page serves the same intent—start with the FACTASH portfolio content audit workflow. Begin this framework only after the retained URL, audience, and purpose are clear.

Refreshing is also not changing a date, adding a paragraph to meet a word count, or rewriting copy because rankings moved. Google’s people-first content guidance explicitly warns against changing dates when content has not substantially changed and against adding or removing content merely to make a site seem fresh. A truthful modified date can describe a meaningful revision; it is not, by itself, a ranking improvement.

This framework keeps five activities distinct:

1. collect evidence about the retained page;
2. decide whether and how to update it;
3. make substantive editorial and technical changes;
4. publish and request recrawling where useful;
5. measure without assuming causation.

Entry criteria: confirm this is a refresh

Proceed only when all of the following are true:

• one canonical URL has been selected for retention;
• its core audience and task remain valid;
• the update can preserve that core intent;
• no unresolved same-intent page requires a merge decision;
• the page can be made accurate and useful;
• a responsible owner and reviewer are available.

Stop and return to the portfolio audit if research reveals duplicate intent, a better consolidation destination, no continuing audience need, or a URL change requirement.

Keeping this boundary matters. A one-page refresh preserves the URL and improves the resource. A merge changes the portfolio and requires redirect, sitemap, canonical, and internal-link decisions across multiple URLs.

Phase 1: collect page-level evidence

Do not edit during the first pass. Preserve a baseline so the team can explain why the update was approved and what changed.

Write the retained-page contract

Complete one sentence:

This page helps [AUDIENCE — READER TO FILL] complete [TASK — READER TO FILL] by providing [OUTCOME — READER TO FILL].

Then record:

• primary and secondary intent;
• necessary content format;
• scope exclusions;
• subject-matter owner;
• conversion or business purpose, if any;
• current canonical URL.

This contract is the guardrail for the refresh. New sections should support it rather than turn the page into several loosely related articles.

Capture search evidence

Use the Search Console Performance report to export page-filtered data with the exact date range, search type, country, and device filters preserved. Review:

• clicks;
• impressions;
• CTR;
• average position;
• queries;
• changes in the mix of queries;
• web, image, video, or news performance where relevant.

Compare suitable periods and account for seasonality, campaigns, outages, migrations, design changes, and analytics changes. Search Console’s chart and table can use different aggregation, so totals may differ. A decline identifies a question to investigate; it does not identify the cause.

If the timing overlaps a broad ranking change, check Google’s core update guidance. Google recommends confirming that the rollout has finished, comparing appropriate periods, reviewing affected pages and queries, avoiding drastic action for small position changes, and assessing sustained large declines more deeply.

Capture technical evidence

Record:

• live HTTP status;
• indexability;
• declared canonical;
• Google-selected canonical, when available;
• sitemap inclusion;
• rendered page and resources;
• mobile usability and page experience issues relevant to users;
• structured data currently present;
• inbound internal links and anchor text;
• broken outbound and internal links.

Use URL Inspection to check how Google sees the page. A technical issue can mimic a content problem; fix the diagnosed issue rather than rewriting unrelated sections.

Build a claim and task inventory

Read the complete page and list:

• every claim that could have changed;
• every step a reader must perform;
• current primary sources;
• unsupported statistics or quotations;
• screenshots, labels, menus, prices, policies, and product names;
• sections that answer the retained task well;
• gaps that prevent task completion;
• repetition and tangents;
• accessibility issues, including inaccurate image alternative text.

Google’s self-assessment asks whether content is substantial, complete, original, trustworthy, accurately sourced, and useful enough for a reader to achieve a goal. Use those questions as prompts for human review, not as a fabricated quality score.

Phase 2: make the update decision

A performance decline does not automatically require a rewrite. Choose the smallest action that addresses verified problems while preserving useful material.

Keep without a content change

Choose this when the page remains accurate, distinct, useful, and technically sound. Record the evidence and a future review trigger. Do not republish or change the date solely because the page was reviewed.

Corrective maintenance

Use this for narrow, verified defects:

• repair a broken link;
• correct a factual error;
• replace an obsolete screenshot;
• clarify a confusing instruction;
• fix a canonical or indexing inconsistency;
• make image alt text describe the current image.

Record each correction. A small correction should not be represented as a complete rewrite.

Substantive refresh

Choose this when the retained intent is still right but the page cannot fully or accurately serve it without meaningful editorial work. Examples include:

• changed procedures or primary-source guidance;
• missing steps or decision criteria;
• outdated examples central to understanding;
• weak organization that blocks task completion;
• unsupported claims requiring verification or removal;
• a title or introduction that no longer describes the page;
• internal links that fail to connect a reader to necessary next steps.

Escalate out of the refresh workflow

Stop when the evidence supports:

• merging a same-intent URL;
• splitting a page into separately useful intents;
• removing an unsalvageable page;
• moving to a different URL;
• legal or expert review beyond the assigned team.

These are governance decisions, not ordinary refresh tasks.

Phase 3: prepare a source-backed refresh brief

The brief should map each problem to evidence and an acceptance test.

Retained URL: [READER TO FILL]
Canonical URL: [READER TO FILL]
Audience: [READER TO FILL]
Primary task and intent: [READER TO FILL]
Baseline date range and filters: [READER TO FILL]
Known confounders: [READER TO FILL]
Verified problems: [READER TO FILL]
Sections to preserve: [READER TO FILL]
Claims to verify, replace, or remove: [READER TO FILL]
Primary sources and access dates: [READER TO FILL]
Missing steps or decisions: [READER TO FILL]
Internal links to add, remove, or update: [READER TO FILL]
Title and description changes, with reason: [READER TO FILL]
Images and alt text changes: [READER TO FILL]
Required expert or legal reviewer: [READER TO FILL]
Acceptance tests: [READER TO FILL]
Owner and target date: [READER TO FILL]

Source requirements should match the topic’s risk. Prefer current primary sources for claims about platforms, laws, standards, products, and official procedures. Preserve access dates and distinguish facts from editorial recommendations.

Phase 4: make substantive page improvements

Preserve the URL and core promise

Keep the established URL when it remains the correct canonical destination. Avoid adding a year to a new URL merely to signal recency. If the URL must change, stop and use a migration or consolidation process.

The title, H1, introduction, and conclusion should describe the retained task consistently. Google’s SEO Starter Guide recommends unique, clear, concise titles and short, page-specific meta descriptions. These help users understand the result; they do not guarantee a particular ranking or CTR.

Correct facts before expanding coverage

For each material claim:

1. locate an appropriate current source;
2. confirm that the claim says no more than the source supports;
3. link contextually where the source helps the reader;
4. remove unsupported precision;
5. record reviewer and access date when governance requires it.

Do not preserve a stale number because it previously attracted links. Do not add invented benchmarks, studies, traffic lifts, or first-person experience.

Complete the reader’s task

Add only what the retained-page contract requires:

• prerequisites;
• ordered steps;
• decision rules;
• limitations and exceptions;
• definitions needed at the point of use;
• verification steps;
• next actions.

Remove repetition and unrelated sections. There is no preferred Google word count; the Starter Guide says content length alone does not matter for ranking.

Improve structure and navigation

Use descriptive section headings, short paragraphs where useful, and direct anchor text. Link to primary sources and to relevant site resources that genuinely help the next step.

For related portfolio design, link to the FACTASH topic cluster strategy. For link placement and anchor decisions, use the FACTASH internal linking strategy.

Review all inbound links that use outdated anchors and all outbound links affected by the revision. Point internal links to canonical URLs. Google’s canonical documentation recommends a self-referential canonical on the canonical page and consistent internal links to that URL.

Update media truthfully

Replace screenshots or diagrams only when they no longer help. Keep alt text concise and descriptive of the actual image in its context. Do not place keywords in alt text that the image does not depict.

If an image is decorative, its implementation should not invent a description. If the image changes, re-check the alt text rather than carrying it forward automatically.

Represent dates accurately

Update the visible modified date only after a substantive revision and only if the date accurately reflects the work. Keep a change log explaining the revision. A review with no substantive change may be recorded internally without presenting the article as newly updated.

Phase 5: run editorial and technical QA

Editorial QA

• [ ] The retained-page contract still describes the finished page.
• [ ] The primary task can be completed from the page.
• [ ] Changed claims are supported by current, appropriate sources.
• [ ] Unsupported facts, fake precision, and stale examples are removed.
• [ ] Preserved sections were re-read in context.
• [ ] The title, H1, introduction, and conclusion promise the same outcome.
• [ ] Links are contextual and useful.
• [ ] Authorship and review information are accurate.
• [ ] The modified date, if changed, reflects substantive work.
• [ ] No ranking, traffic, or CTR outcome is promised.

Technical QA

• [ ] The retained URL returns the intended success status.
• [ ] The page remains indexable when indexing is intended.
• [ ] The absolute self-canonical points to the stable retained URL.
• [ ] Sitemap and internal links use the canonical URL.
• [ ] The rendered page includes the intended content and resources.
• [ ] Structured data, if present, matches visible content.
• [ ] Tracking and conversions still work.
• [ ] Images load and alt text describes the actual assets.
• [ ] No new broken links or redirect chains were introduced.

Phase 6: publish and request recrawling

Record the publication time, final diff, reviewer, and any simultaneous site changes. Verify the live page before requesting another crawl.

For a few updated URLs, an owner or full user can request indexing in Search Console’s URL Inspection tool. For many changed URLs, update and submit the sitemap. Google’s recrawl documentation says crawling can take from days to weeks, repeated requests for the same URL do not make crawling faster, and a request does not guarantee indexing.

Phase 7: measure the retained URL

Measurement should test whether the page and user outcome improved, not manufacture a success story.

Capture the same filters used in the baseline and annotate:

• publication date and time;
• exact editorial and technical changes;
• core updates;
• seasonality and campaigns;
• migrations, templates, navigation, or tracking changes;
• outages or indexing incidents.

Review:

• Search Console clicks, impressions, CTR, average position, and query mix;
• indexing and canonical status;
• conversions or other reader outcomes defined before the change;
• support, feedback, or task-completion signals available to the site;
• crawl, render, structured-data, and link errors.

Use comparable windows and separate search types, countries, and devices where that distinction matters. The SEO Starter Guide says changes can take from hours to several months to appear and recommends allowing time before assessing impact. Google’s core update guidance similarly notes that broader reassessment may take months.

Do not attribute every movement to the refresh. Record “inconclusive” when confounders, limited data, or elapsed time prevent a defensible conclusion.

Reader-fill refresh measurement log

Retained URL: [READER TO FILL]
Baseline window: [READER TO FILL]
Comparison window: [READER TO FILL]
Search type, country, device filters: [READER TO FILL]
Publication annotation: [READER TO FILL]
Substantive changes released: [READER TO FILL]
Concurrent technical changes: [READER TO FILL]
Core update or seasonality notes: [READER TO FILL]
Clicks, impressions, CTR, average position: [READER TO FILL]
Query-mix observations: [READER TO FILL]
Index and canonical verification: [READER TO FILL]
Reader or business outcome: [READER TO FILL]
Errors found: [READER TO FILL]
Conclusion: [IMPROVED | DECLINED | MIXED | INCONCLUSIVE]
Evidence for conclusion: [READER TO FILL]
Next review trigger: [READER TO FILL]
Owner: [READER TO FILL]

A reliable refresh leaves three records: the evidence that justified work, the source-backed changes to one retained URL, and the post-publication measurement with its limits. The modified date is only a truthful label on that work—not the work itself.

schema