Mobile Friendly Test: How to Check Your Site's Mobile SEO After Google Retired Its Tool

A client emailed me recently with a simple question: "I wanted to run a mobile friendly test, but Google's tool no longer loads. What do I use now?" Because of the change, I hear some version of this every few weeks. The old one-click checker has gone. Mobile SEO, however, matters more than ever. In this guide I walk through the current ways to test, what each tool actually shows you, and the checklist my team uses on every audit.

What is a mobile friendly test and how do you run one today?

A mobile friendly test is a check that confirms a page is readable on a phone, usable with a finger, and serves the same content as the desktop version. Today you run it with a small toolkit instead of one button: Lighthouse, Chrome DevTools device mode, the URL Inspection tool in Search Console and a real phone.

In other words, no single pass or fail badge exists anymore. Instead, each tool answers a different question. Lighthouse lists technical problems. DevTools shows the layout at different screen widths. URL Inspection reveals how Google itself sees your page through its smartphone crawler.

From what I see in the field, businesses that repeat these four steps catch mobile issues before customers complain about them. Also, the cost is close to zero, because every tool on the list is free.

What happened to Google's Mobile-Friendly Test tool?

Google shut down the Mobile-Friendly Test tool, its API and the Mobile Usability report in Search Console on December 1, 2023. The company had announced the change months earlier. Its reasoning: many stronger resources for evaluating mobile usability now exist, with Chrome's Lighthouse named as the main one.

That decision does not mean mobile usability stopped mattering. Google's page experience documentation still asks site owners whether their content displays well on mobile devices. The same page also points you to Lighthouse for page experience improvements, including mobile usability.

So the tool disappeared, but the standard stayed. This is where I see the most common mistake. Some site owners assume that if Google removed the checker, Google no longer cares. That logic is backwards. Google already crawls your site through a phone's eyes.

One more practical note: plenty of old tutorials still describe the retired tool step by step. Those instructions no longer work, since the tool address is closed. So check the date on any guide you read. A mobile testing tutorial from before December 2023 probably relies on a tool that no longer exists. Also, some third party sites reuse the old name for their own checkers. Those do not reflect Google's official view.

How does mobile-first indexing change the stakes?

Google announced in October 2023 that the move to mobile-first indexing had essentially landed. Then, after July 5, 2024, it moved the last group of sites still crawled by the desktop crawler over to the smartphone crawler. As a result, Google now evaluates almost every site through its mobile version.

Google's mobile-first indexing best practices state it plainly: only the content shown on the mobile site counts for indexing. Therefore a paragraph, a table or an FAQ block that you hide on phones may effectively not exist for ranking purposes.

In practice, a mobile friendly test is no longer just a user experience check. It is also an indexing check. Anything missing on the phone is missing in Google's eyes too.

Which tools should you use for a mobile friendly test?

No single tool shows everything. That is why I combine the following tools on every audit. The table sums up which tool answers which question.

None of these tools costs money. Still, each one covers a different blind spot. For example, Lighthouse will never tell you that the on-screen keyboard hides your checkout button. You only notice that on a real device.

How do you run a mobile audit with Lighthouse?

Lighthouse is an open source auditing tool that ships inside Chrome. To use it, open the page in Chrome, press F12 to open developer tools and switch to the Lighthouse tab. Then pick "Mobile" as the device and start the analysis.

The report comes in four categories: performance, accessibility, best practices and SEO. Here a small detail matters a lot. Lighthouse 12 moved the viewport and font size audits from the SEO category into best practices. It also replaced the old tap targets audit with a target size audit under accessibility.

That means a perfect SEO score does not prove your page works on phones. Many mobile problems now show up in other categories. When I read a report, I follow this order:

• Best practices: viewport tag and legible font size warnings.
• Accessibility: target size, contrast and unlabeled form fields.
• Performance: LCP, CLS and total blocking time.
• SEO: crawlability, meta description and link text.

One more tip: run the audit in an incognito window. Otherwise, browser extensions can distort the results.

What should you look for in Chrome DevTools device mode?

