Mobile-First Indexing: A Readiness Checklist for Your Site

Since 2024, Google has completed the rollout of Mobile-First indexing for every site without exception. The crawler now evaluates your site exclusively through the lens of its mobile version. If the mobile version shows less content, has different meta tags, or loads slower — that is exactly what Google sees when ranking your pages. According to Statcounter, mobile devices account for over 60% of global web traffic in 2025.

This guide covers everything from a baseline checklist through technical viewport details, m.site pitfalls, testing strategies, mobile speed, and what's changing in 2025–2026. Every section is actionable, not advisory. Mobile-First readiness is a core part of a solid SEO promotion strategy.

What Mobile-First Indexing Is and Why It Matters

Before 2016, Google indexed sites using a desktop Googlebot — the mobile version was secondary. From 2016, Google began gradually switching sites to Mobile-First: selectively at first, then at scale. By 2024 the transition was complete — every site in the index is evaluated exclusively by the mobile bot. Official documentation: Google Mobile-First Indexing.

The practical implication: if your mobile version hides content blocks behind tabs or accordions, Google sees them but may assign them less ranking weight compared to visible text. If the mobile version redirects to a separate m.site, there's a risk of content and meta tag discrepancies between versions.

Checklist: Viewport and Responsive Design

1. The viewport meta tag is present on every page. <meta name="viewport" content="width=device-width, initial-scale=1"> is mandatory. Without it, the browser renders the page at desktop width and scales it down.
2. Don't block user scaling. user-scalable=no and maximum-scale=1 are bad accessibility practice (WCAG 1.4.4). Let users scale the page.
3. Responsive CSS, not a separate subdomain. m.domain.com is outdated architecture. Responsive design on a single URL is the standard — and what Google recommends.
4. Touch targets at least 44×44 px. Touch areas smaller than 44px are a common cause of poor mobile engagement metrics. Lighthouse flags this as a separate audit item.
5. Body text no smaller than 16px. Text below 12px requires zooming — Google penalises readability scores accordingly.

Checklist: Content on the Mobile Version

1. All main content is accessible without JavaScript. Use the "View as Google" test in GSC to verify what Googlebot actually renders.
2. Content in tabs and accordions is indexed. Google can read content in hidden tabs, but in practice it may receive less ranking weight. Keep key content visible where possible.
3. Meta tags are identical on mobile and desktop. Title, meta description, canonical — must match exactly.
4. Structured data (Schema.org) is present on the mobile version. Rich snippets configured only for desktop won't be seen by Google under Mobile-First.
5. Images on the mobile version have alt attributes. Images without alt lose a relevance signal that the mobile bot reads just like the desktop bot.

Checklist: Technical Parameters

Checklist: Mobile Page Speed

Mobile devices have on average half the bandwidth and four times less CPU power compared to desktop. Mobile speed optimisation is a distinct task from desktop — the same techniques don't always apply with the same priority.

1. Use srcset and sizes for responsive images — don't load 1200px images on 375px screens.
2. Test LCP and INP via PageSpeed Insights with mobile emulation (Google uses Moto G Power as the benchmark device).
3. Avoid render-blocking fonts — no more than 2 weights, woff2 only, font-display: swap.
4. Confirm desktop-only styles and scripts aren't loading on mobile — use conditional loading via media queries or dynamic import.

Technical Mobile Optimisation Deep-Dive

Viewport meta tag: correct vs incorrect syntax

The correct version Google expects:

<meta name="viewport" content="width=device-width, initial-scale=1">

Common mistakes:

• content="width=320" — fixed width, doesn't adapt to different devices
• content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no" — blocks zoom, violates accessibility (WCAG 1.4.4)
• Missing viewport entirely — browser defaults to 980px viewport, page looks like a shrunken desktop version

Touch targets: minimum 48×48 px

Google recommends a minimum of 48×48 CSS pixels for any interactive element. If the element itself is visually smaller, increase the tap area through padding, not the element size itself:

button { padding: 12px; } /* total tap area: 24 + 12x2 = 48px */

Lighthouse checks this under "Tap targets". The typical problem: navigation menus with 32px-height items and minimal spacing.

Font-size minimum 16px for body text

This is a ranking factor, not just UX guidance. GSC Mobile Usability reports "Text too small to read" when main content font-size drops below 12px. Best practice: set font-size: 16px on the html element and use relative units (rem) for everything else. This ensures browser zoom and accessibility scaling work correctly.

Horizontal scroll: overflow-x:hidden

"Content wider than screen" is one of the most common GSC Mobile Usability errors. Causes:

• Element with fixed pixel width wider than viewport (e.g. width: 1200px without a media query)
• Table without horizontal scroll wrapper
• Image without max-width: 100%
• Absolutely positioned element extending beyond its parent

Setting body { overflow-x: hidden; } hides the symptom but doesn't fix the cause. Find the offending element in DevTools and fix its CSS. Check by toggling Device Toolbar and looking for a horizontal scrollbar.

Tap delays on iOS: the 300ms issue and how to remove it

