Mobile vs Desktop Google Rankings: Why They Differ, and How to Track Both

A ranking is not a single number. Ask the same site, for the same query, over the same 90 days, and mobile and desktop will disagree. In our own Search Console data the gap reached 11.4 positions on one query, and the direction flipped depending on the query: sometimes mobile ranked better, sometimes desktop did.

That is not a data glitch and it is not a reason to buy a mobile rank tracker. It is a property of how Google builds a results page, and it stays invisible as long as you read a blended average.

This article covers what actually causes the split, what our own numbers looked like, and a short Claude Code workflow that separates the two so you stop making desktop decisions about mobile traffic.

The misconception

The assumption most teams carry, usually without stating it, is that a position is a property of the page. You rank 8 for a query, so you rank 8. Rank trackers reinforce the assumption because they default to one device and print one number per keyword.

The practical consequence is a reporting habit: someone checks a desktop position, writes it in a spreadsheet, and everything downstream treats it as the truth about visibility.

The more useful reality

Two facts, both documented by Google, break the single-number model.

Fact one: the thing being ranked is your mobile page. Google's Search Central documentation states it directly: "Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking." Your desktop HTML is not the primary input, even when the person searching is on a laptop.

Fact two: the results page is built for the device in front of it. Search Console's own help documentation says it plainly, and it is worth reading twice: "Search results are specific to the time, place, device, and recent history of the person searching."

Put those together and the ranking you wrote down is one sample from a distribution that shifts by device. The number is not wrong. It is just narrower than how it gets used.

Why the myth spreads so easily

Four ordinary things keep the single-number model alive.

• Trackers default to desktop. A desktop SERP is cheaper to fetch and simpler to store, so it becomes the default column. Device switching exists on many plans, which is different from being on by default.
• Search Console blends devices. The default Performance report averages across mobile, desktop, and tablet. You have to open the Devices tab, or pull the API with device as a dimension, to see the split. Nothing on the default view warns you that a blend is happening.
• Mobile rank tracking is sold as an add-on. When a vendor lists "mobile rank tracker" as a feature, the implication is that the standard report already covers everything. It covers a slice.
• The effect is invisible on small samples. If you look at ten queries and they all agree, the problem looks theoretical. It becomes visible at the query level, on queries with enough impressions to average.

What our own 90 days showed

We pulled our own Search Console property, 90 days ending September 11, 2026, with query and device as dimensions.

Same property, same window, three different stories. Note that mobile average position is better while mobile CTR is worse.

Two things in that table deserve care.

The first is the reversed signal. Mobile average position was better than desktop (30.8 against 34.4), yet mobile CTR was worse (0.97% against 1.10%). A better position with a worse click rate is normal on mobile: result pages are taller, the layout differs, and the top of the page is crowded with features. Anyone reporting only the position would have called mobile the stronger surface and missed the click gap entirely.

The second is the trap in reading site-wide averages at all. Those two rows summarise different query mixes. Desktop carries 82% of our impressions because our audience is SEO practitioners at desks, and mobile carries a different, smaller set of queries. Site-wide averages hide that. The per-query join is what makes the number actionable.

So we did the join. Of 130 queries with at least 20 impressions, 85 had data on both devices. Here are the six largest divergences.

The gap runs in both directions. "Mobile ranks worse" is as wrong as "a ranking is a ranking".

The direction flips. That is the finding that should change your operating habit: you cannot fix device divergence with a rule of thumb, because there is no consistent direction to correct for. You have to measure it per query.

What to do instead: split, join, threshold, decide

Four steps, about 20 minutes once the workflow exists.

Step 1: pull query and device together. In Search Console, open Performance, add the Devices tab alongside Queries, and export at 90 days. Through the API, request dimensions ["query","device"] with a row limit high enough to hold your query set. The API accepts a row limit well above what a mid-size site needs, so request high and trim locally.

If you already produce a weekly ranking report, this becomes an extra dimension on something you own rather than a new workbook. The report contract in our weekly ranking report workflow has a slot for it.

Step 2: join on the query key. One row per query, with a mobile column and a desktop column. Rows that exist on only one device are a finding in themselves: they mean the query gets impressions on one surface and not the other.

Step 3: apply a threshold before you look. Five positions is a workable starting threshold. Below that, you are reading noise. Above it, you have a query where the two surfaces genuinely disagree.

