Rank tracking and Search Console

Search Console gives you four numbers on the same screen, and they answer four different questions. Most reporting treats them as one story with four chapters, which is how a team ends up rewriting a site because a total moved.

Clicks are people. Impressions are appearances under a reporting rule. CTR is a ratio between them that moves when either one moves. Average position is an average across a set of queries that changes composition every week, whether or not any page moved.

Reading them together is the skill. Reading any one of them alone is the most common source of confident wrong conclusions in the whole discipline.

Segment before you explain. A site-wide total is the least informative number on the screen.

What each number will and will not tell you

Clicks and impressions are also the two that reconcile with something outside Search Console. A click has a corresponding session somewhere, give or take the measurement gap. There is no external check on a CTR or an average position, which means an error in either one can persist in a report for a year without anything contradicting it.

Average position is an average of a mix

This is the number that produces the most false reporting, because it can improve while everything gets worse and worsen while everything improves. It is an average over whichever queries recorded impressions in the period, and that population is never the same twice.

A keyword that falls out of view improves your average. A term sitting at position 47 stops recording impressions. It leaves the population, the average of what remains gets better, and a report says average position improved from 14.8 to 11.9. Nothing improved. A page got worse enough to stop appearing at all.

The same mechanism runs in reverse when a page starts ranking for a batch of harder terms. Every existing query is unchanged or better, the new terms enter at position 30, and the average worsens. That is a page succeeding and a metric reporting failure.

The fix is to compare like for like. Read position for a fixed cohort of queries rather than for whatever the site recorded, and when you do quote a site-wide average, say what population it covers.

Segment before you explain

Horizon's total clicks fall 8% over a period. That number supports no conclusion whatsoever until it is broken apart, and breaking it apart takes about ten minutes.

Segmented, the picture is entirely different: the Austin service cohort is stable, and the whole loss belongs to one seasonal guide, on mobile. That is a specific finding about one page and one device, with an obvious explanation and no site-wide implication at all.

The unsegmented version costs a quarter. Reported as an 8% sitewide decline it produces a site-wide response: a content refresh program, a technical audit, a strategy review. All of it aimed at a site that was not failing, while the actual seasonal pattern repeats next year and gets rediagnosed from scratch.

What the data does not contain

A meaningful share of queries are withheld for privacy, which means query-level totals will not reconcile with the top-line figures and were never meant to. Teams lose hours to this reconciliation every year.

Search Console also counts differently from your analytics. It records appearances and clicks on the result page; analytics records sessions that arrived and executed a script. They will disagree, both are right about what they measure, and a report that presents them as one number is wrong about both.

Establish what each export actually covers

Before any analysis, and before opening a second file, answer four questions about the one in front of you and write the answers at the top of it. Almost every wrong conclusion in this discipline is correct arithmetic performed on data covering something other than what the analyst thought.

The failure this prevents is the worst kind, because it is undetectable in the output. A folder figure quoted as a page figure inflates every number downstream and survives every later check, since the arithmetic performed on it is correct.

Read a period properly

Five steps before any explanation is offered. Explanations produced before step four are guesses with a chart attached.

1. Set a comparison period that means something.Long enough to survive weekly noise, and matched against a comparable period rather than the previous one. Seasonal topics compare against the same weeks last year.
2. Read the four numbers together.Their combination identifies the shape. Any single one is compatible with several causes and will point you at the wrong work.
3. Segment by query, page, country, device, and appearance.Until the change belongs to something specific. A movement that survives every segmentation is genuinely site-wide, and that is rare enough to be worth confirming.
4. Check whether demand, rank, or presentation changed.Three different causes with three different responses. This is the question the segmentation exists to answer.
5. Record the limitations with the finding.Anonymized queries, the comparison window, and any filter you applied. A finding without its scope cannot be checked later and will be misquoted.

A rank tracker and Search Console answer different questions, and running one as a substitute for the other is the core mistake in this lesson. Search Console tells you what actually happened to real people across every query you appeared for. A tracker tells you what a controlled check saw for queries you chose, under conditions you set.

The tracker's value is that control. Same engine, same market, same device, same schedule, which makes two observations comparable in a way first-party data cannot be, because first-party data has no fixed population. Its limitation is that it only ever knows about the queries you put in it.

A tracker is a controlled sample chosen to change decisions, not a census and not a scoreboard.

Five settings define what a tracked number means

Record all five with the cohort. A tracked history whose settings changed midway is two datasets in one chart, and nobody looking at it later will know where the seam is.

