Google’s indexing and rankings have been based on the mobile version of pages for a long time now. However polished your desktop site is, if the mobile version is missing content, buttons don’t respond, or loading stalls, rankings still drop — and they drop with no warning at all.
The core of mobile-first indexing boils down to one sentence: the mobile version must be as complete and as usable as the desktop version. Run through the four categories totaling 9 checkpoints — content parity, readability and tappability, media and performance, and structured data — and most mobile-driven traffic drops can be caught in advance.
- Content parity (checkpoints 1–3): the mobile version must include all body text, images, and tables from desktop; keep in-body internal links and breadcrumbs; output title, meta, and canonical unchanged.
- Readable and tappable (checkpoints 4–6): body font no smaller than 16px, tap targets no smaller than 48×48px, a viewport tag present, no horizontal scroll at 375px width, and no intrusive interstitials above the fold.
- Media and performance (checkpoints 7–8): serve images via srcset sized to the screen width with explicit width/height, mobile LCP under 2.5s, INP under 200ms, CLS under 0.1, and defer third-party scripts until after onload.
- Structured data and ongoing monitoring (checkpoint 9): Article, Breadcrumb, and FAQ markup must also appear on mobile; verify with the rich results test using mobile fetch; and fold all 9 items into the pre-launch checklist.
First confirm mobile and desktop content parity
The most common and most damaging problem is content shrinkage. To make pages look cleaner on phones, many sites stuff body text into accordions or cut out related-article modules and breadcrumbs entirely — and the mobile version the crawler gets is a big chunk smaller than desktop, so long-tail pages lose their entry points.
Checkpoints 1–3: content, internal links, meta info
- Complete body text: the mobile version must include every paragraph, image, and table from desktop. Collapsible areas can be closed by default, but they must exist in the HTML — not fetched asynchronously only after a user click
- Internal link parity: sidebars can be trimmed, but in-body links and breadcrumbs must remain. Use Search Console’s URL Inspection tool to view the rendered HTML and simply count the link numbers on both ends
- Consistent meta info: title, meta description, and canonical output unchanged on mobile — don’t lose or rewrite them when the template switches
Here’s a quick way to tell: crawl the rendered snapshot of both ends and compare plain-text word counts. A gap over 20% is a strong sign that content is hidden or lazy-loaded — then you just need to locate which block it is.
Bring readability and tappability up to passing grade
This layer needs no complex tooling — flipping through on a real phone surfaces most of the problems. Text too small to read, buttons too close together causing mis-taps, and pages that drag sideways all directly hurt how often users complete actions, and they count toward experience signals.
| Checkpoint | Passing standard | How to verify |
|---|---|---|
| Body font size | No smaller than 16px, line height 1.6+ | Read a passage on a real device without zooming |
| Tap targets | No smaller than 48×48px, 8px+ spacing | Lighthouse tap-target detection |
| Viewport setting | viewport meta tag present | Check page source |
| No horizontal scroll | No sideways scroll at 375px width | Device emulation plus real-device double check |
| No intrusive interstitials | No fullscreen popup covering the first screen | First visit in an incognito window |
The first three rows above correspond to checkpoints 4–6; the last two are baseline requirements in the same category. One more note: low-end Android phones often have a visible width of only 360px, narrower than 375px. Test both widths so edge cases don’t slip through — long tables and code blocks are especially prone to bursting their containers here.
Media and performance are the real mobile bottleneck
Phone networks are unstable and CPUs are weak — a page that opens in 1.2s on desktop can take 4s on a mid-range Android. The LCP element on mobile is usually the hero image or big heading, so compressing above-the-fold resources gives the most direct payoff.
- Checkpoint 7: serve images with srcset plus sizes sized to the screen width, and set explicit width/height on the hero to prevent layout shift; videos should not autoplay or force fullscreen
- Checkpoint 8: keep mobile LCP within 2.5s, INP under 200ms, CLS under 0.1
- Inline critical CSS so first-screen styles don’t depend on external requests and weak networks don’t show a long white screen
- Defer third-party scripts — customer service, analytics, ads — uniformly until after onload so they don’t compete for above-the-fold bandwidth
For metric definitions and optimization order, cross-reference the Core Web Vitals practical guide; if the bottleneck lands on image size and caching strategy, the moves in the site speed trio apply almost verbatim — no need to re-invent the wheel.
Don’t let structured data and ongoing monitoring lag on mobile
Checkpoint 9: Article, Breadcrumb, and FAQ markup must also be output on mobile. Many themes use a separate codebase for the mobile template, so schema that’s perfectly marked up on desktop vanishes on phones — and the rich snippet goes with it. Use the rich results test with mobile fetch and confirm item by item.
Mobile-first is not a one-time project. Changing a theme, installing a plugin, or adding a snippet of customer-service code can reintroduce horizontal scroll or popups. Put these 9 items into the pre-launch checklist and run them alongside other technical checks, so you don’t step in the same hole three times.
- Before every release, run Lighthouse in mobile mode and archive the report so you can trace which change introduced a problem
- Preview new blocks at both 360px and 375px widths before merging into the main branch
- Once a quarter, walk the core paths end-to-end on a real device — emulators can’t measure touch feedback and scroll inertia
- Set Search Console’s experience-related reports to weekly review, handling curve anomalies the same week
When it comes to execution, the rhythm isn’t complicated: first use the URL Inspection tool to compare the mobile and desktop rendered HTML of a key article and confirm body text and internal links haven’t shrunk; then open the homepage and an article on your phone under 4G and note the jank points and mis-tap spots; turn the 9 checkpoints into a table and assign owners on the frontend and content sides; fix hidden content and undersized tap areas first since they hit rankings and conversions most directly; and finally attach the checklist to the release flow as a mandatory gate rather than an option. Mobile experience is a game where flipping through on a phone solves half and the checklist solves the other half — do both, and rankings basically won’t be dragged down by mobile.
FAQ
What is mobile-first indexing?
Google crawls, indexes, and ranks based on the mobile version of pages, so the mobile version must be as complete and usable as desktop. Shrunken mobile content or unresponsive buttons drop rankings directly.
How do I tell if mobile content is hidden?
Crawl the rendered snapshots of mobile and desktop and compare plain-text word counts. A gap over 20% strongly suggests hidden or lazy-loaded content — then you just locate which block it is.
What font size should mobile body text use?
Body text no smaller than 16px with line height 1.6+; tap targets no smaller than 48×48px with 8px+ spacing; a viewport tag present; and no horizontal scroll at 375px width.
What’s a passing mobile LCP?
LCP under 2.5s, INP under 200ms, CLS under 0.1. Compressing above-the-fold resources pays off most directly; on mobile the LCP element is usually the hero image or big heading.
Can mobile lose structured data?
Yes. Many themes use a separate codebase for mobile, so schema marked up on desktop vanishes on phones. Use the rich results test with mobile fetch and confirm item by item.
Figure: Mobile-first indexing: 9 checkpoints for mobile experience — key points (compiled by Operations GO)
