The Mobile-Friendly Test is gone — what to use instead

If you came here looking for Google’s Mobile-Friendly Test, the short answer is that it no longer exists. Google retired the standalone tool and the Mobile Usability report in Search Console in December 2023. The reasoning was that mobile-friendliness had stopped being a distinguishing question: Google now crawls and indexes with a mobile crawler by default, so a site that works at all works on mobile.

Why it went away

Mobile-first indexing completed for all sites in 2023. Googlebot fetches your pages as a mobile device, and the mobile version is the version indexed and ranked. There is no separate desktop index to fall back on.

That changed the nature of the question. A binary “is this page mobile-friendly?” verdict was useful when many sites were not, and most had a separate mobile site or none. Now the answer is yes for almost everything responsive, and the verdict stopped distinguishing anything — while still being quotable enough that people optimized for the badge rather than for their users.

The consequence worth internalising: mobile is not a checkbox to satisfy after the desktop site is done. It is the version that gets indexed.

What to use instead

Chrome DevTools device mode for layout. Open DevTools, toggle the device toolbar, and set the width to 360 or 375 CSS pixels — narrower than most tools default to, and where layout problems actually appear. Do this on real templates, not just the homepage.

Lighthouse for the underlying issues. It still checks viewport configuration, tap target sizing, legible font sizes and content wider than the screen — the same things the old tool reported, minus the badge. Run it in mobile mode, which is the default.

Search Console’s Core Web Vitals report for what real mobile visitors experience. It separates mobile from desktop, and it is field data, so it reflects actual devices rather than a simulation.

URL Inspection to see what Googlebot rendered. The screenshot is taken with the mobile crawler, so it is the closest thing remaining to the old test’s rendered preview — and it is more authoritative, because it is the actual crawler rather than an emulation of it.

A real phone. Not a substitute for the above, but it catches things emulators do not: how the site behaves on a slow connection, whether tap targets are reachable one-handed, whether an interstitial covers the content, whether the keyboard obscures the form field it opened for.

What actually goes wrong on mobile

The old test reported five failure types. They have not stopped mattering just because the badge is gone.

No viewport meta tag. <meta name="viewport" content="width=device-width, initial-scale=1">. Without it the browser assumes a desktop width and scales the whole page down, which is the classic “everything is tiny” look. Still the single most consequential mobile mistake, and a one-line fix.

Content wider than the screen. A fixed-width element, a wide table, an unbroken code string or an image with explicit pixel dimensions forces horizontal scrolling. Tables are the usual culprit and the fix is a horizontally scrollable wrapper around the table rather than the page.

Text too small to read. Body text below about 16px on mobile forces zooming. Under 12px is effectively unreadable.

Tap targets too close together. Links and buttons need roughly 48 CSS pixels of target area and space between them. Adjacent links in a list with no padding are the common failure, and the symptom is users tapping the wrong one.

Blocked resources. If robots.txt blocks your CSS or JavaScript, Googlebot renders an unstyled page and judges that. Rare, and completely silent when it happens.

The problems the old test never caught

Worth more attention than the checklist above, because they affect rankings and nothing flags them.

Content that differs between mobile and desktop. Since the mobile version is what gets indexed, anything hidden or omitted on mobile is effectively removed from your page as far as Google is concerned. Truncated descriptions, omitted sections and lazy-loaded content that never loads without scrolling all cost you indexed content. This is the most expensive mobile mistake and the least visible.

Different structured data or metadata per breakpoint. If your mobile template emits different canonicals, titles or structured data, the mobile ones are the real ones.

Layout shift from ads and images. CLS is overwhelmingly a mobile problem, because narrow viewports magnify every reflow. Reserve space with explicit dimensions or aspect ratios.

Interstitials and consent walls. A dialog covering the content on arrival is both a ranking risk and a measurable bounce problem.

Interaction responsiveness. Mobile CPUs are slower, so INP is harder to pass on mobile than desktop — often the metric that fails while the others pass. See how to diagnose slow page speed.

Is mobile-friendliness still a ranking factor?

Yes, but the question is now slightly the wrong shape. Mobile usability is part of how pages are assessed, and mobile-first indexing means the mobile rendering is the page being assessed. So it is not a separate bonus applied to mobile-friendly sites; it is the baseline condition for being evaluated at all.

The practical version: you cannot rank well with a page that is unusable on a phone, and you gain nothing extra for being merely adequate on one.

Checking yours

Run Lighthouse in mobile mode on your three highest-traffic templates and check the viewport tag, font sizes and tap targets. Then look at the Core Web Vitals report’s mobile tab for what your visitors actually get.

Our free site check reports viewport configuration, mobile rendering problems and Core Web Vitals in one pass, which covers the mechanical half of this list without needing to run three tools. For the content-parity problem — the one that costs the most and shows up nowhere — compare your rendered mobile HTML against desktop directly; JavaScript SEO and rendering explains how to get at the rendered version Google actually indexed.