Chrome DevTools device mode lets you view your page at different phone sizes. After opening developer tools, click the device icon or press Ctrl+Shift+M. Then choose a preset device or type a custom width.

The first thing I check is horizontal scrolling. If the page is wider than the screen, visitors have to swipe sideways to read. The cause is usually a fixed-width table, an oversized image or a broken margin.

I also run these checks in device mode:

1. Try the narrowest screens. Between 320 and 360 pixels, do the menu and headings break?
2. Turn on network throttling. On a slow connection, how long until the first screen becomes useful?
3. Rotate to landscape. Does a sticky header eat half the screen?
4. Open and close the menu. Does the hamburger icon respond to taps?

Keep in mind that device mode is a simulation. It does not reproduce real processor speed, real touch precision or every browser quirk. So the final check always happens on a physical device.

What does the URL Inspection tool in Search Console reveal?

URL Inspection is the only official way to see your page the way Google sees it. Google's URL Inspection help page explains that the live test runs with a smartphone crawler. For that reason, I consider it the closest successor to the old mobile test.

The workflow is simple. First, paste the address into the search bar at the top of Search Console and click "Test live URL". When the test finishes, open "View tested page". Next, you find the rendered HTML, a screenshot, the HTTP headers, JavaScript console output and any resources that failed to load.

The part I use most is the list of blocked or failed resources. For instance, if robots.txt blocks a CSS or JavaScript folder, Google renders a broken layout. In that case, review your rules with a robots.txt generator before anything else.

That said, the tool has limits. Each property has a daily quota of live tests. Also, a positive result does not guarantee the page will appear in search results. The tool measures technical access, not quality or ranking.

How should you read PageSpeed Insights and Core Web Vitals data?

PageSpeed Insights combines two different data types on one screen. The top section shows real user data from the Chrome UX Report, if your page has enough traffic. The lower section shows Lighthouse lab results.

Knowing the difference matters, because the two often disagree. A lab test simulates one device on one connection. Field data reflects what real visitors experienced over the previous 28 days. And field data is what Google's systems look at for page experience.

The Core Web Vitals guide on web.dev defines the "good" thresholds this way: Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less. Google assesses each threshold at the 75th percentile of page visits.

Also note that INP replaced First Input Delay in March 2024. If older reports still show FID, keep that change in mind when you compare numbers over time.

Why do you still need to test on a real phone?

No automated tool can fully imitate a customer using your site with their thumb. Therefore I test critical pages on at least two real phones: one iOS and one Android. If possible, one of them is a mid-range, slower device.

Specifically, real devices tend to surface these issues: the submit button disappearing behind the keyboard, a sticky chat bubble covering the menu, a cookie banner filling half the screen, and a date picker that refuses to open. Lighthouse flags none of these as errors.

Next, try loading the site over mobile data instead of office Wi-Fi. A site that feels instant on a fast network can feel sluggish on a weak signal. In my experience, this simple step surprises teams more than anything else.

When you pick test devices, do not rely on the newest phone in the office. Many of your customers likely use older, slower hardware. Check the device report in Google Analytics and plan tests around the most common models.

In short, tools give you measurements, while a real phone gives you your customer's perspective. You need both.

My mobile friendly test checklist: what my team checks every time

The list below covers the mobile friendly test steps I apply to every new site and after every major update. Work through it in order and you will not skip any fundamentals.

1. Does the page include a viewport tag that ties the layout width to the device width?
2. Can visitors read body text without zooming?
3. Are buttons and links large enough and spaced far enough apart for a thumb?
4. Does any horizontal scrolling appear?
5. Does the mobile version keep all main content, headings and FAQ blocks from desktop?
6. Do the title and meta description match on both versions?
7. Does the mobile HTML carry the same structured data?
8. Do both versions use identical robots meta tags?
9. Does primary content appear without waiting for a tap or swipe?
10. Do pop-ups cover the content?
11. Do Core Web Vitals field values sit in the "good" range?
12. Can you complete forms and checkout on a real phone without friction?

The sections below unpack each point. If you want this checklist running as a monthly routine across a larger site, we can set that up as part of my SEO consulting work.

How do you check the viewport, font size and tap targets?

