Mobile Friendly Test

What is a mobile friendly test and what does this tool measure?

A mobile friendly test checks whether a web page is easy to read and use on a phone. This tool opens a single address with Lighthouse on Google PageSpeed Insights, and emulates a mid-range phone on a slow mobile network. Then it sums up the result in one verdict. The verdict rests on three core checks:

• Viewport tag: does the page open at phone width, or as a shrunken desktop layout?
• Font size: can visitors read the text without zooming?
• Tap targets: can visitors hit buttons and links comfortably with a finger?

On top of that, one screen shows the zoom setting and the horizontal scroll risk. It also shows a mobile screenshot, a loading filmstrip, four Lighthouse scores and Core Web Vitals. My team and I run this test in the first week of every SEO consulting project. That is because mobile problems rarely show up on a desktop screen, while most customers open the site on a phone.

Google retired its mobile friendly test: what should you use now?

Google announced the decision in April 2023. It shut down the Mobile-Friendly Test, its API and the Search Console Mobile Usability report on December 1, 2023. The reasoning was simple: since the tool first launched, far more thorough resources for evaluating mobile usability had appeared. Google therefore pointed site owners to Lighthouse from Chrome.

This tool fills that gap. You can also run Lighthouse on your own computer from Chrome DevTools; however, the result then depends on your machine and your network. PageSpeed Insights runs the test on Google's servers with a standard mobile profile, and it also adds real-user data when that exists. I explain how to read a Lighthouse report step by step in my article on the Google Lighthouse performance test.

One detail matters here: Lighthouse 13, released in October 2025, dropped the old font size audit. It also turned the viewport audit into a new insight audit. That is why the tool also reads the viewport tag from our own server. If no font size audit comes back, the row shows up as a note that stays out of the verdict.

Does being mobile friendly affect Google rankings?

Indirectly, but strongly. Since July 5, 2024, Google crawls every site with its smartphone crawler and indexes the mobile version of each page. So text, headings or structured data that are missing on mobile may not exist for Google either. Content that does not load on a mobile device at all cannot make it into the index.

On the other hand, Google states plainly in its page experience documentation that Core Web Vitals are part of its ranking systems. The same page also says that good scores do not guarantee top positions. The most relevant content can still rank even when its page experience is weak. My reading from the field: mobile usability and speed remove obstacles in front of good content; they do not lift weak content on their own.

I cover how speed affects rankings and conversions, with examples, in how site speed affects SEO.

Why does the viewport tag matter so much?

The viewport tag tells the browser how wide to lay out the page. Without it, some mobile browsers render the page in a virtual desktop width of 980 pixels and then shrink it to fit the screen. The result is a tiny desktop view that nobody can read without zooming. You spot this right away in the tool's screenshot.

The correct tag is a single line: <meta name="viewport" content="width=device-width, initial-scale=1">. Still, I keep seeing three mistakes in that one line:

• Fixed width: a value such as width=980 forces the phone into a desktop width.
• Zoom lock: user-scalable=no, or a maximum-scale below 2, stops people with low vision from enlarging text; WCAG asks for at least 2x scaling.
• Duplicate tags: when a theme and a plugin each print a tag, the browser applies the last one, so your setting can quietly lose.

To set the tag together with your title and description tags, use the meta tag generator.

What sizes are right for tap targets and font size?

For tap targets, the current yardstick is WCAG 2.2 criterion 2.5.8. Each target should be at least 24 × 24 CSS pixels. Otherwise, small targets need enough space that 24 pixel circles around them do not overlap. The Lighthouse target-size audit checks exactly this rule. For important buttons, the 44 × 44 pixels of criterion 2.5.5 is a more comfortable goal. The old Lighthouse tap-targets audit used 48 × 48 pixels.

In practice, these are the small targets I catch most often: crowded footer links, social media icons, carousel dots and links placed side by side inside text. Moreover, the fix rarely breaks the design; adding padding enlarges the tappable area while the visible icon stays the same.

