Last updated
Why My Mobile Rankings Differ From Desktop
Mobile rankings differ from desktop because Google indexes and scores the mobile render of a page under mobile-first indexing, not the desktop version used in QA. That render then competes under its own device-specific SERP-feature rules, so an unchanged ranking can look like a drop.
A device gap usually means two different pages are competing
A page can hold a strong desktop position and a weaker mobile one for the same query, and the instinct is to treat that as one ranking problem with two symptoms. It is closer to two separate scoring events on two different renders of the same URL, run through two different sets of query-time rules.
This diagnostic isolates the mechanics behind that gap: what mobile-first indexing actually indexes, where mobile templates quietly lose parity with desktop, and how SERP feature selection changes by device. It sits under the broader why your SEO stopped working diagnostic, which covers ranking failures that are not device-specific.
Six reasons mobile and desktop rankings diverge
Each reason below is a distinct mechanism, and a site can hit more than one at once. Name the mechanism before changing templates, navigation, or canonical tags.
Googlebot Smartphone Indexes A Thinner Render Than Your Desktop QA Pass
Since mobile-first indexing became the default, Google primarily builds its index from what the mobile crawler receives, not from what a person reviewing the page on a desktop monitor sees. If the template served to mobile requests strips paragraphs, drops JSON-LD, or trims a comparison table down to a summary line, the indexed version of that URL is the smaller page, permanently, not the fuller one a stakeholder approved in a desktop review.
Every content, schema, or link change needs a mobile-render check before anyone calls it shipped. A change that looks complete in a desktop browser can still ship an incomplete document to the crawler that actually decides what the page is about.
What this looks like: Desktop DevTools shows full copy and schema, but fetching the same URL as Googlebot Smartphone returns a shorter page with fewer words and no structured data.
The Responsive Breakpoint Drops Body Paragraphs Desktop Visitors Still Read
Many responsive builds hide secondary content on small screens for a cleaner layout, and that choice is harmless when the markup stays in the DOM and only its visibility changes with CSS. It stops being harmless when a build removes that markup from the mobile response entirely, or defers it to a script that only runs after a click, because the mobile render genuinely carries less text than desktop at that point.
The test that separates a cosmetic collapse from a real content loss is simple: fetch the raw mobile HTML and check whether the paragraph is present in the source, not whether it is visible on screen. Present-but-hidden still counts. Absent-until-clicked does not.
What this looks like: A pricing table or spec list collapses into a 'view more' toggle under a set screen width, and the rows behind that toggle never make it into the mobile word count.
A Collapsed Hamburger Menu Cuts Internal Links The Desktop Header Still Carries
Internal link equity travels through the links a crawler actually finds, and mobile-first indexing means Googlebot Smartphone’s crawl of the navigation is the one that counts. A page reachable from forty navigation links on desktop but five on a stripped-down mobile menu passes a much smaller internal-link signal into the index, even though the desktop template never changed.
This shows up as deep category or resource pages that look fine in a desktop-spoofed crawl but underperform for real mobile searchers, because the crawl graph that actually built the index never had as many paths leading there.
What this looks like: Desktop's mega menu links to a dozen category and resource pages; the mobile hamburger keeps three, so the mobile crawl finds far fewer paths to deeper URLs.
An m-Dot Subdomain Splits Ranking Signals Between Two Separate URLs
Sites still running a separate mobile subdomain instead of one responsive URL depend on correct, bidirectional canonical and alternate tagging to tell Google the two addresses represent one document. When that pairing is missing, broken, or one-directional, Google can index both URLs as distinct pages, splitting backlinks, content signals, and click history between them instead of consolidating everything around one.
Mobile searchers then land on a version carrying a weaker signal set than the main domain, desktop searchers land on the stronger one, and the two rankings diverge because two different documents are technically competing in two different result sets for the same query.
What this looks like: m.example.com and www.example.com both rank for the same query in different result sets, and neither accumulates the full signal set a single indexed URL would.
The Same Query Triggers A Map Pack On Phones And Ten Blue Links On Desktop
Query-time SERP feature selection is device-aware. The identical keyword can surface a local pack, an image carousel, or a shopping unit on a phone, where local or visual intent is weighted more heavily, while the same text returns a plain organic list on desktop. That is a change in which feature answers the query, not a change in how relevant the underlying page is judged to be.
Comparing “position” across devices without accounting for feature type produces false alarms. The fix is tracking rank by device and by feature type together, so a swapped feature and an actual loss stop looking identical in a report.
What this looks like: A branded local query pulls a map pack and a call button on mobile, then a standard organic list on desktop, and the team reads the mobile view as a lost ranking.
Mobile Field Data Misses The Web Vitals Threshold Desktop Clears Easily
Core Web Vitals field data is collected separately per device category from real visitors, not from a single lab machine. Desktop users on fast connections and capable processors can produce clean numbers on a page that, loaded on a mid-range phone over a slower mobile network, shows layout shift or slow response to taps. Page-experience signals feed into ranking against that per-device dataset, not against the desktop lab result.
This gap usually traces to render-blocking scripts, hero images not properly sized for mobile viewports, or third-party tags that cost noticeably more on a slower mobile processor, all of which a desktop-only performance audit will never surface.
What this looks like: Lab tests run on a wired desktop machine pass every Core Web Vitals threshold, while real mobile users on mid-range phones and slower networks report loading and responsiveness that fail the same thresholds.
How mobile-first indexing turns a crawl into a device-specific result
Crawl, index, rank, and SERP feature selection are four separate stages, and a device gap can originate in any one of them. Understanding the order clarifies which stage actually broke instead of guessing across the whole pipeline at once.
The mobile crawl is the one mobile-first indexing depends on: whatever that crawler parses is what enters the index, what ranking systems score, and what query-time systems later choose a SERP feature for. This crawl-to-feature pipeline sits with the rest of the crawl stack on AEO Tracking, because indexed-render checks and device-segmented Core Web Vitals are measured on the same URLs.
From mobile crawl to a device-specific SERP result
- 01Googlebot Smartphone fetches and parses the mobile render of the page
- 02That mobile render enters the index if it clears the same quality gates as desktop
- 03Ranking systems score the indexed mobile version's relevance and authority
- 04Query-time systems select which SERP feature fits the device and inferred intent
- 05The result surfaces in that feature or loses the slot to a page with stronger mobile signals
| Signal | What desktop shows | What mobile shows | What actually happened |
|---|---|---|---|
| Indexed word count | Full body copy visible on load | Same copy collapsed behind a toggle | Indexing scores the mobile render, and DOM-absent text never counts |
| Internal links found | Mega menu links to a dozen pages | Hamburger menu keeps three links | The mobile crawl discovers fewer paths into the site's link graph |
| URL indexed | www.example.com/page/ | m.example.com/page/ | A broken canonical or alternate pairing splits authority across two URLs |
| Structured data | JSON-LD ships in the desktop template | Mobile template strips schema for weight | The mobile render loses an entity and eligibility signal entirely |
| SERP feature shown | Standard ten-link organic list | Map pack or local pack | Device and inferred intent changed which feature query-time systems selected |
| Core Web Vitals | Lab test on a wired machine passes | Field data on mid-range phones fails | Real mobile conditions decide page-experience eligibility, not desktop lab numbers |
Signs you are looking at a device gap, not a real ranking loss
Each item below is testable with a live fetch, Search Console, or a device-segmented rank tracker. Vague impressions about “mobile feeling worse” are not on this list for a reason.
SIGNS CHECKLIST
0 / 8 checked
How to close the gap between what desktop shows and what mobile scores
Work through this in order: prove what the mobile crawler actually receives, rebuild any parity gap it exposes, then separate genuine ranking loss from a device-specific feature swap before changing anything else.
Prove what Googlebot Smartphone actually indexes
Every fix downstream depends on knowing what the mobile crawler receives, not what a desktop browser renders.
Fetch the page as Googlebot Smartphone and diff it against desktop
Result: You know the exact word-count, link, and schema gap between the two renders before changing anything.
- Curl the URL with a mobile Googlebot user agent and save the raw HTML
- Curl the same URL with the desktop Googlebot user agent and save it separately
- Strip tags and compare word counts between the two files
- Confirm JSON-LD blocks are present in both, not only the desktop file
#!/usr/bin/env bash
URL="https://www.example.com/your-page/"
MOBILE_UA="Mozilla/5.0 (Linux; Android 12; Pixel 6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Mobile Safari/537.36 (compatible; Googlebot/2.1)"
DESKTOP_UA="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
curl -sSL -A "$MOBILE_UA" "$URL" -o mobile.html
curl -sSL -A "$DESKTOP_UA" "$URL" -o desktop.html
echo "Mobile word count:"; sed 's/<[^>]*>//g' mobile.html | wc -w
echo "Desktop word count:"; sed 's/<[^>]*>//g' desktop.html | wc -w
echo "Mobile JSON-LD blocks:"; grep -c "application/ld+json" mobile.html
echo "Desktop JSON-LD blocks:"; grep -c "application/ld+json" desktop.html
Confirm mobile-first indexing is scoring the render you expect
Result: You rule out a stale index or an unexpected split between a mobile subdomain and the main domain.
- Run a live URL Inspection test set to the smartphone crawler in Search Console
- Check whether the inspected URL matches the one you fetched manually
- Note whether Search Console flags a separate mobile-usability issue on this template
- Repeat the check after any deploy that touches this page's template
Rebuild the parity the mobile template dropped
Once the gap is measured, close it in the template, not in a one-off content edit.
Restore collapsed body content and schema at the mobile breakpoint
Result: The mobile render carries the same paragraphs, tables, and JSON-LD the desktop template ships.
- Switch any content-hiding toggle from DOM removal to CSS visibility
- Ship JSON-LD in the initial mobile HTML response, not only the desktop template
- Re-run the fetch diff from step one and confirm word counts converge
- Add a template-level check that blocks deploys where mobile content drops below desktop
Rebuild the internal-link paths the mobile nav quietly cut
Result: Pages that depended on desktop mega-menu links regain a comparable path count on mobile.
- Count links on the mobile navigation crawl versus the desktop navigation crawl
- Add footer or in-body links for category pages the mobile menu no longer reaches
- Prioritize restoring links to pages with the largest mobile-vs-desktop word-count gap
- Re-crawl the mobile template to confirm the missing paths are back
#!/usr/bin/env bash
URL="https://www.example.com/your-page/"
MOBILE_UA="Mozilla/5.0 (Linux; Android 12; Pixel 6) Chrome/120.0.0.0 Mobile Safari/537.36 (compatible; Googlebot/2.1)"
DESKTOP_UA="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
curl -sSL -A "$MOBILE_UA" "$URL" -o mobile.html
curl -sSL -A "$DESKTOP_UA" "$URL" -o desktop.html
echo "Mobile link tags:"; grep -o '<a ' mobile.html | wc -l
echo "Desktop link tags:"; grep -o '<a ' desktop.html | wc -l
grep -oE '<a [^>]*>' desktop.html | sort -u > desktop_links.txt
grep -oE '<a [^>]*>' mobile.html | sort -u > mobile_links.txt
echo "Links present on desktop but missing on mobile:"
comm -23 desktop_links.txt mobile_links.txt
Separate real ranking loss from a SERP-feature swap
The last group confirms whether anything is actually broken, or whether the pipeline just chose a different feature for a different device.
Fix canonical and alternate tags between mobile and desktop URLs
Result: A single URL, or a correctly paired m-dot and main domain, consolidates signals instead of splitting them.
- Confirm the mobile URL's alternate tag points at the desktop URL and vice versa
- Move to one responsive URL if the m-dot subdomain serves no separate purpose
- Check Search Console coverage for both URLs to spot lingering duplicate indexing
- Redirect any orphaned mobile-only URL once consolidation is confirmed
Track rank and Core Web Vitals by device, not as one blended number
Result: Feature swaps and real losses stop looking identical in weekly reporting.
- Segment rank tracking by mobile and desktop for every priority query
- Log which SERP feature type appeared for each device on each check
- Review mobile and desktop Core Web Vitals field data as separate datasets
- Flag a real loss only when position drops within the same feature type
What a mobile-thin render costs your AI visibility score
VISIBILITY INSIGHT
A mobile-thin render lowers entity strength before it lowers a rich-result screenshot
An AI visibility score blends mention frequency, citation share, factual accuracy, entity strength, and competitive share of voice across engines like ChatGPT, Perplexity, and Google AI Overviews. A site with a mobile-thin indexed render scores lower on entity strength and citation share specifically, because the version answer engines actually retrieve carries less proof text and structured data than a desktop reviewer assumes exists. SearchDock checks the render crawlers and AI systems actually receive against the content a desktop QA pass shows, on the same URL. It also tracks citation and mention patterns across engines, so a device-level content gap surfaces before it becomes a visibility gap.
Generate a compliant llms.txtA page that reads thin to a crawler reads thin to an AI answer engine too, regardless of what desktop QA shows.
Related device, ranking, and visibility diagnostics
These spokes cover the site-level and AI-facing symptoms that sit next to a device-specific rank gap.
Fix the render before you fix the ranking
Start with what the mobile crawler actually receives, not with what a desktop review approved. Close any content, link, or schema parity gap the mobile template introduced, then confirm canonical pairing before touching anything else. If desktop rankings are weak everywhere and not just relative to mobile, the wider gap belongs with why your website is not ranking instead of a device comparison. If Googlebot cannot fetch the page at all on either device, that failure belongs with why AI cannot read your website before any device comparison matters.
See whether AI engines read the same page your mobile visitors getFrequently asked questions
Why does my page rank differently on mobile than on desktop?
Google indexes and scores the mobile render of a page under mobile-first indexing, so mobile rankings reflect what a phone-based crawler receives, not the desktop version your team reviews. If that mobile render carries less content, fewer internal links, or missing structured data, mobile relevance signals fall short of what desktop QA suggests they should be.
What is mobile-first indexing?
Mobile-first indexing means Google primarily uses the mobile version of a page for indexing and ranking, instead of the desktop version a person QAs on a monitor. Googlebot Smartphone fetches and parses that render, and whatever it finds becomes the basis for relevance scoring. A desktop-only review can miss content, links, or schema the mobile template quietly drops.
Does having a separate mobile site like m.example.com hurt my rankings?
It can, when the canonical and alternate tags between the m-dot version and the main domain are missing or point the wrong direction. Without that pairing, Google may index both URLs as separate documents and split backlinks, content signals, and click data between them. A single responsive URL avoids that split entirely.
Why does the same search show a map pack on my phone but not on my computer?
Query-time systems select which SERP feature fits the device and the inferred intent behind the search, and local or visual intent gets weighted differently on phones than on desktop screens. A map pack replacing a standard result list on mobile is a feature-selection difference, not proof the page lost relevance. Compare device-segmented rank data before assuming a drop.
Should I check Core Web Vitals separately for mobile and desktop?
Yes. Core Web Vitals field data comes from real users on their own devices and networks, and mobile users on slower connections or mid-range phones often report worse loading and responsiveness than desktop users on the identical page. Page-experience signals feed into ranking per device dataset, so a passing desktop lab test can hide a failing mobile reality.
How do I see what Google actually indexed on my mobile page?
Fetch the live URL with a Googlebot Smartphone user agent and read the raw HTML response, or run a live URL Inspection test set to the smartphone crawler. Compare that output's word count, links, and structured data against what a desktop browser shows. Differences there are exactly what mobile-first indexing scores, whether or not a visitor ever notices them.
Can hiding content in a mobile accordion or tab hurt my SEO?
Content hidden by CSS but still present in the page's DOM is generally still indexed and counted toward relevance. Content stripped from the mobile template entirely, or injected only after a user clicks or scrolls, is a separate problem, because the mobile render being scored never contained it in the first place. Confirm which case applies before you touch the design.