Twenty queries, not ten thousand

Module 2 produced a research set of several hundred rows. Almost none of them belong in a tracker. The question for each candidate is whether movement in it would change what you do next, and for most wording variants the honest answer is no.

Horizon tracks around twenty, covering Austin service evaluation, settlement estimation, and branded discovery. Each represents a distinct task, a distinct page group, or a distinct risk. A variant that would move identically to a term already tracked adds cost and no information.

Tag by decision, not by topic. Cohorts should map to the groups you would act on separately: a page group, a market, a strategic risk. Tags that mirror your keyword research produce reports nobody can act on, because the grouping was never tied to a decision.

Write down the expected volatility for each cohort when you create it. Knowing in advance that a cohort routinely swings three positions is what stops a normal week being reported as a movement, and it is far more honest written before the data arrives than after.

The cost argument matters too, and it is the one that usually decides this in practice. Every tracked keyword is a recurring check on a schedule, so a set of four hundred is a standing bill that produces four hundred rows nobody reads. Twenty rows get read every week, which is the only condition under which tracking changes a decision at all.

Design the tracked set

Six decisions. The set should be small enough that somebody reads every row when it moves.

1. Start from approved decisions, not research rows.Only keywords that survived module 2's qualification, each with a target page. A tracker filled from a research export is a bill with a chart on it.
2. Choose one representative query per distinct task.If two candidates would always move together, tracking both buys nothing. Pick the one that best represents the task and note the variants it stands for.
3. Set engine, market, device, depth, and cadence.All five, deliberately, and record them. These are the conditions that make later comparisons valid or meaningless.
4. Add competitors that share the result page.The ones actually appearing for these queries, which module 2 established are frequently not your business competitors.
5. Tag by the group you would act on.Page group, market, or risk. The test is whether a tag would ever cause you to treat its rows differently.
6. Write the expected volatility and the review trigger.How much movement is normal here, and what size or duration of change is worth a person looking. Both are more honest set in advance.

The diagram above separates six causes that all produce the same falling line. This lesson covers what the tracked data adds to that diagnosis, and the two mistakes that survive even when somebody is checking properly.

The tracker's contribution is the competitive picture. Search Console tells you your position moved; it cannot tell you who took the slot or whether the result page changed shape. A tracked cohort with competitors attached shows the movement as a relative event, which is usually what it actually was.

Two URLs on one query is not automatically a problem, and one week of movement is not automatically a signal.

Two URLs on one query is not cannibalization

This is the false positive that generates the most unnecessary work. Two of your pages appear for the same query, somebody calls it cannibalization, and a consolidation project starts. Frequently nothing is wrong.

The test is whether a winner is unstable, not whether two pages exist. Horizon's case-results page holds 86% of the clicks for texas accident settlement examples and won every observed day across 29 days. A second URL appears underneath it. The engine has already chosen, consistently, and there is nothing here to fix.

Real cannibalization looks different: the ranking URL alternates between checks, neither page holds a clear share, and the query's performance is worse than a single well-defined page would achieve. Alternation over time is the signal. Coexistence is not.

Note also what the evidence could not establish. When the last crawl recorded no internal links into the competing pages, anchor-text causes cannot be checked, and that limitation belongs in the finding rather than being quietly ignored.

Volatility is not movement

Results move on their own. A cohort that swings three positions week to week will produce an alarming-looking drop roughly as often as it produces a rise, and responding to each one is how a team spends a quarter reacting to noise.

This is what the expected volatility recorded in the previous lesson is for. A change inside the normal band is not a finding, however uncomfortable the chart looks. A change outside it, sustained across more than one check, and affecting a cohort rather than one query, is worth a person's time.

Duration and breadth beat magnitude. A single query dropping ten positions for one week is usually nothing. Four queries in the same cohort dropping three positions and staying there is a real event, and it is the smaller number that deserves the investigation.

Decompose the gains too, before anybody celebrates

The same discipline applies in reverse and almost nobody applies it. A month that looks unusually good gets reported as growth, and the decomposition that would have taken ten minutes never happens, because nothing appeared to be wrong.

Reported as a single organic clicks number, that quarter reads as a success while the work being paid for was losing. It is the strongest practical argument for the rule that branded and non-branded never appear in the same total.

When the honest answer is no action

Some diagnoses end with nothing worth doing, and recording that is a result rather than a failure. The clearest case is a result-page change: a feature now occupies the space above the first standard result, the click that used to come from position three no longer exists, and no amount of work on your page recreates it.

