Google Killed the Mobile-Friendly Test. Here's What to Use Instead

Google retired the Mobile-Friendly Test on December 1, 2023. The old URL — search.google.com/test/mobile-friendly — now redirects to a "this tool is no longer available" page. The Mobile Usability report inside Search Console got the same treatment on the same day.

That left a lot of people Googling "mobile friendly test" and landing on dead pages. If that's you, here's the short version: use Lighthouse, PageSpeed Insights, or our Mobile Friendly Test tool. The signals Google still uses haven't changed — only the testing UI did.

Why Google Killed the Tool

Google's reasoning was that mobile-first indexing has been the default since July 2019 and the global rollout completed in late 2023. At that point, every site Google crawls is being crawled with the smartphone Googlebot. A standalone "is this mobile-friendly?" test became redundant with their broader page experience signals.

But the underlying ranking factors didn't go anywhere:

• Mobile-first indexing is still in effect. Googlebot crawls your site as a mobile device. If your mobile version is missing content, structured data, or alt text that exists on desktop, Google won't see it.
• Page experience signals still factor into rankings, including Core Web Vitals on mobile, HTTPS, and no intrusive interstitials.
• Mobile usability problems still hurt indirectly through bounce rate and engagement metrics that influence how Google evaluates a result.

So the question shifted from "does Google's tool say I pass?" to "does my page actually work for a thumb on a 390px screen?"

What Google Actually Checks on Mobile

The criteria the old tool flagged are still the criteria you should care about. They map to physical user behavior, not algorithm preferences.

Viewport Meta Tag

Without <meta name="viewport" content="width=device-width, initial-scale=1">, mobile browsers render the page at desktop width and shrink it. Text becomes microscopic. This is the single most common mobile failure on legacy sites.

Tap Target Size

Buttons and links need to be at least 48×48 CSS pixels with enough spacing between them. Google's documented minimum is 48px, though Apple's HIG recommends 44pt. If two links are stacked 4px apart, users mis-tap. Mis-taps mean back-button presses. Back-button presses signal a bad result.

Readable Text Without Zooming

16px is the practical minimum for body text on mobile. Anything smaller forces pinch-zoom, which is a bounce trigger. Line-height should be at least 1.4 to keep paragraphs scannable.

No Horizontal Scroll

A page that requires sideways scrolling to read fails the most basic mobile expectation. The usual culprits: fixed-width tables, oversized images, or width: 1200px declarations that didn't get a max-width override.

Content Parity With Desktop

Under mobile-first indexing, if a piece of content only renders on desktop, Google effectively can't see it. Hidden tabs, "Show more" sections, and off-screen lazy-loaded content all need to be reachable in the rendered mobile DOM — not gated behind device-detection.

The Real Replacements

Lighthouse (Built Into Chrome)

Open DevTools → Lighthouse tab → run the report with "Mobile" selected. You get the same signals the old tool checked plus Core Web Vitals, accessibility, and SEO scoring. Lighthouse is what PageSpeed Insights runs under the hood — testing once with Lighthouse covers both surfaces.

PageSpeed Insights

pagespeed.web.dev runs Lighthouse on Google's servers and folds in real-world Chrome User Experience Report (CrUX) data when available. The "Mobile" tab is the relevant one. Pay attention to the field data box — that's what users actually experience, not what a clean test environment produces.

Search Console Page Experience Report

The "Mobile Usability" report is gone, but Search Console still surfaces page experience issues under the Core Web Vitals report (Mobile section) and under Crawl Stats. If Google detected a problem at index time, it shows up there.

Bing Webmaster Tools Mobile Friendliness Test

Bing still runs a standalone mobile-friendliness test and it works on URLs that Google would have accepted. The output isn't identical to Google's old tool, but the criteria overlap heavily.

A Direct HTML Audit

The fastest path is to inspect your HTML for the actual signals: viewport meta tag, font sizes, viewport-relative widths, and tap target spacing. That's exactly what our Mobile Friendly Test does — paste a URL or HTML, get a checklist of which mobile signals pass or fail with specific selectors flagged.

Common Mobile Mistakes I See on Real Sites

After running this check across maybe 200 client sites, the same five problems show up again and again:

1. Missing viewport tag on a "responsive" theme. Themes built before 2015 sometimes lack it. The CSS scales fine — the browser just isn't told to use it.
2. Tables with fixed pixel widths. A <table style="width: 800px"> will create horizontal scroll on every phone. Either give it max-width: 100% plus overflow-x: auto on a wrapper, or restructure into stacked rows.
3. Buttons styled as links with 14px text. Inline links are fine at body size, but anything that's intended to be tapped needs button-sized hit area regardless of how it's labeled.
4. Auto-playing video carousels. Mobile bandwidth, mobile autoplay restrictions, and CLS scores all suffer. Use a click-to-play poster image.
5. Sticky headers eating 30% of the viewport. A 200px-tall sticky nav on a 700px tall iPhone screen leaves almost no content visible. Cap at 60-80px or hide on scroll.

A 5-Minute Mobile Audit

Here's the workflow I run on a new site before any technical SEO work:

1. Open in Chrome DevTools, toggle device emulation, set to iPhone 14. Reload. Eyeball the page. If it looks broken at this size, fix that before running any tool.
2. Check the rendered HTML for <meta name="viewport">. View source, search for "viewport". If it's missing, that's the first fix.
3. Run Lighthouse mobile. Look at the SEO score and the accessibility score together — accessibility issues often map 1:1 to mobile usability issues.
4. Open HTTP Headers Checker and verify the page isn't sending X-Robots-Tag: noindex to mobile user agents (yes, this happens — usually a misconfigured CDN rule).
5. Test from a real phone on cellular. Simulators don't catch the things that matter most: actual tap accuracy, actual font legibility outdoors, actual load time on flaky networks.

If you want to dig into specific Core Web Vitals scores after the basic audit passes, the Page Speed Analyzer breaks down render-blocking resources and other performance bottlenecks. Mobile-friendliness is the floor, not the ceiling — clearing it doesn't mean the page is fast.

What's Different in 2026

Two recent shifts worth knowing:

• INP replaced FID in Core Web Vitals in March 2024. INP measures interaction responsiveness across the whole page session, not just the first interaction. Mobile devices, especially mid-range Android, are where INP regressions show up first. JavaScript-heavy pages that scored fine on FID can fail INP badly.
• Google reduced the weight of "Page Experience" as a ranking signal in late 2024 and folded most of those signals into general quality assessment. That doesn't mean ignore mobile — it means a mobile-broken site won't be saved by good content the way some SEOs assumed it would be in 2022.

The takeaway: Google retired the test, not the standard. If your pages render cleanly on a phone, have proper viewport configuration, and don't make users squint or pinch-zoom, you're fine. If they don't, no testing tool — old or new — is going to fix that for you.