Find what your mobile page quietly leaves out
Google indexes the smartphone response and nothing else. We fetch your page as both crawlers and diff them — content, headings, internal links, images, schema, canonical and robots directives — so you can see precisely what is missing from the only version that counts.
The problem no dashboard reports
When mobile-first indexing was rolling out, Search Console told you which crawler was being used for your site and warned about mobile parity. That reporting is gone, because the transition is finished — every site is indexed mobile-first now.
What went with it was the warning. If your mobile template starts dropping a content block, or your schema stops rendering below a breakpoint, nothing tells you. Traffic drifts down over months and gets attributed to an algorithm update.
The check is simple and nobody runs it: fetch the page as both crawlers and see whether they got the same thing.
Structured data
The costliest gap. Rich results are built from the mobile response. Schema on desktop only produces nothing at all, with no error anywhere to explain why the rich result vanished.
Internal links
Mobile navigation assembled in JavaScript is invisible in the HTML. The pages behind it lose their discovery path and their share of internal authority.
Body content
Sidebars, related-content blocks and long-form sections dropped at small breakpoints. If it is not in the mobile HTML, Google does not have it — "it is still on desktop" is not a defence.
Directives
Divergent canonical or robots tags by user-agent. Almost always accidental, and invisible until the page disappears from results.
Test templates, not pages
These failures are almost never page-specific. A product page that drops its schema on mobile drops it on every product page. Run one URL from each template you use — home, category, product, article, location — and you will have covered the site.
Frequently asked questions
What is mobile-first indexing?
Google crawls and indexes your site using a smartphone user-agent, and the page it receives that way is the page it indexes. It is not a preference or a tiebreak — the desktop version is no longer consulted for indexing at all. Google completed the transition for all sites and retired the Search Console reporting around it, which is part of why the problem is now so quiet: there is no dashboard warning when your mobile version starts serving less than your desktop one.
My site is responsive. Do I still need to check this?
Yes, and responsive sites are where the surprises are. Responsive design means one HTML document, which mostly solves the problem — but plenty of frameworks and page builders branch on user-agent server-side for performance, load different modules at different breakpoints, or ship a mobile navigation built entirely in JavaScript. Any of those produces a mobile HTML response that is genuinely smaller than the desktop one. The only way to know is to fetch both and compare, which is what this does.
What is the most damaging difference to find?
Structured data present on desktop and missing on mobile. Rich results are generated from the indexed version, so schema that only exists on desktop generates nothing — and it fails silently, with no error in Search Console and no obvious cause. A close second is internal links: if your mobile navigation is assembled by JavaScript rather than served in HTML, the pages behind it lose their discovery path.
Is content hidden in an accordion a problem?
No. Google has been explicit that content hidden behind tabs, accordions or "read more" controls on mobile is indexed and weighted normally, precisely because collapsing content is a reasonable response to a small screen. What matters is whether the text is in the HTML. This tool reads markup, not layout, so collapsed content counts as present — which is the correct answer.
Why does the tool show fewer words than I can see on the page?
Because it does not execute JavaScript. If your content is assembled in the browser, it will not appear in either column — which is worth knowing on its own. Googlebot does render on a second pass, so a gap here is not automatically a gap in Google's index. It is a gap for every AI crawler, though: GPTBot, ClaudeBot and PerplexityBot do not render JavaScript, so what this tool sees is roughly what they see.
What about separate m-dot URLs?
They still work, but they are the hardest configuration to keep correct under mobile-first indexing — every signal has to exist on both, cross-linked with rel=alternate and rel=canonical, and any drift between the two becomes a ranking problem. If the tool reports separate URLs, that is the finding worth acting on before any of the others. Moving to responsive on a single URL removes the entire class of failure.
Do title and meta description really need to match?
They need to be deliberate. Google uses the mobile version, so a shorter "mobile-optimised" title is simply your title now. The reason a mismatch is worth flagging is that it is almost never intentional — it is usually an artefact of a separate mobile template that nobody has looked at in two years.
Related tools and reading
Template-level problems repeat across every page.
One dropped schema block on a product template is a thousand product pages without rich results. A technical audit finds these once and fixes them once.
Get a Free SEO Audit