Traffic decay content refresher: a lost position and a lost rich result look the same in a chart and need opposite fixes

---
name: traffic-decay-content-refresher
description: Diagnoses a page whose organic traffic has fallen and produces the rewritten page, not a findings list. It separates a genuine ranking loss from a Search Console measurement artefact, such as an average position that improved only because low-ranking impressions stopped happening, and from the traffic cliff a page gets when a rich result type it depended on, FAQ, HowTo, or one of six others, was retired with no ranking change at all. It applies a five-way decision rule, refresh, consolidate into a stronger page, leave alone, remove, or wait for more data, then rewrites the page and records what changed and why. This skill should be used when a page's organic sessions or clicks have dropped and a refresh, consolidation or removal decision needs to be made and carried out, not just diagnosed.
---

# Traffic decay content refresher

## The claim this skill is built on

Most "content decay" advice starts from a diagnosis it never actually performed: traffic on a page fell, therefore the content got stale, therefore rewrite it and change the date. That chain skips the only question that matters first, whether anything about the page's ranking changed at all. A great deal of what gets called decay is a measurement artefact in how Search Console composes its numbers, or a traffic cliff caused by a rich result type Google retired outright, with the page's actual position untouched. Rewriting a page that never lost rank wastes the effort and leaves the real cause, usually a lost visual advantage rather than a lost rank, unaddressed.

The second failure sits inside "freshness" itself. Google documents a real, query-dependent freshness mechanism, but it is not the general ranking signal most refresh advice assumes, and Google names date-changing without substantial change as a negative signal in its own quality guidance. Treating a date stamp as the lever produces the opposite of the intended effect.

This skill runs that diagnosis first, as a decision rule with a real "cannot tell yet" branch, not a checklist that always ends in a rewrite.

## Part one: freeze what decayed before doing anything

Before opening the page, write down exactly what fell, for exactly which window, compared to exactly which prior window. "Traffic is down" is not a claim that can be checked; "organic clicks fell from a 90-day average of 340 a week to 210 a week, comparing the last 12 weeks against the 12 before them" is. Pull three series separately for that window, not one blended number: average position, impressions and clicks, each by week, split by device and by the individual queries driving most of the prior traffic where volume supports it. A single blended session count hides which of the three actually moved, and the fix for each is different.

## Part two: establish whether the decline is real

This is the step most refresh work skips, and it is where the method earns its place. Search Console's average position is not a rank a page holds. Google defines it as the topmost position a property occupied, averaged only across the queries and impressions where it actually appeared: a query returning the page at positions 2, 4 and 6 counts as 2, one returning 3, 5 and 9 counts as 3, and the reported average across both is 2.5. Two consequences follow, and both are exactly where an apparent decline can be nothing of the kind.

**A result with no impression records no position.** If a page's weakest, lowest-ranking impressions simply stop happening, because the query lost volume, a SERP feature now sits above it, or seasonality moved on, the average position calculated from what remains can go up even though nothing on the page or in its rank actually improved, and the same logic runs in reverse for an apparent worsening. Google states plainly that this is the single most common misreading of the metric.

**Position is measured per SERP element, not per link.** A featured snippet, a knowledge panel, a carousel, each occupies one position regardless of how many links sit inside it, and ads occupy no position at all. A page that used to be the only element answering a query and now shares that query's results with a new AI-generated answer, a competitor's snippet, or a knowledge panel can see impressions and clicks fall while its own blue-link rank has not moved. Position 11 does not reliably mean "top of page two"; Google lists several different results, including a knowledge panel's corner, that can produce that same number.

Diagnostic sequence: compare the three series from part one on their own terms; if position held steady or improved while impressions and clicks both fell, the page has not lost rank and the search moves straight to part three's rich-result and query-mix checks. If position genuinely worsened, confirm the movement holds across several consecutive weeks and a real impression base rather than one anomalous week, since Google's own advice is to watch change over time rather than the absolute number, and weekly noise on a low-impression page looks identical to a genuine move until the window is wide enough to tell them apart.

