More than 60% of web searches happen on mobile. Google indexes and ranks the mobile version of your site first. If your site doesn't work well on a phone, it doesn't rank as well — for anyone, on any device. Mobile SEO isn't a niche concern; it's the baseline.
Mobile-first indexing explained
Mobile-first indexing means Google's crawlers primarily visit and evaluate the mobile version of your website when deciding how to index and rank it. This has been Google's default since 2019 and applies to all websites.
Before mobile-first indexing, Google primarily crawled desktop sites and applied rankings to both desktop and mobile searches. Now it crawls the mobile version and applies those rankings everywhere. The desktop version still exists and matters for desktop users — but Google's index entry for each page is based on what Googlebot sees when it visits your site on a mobile device.
The direct implication: any content, links, or structured data that only appears on your desktop site (hidden on mobile, loaded differently, or on a separate m.site) may not be seen by Google at all. Your mobile site is your site, as far as Google is concerned.
Responsive design: the right approach
The recommended approach to mobile optimisation is responsive web design — a single website that adapts its layout to different screen sizes using CSS. The same URL, the same HTML content, the same server — just a layout that reorganises itself based on the visitor's screen width.
Google explicitly recommends responsive design over alternatives like separate mobile sites (m.yourdomain.com) or dynamic serving (same URL, different HTML). The reason: one URL for one piece of content is simpler to index, easier to manage canonicals for, and less likely to produce mobile/desktop content discrepancies.
If you're having a website built or redesigned, insist on responsive design from the start. Retrofitting responsiveness to a non-responsive site is often more work than building correctly from scratch. See the web design SEO mistakes guide for the full list of things to avoid in a build.
Mobile usability requirements
Google checks for specific mobile usability issues in Search Console (Experience → Mobile Usability). These are distinct from general mobile optimisation — they're specific technical failures that Google explicitly identifies as problems:
Viewport not configured
The viewport meta tag tells browsers how to scale the page. Without it, mobile browsers render the desktop layout at full width and then shrink it — producing a tiny, unreadable page the user has to zoom in on.
<meta name="viewport" content="width=device-width, initial-scale=1">
This single line belongs in the <head> of every page on your site. If it's missing, everything else about mobile SEO is undermined.
Text too small to read
Body text should be at least 16px — smaller than this is hard to read on a phone screen without zooming, which is a failure. Check your stylesheet. If body font-size is set at 12px or 14px for "density" or "aesthetics", increase it. Legibility is non-negotiable for both usability and Google's assessment.
Clickable elements too close together
Buttons, links, and form elements need to be large enough to tap accurately with a finger. Google's guideline: interactive elements should be at least 48x48 CSS pixels and have at least 8px of space between them. Small links packed together are a mobile usability failure — typical on pages where desktop link lists are displayed unchanged on mobile.
Fix by: adding padding to all interactive elements (minimum 12px padding on links, buttons with height of at least 44px), increasing spacing between link groups, and reviewing all navigation and footer links on mobile.
Content wider than the screen
When content overflows the viewport, the page has horizontal scrolling — a clear mobile usability failure. Common causes:
- Fixed-width elements (e.g.
width: 900pxon a container instead ofmax-width: 900px; width: 100%) - Large images without
max-width: 100% - Wide tables without
overflow-x: autoon a wrapper - Long unbreakable strings (URLs, long words in some languages) without
word-break: break-word
Intrusive interstitials
Pop-ups and interstitials that cover the main content on mobile — especially immediately after arriving from search — are penalised by Google's intrusive interstitial penalty. This includes: full-page pop-ups that appear immediately, cookie consent banners that are excessively large, and "install our app" banners that obscure content.
Cookie consent banners are technically required by law in many jurisdictions and are exempt from the penalty if they don't block the main content. Full-page promotional pop-ups (newsletter sign-ups, "get 10% off") triggered on page load for mobile visitors are the primary target of the penalty.
Mobile page speed
Mobile users are often on slower connections than desktop users — 4G rather than broadband, or variable signal quality. Mobile Core Web Vitals scores are almost always worse than desktop scores for the same page, and Google's mobile CWV scores are what counts most for ranking.
Mobile-specific speed issues:
- Images not resized for mobile: serving a 2400px-wide hero image to a 390px mobile screen wastes bandwidth and slows load. Use
srcsetto serve appropriately sized images to each screen size. Use WebP format for all images. - Render-blocking resources: CSS and JavaScript that block the browser from displaying anything until they've loaded. Use
deferorasyncon non-critical JavaScript. Inline critical CSS or load it with high priority. - Too many third-party scripts: chat widgets, social share buttons, analytics tools — each adds load time on mobile. Audit and remove any you don't need. Lazy-load any that don't need to be present on page load.
- No compression: ensure gzip or Brotli compression is enabled on your server. This typically reduces HTML, CSS, and JavaScript file sizes by 60–80% and has no visible effect on the user.
Run your pages through PageSpeed Insights and focus on the mobile tab — especially LCP (Largest Contentful Paint), which measures how quickly the main content appears. On mobile, the target is under 2.5 seconds. See the full page speed guide for fixes.
Content parity between mobile and desktop
Because Google indexes the mobile version, any content that's hidden, truncated, or unavailable on mobile is content Google won't see. This matters for:
- Tabbed content and accordions: content hidden behind tabs or collapsed accordions is typically crawled by Google, but check that it's in the HTML (not loaded via JavaScript that Googlebot doesn't execute). Google has confirmed it can access tabbed content — but if the same content is fully visible on desktop and collapsed on mobile, the desktop's prominence signal doesn't apply on mobile.
- Desktop-only navigation elements: sidebar navigation visible on desktop but replaced by a hamburger menu on mobile is fine — both are in the HTML. But if you're using two separate HTML structures and only showing one via CSS, ensure the mobile one contains all the links you want indexed.
- Structured data on mobile: if structured data only appears on the desktop version of a page (rare, but possible with some CMS configurations), Google won't see it for indexing purposes. Verify that schema markup is present on the mobile version.
The rule: whatever content you want Google to see must be in the HTML of the mobile page. Hiding it with CSS display:none on mobile doesn't remove it from Google's view, but omitting it entirely from the mobile HTML does.
Mobile and local search
Local intent searches ("near me", "open now", "[service] in [city]") are disproportionately mobile. Someone searching for a plumber or restaurant on their phone is typically doing so in an immediate-need context. This has two implications:
- Your phone number must be clickable: on mobile, phone numbers should be wrapped in
<a href="tel:...">links so a single tap initiates a call. A visible but non-tappable number on mobile means missed enquiries. - Local pack results are heavily mobile: the Google Local Pack (the map results) appears prominently on mobile for local searches. Google Business Profile optimisation is therefore even more critical for mobile local search. See the GBP guide and the local SEO guide.
For service businesses especially, mobile users are often the highest-intent visitors — they're searching, finding you, and deciding whether to call, all in the same 2-minute window. A mobile experience that requires zooming, hunting for a phone number, or wrestling with a non-responsive form loses those leads.
How to test your mobile site
Google Search Console → Experience → Mobile Usability: this shows all URLs on your site that Google has identified as having mobile usability issues, with specific error types. Fix these first.
Physical device testing: use an actual phone. Open your site and walk through the key user journeys — finding contact information, filling out a form, reading a blog post, navigating between pages. This reveals usability issues that automated tools miss: font sizes that are technically compliant but feel wrong, tap targets that are technically large enough but practically awkward, content that loads slowly on real mobile data.
Chrome DevTools device emulation: open Chrome DevTools (F12), click the device toggle icon, and view your site in various mobile viewport sizes. Not a perfect substitute for real device testing, but useful for quick checks during development.
PageSpeed Insights mobile tab: run key pages and review the mobile Core Web Vitals scores and specific opportunities for improvement.
Common mobile SEO issues and fixes
- Navigation not functional on mobile: hamburger menu doesn't work, links can't be tapped, sub-menus are inaccessible. Fix with a mobile-first navigation design that works without hover states.
- Forms unusable on mobile: form fields too small to tap, keyboard covers the active field and the user can't see what they're typing, submit button cut off at the bottom of the screen. Test every form on a real phone and fix the UX.
- Video not responsive: embedded videos (YouTube, Vimeo) at a fixed pixel width overflow the mobile viewport. Use percentage-width containers or the padding-bottom trick for responsive iframes.
- Hover-dependent interactions: dropdown menus, tooltip content, or interactive elements that only work on hover. Mobile users can't hover — these need to be converted to tap-based interactions.
- Fonts that don't load on mobile: some web font loading strategies cause invisible text (FOIT — Flash of Invisible Text) on slower mobile connections. Use
font-display: swapin your @font-face declarations to show fallback fonts while custom fonts load. - Maps not mobile-friendly: embedded Google Maps at fixed sizes. Use responsive iframes and test that the map is navigable on a phone.
See the Core Web Vitals guide for the specific performance metrics Google measures on mobile and how each is calculated.