iOS browsers and older Android Chrome had a 300ms delay before processing a tap — time to determine if it was a double-tap zoom gesture. The CSS fix:

* { touch-action: manipulation; }

This disables double-tap zoom and eliminates the 300ms delay. Modern browsers (Chrome 32+, iOS 13+) already remove the delay when viewport is set correctly with width=device-width, but touch-action: manipulation guarantees the result on older devices.

Interstitial ads and Google's penalty

Since 2017, Google demotes pages where a pop-up covers the main content immediately after a user arrives from search results on mobile. The penalty targets the moment of arrival from search — not every pop-up on the site.

Permitted pop-ups:

• Age verification (alcohol, adult content)
• Cookie/GDPR consent banner
• Login gate for paywalled content

Penalised pop-ups:

• Email subscription offer immediately on landing from search
• Advertisement covering the full content before interaction
• Promotional banners occupying more than 15–20% of screen height

The classic case: an e-commerce store with a "-10% discount for newsletter signup" pop-up appearing 1 second after page load on mobile. Moving the trigger to 30 seconds of engagement or exit intent removes the demotion at the next crawl.

Mobile vs Desktop Version: Architectural Traps

Separate m.site — the risks

The m.site architecture (e.g. m.example.com) was standard until 2014–2015. Today it carries serious SEO risks under Mobile-First:

• Canonical confusion. If canonicals on mobile pages point to m.site rather than the main domain, Google may treat the mobile URL as the canonical version. Correct setup: canonicals on mobile pages point to the desktop URL.
• Content divergence. Mobile versions tend to accumulate "trimmed for convenience" content over time. Under Mobile-First, trimmed content is the content Google ranks.
• hreflang synchronisation. If you have language versions, hreflang must be duplicated on both versions. One missing tag breaks the entire chain.
• Double crawl budget spend. Google crawls both m.site and the main domain — doubled crawl budget spend with zero SEO benefit.

Dynamic serving (Vary: User-Agent)

Dynamic serving returns different HTML for mobile and desktop Googlebot on the same URL, using the Vary: User-Agent response header. Google officially supports this approach, but recommends responsive design as simpler and more reliable. Key pitfall: CDN and proxy servers can cache the wrong version without explicit Vary: User-Agent support configuration.

Hidden content on mobile and its indexing impact

Content with display:none is technically accessible to Googlebot but may receive less ranking weight. If content is hidden on mobile but visible on desktop — under Mobile-First, Google evaluates the hidden version. Accordions and tabs are an understood pattern — Google generally indexes content inside them.

Testing Mobile Optimisation

GSC Mobile Usability report — common errors explained

Google Mobile-Friendly Test — current status

The standalone Mobile-Friendly Test tool is effectively deprecated. Google integrated mobile readiness checks into Rich Results Test and URL Inspection. In 2023, Google confirmed that "mobile-friendly" is no longer a standalone ranking signal — it's absorbed into Core Web Vitals and Mobile Usability criteria.

Use instead:

• GSC → Experience → Mobile Usability (site-wide audit)
• GSC → URL Inspection → Test Live URL (per-page check)
• Lighthouse in Chrome DevTools (local development)

Chrome DevTools Device Mode and real-device testing

DevTools Device Mode is a starting point, not a final test. For speed testing, use Lighthouse with the "Mobile" preset — it applies CPU throttling (4x) and network throttling (slow 4G) to simulate real conditions. For real-device testing, the minimum set is one budget Android (2–3 years old) and a mid-generation iPhone. The gap between emulator results and real Moto G Power results is routinely 15–20 PageSpeed points.

The emulator shows responsive CSS behaviour but cannot reproduce real mobile CPU constraints, memory pressure, or genuine network latency. Test on hardware — especially for critical user flows: homepage load, product page, checkout.

Speed on Mobile

Why mobile loads slower

Three structural reasons:

• Network. Average 4G speed is 30–40 Mbps in ideal conditions, but drops to 3–5 Mbps in buildings, transit, or congested areas. 4G latency is 30–50ms — 2–5x higher than WiFi.
• CPU. Google's benchmark test device — Moto G Power — processes JavaScript at roughly 4x slower than a mid-range desktop.
• Memory. JS heap is constrained on mobile — complex SPAs can trigger memory pressure and GC-induced slowdowns.

LCP on mobile is often 2–3x worse than desktop

If desktop LCP = 1.8s (good), the same site on mobile frequently shows LCP = 4–5s (poor). Typical causes: hero image served without srcset or WebP, synchronous CSS blocking render, slow TTFB from uncached server, render-blocking fonts causing FOIT.

Critical CSS for Above The Fold

Critical CSS means inlining the minimal set of styles required to render Above The Fold content directly inside a <style> tag in <head>. The rest of the stylesheet loads asynchronously after the first render. Tools: the critical npm package, Penthouse, or WP Rocket's built-in Critical Path feature. Implementation pattern:

1. Identify elements visible without scrolling (header, hero, navigation)
2. Extract their CSS using automated tooling
3. Inline this CSS in <head>
4. Load the main CSS file with media="print" onload="this.media='all'"