**Decision point.** Real decline: position itself fell and held fallen across a sustained window on a real impression base. Continue to part three to find the mechanism. Artefact only: position held steady or improved while clicks and impressions fell. This is not a ranking problem; go straight to the rich-result and query-mix checks below rather than rewriting anything. Cannot tell: the window is too short, the impression volume too thin to separate signal from noise, or the "before" baseline was itself unstable. Do not force a verdict; note a recheck date and revisit this step once more weeks of data exist.

## Part three: establish the mechanism

Once a real decline, or a click loss without a rank loss, is confirmed, work through the mechanisms below in order; the first two are the cheapest to rule out and the most commonly skipped.

**Mechanism A: a retired rich result.** If the page ever carried FAQPage or HowTo markup, check whether the decline lines up with a retirement date rather than anything the page did. FAQ rich results were restricted to authoritative government and health sites from 8 August 2023, then stopped appearing in Google Search entirely from 7 May 2026, with the documentation removed on 15 June 2026; FAQPage markup today produces nothing. HowTo was removed on mobile first, then fully deprecated on desktop from 13 September 2023, and Google stated explicitly that this was not a ranking change. Course info, estimated salary, learning video, special announcement and vehicle listing markup lost documentation support on 9 September 2025, and practice problem markup was deprecated that November with its documentation removed on 6 January 2026, six further types inside a four-month window. Structured data was never a ranking factor: a structured data violation costs eligibility for a rich result, not rank, and Google frames the feature's benefit as a more clickable result rather than a better one. A page that depended on one of these types for its visual space loses exactly the clicks that space earned, rank untouched, and recovery is unavailable: no amount of fixing the markup brings back a feature that no longer exists.

**Mechanism B: a query-mix or SERP-feature shift with no markup involved.** Even with no structured data on the page, a query can start returning an AI-generated answer, a competitor's snippet, or a larger knowledge panel it did not return before. This produces the same shape of chart as mechanism A, falling clicks and impressions with flat position, but there is nothing to identify on the page itself; the change happened in the results, not the source.

**Mechanism C: a genuine content quality problem, and where freshness is real.** Google documents a real, query-dependent freshness mechanism it calls "query deserves freshness", surfacing newer results where recency is expected: a movie just released, a product just launched, an event still unfolding. That is a property of the query, not a boost every page earns by being recently touched. Google separately names changing a date without substantially changing the content as a sign of search-engine-first content, and answers whether adding or removing content mainly to seem "fresh" helps rankings with "No, it won't." Its rule: give a page a fresh date only when substantially changed, never as a standalone exercise, never with a future date. If the query is genuinely freshness-eligible and coverage is materially behind what currently ranks, that is a real content problem worth a substantive rewrite. If the query is not freshness-eligible, a date-only touch-up will not help and risks reading as the negative signal Google names.

**Mechanism D: a technical drift.** Check whether Google is still choosing the canonical URL the site intends. Canonicalisation signals stack, and Google documents their relative strength: a redirect and a rel=canonical annotation are both strong signals, sitemap inclusion is weak, and specifying nothing is a valid choice that lets Google pick. If a duplicate or parameterised URL has quietly become the chosen canonical, the original's own reported metrics can collapse while the content and its signal sit intact elsewhere. Also check whether the page is still crawlable: a page accidentally blocked in robots.txt is invisible to any noindex placed on it, since the crawler never reads the rule, so it can keep appearing in results with no snippet while genuinely losing its traffic. This mechanism is a handoff, not a rewrite; route it to whoever owns redirects and robots rules.

**Mechanism E: cannibalisation.** If another page on the same site targets overlapping queries, check whether its clicks rose roughly in line with this one's fall. If the combined total held steady, the traffic moved inside the site rather than leaving it, and the fix is consolidation, not a rewrite of the page that lost the internal competition. If the combined total also fell, both pages have a real problem needing its own diagnosis.

