Mobile-First Indexing: The Complete Audit

Evergreen playbook

Mobile-First Indexing: The Complete Audit and Recovery Playbook

Google has crawled and ranked on the mobile version of your pages since mobile-first indexing completed its rollout in October 2023. Most sites still leak rankings through the same handful of parity gaps, quietly, between named algorithm updates rather than because of them. This is the audit that finds and fixes those gaps — the mechanism-level checklist, not a reaction to whatever update is in the news this week.

Most mobile-first indexing problems don’t arrive with a headline. They arrive as a slow bleed in impressions over a few months, and by the time someone notices, it’s tempting to blame whatever named update happens to line up with the timing. The more useful — and more common — explanation is structural: your mobile page is quietly thinner than your desktop page, and Google has been ranking off the thinner one the whole time. That’s the problem this playbook is built to find and fix, independent of any single update.

What mobile-first indexing actually is

Strip away the update speculation and the underlying mechanism hasn’t moved much. Google’s own crawling and indexing documentation still describes the same core rule it’s used since the rollout finished in October 2023: Google indexes and ranks primarily on the mobile version of your page, crawled with a smartphone user agent. If your mobile page has less content, fewer internal links, thinner structured data, or lower-quality images than your desktop page, Google is working from the weaker version — not “also considering” the stronger desktop one as a backup.

That single fact is still the most common way sites quietly lose ground without ever seeing an update in the news. Nobody announces “your mobile FAQ accordion hides half your content from the crawler” — you just watch impressions erode over a few months and blame the next named update that happens to line up with the timing.

The mobile-first audit

This is the version of “what to do” that works regardless of what’s showing up on ranking-volatility trackers this week, because it’s just good practice against the indexing mechanism itself — run it quarterly, not just when something feels off.

1. Confirm parity before you diagnose anything

• Pull a live mobile render via Search Console > URL Inspection > View Crawled Page. Compare the rendered HTML line-by-line against the desktop source for your top 20 landing pages. Look for missing paragraphs, trimmed product descriptions, or FAQ sections that exist in desktop source but not in the mobile render.
• Run the same URLs through Google’s Rich Results Test using the mobile user-agent toggle. Verify that Article, FAQPage, HowTo, Product, and BreadcrumbList schema are present and identical to the desktop version. If schema is injected via JavaScript, confirm it fires in the mobile render, not just desktop.
• Use Screaming Frog (or Sitebulb) with the user-agent set to Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Mobile Safari/537.36 and viewport set to 360×640. Crawl your top 200 pages and export the “Rendered HTML” view. Diff this against a desktop crawl to spot missing content blocks.
• Check whether accordions, tabs, or “read more” toggles hide text from the initial DOM on mobile rather than just visually collapsing it. If the content is absent from the rendered HTML until a click event, Google may not index it. Use display:none or visibility:hidden sparingly for critical content; prefer height:0;overflow:hidden with an ARIA toggle if you must hide it visually, but keep it in the DOM.
• Compare internal link counts between the mobile nav/footer and the desktop equivalents — hamburger menus are the single most common place links quietly disappear. Count hrefs in the rendered mobile HTML vs. desktop HTML for the same page. A drop of more than 15–20% is a red flag.

2. Separate real ranking loss from reporting noise

• Check Google’s Search Status Dashboard first, every time. If there’s no logged incident for your date range, you’re not analyzing a named update — you’re analyzing something else (seasonality, a SERP feature change, a tracking bug, a site issue).
• Compare Search Console clicks and impressions for the same weekday ranges before and after any date you suspect, not raw week-over-week, to avoid weekday traffic-pattern noise. Use 28-day or 91-day ranges for cleaner statistical baselines.
• Segment by device in Search Console. A drop that’s mobile-only points you straight back to parity and Core Web Vitals rather than generic content quality. If desktop is stable while mobile drops, you have a mobile-specific problem, not a broad quality update.
• Don’t assume two nearby volatility events share a cause. In October 2023, Google clarified on its blog that unconfirmed fluctuations reported by the SEO community can be unrelated to subsequent confirmed updates — match dates to the dashboard’s actual incident window before drawing a line between them.

3. Fix the mobile-specific things that actually move the needle

• Run PageSpeed Insights on mobile specifically — it pulls real Chrome User Experience Report (CrUX) data alongside lab results, which desktop scores won’t show you. Look at the “Origin” tab in CrUX to see if your whole domain is failing INP or LCP on mobile.
• Prioritize Interaction to Next Paint (INP) fixes on any page with heavy third-party scripts (chat widgets, ad tags, consent managers, A/B testing frameworks) — these disproportionately hurt mobile. INP officially replaced First Input Delay (FID) as a Core Web Vital in March 2024. A mobile INP above 200 ms needs attention; above 500 ms is a severe user-experience penalty.
• Audit your Largest Contentful Paint (LCP) on mobile. Hero images served via srcset should not load a 1600 px wide asset into a 360 px viewport. Use responsive images with sizes attributes, and preload the mobile LCP candidate with <link rel="preload" as="image" imagesrcset="..." imagesizes="..."> where appropriate.
• Re-test Cumulative Layout Shift (CLS) after any redesign that changes how ads, images, or embedded widgets load on narrow viewports. Reserve space with min-height containers for dynamic content (ad slots, cookie banners, recommendation widgets) so the page doesn’t jump when they inject.
• If you serve dynamic content by device, verify the Vary: User-Agent HTTP header is set correctly so Google (and CDNs) don’t cache the wrong version. If you use a CDN like Cloudflare or Fastly, ensure your cache key includes the user-agent variant, or you risk serving desktop markup to Googlebot smartphone.

Tools to run this audit at scale

Below is the exact tool stack that makes this playbook practical for sites with more than a few dozen pages. You don’t need all of them, but you need at least one crawler and one speed tool.

When not to act

The most honest thing this article can tell you is when to do nothing. If your rankings dip for a few days with no Search Status Dashboard entry, no device-specific pattern in Search Console, and no site change you made recently, the correct move is to wait. Google’s own core update guidance is blunt about this: a negative ranking impact doesn’t automatically mean something is wrong with your pages, and there’s no specific action to take to “recover” from ordinary volatility. Chasing every SERP fluctuation with structural changes is how sites end up making their mobile experience worse trying to fix a problem that was never there.

Where mobile fits into Google’s broader quality signals

Core Web Vitals — measured from mobile Chrome usage data first — remain part of the page experience signals Google has confirmed factor into ranking. Sites with weak mobile Interaction to Next Paint or Cumulative Layout Shift scores don’t get a separate “mobile penalty” line item, but they do enter every broad quality re-evaluation carrying a real UX handicap that compounds with any content-quality gaps a wider update also catches.

That’s the throughline worth remembering: mobile-first indexing itself is stable and well-documented since its October 2023 completion; what varies is how often the rest of Google’s ranking systems re-check the parity and performance gaps this audit is built to close. A page with perfect desktop content and broken mobile parity is still a broken page in Google’s index. Run this audit quarterly. Document your baselines. Fix parity before you chase updates.

Frequently asked questions

Sources and further reading