GEO Citation Volatility Tracking

TL;DR

Volatility is not decay. Decay is a downward trend; volatility is high variance around the trend. Confusing the two leads teams to refresh content that is fine and ignore content that is quietly disappearing. Borrow SRE discipline: monitor rolling variance, page on threshold breaches, classify the root cause from a fixed taxonomy, and run a defined stabilization playbook. Without this layer, every weekly dashboard wobble looks like a fire.

Why volatility deserves its own layer

AI engines update underneath you. One published analysis observed roughly 40-60% monthly citation drift across major AI platforms, and a separate study of ChatGPT citations between August and October 2025 reported an 80% expansion in the source pool over that two-month window. Other research noted that traditional Google rankings predict only about 45% of AI visibility and that AI engines typically cite only three to five sources per response—so a small ranking shuffle on the engine side can flip your citation status entirely.

Volatility is also unevenly distributed. One vendor analysis reported a roughly 70x stability gap between frequently and rarely cited domains, with AI Mode showing about 62.4% average volatility while high-authority domains held below 10% volatility across all engines. The implication: the noisier your baseline, the more rigorously you need to filter signal from noise.

Framework overview

1. Rolling-variance metrics on the citation stream.
2. Alerting thresholds at P0, P1, and P2 severities.
3. Root-cause taxonomy with a small, closed list of categories.
4. Runbook — the triage and stabilization sequence.
5. Escalation path — when to escalate to the decay framework or a refresh.

1. Rolling-variance metrics

For each tracked entity — individual citation URL, prompt, query class, engine, or brand — compute a rolling-variance statistic over a fixed window. A 7-day rolling window paired with a 28-day trend baseline is a reliable starting point.

Use Welford's online algorithm or an exponentially weighted moving variance to keep computation cheap. Track at minimum:

• Citation count variance (per URL, per engine).
• Position variance (rank within the engine's cited set when ordered).
• Win-rate variance (per prompt: did the engine cite the brand at all).
• SOV variance (per cohort, see share-of-voice measurement).

Normalize variance against the entity's own 28-day baseline so absolute differences across engines do not bias alerts. A weekly z-score of 2 or higher means "unusual relative to its own history."

2. Alerting thresholds

Borrow SRE practice: define severities once and tune per environment.

• P0 — page: weekly z-score ≥ 3 and a 50%+ citation-volume drop on a tracked top-50 prompt, holding for two consecutive runs. Wakes someone up.
• P1 — ticket within 24h: z-score ≥ 2 on any tier-1 entity, OR engine-wide variance spike across more than 30% of the bank.
• P2 — weekly review: z-score ≥ 1 on tier-2 entities; aggregated and reviewed in the program's weekly meeting.

Do not alert on raw counts. Raw count thresholds generate false positives whenever traffic and prompt mix shift; z-scores against the entity's own baseline are stable.

3. Root-cause taxonomy

Keep the list small and closed. Every volatility event maps to exactly one primary cause:

1. Model update. The engine shipped a new model version (model_version change recorded in tracking).
2. Content edit. Your content changed (publish, refresh, delete) within the window.
3. Competitor move. A tracked competitor published, refreshed, or distributed content (visible in their citation gain).
4. Query drift. The prompt's intent or popular phrasing shifted (visible in PAA changes or community-thread reformulations).
5. Schema change. Structured data, robots.txt, llms.txt, sitemap, or canonical URL changed (visible in your own deploy log).
6. Other / unclassified. Reserved for genuinely unknown causes; these should be a small minority and reviewed at the program level.

Secondary causes are tracked in a freeform field; the primary cause must be one of the six.

4. Runbook

For each P0 or P1 alert:

1. Confirm the alert is real. Re-run the impacted prompts on the affected engine. Single-run noise resolves on replicates.
2. Diagnose by walking the taxonomy in order:
3. Did model_version change? Mark cause = model update; do not refresh content yet, observe for two more cycles.
4. Did your content change? Mark cause = content edit; review the diff against the AI-citable patterns (TL;DR, AI summary, FAQ).
5. Did a competitor publish? Mark cause = competitor move; review their new content and decide whether to expand or counter.
6. Did the prompt's phrasing change? Mark cause = query drift; route to the prompt-bank steward to update the prompt's canonical phrasing.
7. Did schema or robots/llms.txt change? Mark cause = schema change; revert if accidental, validate if intentional.
8. Stabilize: apply the smallest action that restores variance to baseline. Often nothing—volatility resolves on its own when the cause is a model update.
9. Escalate to the decay framework if variance remains elevated for two full reporting windows. Volatility that persists is decay in disguise.
10. Postmortem P0 alerts in the next program review, with cause attribution and any runbook gaps logged.

5. Escalation path

• Volatility resolved within one window → close the ticket, log the cause.
• Volatility persists across two windows → escalate to GEO citation decay tracking framework, advance the entity by one decay tier.
• Volatility coincides with a confirmed engine model update → hold action, observe four windows; many model updates revert citation patterns within a month.

Common implementation mistakes

• Alerting on raw count rather than variance against baseline. False positives every time the program scales.
• Conflating volatility (noise) with decay (trend). Different responses required.
• Skipping the closed taxonomy. Free-text causes make trend reporting impossible.
• Refreshing content reactively on every weekly wobble. Refresh fatigue lowers freshness signal in aggregate.
• Pinning a single global threshold. Tier the thresholds by entity importance.
• Ignoring model_version. Without that field, model-update volatility is misread as content failure.

FAQ

Q: How is volatility different from decay?

Volatility is variance around a trend. Decay is the trend itself. A citation can be volatile but not decaying (noisy but stable on average) or decaying but not volatile (a smooth glide downward). The two require different responses.

Q: Should we always page on a P0 alert?

For program-critical entities, yes. Most teams page only on tier-1 entities (top revenue prompts, branded queries, anchor pages) and ticket everything else. Tune to your team's capacity.

Q: What window should we use for rolling variance?

7-day rolling variance against a 28-day baseline is a reliable starting point. Shorter windows catch model updates faster but produce more false positives. Longer windows smooth too much.

Q: How many root causes should an event have?

Exactly one primary cause from the closed taxonomy, optionally with secondary causes in a freeform field. Multi-primary attribution destroys downstream cause-distribution reporting.

Q: Is model_version really worth tracking?

Yes. Model updates are the most common cause of P0/P1 volatility events. Without model_version, every model swap looks like a content failure and triggers unnecessary refresh work.