The mobile-friendly test Google took away

Google retired it in December 2023, along with the Mobile Usability report in Search Console and the Mobile-Friendly Test API. Its stated reasoning was that the mobile web had matured and the tool had served its purpose. The demand did not go away with it — people still need to know whether a page works on a phone, and the URL that used to answer that question now redirects to documentation.

No, and it is worth being precise about the difference. Google's test loaded the page in a real headless browser and measured the laid-out result. This reads the declarations instead — your viewport meta tag, your stylesheets and your markup. That catches every configuration-level failure, which is the great majority of real ones: a missing viewport tag, a viewport locked to a fixed width, zoom disabled, font sizes under 12px, fixed widths wider than a phone, no media queries at all, legacy plugin content. It cannot measure a rendered tap target or confirm that a specific rule applies at 360 pixels wide. Where it is inferring rather than measuring, it says so in the finding.

Yes, though the framing has changed. There is no longer a separate "mobile-friendly boost" — instead, Google indexes the mobile version of every site, so a page that renders badly on a phone is simply a bad page as far as the index is concerned. Page Experience signals, including Core Web Vitals, apply to that mobile version. The practical effect is the same as it always was, arrived at differently.

Then the problem is in the rendered layout rather than the declarations, and this tool has reached its limit honestly. Open your browser's device toolbar at 360 pixels wide and scroll — that finds horizontal overflow in seconds. Then run PageSpeed Insights, which executes a real Lighthouse pass on a simulated mobile device and will catch layout and performance problems a static read cannot.

Most likely we could not read your stylesheets. We only fetch same-origin CSS — a stylesheet on a CDN or a separate assets domain is not fetched, deliberately, because fetching arbitrary cross-origin URLs would turn this into an open proxy. If the result banner says fewer stylesheets were read than were linked, that is what happened, and the CSS checks found nothing because they had nothing to look at rather than because the page passed.

Yes, and more for accessibility than for SEO. Blocking zoom with user-scalable=no or a low maximum-scale is a WCAG 1.4.4 failure, and it is one of the most common complaints from people with low vision. It was so widely misused that iOS Safari has ignored the directive for years — which means the main thing it still does is break the experience on Android. There is no good reason to keep it.

Under 12px is genuinely hard to read at arm's length on a phone, which is where this tool draws the line. In practice 16px is the sensible floor for body copy, and it is what most design systems have settled on. Smaller sizes are fine for footnotes, captions and legal text — they are not fine for anything a visitor actually needs to read to make a decision.

Fixed pixel widths on elements inside otherwise responsive layouts — a table, an embedded map, a legacy widget, an inline style on a container. Each one forces horizontal scrolling on the whole page. The fix is nearly always to wrap the offending element in a container with overflow-x: auto so it scrolls inside its own box, rather than trying to make the element itself flexible.