**Mechanism F: a policy or reputation issue.** Rare for an ordinary page, worth ruling out on syndicated or heavily scaled content. The site reputation policy, renamed from "site reputation abuse" and still under that current name on the live policy page, applies where third-party content is published mainly to borrow a host site's earned ranking signals; noindexing it does not clear a manual action alone, and moving it to another subdirectory of the same domain does not fix it. As of 28 August 2026, effective 30 August 2026, enforcement diverges by region: outside the EEA a manual action still directly affects the affected section's rank, while inside the EEA that section is instead separated in Google's systems to rank independently over time. Separately, scaled content abuse targets pages generated at scale for the primary purpose of manipulating rankings rather than helping users, whether produced by automation, humans, or both; neither AI production nor volume alone is the violation, the combination of purpose and scale is. Check Search Console's Manual Actions report directly; this kind of demotion looks like ordinary decay from the outside.

One note that recurs constantly here: there is no duplicate content penalty. Google has said so since 2008 and repeats it in its current starter guide with its own scare quotes around the word. The documented risk is dilution, not punishment: when Google cannot detect every duplicate of a page it cannot consolidate their signals into one representative URL, so authority ends up split across weaker URLs instead of concentrated in one. Consolidating two pages concentrates signal; it is not an escape from a punishment that was never real.

## Part four: the decision rule

Work through the branches in order. Each one assumes the diagnosis from parts two and three is already done.

- **Position stable or improved, clicks and impressions fell, and the fall lines up with a rich-result retirement date the page depended on.** Refresh the on-page snippet, opening paragraph and meta description so the answer is compelling without the retired feature's visual space. Do not touch the content structure otherwise, and do not attempt to recover the rich result; the feature no longer exists, regardless of the markup.
- **Position genuinely fell, the query is freshness-eligible, and the page's coverage is materially behind what currently ranks.** Refresh substantively: update what changed, add what is missing, remove what is wrong, and give it a new date only alongside those real changes, never on its own.
- **Position genuinely fell and a sibling page on the site is capturing the same queries, combined total roughly flat.** Consolidate. Redirect the weaker page to the stronger one, since a redirect is a documented strong canonicalisation signal, update internal links pointing at the losing page, and fold anything worth keeping into the survivor rather than leaving a bare canonical tag as the only signal.
- **Position held steady, or the decline is fully explained by an external, uncontrollable factor with no lever left on the page itself.** Leave it alone. Rewriting a page that is not the cause of its own traffic chart spends effort with nothing to show for it.
- **The page now serves no viable query intent, carries negligible external links, and is not needed against cannibalisation elsewhere.** Remove it, using the documented sequence: keep it crawlable, add noindex, wait for recrawl, and only consider a robots.txt disallow afterwards if at all. Blocking it in robots.txt first is the common mistake, since a disallowed page's noindex is never read, leaving it free to keep appearing with nothing but the block to show for the effort.
- **You cannot tell yet.** The window is too short, the impression volume too thin, a core update is mid-rollout, or the baseline was itself unstable. Record the numbers, set a recheck date, and rerun part two then, rather than spending a rewrite on a chart that has not finished telling its story.

## Part five: what the rewrite output actually contains

The deliverable is the revised page, plus a short record that survives the person who wrote it: the metric and window that triggered the review, the mechanism and evidence for it, the branch chosen and why neighbouring branches were ruled out, what actually changed on the page, and the date to check the numbers again.

Two guardrails apply regardless of branch. A date change follows a substantive edit, never a standalone action; a refresh that only bumps the visible date is the exact behaviour Google's guidance names as a negative signal, not a neutral one. And if this method runs across many pages at once, check the volume against the scaled content abuse test first: the policy turns on primary purpose and scale together, so near-identical template edits across hundreds of pages with no real per-page judgement sit closer to what the policy targets than fewer, genuinely reconsidered pages.

## Part six: worked example, compressed

A software company's blog carries a page titled "How to Run a Daily Standup Meeting". Organic sessions fell 40 per cent comparing the last 90 days to the 90 before. The obvious response would be to rewrite it and give it a new date.