What that deserves is a measurement of the loss and a decision about where the effort goes instead. Chasing a click that has structurally moved is the most expensive form of activity in this module, because it looks like diligence and produces nothing for as long as anybody is willing to fund it.

Write the no-action decision down with its reasoning. An undocumented decision not to act is indistinguishable from nobody having looked. Six weeks later the same cohort surfaces in the same report, somebody investigates it again from the beginning, and the second investigation reaches the same conclusion at the same cost.

The same applies to a demand change. Fewer people searching is a market fact, and the response is to note it, check whether the demand moved to a different phrasing rather than disappearing, and reallocate. None of that is a page problem and none of it is fixed by content.

Diagnose a tracked movement

Four steps, and the first one stops most investigations before they consume anybody's afternoon.

1. Confirm the movement is outside normal volatility.Against the band you recorded when the cohort was created, sustained across more than one check. Most alarming single-week changes fail this test.
2. Establish the affected cohort and duration.One query or a group, one device or both, one market or all. The breadth of the change is the strongest hint about which of the six causes applies.
3. Read the tracked history beside Search Console.The tracker shows the competitive movement and the result features; Search Console shows what real people did. Neither one alone identifies the cause.
4. Check the target URL and cannibalization properly.Whether the ranking URL changed, and whether a winner is genuinely unstable rather than merely accompanied. Coexistence with a consistent winner is not a finding.

The default SEO report is a dashboard screenshot and a list of what the team did. It answers a question nobody asked, which is what happened to some numbers, and leaves the reader to work out whether anything should change.

A useful report answers three questions in order: what did we observe, what do we think it means, and what happens next. Those are separate things and mixing them is how a report becomes unfalsifiable.

Observation, inference, decision, kept visibly apart. The reader should be able to disagree with your inference without disputing your data.

Three layers, labeled

Observation is what the data directly supports, including its filters and period. Inference is your reasoned explanation, which the evidence supports without proving. Decision is what happens as a result, with an owner and a date.

Horizon's version reads as three sentences. Observed: the Houston cohort lost three positions while demand held. Inference: competitor and result-page changes are more plausible than technical failure, because crawl evidence showed none. Decision: compare local proof and result fit, owner Mia, review after two weekly checks.

The value of separating them is that a reader can accept the observation, challenge the inference, and still evaluate the decision. Blend them into one narrative and any disagreement becomes an argument about whether the whole report is trustworthy.

Lead with the decision

Put the conclusion and the next action at the top, before the evidence. The reader who has thirty seconds gets the thing they needed, and the reader who has ten minutes reads on to check your reasoning.

Reports built the other way round, with methodology first and conclusion last, are written in the order the analyst worked rather than the order the reader needs. That order is comfortable to write and consistently unread.

The smallest evidence view that shows it

One filtered view that demonstrates the specific claim beats six screenshots of dashboards. If the finding is about the Houston cohort on mobile, show that, not the site-wide chart with an arrow drawn on it.

Include the filters in the image or beside it. An evidence view whose scope is invisible cannot be reproduced, and a reader who cannot reproduce it has to take the whole report on trust. Module 1's baseline discipline applies unchanged here.

State what you do not know

Confidence belongs in the report, and so does the alternative explanation you considered and could not rule out. This feels like weakening the argument and does the opposite: a report that names its own uncertainty is far harder to dismiss than one that claims certainty it cannot support.

It also protects the next decision. A team that was told the diagnosis was medium confidence responds sensibly when it turns out to be wrong. A team that was told it was certain treats the same outcome as a failure of the person who reported it, and reports get more cautious and less useful from then on.

Write the report

Seven steps. It should be shorter than the export it replaces and considerably more useful.

1. Open with the decision and the next action.The reader with thirty seconds should leave knowing what changes. Everything after this exists to justify it.
2. State the observation with its scope.The filters, the period, and the comparison. An observation without its scope is an assertion.
3. Label the inference as an inference.Say what you think it means and why, and use module 1's join language. Observed together, plausibly connected, or verified.
4. Show the smallest view that demonstrates it.One filtered chart, with its filters visible. Six dashboards demonstrate diligence rather than a finding.
5. Name the alternative you could not rule out.There is almost always one. Naming it is what makes the rest of the report credible.
6. Separate completed work from pending work.And keep both out of the outcome layer. Shipped is not the same as worked, which is module 1's tree applied to reporting.
7. Assign the owner and the review date.A decision with no date is a suggestion. The date is also what turns the next report into a comparison rather than a fresh start.