Mobile-Friendly Test: How to Check Your Site Now That Google's Tool Is Gone

In short: Google retired its Mobile-Friendly Test, the Mobile-Friendly Test API and Search Console's Mobile Usability report on December 1, 2023. Mobile did not become less important: Google crawls and indexes sites with its smartphone crawler only, and content that can't be reached on a phone is not indexable. To test a site today, check the basics (viewport tag, images that scale, readable text, tap targets) with a quick checker and Lighthouse, look at the page on real phones, and confirm the mobile version has the same content as desktop.

For years, "mobile-friendly test" meant one thing: paste a URL into Google's tool and get a green "Page is mobile-friendly" banner. That tool no longer exists, and many guides still link to it. This article explains what happened, what Google expects from mobile pages now, how to test them with tools that still work, including our free mobile-friendly test, and how to fix each problem.

What happened to Google's Mobile-Friendly Test

In an April 2023 post on page experience, Google announced: "Also starting December 1, 2023, we'll be retiring Search Console's 'Mobile Usability' report, the Mobile-Friendly Test tool and Mobile-Friendly Test API." The reason it gave was not that mobile stopped mattering. It noted that many robust resources for evaluating mobile usability had emerged, "including Lighthouse from Chrome."

So since December 2023 there is no official Google pass or fail for mobile-friendliness. Third-party checkers, Lighthouse and your own testing fill that gap.

Why mobile still decides how you're indexed

Two announcements matter more than the retired tool:

1. Mobile-first indexing is complete. In October 2023 Google wrote that "the trek to Mobile First Indexing is now complete" (announcement). Its best practices page defines what that means: "Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking."
2. Desktop crawling ended for Search. In June 2024 Google said: "After July 5, 2024, we'll crawl and index these sites with only Googlebot Smartphone," and "If your site's content is not accessible at all with a mobile device, it will no longer be indexable" (announcement).

The practical consequence: whatever your mobile version shows is your page as far as Google is concerned. Text hidden on mobile, a missing section or a different title on the mobile template is what gets indexed.

Page experience adds a second layer. Google's page experience guidance asks "Does your content display well on mobile devices?" and says its core ranking systems "look to reward content that provides a good page experience," while stressing there is no single page experience signal.

What "mobile-friendly" means in practice

There's no official checklist any more, but Google's documentation and web.dev cover the ground:

Google recommends responsive web design "because it's the easiest design pattern to implement and maintain." One URL, one HTML document, CSS that adapts: parity problems mostly disappear.

How to test mobile-friendliness today

Use several tools, because each sees a different part of the picture:

1. A quick basics check. Our free mobile-friendly test checks the viewport tag, responsive images, favicon and page language in about 20 seconds (details below).
2. Lighthouse in Chrome. Run it from DevTools with the mobile setting. Since Lighthouse 13 (October 2025), the viewport check lives in the "Optimize viewport for mobile" insight, and the old legible font size audit was removed with no replacement.
3. Chrome DevTools device mode. Drag the width from 320 px upward and watch for horizontal scrollbars, overlapping elements and text that overflows its box.
4. Real phones. Use at least one small Android phone and one iPhone. Try the menu, forms and checkout with your thumb.
5. Search Console URL Inspection. The live test shows a screenshot of the page as Googlebot Smartphone renders it, plus the rendered HTML, so you can confirm that the content you care about is there.
6. Real-user speed data. Core Web Vitals for phone visitors, from the Chrome User Experience Report. Our Core Web Vitals guide explains how to read them.

How the Searvia mobile-friendly test works

The free mobile-friendly test runs our full website audit (38 checks) and puts the four mobile checks at the top. Enter a domain or a page address and it fetches that page (the home page if you enter only a domain), following redirects, and reads the HTML your server sends without running JavaScript.

A few details about how it judges:

• The viewport check fails rather than warns because a page without a viewport tag is broken on every phone, not slightly worse.
• For favicons, the /favicon.ico fallback counts only if it returns a real file, not an HTML error page.
• The language check shows the first two letters of the code, so en-GB appears as "en".

The full report also includes the speed section, where the Core Web Vitals check reads 75th percentile LCP, INP and CLS for phone visitors from Chrome's real-user data: for the page you entered when Chrome has enough data for it, otherwise for the whole site.

What it does not do: it doesn't render the page in a phone-sized browser, so it can't see horizontal overflow, font sizes, tap target spacing or pop-ups. That's what Lighthouse, device mode and real phones are for. Think of the checker as the five-minute triage and the manual tests as the inspection.

How to read the results

• Viewport failing: fix this first; nothing else on the page matters until the layout fits the screen.
• Responsive images warning: phones are downloading desktop-sized images. Not broken, but slower, especially on mobile networks.
• Favicon or language warnings: small, quick fixes that improve how you appear in Google results and how screen readers handle the page.
• "Too few images to judge": neutral. With fewer than three images, the share doesn't say much.

How to fix each problem

"The page has no mobile viewport tag."

1. Add this line inside <head> on every template:

<meta name="viewport" content="width=device-width, initial-scale=1">

1. Don't add user-scalable=no or a low maximum-scale. web.dev advises against them "because they can prevent the user from zooming."
2. Check there is only one viewport tag. A theme and a plugin can both print one; the second may override the first.
3. Reload on a phone. If the page now shows a cramped desktop layout instead of a tiny one, the viewport works and the CSS needs responsive rules (see below).

Making the layout responsive

A viewport tag only tells the browser to use the screen width. The CSS still has to adapt:

