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, and the rollout completed fully in April 2023. Every site is now indexed based on what Googlebot sees on a mobile device, regardless of how the desktop version looks.
What mobile-first indexing means 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. This tag tells the browser to render the page at the device’s screen width rather than at a fixed desktop width.
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.
Auditing mobile SEO
Search Console Mobile Usability report identifies specific pages with usability issues and categorises the problem type. Address high-priority pages (high traffic, high impressions) first.
Google’s Mobile-Friendly Test tool tests individual URLs and renders a preview of how Googlebot sees the page on mobile. It shows whether mobile usability issues are detected and what resources Googlebot could not load.
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.
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 |