How to Fix Mobile Usability Issues Google Still Cares About

In December 2023, Google retired the Mobile Usability report in Search Console, along with the Mobile-Friendly Test tool and its API. A lot of site owners read that as "Google no longer cares about mobile." The opposite is true. Google crawls and indexes virtually every site with its smartphone crawler, so the mobile version of your page is the version that gets ranked.

What changed is where you find the problems. This guide covers the mobile usability issues that still matter, how to detect each one with the tools available now, and the code to fix them.

Why mobile usability still matters

Three reasons, in order of importance:

1. Mobile-first indexing. Google uses the mobile rendering of your page for indexing and ranking. Content, links and structured data that exist only on desktop may as well not exist.
2. Page experience. Core Web Vitals are measured separately for mobile, and mobile scores are usually worse. Intrusive interstitials are still called out in Google's page experience guidance.
3. Conversions. Most sites get the majority of their traffic from phones. A button that is hard to tap or a form that zooms unexpectedly loses customers regardless of what any ranking system thinks.

Where to find mobile issues now

With the dedicated report gone, use a combination of tools. Each one covers a different angle:

Using URL Inspection's rendered view

This is the closest replacement for the old Mobile-Friendly Test, and arguably better, because it shows Google's own rendering.

1. In Search Console, inspect a URL and click Test live URL.
2. Click View tested page.
3. The Screenshot tab shows the page as Googlebot smartphone rendered it. The HTML tab shows the rendered DOM. More info lists page resources that could not be loaded and JavaScript console messages.

If the screenshot is blank, cut off or missing main content, you have a rendering problem, not a design problem. Blocked CSS or JavaScript in robots.txt is a classic cause; see robots.txt vs noindex vs nofollow for why blocking assets hurts. Content that only appears after client-side rendering is the other; JavaScript SEO and Googlebot rendering covers that in depth.

Using DevTools device mode

Press Ctrl+Shift+M (Cmd+Shift+M on Mac) with DevTools open. Pick a device preset or set a custom width. Test at least these widths, because breakpoints often fail between presets:

• 320 px (small phones and zoomed-in users)
• 360 px (very common Android width)
• 390 to 430 px (current iPhones)
• 768 px (tablets in portrait)

Drag the viewport edge slowly from 320 to 800 px and watch for anything that breaks.

The issues, and how to fix each one

1. Missing or incorrect viewport tag

Without a viewport meta tag, mobile browsers render the page at a desktop width (typically 980 px) and scale it down, so everything is tiny.

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

Do not add maximum-scale=1 or user-scalable=no. Blocking zoom is an accessibility failure, and users with low vision depend on pinch zoom.

2. Content wider than the screen

Horizontal scrolling usually comes from one element: a fixed-width table, an image without a max width, a long URL or code string, or an embed with a hard-coded width.

Paste this into the DevTools console to find the culprits:

const vw = document.documentElement.clientWidth;
document.querySelectorAll('body *').forEach((el) => {
  const r = el.getBoundingClientRect();
  if (r.right > vw + 1 || r.left < -1) {
    console.log(Math.round(r.width), el);
  }
});

Then apply the standard fixes:

img, svg, iframe, canvas {
  max-width: 100%;
  height: auto;
}

.table-wrap {
  overflow-x: auto;
}

.prose {
  overflow-wrap: anywhere;
}

Wrap wide data tables in a scrolling container rather than letting them push the whole page sideways. Keep width and height attributes on images so the browser reserves space; height: auto keeps the aspect ratio while preventing layout shift, as explained in our guide to Cumulative Layout Shift.

3. Text too small to read

Base body text at 16 px is the practical minimum on phones. Smaller sizes force users to zoom, and on iOS Safari, any form input with a font size below 16 px triggers an automatic zoom when focused, which is disorienting.

html {
  font-size: 100%; /* respects the user's browser setting, usually 16px */
}

body {
  font-size: 1rem;
  line-height: 1.5;
}

input, select, textarea {
  font-size: 1rem; /* prevents iOS focus zoom */
}

Use rem units rather than fixed pixel sizes so text scales with the user's preferences.

4. Tap targets too small or too close

Links in dense footers, icon buttons, pagination numbers and inline links in small text are the usual offenders. Two references are useful:

• WCAG 2.2 (success criterion 2.5.8, level AA) sets a minimum target size of 24 by 24 CSS pixels, or equivalent spacing.
• Google's long-standing design guidance recommends about 48 by 48 CSS pixels for primary touch targets.

Aim for 48 px on anything important, and never go below 24 px.

.icon-button {
  min-width: 48px;
  min-height: 48px;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}

.footer-links a {
  display: inline-block;
  padding: 12px 8px;
}

You can enlarge the tappable area with padding without changing the visual design.

5. Intrusive interstitials

Google's guidance has long treated popups that cover the main content on mobile, especially immediately after arriving from search, as a poor experience. Typical problems:

• A full-screen newsletter modal on page load.
• An app install banner that pushes content below the fold.
• A layout where the above-the-fold area looks like an interstitial and the content starts below it.

Legally required notices (cookie consent, age verification where the law requires it) and login dialogs for private content are treated differently. For marketing popups, use a small banner, trigger on scroll depth or exit intent, and make the close control large and easy to tap.

6. Content parity with desktop

Because Google indexes the mobile version, anything removed from mobile is effectively removed from Google. Check that the mobile version has:

• The same primary content, including text inside tabs and accordions (hidden-but-present content is fine; content that is not in the DOM at all is not).
• The same headings, internal links and navigation paths to important pages.
• The same structured data and meta robots directives.
• The same images with the same alt text. Our image SEO guide covers alt text and lazy loading in more detail.

A fast way to check: compare the rendered HTML from URL Inspection against a desktop crawl of the same URL.

7. Content that requires interaction to load

Googlebot does not click, tap or scroll the way users do. Content that loads only after a "Load more" click or a swipe may never be seen. Use real <a href> links for pagination, and load lazy content with native loading="lazy" or IntersectionObserver rather than on user events.

Mobile performance is mobile usability

A page that renders correctly but takes six seconds to show its main content on a phone is not usable. Mobile Core Web Vitals deserve their own pass:

The Core Web Vitals developer guide covers each metric. For responsiveness on slower phones specifically, see INP vs FID: what changed.

A repeatable mobile check

Run this on one representative URL per template (home, category, product, article, contact) after every significant release:

1. URL Inspection live test: screenshot complete, no blocked resources.
2. Lighthouse mobile run: no viewport warnings, no contrast failures, and no target size warnings where your Lighthouse version reports them.
3. DevTools device mode at 320, 360 and 414 px: no horizontal scroll, run the overflow script.
4. Form inputs at 16 px or larger; no zoom on focus in iOS Safari.
5. No full-screen popups on landing from search.
6. Content, links and structured data match the desktop version.
7. Field data in PageSpeed Insights or Search Console: mobile LCP, INP and CLS passing.

Doing this by hand every release gets skipped eventually. OctaneAudit Monitoring runs daily checks on your key pages and alerts you when a mobile regression appears.

Summary

• The Mobile Usability report and Mobile-Friendly Test were retired in December 2023, but mobile-first indexing means mobile problems matter more than ever.
• Use URL Inspection's rendered screenshot, Lighthouse, PageSpeed Insights and DevTools device mode instead.
• Fix the basics first: a correct viewport tag, no horizontal overflow, 16 px base text, and tap targets of at least 24 px (ideally 48 px).
• Keep content, links and structured data identical between mobile and desktop, and avoid intrusive popups.
• Treat mobile Core Web Vitals as part of mobile usability, and recheck every template after each release.