• Give images and videos max-width: 100%; height: auto; so they never overflow.
• Use flexible widths (percentages, fr, min()) instead of fixed pixel widths for containers.
• Add media queries where the design breaks, not at specific device widths. web.dev: "Design the content to fit on a small screen size first, then expand the screen until a breakpoint becomes necessary."
• Wrap wide tables in a scrollable container rather than letting the page scroll sideways.

"N of M images use srcset."

Offer several sizes and let the browser pick, as described on MDN:

<img
  src="/img/boots-800.jpg"
  srcset="/img/boots-480.jpg 480w, /img/boots-800.jpg 800w, /img/boots-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 50vw"
  alt="Brown leather hiking boots on a wet rock"
  width="800" height="600">

srcset lists the files and their widths; sizes tells the browser how wide the image will be on screen. For fixed-size images like logos, use x descriptors (logo.png, [email protected] 2x). WordPress adds srcset to images inserted through the editor automatically; most image CDNs can generate the sizes for you. Add width and height too, so the browser reserves space and the layout doesn't jump.

"No favicon was found."

1. Create a square icon. Google requires a 1:1 ratio, at least 8 × 8 px, and recommends larger than 48 × 48 px (favicon guidelines).
2. Add it to the home page head:

<link rel="icon" href="/favicon.ico" sizes="48x48">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

1. Keep the URL stable and make sure robots.txt doesn't block the file; Google needs to crawl both the home page and the icon. Google supports one favicon per hostname.

"The page does not declare its language."

Set the language on the root element:

<html lang="en">

Use a valid BCP 47 code such as en, en-GB, pt-BR or tr. The lang attribute lets screen readers pronounce text correctly and is required for WCAG's "Language of Page" criterion (MDN). One clarification: Google says it detects a page's language from the text itself, not from lang, so this is an accessibility and browser fix more than a ranking one.

Beyond the four checks

Once the basics pass, work through the parts no automated checker fully covers:

• Content parity. Compare mobile and desktop for the same URL: main text, headings, images with the same alt text, structured data, title, meta description and robots meta tags. Google lists all of these in its mobile-first best practices.
• Lazy loading. Google warns: "Don't lazy-load primary content upon user interaction." Googlebot doesn't tap "Read more" or swipe carousels.
• Tap targets. Buttons and links of about 48 × 48 px with space between them. Lighthouse flags targets smaller than 48 × 48 px when they overlap neighbors.
• Text size. Body text that is readable without zooming. Lighthouse no longer audits font size, so check on a real phone.
• Pop-ups. Cookie banners and newsletter forms that cover the content on a small screen fall under Google's intrusive interstitials question.
• Speed on phones. Phone CPUs and networks are slower; check field data for mobile separately from desktop.

If you run a separate mobile site

Some older sites serve phones from a different address, such as m.example.com, or send different HTML to phones from the same URL (dynamic serving). Google still supports both, but they make parity harder, and its best practices add extra rules for separate URLs:

• The error status must be the same on both versions: a page that returns 404 on desktop should not return 200 on mobile, and the other way round.
• The mobile version should not use URL fragments (#) for content.
• robots.txt rules should match, so Googlebot can crawl the same sections on both hosts.
• Desktop pages point to their mobile versions with rel="alternate", and mobile pages point back with rel="canonical".
• hreflang needs to be set up separately for each version.

If you are planning a redesign anyway, moving to a responsive design on one URL removes this whole category of problems. Our free checker reads the version your server sends to its own crawler, so on a site with dynamic serving, test the phone version separately with Lighthouse or URL Inspection.

Worked example (hypothetical)

The following is a hypothetical example, not real data. Cobble & Crumb, an invented bakery with a hand-coded site from 2016, sees most visits arrive from phones and few orders follow. The mobile-friendly test reports:

• Mobile viewport, fail: no viewport tag.
• Responsive images: 1 of 14 images uses srcset.
• Favicon: passes.
• Page language, warning: no lang attribute.

The owner adds the viewport tag and lang="en", then opens the site on a phone: the text is now full size, but the 960 px fixed-width container forces sideways scrolling. A developer replaces the fixed width with max-width: 960px; width: 100%, adds max-width: 100% to images, stacks the three-column menu into one column below 600 px and enlarges the order buttons to 48 px high. The product photos get srcset with 480, 800 and 1600 px versions. A second run passes viewport and language, responsive images now passes with 13 of 14, and Lighthouse's viewport insight is clean. The remaining work is content: the mobile layout had hidden the opening hours, which go back on the page.

A 30-minute mobile checklist

1. Run the mobile-friendly test and fix a missing viewport tag first.
2. Open your top five pages on a real phone. Look for sideways scrolling, tiny text and buttons that are hard to hit.
3. Run Lighthouse in mobile mode on the same pages.
4. Compare mobile and desktop content for each page template.
5. Add srcset to large images, a favicon and the lang attribute.
6. Check phone Core Web Vitals and fix the slowest template.

How Searvia helps you stay mobile-ready

The free mobile-friendly test checks the basics on your home page, or any page you enter, in about 20 seconds, without sign-up, along with 34 other checks across search appearance, crawling, AI search readiness, speed and security.

For ongoing monitoring, a free Searvia account adds page speed tracking: lab scores and real Chrome user data for your most visited pages, rechecked every week, with fixes ordered by estimated time saved. The site audit crawls every page for the problems that hurt mobile and desktop alike, such as missing titles, broken links and thin content. For the rest of the technical checklist, see our technical SEO audit guide.