What this test checks, and how to fix each one
Every check below is a Lighthouse audit that Google still runs; it just stopped showing you the results in one place. The fixes are all small and all permanent.
No mobile viewport tag
Without a viewport tag the phone assumes the page was designed for a 980px desktop screen, renders it at that width, and scales the whole thing down. Text becomes unreadable, and every tap gets a 300ms delay while the browser waits to see whether you meant to double-tap to zoom. This one tag in the <head> fixes both:
<meta name="viewport" content="width=device-width, initial-scale=1">
Do not add maximum-scale=1 or user-scalable=no. They stop people with poor eyesight from zooming, and the accessibility audit fails for it.
Tap targets too small or too close together
A fingertip covers roughly 44×44 CSS pixels. The check requires every link and button to have a clickable area of at least 24×24px with 8px clearance from the next one, so a thumb cannot land on two at once. The usual culprits are footer link lists set in small type with no padding, rows of social icons, and pagination.
/* Padding, not font-size, is what makes a target bigger */
footer a, nav a { display: inline-block; padding: 8px 6px; }
.icon-row a { min-width: 44px; min-height: 44px; }
The audit lists the exact elements in PageSpeed Insights (Accessibility → Touch targets), so fix those rather than guessing.
Images look blurry on phones
A modern phone packs two or three device pixels into every CSS pixel. An image that is exactly 400px wide in a 400px-wide slot is being upscaled 2–3× and looks soft. The fix is to offer a higher-resolution version and let the browser pick:
<img src="hero-800.jpg"
srcset="hero-800.jpg 800w, hero-1600.jpg 1600w"
sizes="(max-width: 600px) 100vw, 600px"
width="800" height="500" alt="…">
This is the same mechanism the image formats guide uses for serving smaller files to smaller screens; done once, it fixes both problems.
On any platform, the srcset above is the whole fix and costs nothing — WordPress even generates the size variants for you when you upload, so it is usually a one-line theme change. If your site is WordPress with hundreds of existing images and a theme that will not cooperate, an adaptive-images plugin writes the srcset and the resized files for every image automatically. For that case we use ShortPixel. That is an affiliate link: we earn a commission if you sign up, at no extra cost to you.
Images are stretched or squashed
When CSS forces both a width and a height that do not match the file’s proportions, the browser distorts the image to fit. Set one dimension and let the other follow, or crop instead of stretching:
img { width: 100%; height: auto; }
/* or, for fixed-size slots: */
.card img { width: 100%; height: 200px; object-fit: cover; }
Keep the width and height attributes on the tag in either case — they are what stop the page jumping while the image loads, which is the layout shift problem.
What it does not check
Font size and “content wider than screen” were part of the old report; Lighthouse 12 removed both audits because they produced too many false positives. Neither is dead as a problem. If the text looks small, it is small — 16px body text is the sensible floor — and if the page scrolls sideways on a phone, something has a fixed width larger than the screen. Both are things a two-minute look on a real phone will tell you more reliably than any tool.
Common questions
Where did the Mobile Usability report in Search Console go?
Google removed it in December 2023, along with the Mobile-Friendly Test tool, saying the checks were folded into Core Web Vitals and the page experience guidance. The underlying checks still exist as Lighthouse audits, which is what this page runs. Nothing about the problems changed — a page without a viewport tag is as unusable on a phone today as it was then.
Does mobile usability still affect rankings?
Google has indexed the mobile version of pages exclusively since 2023, so a page that is broken on phones is broken as far as ranking goes. There is no separate 'mobile-friendly' signal any more; a page that is unusable on a phone simply performs badly on the signals that do exist — engagement, Core Web Vitals, and whether people bounce back to the results.
Why is the test result different from what I see on my phone?
The test loads the page on a simulated mid-range Android phone with a fresh profile: no cookies, no cached files, no logged-in state. If your phone shows a cookie banner as dismissed or a font already cached, the layout can differ. Test in a private window on a phone you have never used on the site to see what a first-time visitor gets.
Text is readable on my phone, but the test says the tap targets are too small. Why?
Readable and tappable are different problems. The check measures the clickable box of each link and button — at least 24×24 CSS pixels with 8px of space from its neighbours. Inline links in a paragraph pass when the line height gives them room; footer link lists and icon rows packed together are the usual failures.