Effect: FCP and LCP improve significantly because the browser renders the visible page without waiting for an external CSS file.

Reducing mobile payload with srcset

The srcset attribute lets the browser pick the optimal image size based on viewport width and Device Pixel Ratio:

<img src="image-800.webp" srcset="image-400.webp 400w, image-800.webp 800w, image-1200.webp 1200w" sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px" alt="...">

On a 375px viewport phone, the browser loads image-400.webp instead of image-1200.webp — a 3–6x file size difference. On a page with 20 images, that's a potential saving of 2–4 MB of payload per page view.

The Future of Mobile-First: What Changes in 2025–2026

Core Web Vitals: INP replaced FID

Since March 2024, Google officially replaced FID (First Input Delay) with INP (Interaction to Next Paint). INP measures responsiveness for all page interactions, not just the first click. This is critical on mobile: JavaScript-heavy pages (product filters, shopping carts, interactive components) frequently show poor INP on budget devices.

INP thresholds:

• Good: under 200ms
• Needs improvement: 200–500ms
• Poor: over 500ms

How to improve INP: reduce JS bundle sizes, move heavy computation to Web Workers, use debounce/throttle for event handlers, avoid long tasks on the main thread.

Mobile traffic growth

Mobile devices account for over 60% of global web traffic in 2025. In e-commerce and news — up to 70–75%. A 10–15 point PageSpeed degradation on mobile directly affects the majority of real visitors. There's no longer any practical justification for treating mobile as secondary.

AI Overviews and mobile optimisation

Google AI Overviews (formerly SGE) occupy even more screen space in mobile search results, compressing organic listings further down. This reduces CTR for positions 1–5 on affected queries. The practical consequence for SEO: Featured Snippets and structured data become more important — Google draws on these sources for AI Overview content. Mobile technical optimisation is a prerequisite for being included in these blocks.

Progressive Web Apps (PWA)

PWAs are web applications with near-native functionality: offline mode via Service Worker, push notifications, add-to-home-screen capability. From an SEO standpoint, PWAs don't directly improve rankings, but they improve engagement metrics through faster repeat loads (via Service Worker caching) and higher return visit rates. For e-commerce and media sites, a well-implemented PWA meaningfully increases the share of returning mobile visitors.

Tools for Verifying Mobile Readiness

• Google Search Console → Mobile Usability — shows pages with mobile display issues: small font, content wider than screen, buttons too close together.
• PageSpeed Insights — always check the Mobile tab, not Desktop. Scores differ significantly. The "Diagnostics" section gives the most actionable recommendations.
• Google Rich Results Test — verifies structured data visibility during mobile rendering.
• Chrome DevTools → Lighthouse → "SEO" category includes mobile meta tag and viewport checks. Run with the Mobile preset for realistic throttling.
• GSC → URL Inspection → Test Mobile Usability — renders the page with the mobile Googlebot and shows a screenshot alongside a list of blocked resources.
• WebPageTest.org — test from real mobile devices in the cloud, including 3G throttle and different geographic locations.

Common Mobile-First Indexing Mistakes

1. Mobile version shows reduced content. Content absent from the mobile version doesn't get indexed. This is the highest-impact mistake and the most common.
2. Different title and meta description on mobile and desktop. Most common on m.site architectures or dynamic serving setups.
3. Missing viewport meta tag. Google treats the page as unoptimised for mobile — and it's a visible signal in GSC.
4. Images without explicit dimensions on mobile. Worsens CLS — part of the technical audit in an SEO promotion engagement.
5. Interstitials covering content on page load. Google demotes pages where pop-ups cover main content immediately after a user arrives from search.
6. robots.txt blocking Googlebot-Smartphone. A legacy robots.txt with a Disallow for the mobile bot effectively removes the site from Mobile-First indexing.
7. Structured data only on the desktop version. With m.site or dynamic serving, verify that Schema.org markup is also present on the mobile version.

Frequently Asked Questions

What is Mobile-First indexing and when did Google implement it?

Mobile-First indexing means Google uses the mobile version of a site as the primary basis for ranking. Google began rolling it out in 2018 and completed the transition in 2024 — all sites are now indexed based on their mobile version without exceptions.

How can I check if my site is ready for Mobile-First indexing?

Use Google Search Console (Overview section — check which agent last crawled your site), Google Mobile-Friendly Test, and PageSpeed Insights. If GSC shows Googlebot Smartphone as the last crawler, your site is already in Mobile-First indexing.

What is the difference between responsive design and a separate m-site for Mobile-First?

Responsive design is the safest option: one URL, same content, only CSS changes the layout. A separate m.site complicates SEO as you need to synchronize content, meta tags, canonical tags, and hreflang between two versions. Google recommends responsive design as the preferred approach.

What happens to rankings if the mobile version shows less content than the desktop version?

Rankings will drop. Google ranks based on what Googlebot Smartphone sees. If the mobile version hides text, images, or structured data using CSS display:none or JavaScript, that content is not considered for ranking — only content visible on mobile counts.