A site usually performs badly on phones for four reasons: a misconfigured viewport, text that is too small, tap targets placed too close together, and content wider than the screen. Automated audits check these four things. Users experience the same four things. Below is how to diagnose each one and what to change.
One point first, because it decides where you look. Google’s Mobile-Friendly Test no longer exists.
What happened to Google’s mobile-friendly test
Google retired the Mobile-Friendly Test tool, the Mobile Usability report in Search Console, and the Mobile-Friendly Test API on 1 December 2023. The announcement came in April 2023. The old test address now redirects to the Lighthouse documentation, and the Mobile Usability report is no longer available in Search Console.
The retirement was not a change of priorities. Mobile usability remains part of Google’s page experience guidance, and Google indexes with the smartphone crawler by default. What changed is the instrument. A binary pass or fail verdict was replaced by Lighthouse, which reports what specifically fails, and by field data from real users.
This matters if you are working from older guidance. A significant amount of material published since 2023 still points readers at a tool that returns nothing. If a checklist tells you to run the mobile-friendly test, the checklist predates December 2023, and its other recommendations are worth verifying too.
What the four criteria actually check
The criteria themselves did not disappear with the tool. Lighthouse checks the same things, in more detail.
Viewport configuration tells the browser how to handle page dimensions and scaling. Without the correct settings, the site renders zoomed out or forces horizontal scrolling. The audit looks for a viewport meta tag in the document head.
Text readability covers font size and line height. The question is whether body text can be read without pinch-zooming. 16 pixels is the practical baseline for body copy, with line height between 1.4 and 1.6.
Tap target spacing covers whether buttons and links have enough room around them. The accepted threshold is a touch area of at least 48 by 48 pixels, separated from its neighbours. Below that, people hit the wrong element.
Content width confirms that nothing extends past the screen edge and forces horizontal scrolling.
Responsive is not the same as mobile-optimised
A responsive site adapts layout, text size and element placement to the resolution it renders on. One codebase serves phone, tablet and desktop, and CSS media queries decide what appears where.
This replaced the older pattern of a separate mobile site on its own address, usually an m. subdomain. That approach meant two sites to maintain and two sets of content to keep in sync. A single responsive site on a single address is now the standard.
Responsiveness does not guarantee good mobile optimisation. A layout can scale correctly and still ship buttons that are too small, text that is too fine, and a page that takes twelve seconds to become usable. These are two separate questions, and it is worth keeping them separate when you assess a site.
Why sites fail on mobile
The causes cluster into the same four areas, and they usually trace back to how the site was built rather than to a specific mistake.
Viewport problems lead the list. Many sites either lack the tag or use settings that block correct rendering, such as a fixed width or disabled user scaling. Without it, the mobile browser assumes a desktop layout and shrinks everything.
Text sizing issues appear wherever fixed pixel values were used. They work on desktop and become unreadable on a phone. This is most common on sites built before responsive design became the default approach.
Tap targets placed too close together break navigation. It happens when menus, buttons and links were spaced for a mouse cursor rather than a fingertip.
Content overflowing the screen comes from fixed-width elements, images and tables. Data tables are the usual culprit on B2B sites, where a comparison table designed for a wide screen has no mobile treatment at all.
We see these patterns most often on platforms that grew over several years under different teams. The desktop experience was maintained. The mobile experience was inherited.
How to check a site today
Four methods, in the order we use them on an audit.
Lighthouse is the primary tool. It is built into Chrome and available through PageSpeed Insights. Run it in the mobile profile and it reports font sizes, tap target dimensions, viewport configuration and loading behaviour, with the specific elements that fail. This is what the old mobile-friendly test was replaced by.
Browser developer tools let you simulate devices. In Chrome, open them with F12 and switch on device mode. Test several resolutions and both orientations.
The Core Web Vitals report in Search Console shows field data from real visits, grouped by URL pattern. This is where you establish priority across a whole site rather than one page. Google evaluates at the 75th percentile of real user data, over a rolling 28-day window, against three thresholds: LCP up to 2.5 seconds, INP up to 200 milliseconds, CLS up to 0.1. For the full detail on why those specific thresholds matter for ranking, see how important Core Web Vitals are for SEO in 2026.
Manual testing on real devices stays necessary. It surfaces what automated tools cannot: gestures that conflict, elements hidden behind the on-screen keyboard, forms that cannot be completed one-handed. On any platform where a form is the conversion point, this is not optional.
One distinction is worth holding onto. Lighthouse is lab data and tells you what to fix. Search Console is field data and tells you whether it mattered. Use both, in that order.
Responsive versus mobile-first
Responsive means the site works correctly on a phone. Mobile-first treats the phone as the starting platform and builds upward toward larger screens.
A conventional responsive build starts from the desktop design and scales it down. The approach works, but the mobile version usually pays for it. It receives a simplified desktop layout rather than a layout designed for touch.
Mobile-first inverts the order. The starting point is core mobile functionality, typically a 320 pixel design, then tablet at 768 and desktop at 1920. Features are added going up rather than removed going down.
The advantage is mainly in performance. The phone downloads only the styles and scripts it needs. Desktop widgets, complex animation and heavy graphics are layered on for larger screens.
From a usability standpoint, mobile-first accounts for touch interaction, simplified navigation and content hierarchy from the start. The result is a mobile version that was designed, not compressed.
How to fix the four common failures
Viewport. Add this tag to the document head:
html
<meta name="viewport" content="width=device-width, initial-scale=1">It instructs the browser to match the device width and apply a standard zoom level. Avoid maximum-scale and user-scalable=no, which block zooming and create an accessibility problem.
Text size. Replace fixed pixel values with relative units. Set the base body size to at least 16 pixels and use em or rem from there. Keep line height between 1.4 and 1.6.
Tap targets. Give every clickable area at least 48 by 48 pixels and separate it from its neighbours. Use padding and margin rather than resizing the visible element. In navigation, larger buttons or a collapsed menu usually solve it.
Content width. Use CSS Grid or Flexbox. Define maximum widths as percentages rather than fixed pixels, and give images max-width: 100% and height: auto. Wide data tables need a deliberate mobile pattern, either horizontal scroll within a container or a stacked card layout.
Use media queries to vary styles by resolution. They let you adjust layout, hide elements and change spacing on mobile without touching the desktop rendering.
What this means for search visibility
Google indexes with mobile-first, which means the mobile version is what gets evaluated. If the mobile version carries less content than the desktop version, the search engine sees the smaller one. Content hidden behind a mobile-only accordion is still indexed. Content removed from the mobile template is not.
Core Web Vitals add a second layer. Slow loading, shifting layout and delayed response to touch reduce assessment regardless of content quality. They are one signal among many, and they behave as a tiebreaker rather than a lever.
The commercial effect runs ahead of the ranking effect. Conversion falls measurably on poorly optimised mobile sites. People abandon carts and forms when navigation is awkward or tap targets are imprecise. Support volume rises, because usability problems arrive as tickets.
Mobile optimisation is not about passing a test. The test is gone. It is about building a version people can actually use on the device most of them are holding. The same shift toward field-based, real-world evaluation shows up in how AI-driven generative search evaluates WordPress platforms.
FAQ: Mobile site optimisation
Does Google’s mobile-friendly test still work?
No. Google retired the tool, the Mobile Usability report in Search Console and the associated API on 1 December 2023. The old test address redirects to the Lighthouse documentation. Lighthouse, available in Chrome and through PageSpeed Insights, is the replacement.
Is mobile-friendliness still a ranking factor?
Mobile usability remains part of Google’s page experience guidance, and indexing is mobile-first. The dedicated report was retired, not the underlying expectation.
How do I check mobile usability across a whole site now?
Use the Core Web Vitals report in Search Console. It groups URLs by pattern and shows field data from real visits, which is what establishes priority. Lighthouse then diagnoses individual templates.
My site is responsive. Is that enough?
Not necessarily. Responsive layout and mobile optimisation are separate. A site can scale correctly and still fail on text size, tap targets or loading time. Run Lighthouse in the mobile profile to confirm.
What is the minimum tap target size?
At least 48 by 48 pixels, with separation from adjacent targets. Achieve it with padding rather than by enlarging the visible element.
Which mobile problem should I fix first?
The one blocking your commercially important templates. In practice that is usually the viewport tag, because it is a single line and affects every other measurement on the page.