Start with the viewport tag. First, the head of your page needs a viewport meta tag that contains width=device-width. Without it, the phone draws the page at desktop width and shrinks it, so the text becomes unreadable. Lighthouse reports this under best practices.

Next comes font size. Lighthouse warns you when most of the text on a page is too small to read comfortably. In practice, I keep body text large enough that nobody needs to pinch and zoom, and I leave generous line spacing.

Then check tap targets. The WCAG 2.2 target size criterion sets 24 by 24 CSS pixels as the minimum for touch targets. In other words, that figure is a floor, not a goal. For comfortable use, I design buttons clearly larger than that. Tightly packed footer links fail this check more often than anything else.

For example, if a phone number link sits right next to a WhatsApp button, visitors will hit the wrong one. That small slip translates directly into a lost lead.

How do you confirm content parity between mobile and desktop?

Under mobile-first indexing, the most expensive mistake is content that exists on desktop but not on the phone. The most practical way to verify parity is to open the HTML that Google rendered in URL Inspection and search for key passages. If headings, product descriptions or FAQ answers from desktop are missing there, you have a problem.

Google's guidance is explicit on several points. The mobile site should carry the same content, the same headings, equivalent titles and meta descriptions, the same structured data and the same robots meta tags. It also asks you not to lazy load primary content behind user interactions.

That is why I review every "let's simplify it on mobile" decision from the design team. Admittedly, simplifying is a good instinct. However, keeping content inside an accordion or tab is safer than deleting it. The text stays in the HTML, so Google can still read it.

To see how your title and description look on a phone, use the Google SERP preview tool. If tags are missing, the meta tag generator gives you a quick draft.

How do pop-ups and banners hurt the mobile experience?

Google's page experience documentation explicitly recommends avoiding intrusive interstitials. On a phone, the problem looks far worse than on desktop, because a single overlay can cover the entire screen.

In practice, these are the three cases I see most often: a newsletter pop-up that appears the moment the page loads, a cookie banner that covers most of the screen, and a promo overlay with a close button nobody can find. Of course you keep a legally required cookie notice. Still, you can design it so it does not hide the content.

Also count your sticky elements. A sticky header, a sticky bottom bar, a chat bubble and a cookie banner all at once leave almost no room for content. During a mobile test I always look at how much of the screen actually shows content.

I covered the conversion side of this in my guide on reducing bounce rate on a business website. Put simply, if visitors see obstacles instead of content in the first second, they leave.

How do you audit images, lazy loading and structured data on mobile?

Images carry the heaviest weight in mobile speed. Sending a 3000 pixel image to a phone that displays it at 400 pixels wastes bandwidth and slows down LCP. So serve images in sizes that fit the screen and compress them. For a quick fix, an image resizer does the job.

With lazy loading, watch the balance. Deferring images below the fold is good practice, so keep doing it. However, lazy loading the main image in the first screen, which is often the LCP element, slows the page down. Lighthouse flags this among its performance warnings.

On the structured data side, the check is simple. Any Breadcrumb, Product or FAQ markup you have on desktop should also sit in the mobile HTML. You confirm this in the HTML that URL Inspection shows, or in the Rich Results Test.

Also make sure image alt text matches across both versions. Google's mobile-first indexing guide mentions this detail separately.

How do you test forms and conversion steps on mobile?

Mobile SEO brings the traffic. Yet forms and checkout steps are what turn that traffic into customers. For that reason, I believe every mobile friendly test should end with a form. I fill in and submit each critical form on a real phone, start to finish.

These are the points I check:

• Does the phone field bring up a numeric keypad?
• Does the email field show a keyboard with the @ sign?
• Do error messages appear next to the field in plain language?
• Does the submit button stay reachable while the keyboard is open?
• After submission, does the thank you screen load and does the conversion tag fire?

The last item gets missed all the time. The form works on the phone, but a broken redirect to the thank you page means the ad platform never sees the conversion. Check redirect chains with a redirect checker. For form design details, see my article on lead form design for bookings, quotes and demos.

Which problems should you fix first after a mobile audit?