Following part one, the team pulls three series instead of trusting the blended session count: average position for the main query held at roughly 4.2 across both periods, essentially unmoved. Impressions fell about 35 per cent, clicks about 40 per cent, roughly in proportion, so click-through rate itself stayed close to flat.

Part two's decision point routes this past a content rewrite entirely: position did not move, so this is the artefact-or-presentation branch, not the real-decline branch. Part three, mechanism A, checks the page's own markup and finds FAQPage schema answering "how long should a daily standup be", added years earlier to win a rich result. Plotting the traffic history against the retirement dates shows the drop beginning close to 7 May 2026, when FAQ rich results stopped appearing in Google Search entirely, well past the narrower 2023 restriction to health and government sites.

**Verdict.** No content rewrite, no consolidation. The mechanism is a retired rich result, not a ranking or quality problem, so the fix is a refresh limited to the intro and meta description, rewritten so the page's own snippet carries the standup-length answer clearly without depending on markup that now produces nothing, plus removal of the dead FAQPage schema since it is harmless but pointless. Recheck the same query set in eight weeks; if clicks recover once the snippet change is recrawled, the diagnosis holds. If not, revisit part three for a mechanism this pass missed, most likely a competitor's own rich result now occupying the space FAQ used to.

## Failure modes

**The date-only refresh.** The visible date is updated with no substantive change underneath it, on the theory that freshness alone helps. Google names this exact behaviour as a sign of search-engine-first content, so the fix reads as the negative signal it actually is.

**Rewriting a page that never lost rank.** A drop in the blended session count triggers a full rewrite without ever checking position separately. Once position turns out to have held steady, the effort solves a problem the page did not have, while the real cause, usually a rich result or a SERP feature, goes unaddressed.

**Chasing rich-result recovery through markup.** FAQPage or HowTo schema is added, re-added, or "fixed" hoping the rich result returns. It cannot: the feature was retired, not misconfigured, and no correct markup brings back a type Google no longer shows.

**The keyword-density or word-count retune.** A rewrite targets a density figure or pads toward a round word count as the fix. Google states directly that it has no notion of optimal keyword density and no word count minimum or maximum for ranking, so neither lever does anything and the rewrite burns effort on an unsupported mechanism.

**Consolidation by canonical tag alone.** Two pages are merged by adding a rel=canonical between them, with no redirect and no update to internal links still pointing at the loser. The weaker page stays crawlable and linkable, so its signal stays split rather than concentrated, since a redirect is the stronger documented signal here.

**The robots.txt panic block.** A declining page is disallowed in robots.txt to "get it out of Google". A disallowed URL is never crawled, so a noindex on it is never read, and the page can keep appearing in results with no snippet at all, which looks worse than the decline it was meant to fix.

**Treating cannibalisation as decay.** One URL's clicks fall and it gets rewritten in isolation, without checking whether a sibling page on the same site picked up the same queries, so the rewrite competes harder against the site's own better performer instead of consolidating traffic onto it.

**Acting on a single week's dip.** A short anomaly, a core update mid-rollout, a seasonal blip, gets treated as a settled decline and rewritten reactively, and because the baseline was never stable there is no way afterward to tell whether a bounce-back or the rewrite produced any recovery.

## What this skill does not do

- It does not pull Search Console or analytics data on its own. It works from an export supplied to it, and a wrong or too-short export produces a confident wrong verdict.
- It does not restructure a rewritten page against current top-ranking competitors. That is a separate job for a SERP-first rewrite once this method has decided a rewrite is warranted.
- It does not implement the redirect, canonical tag, noindex, or robots.txt change it recommends. Those are CMS or server changes for whoever owns that layer.
- It cannot confirm or rule out a manual action or an algorithmic demotion. That sits inside Search Console's own Manual Actions and Security Issues reports.
- It does not replace institutional memory. An analyst who already knows the site's migrations, redesigns and seasonal pattern often sees the cause faster than any method built from numbers alone.