For font size, Lighthouse used to expect at least 60 percent of the text to be 12 pixels or larger. Lighthouse 13 removed that audit, so there is no automatic score anymore. I recommend never going below 16 pixels for body text. I also judge it from the screenshot: if you cannot read the text without zooming, neither can your visitor.

How should you read Core Web Vitals results?

The tool shows two kinds of data and always labels which one you are looking at. The Real users tab comes from the Chrome User Experience Report (CrUX). It holds data from real Chrome users who opened your page over the last 28 days, and PageSpeed Insights reports it at the 75th percentile. If the page lacks enough data, PageSpeed Insights falls back to the whole origin; if that also falls short, no real-user data appears.

The Lab tab is a single Lighthouse run. Because nobody actually taps anything in the lab, the test cannot measure INP; instead, the tool shows Total Blocking Time (TBT). The thresholds:

• LCP: 2.5 seconds or less is good, over 4 seconds is poor.
• INP: 200 ms or less is good, over 500 ms is poor.
• CLS: 0.1 or less is good, over 0.25 is poor.
• TBT: 200 ms or less is good, over 600 ms is poor.

When the two disagree, trust the real-user data, because that is the experience Google evaluates. The lab, in turn, is ideal for finding the cause of a problem and trying a fix right away. I gathered all user experience signals in my article on SEO and UX page experience factors.

What should you fix first after a mobile friendly test?

I turn a test result into a to-do list in this order.

1. Viewport: if the tag is missing or has a fixed width, fix it first; every other measurement depends on it.
2. Horizontal overflow: if the screenshot shows an image, table or iframe spilling to the right, limit its width with a percentage.
3. Tap targets: add padding to the listed elements or space them further apart.
4. LCP: compress the largest image and serve it at the right size; the image resizer is enough for that.
5. CLS and INP: give images dimensions and defer heavy third-party scripts.

Problems that come from the theme keep coming back after every patch. In that case, moving to a mobile-first structure is cheaper in the long run; I explain the difference in what is mobile first design. If you need a build from scratch, my team and I make a passing mobile test a delivery condition in every web design project.

What is mobile-first indexing and what does it change for your site?

Mobile-first indexing means Google uses the mobile version of a page's content for indexing and ranking. Google rolled it out over several years and announced in October 2023 that the move was complete. Then, after July 5, 2024, it started crawling the remaining sites with Googlebot Smartphone only. In other words, a paragraph, heading or piece of structured data that exists on desktop but not on mobile no longer exists for Google.

Google Search Central's best practices boil down to this:

• the same content and the same clear headings on mobile and desktop,
• equivalent titles and meta descriptions, and the same robots meta tags,
• the same structured data on both versions,
• lazy loading that does not wait for a swipe or click, and images with the same alt text.

With responsive design these conditions usually hold on their own, because both devices get the same HTML. The risk lies in dynamic serving, separate mobile URLs and themes that trim content for mobile. We explain why structured data matters so much in our schema markup guide.

How do you check the mobile and desktop difference with this tool?

Pick the Mobile-first indexing mode in the strip at the top of the tool and enter the address. Our server fetches the same page twice: first as Googlebot Smartphone, then as Googlebot Desktop. It then lines up 16 checks side by side: status code and redirects, title, meta description, robots, canonical, hreflang, H1, H2 and H3 headings, visible word count, internal links, images and alt text, JSON-LD types, lazy loading, viewport and serving method.

The parity score is a weighted average of these checks. Differences that can drop a page from the index, such as noindex or an error code on mobile, cost the most; lost text, structured data and headings follow. A score of 90 or more means the two versions are practically the same. By contrast, anything under 70 shows that the mobile template is losing content.

Keep one limit in mind: the tool reads the raw HTML the server returns and does not run JavaScript. If your content loads later in the browser, confirm the result with URL Inspection in Search Console. Also, some security layers recognise a fake Googlebot by its IP address and block it; the tool reports that case separately. For the rest of the page, run the SEO checker.