Continuous Refresh and Iteration
Prioritize content refreshes with evidence, make substantive updates, verify results, and turn the full SEO process into a repeatable improvement cycle.
Content decay is the loss of a page’s accuracy, usefulness, visibility, or commercial value as facts, products, competitors, results, and user needs change. It is not simply age: a five-year-old definition can remain correct while a two-week-old pricing comparison is wrong. A content freshness program finds those changes, chooses which URLs deserve work, improves them honestly, and measures what happened.
Phase: P17, Continuous Refresh and Iteration. Stage: D — Measure and Improve. Timebox: 2–4 working days to establish the first prioritized queue, then a weekly triage and monthly or quarterly refresh cycle. Owner: the SEO or content lead is accountable; analysts supply evidence, subject-matter owners verify facts, editors make changes, and engineering owns template or technical fixes.
The archive—the collection of existing indexable pages—is often a larger opportunity than the next article because it already has links, search history, internal routes, and reader behavior. Not every old page needs a rewrite; new production must compete for capacity against evidence-backed improvements to existing assets.
Why this phase, and why here
P17 consumes the operating record from earlier phases: goals and business value, tracking access, technical and performance baselines, AI-agent access, research, the topical map, the content inventory and audit , production briefs, on-page decisions, links, structured entities, citations, conversion tracking , reporting cadence, and annotations. Without them, a refresh decision is usually an opinion about age or a reaction to one chart.
This phase comes last because movement is not diagnosis. A URL can lose clicks because demand fell, a device segment changed, another URL took ownership, a release blocked crawling, or the page became less useful. Earlier phases distinguish those causes. Refreshing before tracking and page ownership are stable can preserve the wrong URL, erase a baseline, or duplicate an intent.
Skipping P17 makes the process a one-way publishing line. Facts age, screenshots diverge from the product, offers expire, sources weaken, internal links point to retired pages, schema repeats stale values, and strong pages slide without an owner. New articles then absorb the budget while the larger archive becomes less trustworthy.
dateModified field, a visible “updated” label, or sitemap lastmod (declared modification date) tells readers and machines that the page was reviewed. If the body, evidence, or user value did not change, leave the date alone. A date-only update violates policy because it publishes a false maintenance record.P17 produces a measured learning record and new priorities. These may reopen one phase for one URL or trigger discovery and goal setting when the business, audience, or product has changed.
Inputs and outputs
| Direction | Item | Why it is needed | Acceptance condition |
|---|---|---|---|
| Input | URL-level performance baseline | A decline must be measured against a known starting point. | Contains URL, query or prompt, device and country where available, clicks, impressions, position, conversions, AI mentions or citations, and a fixed date range. |
| Input | Release and annotation log | Movement cannot be attributed without knowing what changed. | Records content, template, migration, product, campaign, tracking, and major external events with exact dates and owners. |
| Input | Content inventory and page-owner map | A refresh must preserve one clear job per URL. | Every candidate has an index status, canonical URL, intent, business role, owner, and current keep/improve/merge/prune decision. |
| Input | Freshness and factual-risk evidence | Age alone does not reveal whether a page is wrong. | Lists volatile claims, source review dates, product changes, broken examples, competitor publishing activity, and sitemap date coverage. |
| Input | Capacity and service levels | A queue with no delivery constraint is only a wish list. | States available editorial, specialist, design, and engineering capacity plus emergency correction rules. |
| Output | Prioritized refresh queue | Production needs an ordered, explainable worklist. | Every candidate has evidence, a score, treatment, owner, effort class, due date, and reason for its position. |
| Output | Refresh brief and change log | Reviewers need to see what will change and what must be protected. | Records diagnosis, retained strengths, approved changes, sources, screenshots, links, fields, and before-state evidence. |
| Output | Published and verified release | A CMS save is not proof of a successful refresh. | The live canonical page is crawlable, indexable as intended, visually checked, factually approved, and stamped only when the change is substantive. |
| Output | Measurement and learning record | The next decision must not depend on memory. | Compares declared windows, separates confounders, records outcome and confidence, and states keep, iterate, revert, merge, or monitor. |
| Output | Next-cycle trigger list | The final phase must contract with the next cycle. | Names which earlier phase must be rerun, for which scope, by which owner, and by what date. |
The queue contracts with production; the learning record and triggers contract with the next cycle. Neither is complete if someone must reconstruct the evidence from dashboards.
The checklist
1. Build the candidate set from movements, risk, and opportunity
What: Create one candidate list from declining URLs, rising URLs worth reinforcing, stale high-value pages, factual changes, expiring offers, weak conversions, and strategic gaps. Why: A “traffic down” list ignores dangerous facts, weaker conversions, and pages beginning to win. How: compare consistent periods, join search and AI visibility signals to the inventory, add owner-reported changes, and tag each trigger. Keep new, lost, and continuously observed URLs separate because only the last group has a valid prior comparison. Tool: AmICited mover reports, Content Freshness, analytics, conversion data, source register, and issue queue. Done when: every candidate has a canonical URL, trigger, evidence window, segment, owner, and proposed treatment: improve, merge, prune, preserve, or investigate.
2. Verify that the movement is real and comparable
What: Confirm the signal before assigning editorial work. Why: Partial periods, tracking changes, seasonal demand, device mix, migrations, and newly entering URLs can create apparent movement without a page-quality change. How: use complete equal-length periods; inspect absolute clicks, impressions, ranking position , conversions, and query mix; split by device and country; then check annotations, canonical selection, index status, and result-page changes. Tool: AmICited mover reports, analytics, search-platform inspection, release log, and live-result review. Done when: the record states whether the movement is confirmed, inconclusive, or explained externally, and no confirmed candidate relies on a partial period or an entered/left row as a before-and-after comparison.
3. Score and order the queue
What: Apply one visible prioritization rubric. Why: Recency alone favors easy cosmetic work, while traffic alone favors large pages and can ignore factual or commercial risk. How: score each dimension from 0 to 3: business impact, measured performance movement, factual or trust risk, and confidence in the diagnosis. Add the four values for a 0–12 priority score, then assign effort as S (under half a day), M (half to two days), L (three to five days), or XL (more than five days or cross-team). Critical false claims bypass the score. Tool: shared refresh queue, business goals, mover exports, conversion data, and risk register. Done when: 100% of candidates have component scores with evidence, effort, owner, treatment, and due date; score ties are resolved by factual risk, then business impact, then lower effort.
4. Diagnose the cause before choosing the change
What: Write a testable explanation for each selected URL. Why: The same red line can require a technical fix, consolidation, a snippet change, a product correction, a new section, or no content edit at all. How: compare the page’s current job with observed queries and prompts; inspect competing results; test crawlability, rendering, canonicals, speed, structured data, and internal links; review conversion behavior; and list what is still working. State the suspected cause and evidence that would disprove it. Tool: live page, AmICited reports and audits, crawler or inspection tools, analytics, brief, and competitor pages. Done when: the refresh brief contains one primary diagnosis, supporting and contradictory evidence, protected elements, the responsible earlier phase, and a “do not edit” decision when evidence does not support a content change.
5. Define a substantive refresh
What: Specify changes that improve accuracy, task completion, or measurable usefulness. Why: Rewording the introduction, changing a few synonyms, or resetting the date does not address decay. How: correct obsolete facts; replace weak or outdated sources; update product steps and real screenshots; close missing subtopics that belong to the same intent; improve the direct answer, examples, comparison frame, tables, internal routes, accessibility, and conversion path where evidence requires it. Preserve sections and queries that still perform. Create a separate page only when the task or intent is distinct. Tool: refresh brief, source register, current product, content elements, subject-matter review, and page preview. Done when: every proposed change traces to a diagnosed problem, every retained strength is named, every factual change has an approved source, and the editor can explain in one sentence what a reader can do or understand after the refresh that they could not before.
6. Re-run the necessary earlier phases
What: Route the URL through the relevant parts of the playbook again. Why: Decay can originate outside the prose. A content edit cannot repair a blocked crawler, slow template, conflicting canonical, broken entity, missing internal route, or unmeasured conversion. How: reopen only the phases implicated by the diagnosis, but apply their full acceptance gates to the affected scope. Recheck discovery when the business goal changed; technical and agent accessibility after platform releases; research and competitors when intent shifted; the topical map when pages overlap; production and on-page rules for the new draft; links, schema, citations, conversion tracking, and reporting before release. Tool: the earlier phase deliverables and their owners. Done when: every implicated phase is marked passed, not applicable with a reason, or blocked with an owner and date; no failed critical gate is hidden inside an editorial ticket.
7. Publish, verify, and use dates truthfully
What: Release the approved change and verify the live canonical URL. Why: Preview accuracy does not guarantee that the live page renders, links, indexes, measures, or exposes the intended update date correctly. How: compare the live page with the brief, inspect title, headings, sources, media, links, schema, analytics events, canonical and indexability, then record the exact release time. Change the visible update date and machine-readable modification fields only when the substantive-change standard passed. Tool: CMS preview, browser, URL inspection, source view, analytics debugger, and release log. Done when: zero critical factual, crawl, canonical, tracking, or broken-link defects remain; the owner signs the live URL; the change log is attached; and every displayed or machine-readable modification date matches the verified release.
8. Measure the result without rewriting the story
What: Evaluate the refresh against its declared hypothesis. Why: Choosing a favorable range after publication turns measurement into storytelling. How: set windows before release, annotate the change, wait for indexing, then compare equivalent query, URL, device, country, conversion, and AI-visibility segments. Record seasonality, campaigns, result-page changes, tracking incidents, and sitewide releases as confounders. Classify the result as positive, neutral, negative, or inconclusive. Tool: mover reports, analytics, conversion reports, AI visibility tracking, and annotation log. Done when: declared metrics are populated or explicitly unavailable, confounders and confidence are recorded, and the owner chooses keep, iterate, revert, merge, or monitor.
9. Convert learning into the next cadence
What: Update rules, queues, and review dates from what the cycle taught. Why: A successful one-off refresh does not prevent the rest of the archive from decaying, and a failed test has value only if the system remembers it. How: update content-risk classes, volatile-source owners, reusable briefs, page-type rules, trigger thresholds, and capacity allocation. Schedule the next scan and route systemic findings back to the relevant earlier phase. Tool: refresh register, playbook documentation, planning board, reporting calendar, and retrospective. Done when: every released refresh has a next review date, repeated failure modes have a system-level action, the next queue is ordered, and at least one named owner accepts each reopened phase.
Tools in AmICited
AmICited supplies prioritization and movement evidence. It does not decide that a page is wrong or prove that one edit caused a result. Retain the filters, date ranges, exports, and screenshots behind each decision.
| Product view | Use in this phase | Deep link | Evidence to retain |
|---|---|---|---|
| Content Freshness | Compare publishing and update cadence, find large stale directories, inspect sitemap additions and removals, and judge confidence from lastmod coverage. | Open the Freshness audit | Host, directory, date range, URL counts, recently updated share, score components, date coverage, crawl gaps, and export date. |
| Keyword Position Movers | Find queries that improved or worsened between periods and separate movement by device. | Open Keyword Position Movers | Previous and current periods, country, device, impressions, clicks, previous and current position, and entered/left status. |
| URL Position Movers | Find pages and site sections that moved, then connect position change with click impact before opening a refresh ticket. | Open URL Position Movers | URL, section, filters, periods, impressions, clicks, position change, click change, and entry/exit status. |
The Freshness Index is a prioritization signal, not evidence that every old URL needs rewriting. Sitemap dates may be missing or unreliable, and a recent lastmod does not prove a reader-visible improvement. Pair directory-level freshness with URL movement, business value, factual risk, and a live-page review.
Decision rules
These are operating defaults for the refresh program, not claims about search-engine algorithms. Change a threshold only in the written policy, not ad hoc for one favored URL.
| Gate | Bad looks like, in numbers | Required action |
|---|---|---|
| False or unsafe content | 1 known material false claim, expired instruction, unsafe recommendation, or legally required statement is wrong. | Remove or correct immediately; bypass the priority score and obtain specialist approval. |
| Date integrity | 1 visible or machine-readable updated date changes while 0 substantive reader-visible changes are logged. | Block release and restore the truthful date. |
| Evidence completeness | Fewer than 2 complete comparable periods, or 0 baseline captures, support a performance-led refresh. | Mark inconclusive and gather evidence before attributing decline. |
| Period comparability | Period lengths differ by more than 1 day, include partial current days, or cross a known seasonal event without annotation. | Rebuild the comparison or document why it cannot support a causal claim. |
| Freshness confidence | Fewer than 20% of URLs in the inspected host or directory have parseable lastmod dates. | Treat sitemap recency as low-confidence and prioritize only with independent evidence. |
| Priority score | A normal candidate scores 9–12 high, 6–8 medium, and 0–5 low on the declared 12-point rubric. | Work high before medium; a lower score may jump the queue only with a recorded risk or deadline. |
| Queue hygiene | More than 10% of open candidates lack an owner, due date, evidence link, or proposed treatment. | Stop adding candidates and repair the queue contract. |
| Content overlap | 2 or more indexable URLs are assigned the same primary intent and audience without an approved differentiation. | Diagnose merge, redirect, canonical, or intent separation before creating another page. |
| Refresh scope | 0 diagnosed problems map to the proposed edits, or more than 3 material dimensions change without a recorded reason. | Reject cosmetic work; split broad tests where practical or document why combined change is necessary. |
| Release quality | 1 critical broken link, factual contradiction, tracking failure, index block, or unintended canonical remains. | Block or roll back the release. |
| First outcome review | No review is scheduled, or the default comparison is shorter than 28 complete days before and 28 after without a volume or urgency reason. | Set a suitable window and owner before publication. |
| Cadence coverage | A business-critical or fast-changing page has no review in 90 days, or any maintained indexable page has no review in 12 months. | Add it to triage; review sooner when a factual or business event fires. |
“Substantive” is judged by the problem solved, not the percentage of words changed. Correcting one dangerous dosage, price, deadline, or compatibility statement can be substantive. Rewriting 30% of a stable article with synonyms may add no value. The change log must name the reader-visible correction or improvement.
Deliverable: the refresh register
Hand over one versioned register with one row per candidate URL and a linked brief for every selected refresh. A spreadsheet, database, or ticket system is acceptable if it preserves the fields and history.
URL | Canonical | Page job | Owner | Trigger | Evidence window | Affected segment
Business impact 0–3 | Movement 0–3 | Factual risk 0–3 | Confidence 0–3
Total 0–12 | Effort S/M/L/XL | Treatment | Primary diagnosis | Disconfirming evidence
Protected queries/sections | Earlier phases reopened | Approved sources | Change summary
Date before | Date after | Release annotation | QA evidence | Measurement date
Clicks/impressions/position before and after | Conversions before and after
AI mentions/citations before and after | Confounders | Outcome | Confidence
Decision: keep/iterate/revert/merge/monitor | Next review | Status | Exceptions
Preserve previous values rather than overwrite them. The brief must let an editor implement without rediscovering the diagnosis, and the evidence must record the analyst’s filters. Attach live-page verification and any required specialist approval.
What goes wrong
- The team sorts by age. Old durable pages displace recently published pages with false facts or collapsing conversions. Use age as one signal; prioritize business impact, measured movement, factual risk, and confidence.
- A timestamp becomes the deliverable. Someone changes
lastmod, the byline date, and three sentences to make the archive look active. The page is not more accurate or useful, and the maintenance record is now misleading. Block the release under the date-integrity gate. - Every decline becomes a rewrite. A mobile-only loss caused by layout, a canonical change, or lower demand receives an editorial ticket. Diagnose technical, segment, and market causes before touching copy.
- Winners are ignored. A page moving from weak visibility into contention may need one strong example, link, source, or conversion path while momentum is visible. Include rising opportunities in triage without disrupting a page that already satisfies its job.
- The strongest section is deleted. A new brief focuses only on the primary query and removes adjacent coverage that earned links or conversions. Record protected sections and query clusters before editing.
- Two pages are refreshed into the same job. Independent editors broaden both pages until they compete. Reopen page ownership and consolidation before production.
- Everything changes at once. Title, intent, body, template, links, CTA, and schema move together. Isolate hypotheses where practical and annotate combined releases.
- A dashboard score replaces a live review. A stale directory looks urgent, but its pages contain durable reference material; another green directory contains recently date-stamped but incorrect pages. Open representative URLs and verify facts.
- The review window is chosen afterward. The analyst stops at the best week or ignores a campaign. Declare comparable windows and confounders before publication.
- The cycle has no capacity. The queue grows while writers are measured on new output. Reserve recurring capacity for the archive.
Next phase
There is no P18. The next phase is the earliest phase implicated by the evidence. A single obsolete screenshot may return to content production and pre-publish QA. Widespread cannibalization may reopen the topical map and content inventory. A crawler regression returns to the technical and AI-accessibility phases. A new product, audience, market, or revenue model returns to discovery.
The default handoff is a trigger list: scope, observed change, business consequence, evidence, phase to reopen, owner, due date, and acceptance condition. Otherwise monitoring continues until weekly triage, a monthly critical-page review, quarterly archive review, or an event trigger.
This loop is the point of the playbook. Earlier phases create a measurable system; P17 keeps it true as the world changes.
Make the archive earn its next cycle
Start with the Freshness audit to see which directories appear stale, then check URL movement and keyword movement across complete comparable periods. Open the page, verify the cause, and assign one substantive change with a done-when condition.
Build the first refresh queue in AmICited, reserve capacity for the highest-confidence work, and publish an updated date only when the page has genuinely earned it.
More tutorials in this section
Ready to put it into practice?
Free check · 7-day trial · no credit card