Step 4: decide per query class, not per query. Money queries get fixed first. Comparison queries usually diverge because the SERP layout differs, not because your page is weak. Brand queries that diverge are almost never an SEO problem. Informational queries can wait.

The Claude Code workflow that does the split

The repeatable part is mechanical: pull, join, threshold, summarise. That is exactly the shape of task that belongs in an agent rather than in your week.

Save this as an instruction file that Claude Code can read, and point it at the property you own:

Pull Search Console data for the property <property> for the last 90 days.
Use dimensions: query, device. Keep only queries with at least 20 impressions.

Join mobile against desktop on the query key.
For every query present on both devices, compute the absolute difference in average position.

Output only rows where the difference is 5.0 or more, sorted by total impressions descending.
For each row show: query, mobile position, desktop position, gap, which device is better,
mobile impressions, desktop impressions.

End with two summary lines:
1. Count of queries where mobile is better, and count where desktop is better.
2. The single query with the largest gap, and its total impressions.

Do not suggest fixes. Do not write content recommendations.
Save the output as mobile-desktop-gap-YYYY-MM-DD.md in the working folder.

Three deliberate choices in that instruction are worth keeping if you adapt it.

It sets a minimum impression threshold, because a query with four mobile impressions produces a position average that means nothing. It forbids fix suggestions, because the decision depends on query class and business context, and an agent guessing at that produces confident nonsense. And it saves to a dated file so you can compare next month's split against this month's, which is the only way to see whether a fix worked.

The prompt is agent-neutral in shape. Codex runs the same instruction through its own file conventions, and the review step is identical.

Guardrails

• Below about 20 impressions, stop. Position averages over a handful of impressions jump by double digits on their own. The threshold in the prompt exists for this reason.
• Tablet is not mobile. Our tablet row had 156 impressions and zero clicks. Grouping tablet into mobile would have made the mobile numbers worse for reasons that have nothing to do with mobile search.
• This article is about measurement, not eligibility. Whether Google can see your mobile content at all is a different problem with different checks. We covered the audit side in Mobile-First Indexing in 2026.
• A better position can be a worse outcome. Mobile ranked better and clicked worse in our own data. Position and click rate need to be read together.
• Do not chase every gap. A 6-position gap on a query with 30 monthly searches is not a project. Rank the list by impressions and let the tail sit.
• Deep positions behave differently. If a query sits past position 100 on both devices, fix the depth problem first. We measured how far Google results actually go in our rank-check depth test.

Auspia view: device divergence is a measurement problem before it is a ranking problem. Most teams have never looked, because the default report hides the split. Once the split is visible, most of the gaps turn out to be explainable and the interesting handful are worth a fix.

FAQ

Does Google rank mobile and desktop pages separately? Effectively yes. Google indexes the mobile version of your content, and the results page served to a phone differs from the one served to a laptop. The two positions come from the same underlying systems, but they are not the same number.

Why is my rank tracker different from Search Console? They measure different things. A tracker fetches a live SERP at one location and device. Search Console averages impressions across all devices, countries, and the whole date range. Both can be right and disagree.

What is a mobile rank tracker and do I need one? A mobile rank tracker fetches the smartphone SERP for a keyword set. It is worth paying for if you need competitor positions or locations you cannot see in your own data. If you only need your own site's mobile visibility, Search Console already has it, split by device, at no cost.

How many impressions before device-level position is reliable? Around 20 is the working floor for a rough read; 100 or more is where the number stops moving week to week. Below 20, keep the query in the list but do not act on it.

Can Claude Code read Search Console directly? Yes, through the Search Console API with a service account or OAuth credentials. The workflow above assumes that connection exists. Our SEO agent guide covers which ranking tasks are worth handing to an agent and which are not.

Should I fix the mobile page if mobile ranks worse? Check the SERP first. If the mobile results page carries more video, more local packs, or a different mix of page types, the fix is content format rather than page quality. If the SERP shape matches and the page is fine, treat it as a content parity problem and audit against the mobile-first checks.

Author: Marcus Ellery, Growth Experimenter Behind 150+ SEO Tests at Auspia. Marcus writes about benchmark data, controlled tests, and the difference between a metric moving and a metric meaning something.