A stability gauge for your organic-search presence: it tracks how much your average position moves day to day, so a calm site stays calm and a turbulent one shows up before clicks fall.
At a glance
Ranking Volatility is a time-series measure of how much your Google Search Console average position swings from one day to the next across your tracked query set. It is plotted as a line over the selected period. A flat line near zero means your rankings are stable; a rising or spiky line means positions are churning, which is the earliest behavioural tell that a Google core update, a technical regression, or a content change is reshaping your organic footprint. The card answers “is my SEO stable right now?” before any clicks or impressions card visibly moves.
| What it tracks | Day-over-day movement in average position, aggregated across your query (and page) set. We compute a daily volatility score from the Search Analytics API position metric, dimensioned by date and query, then summarise the spread of position changes into one number per day and plot it as a line. |
| Data source | Google Search Console Search Analytics API (searchanalytics.query), position metric, date plus query dimensions. Positions are the impression-weighted average rank Google reports, not a third-party rank tracker. |
| How the score is built | For each query active on both day D and day D-1, we take abs(position_D − position_D-1). The daily volatility score is the impression-weighted mean of those per-query absolute deltas, so high-traffic queries moving matters more than a long-tail query bouncing. |
| Why it matters | Volatility leads clicks. When Google runs a core or product update, positions churn for days before the net effect on Clicks Trend settles. A volatility spike is your cue to freeze risky releases and watch the recovery, not to panic-edit pages mid-update. |
| Reading the line | Flat and low: stable, business as usual. A single tall spike then a return to baseline: a one-off shuffle (often a SERP-feature change). A sustained elevated plateau: a real reshaping (core update or a site-side change) that is settling into a new normal. |
| Self-inflicted vs external | Cross-reference the timing. Volatility that lines up with a known Google update window is external; volatility that lines up with your deploy log, a migration, or a robots/sitemap change is self-inflicted and actionable immediately. |
| Time window | Trended across the selected period (the dashboard date range). The underlying daily series is what gives the line its shape; default views show the trailing 28 to 90 days. |
| Alert trigger | No hard alert is wired on this card; it is a Sensitivity-class diagnostic you read alongside Ranking-Drop Alert, which carries the paging logic. |
| Roles | owner, marketing |
Calculation
Calculated automatically from your Google Search Console data. The detail backing this card is “Ranking Volatility over time”, and the line is built as follows:- We pull the Search Analytics API with
dimensions = [date, query]and thepositionmetric across the selected period, plus one extra leading day so the first plotted day has a prior-day baseline. - For every query present on both consecutive days, we compute the absolute position change
abs(position_D − position_D-1). A query that moved from 4.2 to 7.9 contributes 3.7; a query that held at 5.1 contributes 0. - Each day’s volatility score is the impression-weighted mean of those per-query deltas. Weighting by impressions stops a single near-zero-traffic query that bounces between page 8 and page 9 from dominating the signal.
- Queries that appear on only one of the two days (genuinely new or genuinely dropped) are excluded from the delta mean so they do not register as infinite movement; they surface instead on Queries Entering Top 10 and Queries Dropping from Top 10.
- The per-day scores are plotted as a single line over the period. Higher equals more turbulence.
Worked example
A UK outdoor-furniture retailer, Google Search Console connected, tracking roughly 1,800 queries that earn impressions in a typical week. The team is watching the volatility line across two weeks in May 26.| Date (dd MMM yy) | Daily volatility score | Avg position | Clicks | What was happening |
|---|---|---|---|---|
| 06 May 26 | 0.18 | 11.4 | 1,420 | Calm baseline, nothing shipped |
| 07 May 26 | 0.21 | 11.3 | 1,455 | Normal noise |
| 08 May 26 | 0.19 | 11.5 | 1,398 | Normal noise |
| 09 May 26 | 0.94 | 11.9 | 1,360 | Google core update begins rolling out |
| 10 May 26 | 1.62 | 12.7 | 1,205 | Churn building, positions reshuffling |
| 11 May 26 | 1.41 | 13.1 | 1,150 | Still turbulent |
| 12 May 26 | 0.88 | 12.4 | 1,290 | Update settling, some recovery |
| 13 May 26 | 0.34 | 12.1 | 1,330 | New normal forming, slightly worse than before |
- Volatility moved first. On 09 May the score jumped from ~0.19 to 0.94 (roughly 5x baseline) while average position had barely shifted (11.5 to 11.9) and clicks were still near baseline. The line gave the team a two-day head start before the click dip on 10 to 11 May. That window is exactly when you want to know “do not push the planned template change this week”.
- The plateau told the team it was external, not self-inflicted. The deploy log was clean across 09 to 12 May, and the spike lined up with a widely reported core-update window. Had the spike instead matched a Friday template release, the read would have been “we caused this, roll back and re-test”, and the team would have paired this card with Pages Losing Traffic to find the affected URLs.
- The settle level matters more than the peak. By 13 May volatility was back near baseline (0.34), but average position settled at 12.1 versus the pre-update 11.4, a small net loss. The correct action was not to react during the turbulent days but to wait for the line to calm, then assess the new baseline against Position Trend and decide whether a targeted content refresh was worth it.
Sibling cards merchants should reference together
| Card | Why pair it with Ranking Volatility |
|---|---|
| Ranking-Drop Alert | The paging companion. Volatility shows churn; this alert fires when the churn resolves into a real, sustained drop. |
| Position Trend | Shows the net direction of average position over time. Volatility says “how much it is moving”; Position Trend says “where it ended up”. |
| Position Change | The query-level breakdown of who moved during a turbulent period. |
| Position Distribution | Shows whether churn is concentrated in your page-1 queries or your long tail. |
| Queries Dropping from Top 10 | The casualties of a volatility spike: queries that fell off page one. |
| Queries Entering Top 10 | The winners of the same shuffle: queries that climbed onto page one. |
| Ranking by Page Type | Helps localise volatility to a template (category vs product vs blog) so you can tie it to a release. |
| Clicks Trend | The downstream impact. Clicks confirm whether the churn cost you traffic or merely reshuffled it. |
Reconciling against the source
Google Search Console has no native “volatility” line: this is a derived metric Vortex IQ builds on top of the daily position series. To sanity-check it against Google’s own tooling: In the Search Console Performance report:- Open Performance → Search results, enable the Average position metric, and set the date range to match the dashboard. Switch the chart to a daily view. A turbulent stretch in our volatility line should correspond to a visibly jagged or stepping average-position line in the native chart.
- Use the Compare mode (for example, the spike week vs the prior week) and sort the Queries tab by position change. The queries with the largest swings are the ones driving our impression-weighted score.
- Query
searchanalytics.querywithdimensions = ["date", "query"]and thepositionmetric for the same window. Reconstruct the per-query day-over-day deltas yourself; the impression-weighted mean of the absolute deltas should match our daily score within rounding. - Remember Google caps each API response at 1,000 rows per request by default, so a full reconstruction of a large site needs pagination via
startRow. Our pipeline paginates; a quick manual check that pulls only the top 1,000 queries will under-count long-tail churn slightly.
| Reason | Direction of divergence |
|---|---|
| Impression weighting. We weight deltas by impressions; an unweighted manual average over-counts long-tail bounce and reads higher. | Manual unweighted reads higher on long-tail-heavy sites. |
| Data freshness. Search Console data is typically 2 to 3 days delayed and finalises over several days, so the most recent 1 to 3 days of the line can move after the fact. | Recent days revise; older days are stable. |
| Anonymised queries. Google omits rare queries to protect user privacy, so a slice of genuine long-tail movement is invisible to both us and the native UI. | Both under-count rare-query churn. |
| 1,000-row UI cap. The Performance report shows at most 1,000 rows per dimension; a manual eyeball of the queries list misses tail movement our paginated pull captures. | Native UI under-counts vs our score. |
| Query set composition. We exclude queries present on only one of the two days from the delta mean (they are “new” or “dropped”, not “moved”). A naive manual calc that treats a missing query as a huge jump reads much higher. | Naive manual calc reads far higher. |