Mobile SEO and Mobile-First Indexing
Last updated
Mobile-first indexing means Google uses the mobile version of a page as the primary version for indexing and ranking. This has been Google’s default since 2019. Google confirmed the rollout near-complete in October 2023, with the final remaining desktop-indexed sites switched on July 5, 2024. Every site is now indexed based on what Googlebot sees on a mobile device, regardless of how the desktop version looks.
What does mobile-first indexing mean in practice?
Before mobile-first indexing, Google crawled the desktop version of pages and used that content for ranking. A site could have thin content on mobile and rich content on desktop and rank on the basis of the desktop version.
That is no longer the case. If content, structured data, or internal links are present on the desktop version but absent on mobile, they are effectively invisible to Google. The mobile version is the source of truth.
The practical implications differ depending on how the site handles mobile:
Responsive design (single URL, same HTML, CSS adapts the layout) is the simplest approach from a mobile-first perspective. The same content is served to all devices, so desktop and mobile versions are identical. There is no parity problem to manage.
Separate mobile site (typically at m.yourdomain.com or mobile.yourdomain.com) requires careful maintenance. The content on the mobile version must match the desktop version. Internal links on the mobile version must include the same links as the desktop. Structured data on the mobile version must be equivalent. Canonical tags must be implemented correctly between the two versions. Divergence between mobile and desktop on a separate mobile site is one of the most common causes of indexation problems that are difficult to diagnose without knowing that mobile-first indexing applies.
Dynamic serving (same URL, different HTML served based on User-Agent) falls between the two. Content parity must still be maintained, and the server must correctly identify Googlebot-Mobile as a mobile user agent.
Mobile usability signals
Google evaluates mobile usability and uses it as a ranking signal for mobile search results. The main issues, as reported in Search Console’s Mobile Usability report:
Text too small to read: text rendered below approximately 12px on a mobile viewport. Users must zoom to read it, which Google treats as a usability failure.
Clickable elements too close together: links, buttons, and other interactive elements need adequate spacing. Google recommends a minimum tap target size of 48 x 48 CSS pixels with 8px of separation between targets. Elements that are too close cause accidental taps.
Content wider than the screen: content that requires horizontal scrolling on a mobile device. Usually caused by fixed-width elements (images, tables, code blocks) that do not scale to the viewport.
Viewport not configured: pages without a <meta name="viewport"> tag do not scale correctly on mobile. Without it, browsers render the page at a default desktop width (typically 980px) and scale it down, producing tiny text that users must zoom to read. The correct tag is:
<meta name="viewport" content="width=device-width, initial-scale=1">
width=device-width matches the viewport to the device’s screen width. initial-scale=1 sets the zoom level to 100% on load, preventing the browser from scaling the page down. Both attributes are required for correct mobile rendering.
Avoid adding user-scalable=no or maximum-scale=1. These disable pinch-to-zoom, which prevents users with low vision from reading the page and conflicts with WCAG accessibility requirements. Google treats it as a usability failure.
Intrusive interstitials: pop-ups or overlays that cover the main content on mobile, particularly when they appear immediately on page load or when following a search result link. Google introduced a demotion signal for intrusive interstitials in January 2017. Legitimate exceptions include cookie consent banners, age verification, and small non-intrusive banners.
Core Web Vitals on mobile
Core Web Vitals (LCP, INP, CLS) are measured separately for mobile and desktop. Mobile scores are almost always worse than desktop scores due to slower network connections and less powerful processors. The ranking signal uses field data from the Chrome User Experience Report (CrUX), which reflects real-world performance on the devices and connections users actually have.
A site that passes Core Web Vitals thresholds on desktop may fail them on mobile. The Search Console Core Web Vitals report segments data by device, making it straightforward to identify which device type is the primary source of poor scores.
For most sites, mobile LCP (Largest Contentful Paint) is the metric most likely to be outside the “Good” threshold. The fixes are the same as for desktop (preload key images, reduce server response time, eliminate render-blocking resources) but often require more aggressive optimisation to work within mobile network and device constraints.
How do you audit mobile SEO?
Search Console Mobile Usability report was retired in December 2023. Use Lighthouse (Chrome DevTools or PageSpeed Insights) to identify mobile usability issues per URL. Address high-priority pages (high traffic, high impressions) first.
Google’s Mobile-Friendly Test tool was retired in December 2023. The equivalent now is Lighthouse (available in Chrome DevTools or PageSpeed Insights), which renders a preview of how the page performs on mobile and flags usability issues.
URL Inspection in Search Console shows the mobile-rendered version of any URL via the “Test Live URL” option. Comparing the rendered HTML with the desktop source reveals content parity issues.
Lighthouse in Chrome DevTools provides a mobile performance audit including Core Web Vitals scores, accessibility checks, and specific recommendations. Run it in mobile mode (throttled CPU and network) to simulate real-world mobile conditions.
For a full mobile SEO audit checklist, see the Technical SEO Audit Checklist.
Common mistakes
| Mistake | Effect |
|---|---|
| Hiding content behind “read more” toggles on mobile only | Hidden content may be treated as less important, since Google deemphasises content not visible on load |
| Separate mobile site with missing structured data | Rich results not triggered because schema is absent from the indexed version |
| Pop-up appearing immediately on mobile | Intrusive interstitial demotion signal; poor user experience |
| Not testing mobile after CMS or template updates | Desktop changes often break mobile without testing |
| Ignoring mobile Core Web Vitals because desktop passes | Mobile is the ranking version; desktop scores are secondary |