A mobile audit usually produces dozens of warnings. Trying to fix everything at once exhausts the team and delays the work that matters. That is why I sort findings into three groups.

The first group covers indexing problems: missing content on mobile, blocked CSS or JavaScript files and mismatched robots tags. These cause Google to misunderstand the page, so they come first.

The second group covers usability blockers: horizontal scrolling, pop-ups that hide content, a broken menu and forms that fail to submit. Because of that, these cost you customers directly.

The third group covers performance and polish: Core Web Vitals improvements, image optimization and minor accessibility warnings. They matter. Still, focusing on them before the first two groups is like painting the walls of a house with a leaking roof.

This order of priorities also matches the approach I describe in my article on balancing UX and SEO.

Which pages deserve a mobile friendly test first?

Testing every page every month is not realistic, because resources are limited. So I start with templates. On an online store, the home page, category page, product page, cart and checkout usually make up five core templates. As a result, a bug in one template affects every page that uses it.

The second priority is pages that bring traffic and revenue. In the Search Console Performance report, filter by device to "Mobile" and list the pages with the most clicks. That way your testing effort goes where real visitors actually land.

The third priority is ad landing pages. If most of the clicks you pay for in Google Ads come from phones, every mobile bug on that page burns budget. For a broader view of the technical side, my piece on technical SEO after AI works as a good companion.

How often should you repeat a mobile friendly test?

A mobile friendly test is not a one-time job. A theme update, a new plugin, a campaign banner or a new chat widget can break a page that worked fine yesterday. Therefore I recommend putting the test on a calendar.

The rhythm I use comes from field experience, not a guarantee, but it works as a starting point for most businesses: a Lighthouse and real phone check on critical pages after every design or plugin change, a monthly look at the Core Web Vitals report in Search Console, and a full audit of every template once a quarter.

On the other hand, site redesigns carry their own risk. Finish mobile testing before the new design goes live. I collected all the steps for that in my guide on protecting SEO during a website redesign.

Finally, log your results in a simple spreadsheet. Date, page, tool and finding columns are enough. When a problem comes back, you will quickly see what changed.

How do you bring mobile testing into the design phase?

The cheapest mobile fix is buggy code that never gets written. That is why I push mobile checks into the design phase. When the design team draws the phone layout first and then expands to desktop, many problems never appear.

During development, set simple acceptance criteria for every page template: no horizontal scrolling, main content present in the mobile HTML, buttons easy to tap, and no viewport or font size warnings in Lighthouse best practices. A template that fails these criteria does not ship.

I apply this rule in my own web design projects. As a result, the list of post-launch mobile fixes stays short, and clients start with a site that works properly on phones from day one.

What mistakes do I see most often in mobile SEO audits?

Over the years, I have noticed that a few mistakes show up on almost every site I audit. Knowing them shortens your testing time, because you know where to look first.

• A large comparison table built for desktop that overflows the phone screen.
• Category links missing from the mobile menu, which weakens internal linking.
• Customer reviews and FAQ blocks hidden on phones.
• A sticky chat bubble sitting on top of the submit button.
• Redirect chaos on older sites that still use a separate mobile subdomain.

What these mistakes share is that none of them stands out clearly in one automated score. For instance, Lighthouse does not always catch an overflowing table, yet you spot it in two seconds in DevTools device mode. Likewise, you only find a missing menu link when you open the menu and check each item.

So treat tool output as a starting point. You find the real issues when you use the page the way a customer would. On every audit, I spend at least ten minutes just browsing on a phone and taking notes.

Conclusion: turn mobile SEO checks into a routine

Google's old mobile test is gone, but mobile usability has never mattered more. Google crawls, indexes and evaluates your site through a phone. Consequently, the mobile check sits at the center of SEO, not a side task.

To sum up, here is your roadmap: see technical warnings in Lighthouse, test the layout at different widths in DevTools, look through Google's eyes with URL Inspection, read real user data in PageSpeed Insights and give the final word to a real phone. Put the checklist on a calendar and you will catch problems before your customers do.

If you want to run this audit on your own site together, get in touch. In the first call we can review your three most important templates side by side.