Canonical: https://www.strataigize.com/insights/check-mobile-friendliness-website/
Description: Google retired its Mobile-Friendly Test. The free mobile-friendly test tools that replaced it, a PageSpeed Insights API example, and the thresholds to pass.
Published: 2025-12-15T00:00:00.000Z
Modified: 2026-09-06T00:00:00.000Z

[← Blog](https://www.strataigize.com/insights/)

![](https://www.strataigize.com/blog/real/cover-check-mobile-friendliness-website.webp)

# Mobile-Friendly Test 2026: Free Tools and the PageSpeed API

By [**Ian McGavin**](https://www.strataigize.com/about/team/ian/), Founder & CMO · Published December 15, 2025 · Updated September 6, 2026 · 15 min read

To check mobile friendliness in 2026, run your URL through Google PageSpeed Insights, audit it with Lighthouse in Chrome DevTools, preview breakpoints in DevTools device mode, review the Core Web Vitals report in Search Console, then confirm everything on a real phone. Google retired its standalone Mobile-Friendly Test in December 2023, so these are the tools that replaced it.

In this article

1.  [Which mobile-friendly checkers still work in 2026](https://www.strataigize.com/insights/check-mobile-friendliness-website/#which-mobile-friendly-checkers-still-work-in-2026)
2.  [Run a mobile audit with PageSpeed Insights and Lighthouse](https://www.strataigize.com/insights/check-mobile-friendliness-website/#run-a-mobile-audit-with-pagespeed-insights-and-lighthouse)
3.  [Is there a replacement for the Mobile-Friendly Test API?](https://www.strataigize.com/insights/check-mobile-friendliness-website/#is-there-a-replacement-for-the-mobile-friendly-test-api)
4.  [Running Lighthouse locally](https://www.strataigize.com/insights/check-mobile-friendliness-website/#running-lighthouse-locally)
5.  [Chrome DevTools device emulation walkthrough](https://www.strataigize.com/insights/check-mobile-friendliness-website/#chrome-devtools-device-emulation-walkthrough)
6.  [Reading Core Web Vitals mobile data in Search Console](https://www.strataigize.com/insights/check-mobile-friendliness-website/#reading-core-web-vitals-mobile-data-in-search-console)
7.  [Most common mobile failures and fixes](https://www.strataigize.com/insights/check-mobile-friendliness-website/#most-common-mobile-failures-and-fixes)
8.  [The audit we run, step by step](https://www.strataigize.com/insights/check-mobile-friendliness-website/#the-audit-we-run-step-by-step)
9.  [What if you use WordPress or Shopify](https://www.strataigize.com/insights/check-mobile-friendliness-website/#what-if-you-use-wordpress-or-shopify)
10.  [FAQ](https://www.strataigize.com/insights/check-mobile-friendliness-website/#faq)
11.  [Four tools replaced the one badge](https://www.strataigize.com/insights/check-mobile-friendliness-website/#four-tools-replaced-the-one-badge)

[Add us as a preferred source on Google](https://www.google.com/preferences/source?q=strataigize.com)

A free Google setting to see more of our relevant articles in your own search experience. You can change it any time.

Google retired its standalone Mobile-Friendly Test in December 2023, but you can still check mobile usability for free. Use PageSpeed Insights and Lighthouse for performance diagnostics, Chrome DevTools for layout checks, and a real phone for navigation and forms. These checks answer different questions. A fast page can still have buttons you cannot reach, and a usable page can still load slowly.

> Want the verdict in 20 seconds? Run our free [Mobile-Friendly Test](https://www.strataigize.com/tools/mobile-friendly-test/): paste a URL and get the viewport, fixed-width, tiny-text, weight and crawl checks scored, with the fix for each. No email.

![PageSpeed Insights mobile report showing Core Web Vitals field assessment and a Lighthouse performance score, the check that replaced Google's retired Mobile-Friendly Test](https://www.strataigize.com/blog/real/pagespeed-result.webp)

## Which mobile-friendly checkers still work in 2026

The advice to “run Google’s Mobile-Friendly Test” is dead. Google announced it was [sunsetting Search Console’s Mobile Usability report, the Mobile-Friendly Test tool, and the Mobile-Friendly Test API starting December 1, 2023](https://developers.google.com/search/blog/2023/04/page-experience-in-search), and the sunset was confirmed in public coverage on [December 4, 2023](https://searchengineland.com/google-officially-drops-mobile-usability-report-mobile-friendly-test-tool-and-mobile-friendly-test-api-435377). Google’s stated reason in that announcement: mobile usability remains part of its page experience guidance, but other resources have emerged since 2015, “including Lighthouse from Chrome.”

Google also [scrubbed every mention of the tool from Search help docs on December 1, 2023](https://www.seroundtable.com/google-search-consoles-mobile-usability-report-mobile-friendly-tests-are-gone-36497.html) and redirected Search Console mobile usability URLs to the property overview. In the [April 2023 announcement](https://developers.google.com/search/blog/2023/04/page-experience-in-search), Google points people at [Lighthouse](https://developer.chrome.com/docs/lighthouse/overview) as the replacement. A guide still offering the retired tool as a live option is out of date.

One separate checker remains available: [Bing’s Mobile Friendliness Test Tool](https://www.bing.com/webmaster/tools/mobile-friendliness). It checks how Bing views the page on mobile, including viewport configuration, content width, readability and tap spacing. Its verdict does not establish how Google or an AI assistant will rank or cite the page.

| Tool | Cost | What it measures | Limits |
| --- | --- | --- | --- |
| PageSpeed Insights | Free | Lab Lighthouse mobile run plus real-user Core Web Vitals | Field data needs traffic volume; shareable report links persist as snapshots for [up to 30 days](https://developers.google.com/speed/docs/insights/release_notes) |
| Lighthouse in Chrome DevTools | Free | Mobile-emulated performance, accessibility, best practices, SEO, tap targets | Lab only; results vary with your machine’s load |
| Chrome DevTools device mode | Free | Layout, overflow, and fixed elements at real viewport sizes | Emulation, not real hardware or real touch |
| Search Console Core Web Vitals | Free | Site-wide mobile field data grouped by URL group | 28-day rolling window; no tap-target or viewport checks |
| Bing Mobile Friendliness Test | Free | Viewport, content width, readability, tap spacing, plug-ins | Bing’s verdict, not Google’s ranking input |
| Real devices or BrowserStack | Free tier, paid plans | True touch, gestures, browser rendering quirks | Device breadth costs money and time |
| Google Mobile-Friendly Test | Gone | Nothing | Retired December 1, 2023 |

### Mobile usability and mobile-first indexing are different checks

Google uses the mobile version of a page’s content for indexing and ranking. Its [mobile-first indexing guidance](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing) supports responsive design, dynamic serving and separate mobile URLs. Responsive design is the recommended option because it is easier to implement and maintain.

Check that Googlebot can access the content, images and metadata on mobile. Then check how easily a person can use them. A blocked mobile page is a crawling problem; a cramped button is a usability problem. Neither a Lighthouse score nor a tap-target measurement alone tells you whether a page will be indexed.

> Want expert eyes on your site instead of another audit tab? See our [website optimization services](https://www.strataigize.com/services/website-optimization/).

## Run a mobile audit with PageSpeed Insights and Lighthouse

Start with [PageSpeed Insights](https://pagespeed.web.dev/). Paste a URL, run it, and read the Mobile tab before the Desktop tab.

The report splits into two halves that people constantly confuse:

-   **Field data** at the top: real Chrome user measurements from the Chrome UX Report, updated daily on a [rolling 28-day window](https://developer.chrome.com/docs/crux/methodology/tools). This is what Google’s page experience signals actually use.
-   **Lab data** below: a single simulated Lighthouse run on Google’s servers. Useful for diagnostics, not a verdict on real users.

To pass a complete three-metric Core Web Vitals assessment, a page needs the good threshold at the [75th percentile for all three metrics](https://web.dev/articles/vitals). Missing field data means the report cannot provide that complete assessment; it is not evidence that the page failed. Lighthouse cannot measure field INP from a single navigation run.

| Metric | Good | Poor |
| --- | --- | --- |
| Largest Contentful Paint (LCP) | 2.5s or under | over 4.0s |
| Interaction to Next Paint (INP) | 200ms or under | over 500ms |
| Cumulative Layout Shift (CLS) | 0.1 or under | over 0.25 |

Source: [web.dev Core Web Vitals thresholds](https://web.dev/articles/defining-core-web-vitals-thresholds), current as of 2026. INP [replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024](https://web.dev/blog/inp-cwv-march-12), so ignore any checklist that still tells you to optimize FID.

### Two PageSpeed Insights changes that shifted the goalposts

On [December 5, 2024, PageSpeed Insights adjusted how hard it throttles the CPU (the processor)](https://developers.google.com/speed/docs/insights/release_notes), which generally increased Total Blocking Time in mobile lab runs. Field and desktop results were unaffected. If your mobile lab score dropped and nothing shipped, that is a plausible cause.

PageSpeed Insights (PSI) and its API [moved to Lighthouse 13.0 on October 20, 2025](https://developers.google.com/speed/docs/insights/release_notes). Versions can change which diagnostics you see, so record the Lighthouse version with each result. For ongoing real-user monitoring, Google recommends the [CrUX API or CrUX History API](https://developers.google.com/speed/docs/insights/v5/get-started): it plans to stop including CrUX field data in the PSI API.

## Is there a replacement for the Mobile-Friendly Test API?

The old Mobile-Friendly Test API was retired with the tool. The **PageSpeed Insights API** can automate a mobile Lighthouse run, but it does not reproduce the old mobile-friendly pass/fail result. You still need layout and interaction checks.

This request asks for mobile performance, accessibility and SEO diagnostics. Replace the example URL with a public page you want to test:

```
curl --get \
  'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode 'url=https://example.com/' \
  --data-urlencode 'strategy=mobile' \
  --data-urlencode 'category=performance' \
  --data-urlencode 'category=accessibility' \
  --data-urlencode 'category=seo'
```

Google’s [getting-started guide](https://developers.google.com/speed/docs/insights/v5/get-started) permits trying the API without a key and recommends a key for frequent automated requests. Check the current quota for your project before scheduling a batch. If the response is HTTP 429, investigate the quota instead of treating it as a result for the tested page. The [API reference](https://developers.google.com/speed/docs/insights/v5/reference/pagespeedapi/runpagespeed) documents the parameters and response fields.

Read `lighthouseResult.categories` for category scores and `lighthouseResult.audits` for the individual results. Scores use a zero-to-one scale; 0.92 corresponds to 92 out of 100. Save `fetchTime` and `lighthouseVersion` with the tested URL so later comparisons use a known run. Handle HTTP errors and `runtimeError` before treating a response as an audit.

For field performance, use the [CrUX API](https://developer.chrome.com/docs/crux/api) or [CrUX History API](https://developer.chrome.com/docs/crux/history-api). A URL may have insufficient real-user data. Keep that state separate from a poor result, and do not report a lab score as a field Core Web Vitals pass.

## Running Lighthouse locally

Lighthouse ships inside Chrome DevTools. Open your page, right click, choose Inspect, open the **Lighthouse** panel, select **Mobile**, then click Generate report. It [runs against your installed Chrome and never beacons results to a remote server](https://github.com/GoogleChrome/lighthouse), so you can audit staging and password-protected builds that PSI cannot reach.

The mobile preset is not a guess. Lighthouse applies a [4x CPU slowdown multiplier](https://github.com/GoogleChrome/lighthouse/blob/main/docs/throttling.md) to drag a desktop CPU into mid-tier mobile range, plus a “Slow 4G” network preset that represents the bottom quarter of 4G connections. Device emulation uses a Moto G Power profile at a [412 by 823 viewport with a 1.75 device scale factor](https://github.com/GoogleChrome/lighthouse/blob/main/core/config/constants.js), mobile and touch enabled, per Lighthouse’s own `constants.js` (an earlier version of this article cited 2.625, the scale factor of the older Moto G4 profile that Lighthouse retired, not the current value).

[Lighthouse 13 replaced many performance audits with DevTools-aligned insights](https://developer.chrome.com/blog/lighthouse-13-0), keeping `unsized-images` and `non-composited-animations` as diagnostics. It also removed the old font-size audit. A removed diagnostic does not make illegible text acceptable; check the page’s actual text on a phone.

## Chrome DevTools device emulation walkthrough

Scores tell you speed. Emulation tells you whether the page is usable. Run both.

1.  Open the page in Chrome and press the Inspect shortcut, then toggle the **Device Toolbar**.
2.  Pick a narrow viewport first. Test at 360 by 800 and 390 by 844, then step up through tablet widths.
3.  Set throttling to **Mid-tier mobile** or apply Slow 4G plus 4x CPU manually to match the Lighthouse profile.
4.  Rotate to landscape. Open your main navigation, a form, and a checkout or contact step in each orientation.
5.  Watch the Elements panel while you resize to find which container overflows.

What emulation catches that a score never will:

-   Small tap targets crowded against a neighbour, including cases covered by the [Lighthouse tap-targets audit](https://developer.chrome.com/docs/lighthouse/seo/tap-targets)
-   Horizontal overflow from a fixed-width table, embed, or oversized image
-   Sticky headers and cookie banners eating half the viewport on a short screen
-   Modals with a close button pushed off-canvas
-   Inputs that trigger the wrong keyboard or zoom on focus

For comfortable touch controls, aim for 48 by 48 CSS pixels where the layout allows. Lighthouse’s documented rule considers both target size and overlap with nearby targets; it does not fail every smaller control. The separate [WCAG 2.2 AA target-size criterion](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) uses 24 by 24 CSS pixels with spacing and other exceptions. Neither is a universal Google ranking threshold.

Know the ceiling. Emulation resizes a desktop browser and fakes a slow CPU. It does not reproduce real touch latency, iOS Safari quirks, thumb reach, or the way a mid-range Android handles a heavy script under thermal throttling. Finish every audit on an actual phone.

## Reading Core Web Vitals mobile data in Search Console

The old Mobile Usability report is gone. Use Search Console’s Core Web Vitals report for real-user performance, then inspect layout and interactions separately.

Open [Search Console](https://search.google.com/search-console), go to Core Web Vitals, and work the Mobile report. Google [splits the overview by device, groups URLs that deliver similar experiences, and assigns each group the status of its worst-performing metric](https://support.google.com/webmasters/answer/9205520). So one bad metric on a template drags every URL in that template into Poor.

How we read it:

-   Click **Open report** next to the mobile chart, then toggle the Poor, Needs improvement, and Good tabs.
-   Read the “Why URLs aren’t considered good” table. It names the failing metric and the threshold breached.
-   Fix the template, not the URL. Group-level status means one template fix moves many pages.
-   Use **Start Tracking** after deploying. Google runs a [28-day monitoring session and marks the issue fixed only if it stays absent for the full window](https://support.google.com/webmasters/answer/9205520).

Two caveats. The data is a rolling 28-day aggregate, so a fix shipped Tuesday will not show Wednesday. And Google states plainly that [PageSpeed Insights data might vary from the Core Web Vitals report](https://support.google.com/webmasters/answer/9205520), because one is a lab run on one device profile and the other is thousands of real sessions. When they disagree, trust the field data and use the lab run to find the cause. [web.dev explains the lab versus field split](https://web.dev/articles/lab-and-field-data-differences) in more depth. The same metrics sit inside how we approach [website optimization](https://www.strataigize.com/services/website-optimization/).

## Most common mobile failures and fixes

These are the failures the tools above are built to catch, with the threshold or rule each one uses.

| Failure | Detected by | Threshold or rule | Fix |
| --- | --- | --- | --- |
| Missing or misconfigured viewport meta tag | DevTools emulation, Bing test | Desktop layout forced onto a phone | Add `<meta name="viewport" content="width=device-width, initial-scale=1">` |
| Slow hero LCP image | PSI field and lab, Search Console | LCP must be 2.5s or under at p75 | Compress, serve modern formats, preload the LCP element, drop lazy loading on it |
| Images and embeds without dimensions | Lighthouse `unsized-images` diagnostic | CLS must be 0.1 or under at p75 | Set width and height or aspect-ratio on every media element |
| Heavy third-party JavaScript | Lighthouse for blocking work; CrUX or real-user monitoring for INP | Good field INP is 200ms or under at p75 | Break up long tasks; review scripts while preserving consent and required functionality |
| Tap targets too small or too close | Lighthouse tap-targets audit and real-phone checks | Size and nearby-target overlap both matter | Enlarge controls and add spacing; 48px is a comfortable target |
| Content wider than the screen | DevTools device mode, Bing test | No horizontal scroll on a 360px viewport | Fluid tables, `max-width: 100%` on media, no fixed pixel containers |
| Intrusive interstitials | Manual check on a real phone | Content blocked on load | Delay, shrink, or remove full-screen popups |
| Late-loading fonts and injected banners | Search Console CLS group | CLS at p75 | Preload fonts, reserve space for banners and ads |

Notice which tool detects what. No single checker covers the list, which is exactly why the old single pass or fail badge was never enough.

## The audit we run, step by step

Here is the sequence we use on our own site and on client sites, in order.

1.  **Pick three URLs, not one.** Homepage, a top service or product page, and a blog post. Templates fail differently.
2.  **Search Console first.** Core Web Vitals, Mobile view. Note which URL groups sit in Poor or Needs improvement and which metric is named. This is real users, so it sets priority.
3.  **PSI on one URL from each failing group.** Compare field data to lab data. If field says Poor and lab says fine, look for third-party scripts, logged-in states, or slow origins that a clean lab run never sees.
4.  **Lighthouse locally on the same three URLs.** Mobile preset. Read the tap-targets and `unsized-images` diagnostics, and the Accessibility panel for contrast failures.
5.  **DevTools device mode at 360 by 800.** Open the nav, a form, and the primary conversion step. Rotate. Look for overflow and blocked content.
6.  **Bing’s Mobile Friendliness Test** on the same URLs for a second crawler’s verdict on viewport, width, readability, and tap spacing.
7.  **One real phone, mid-range Android if you have one.** Load over cellular, not office wifi. Complete the conversion action end to end.
8.  **Ship template fixes, then Start Tracking in Search Console** and expect 28 days before validation clears.

### Why field data and lab data disagree

Google is explicit that [PageSpeed Insights data might vary from the Core Web Vitals report](https://support.google.com/webmasters/answer/9205520). Lab data is one simulated run on one device profile. Field data is a 28-day rolling aggregate of real Chrome users. [web.dev’s guide to lab versus field data](https://web.dev/articles/lab-and-field-data-differences) names the usual causes: real devices and networks vary more than the lab, third-party scripts behave differently for real users, cache and back-forward cache change returning visits, and CrUX only reports URLs with enough traffic. When they disagree, treat field data as the verdict and the lab run as the diagnostic.

When we review a site we look at Search Console field data first, then use PSI and Lighthouse to name the element or script. Google’s own optimize guides are the playbooks:

-   Slow LCP: [optimize Largest Contentful Paint](https://web.dev/articles/optimize-lcp). Compress the hero, serve a modern format, preload the LCP element, and do not lazy-load it.
-   High INP: [optimize Interaction to Next Paint](https://web.dev/articles/optimize-inp). Break up long tasks and defer or remove third-party JavaScript that blocks the main thread.
-   High CLS: [optimize Cumulative Layout Shift](https://web.dev/articles/optimize-cls). Set width, height, or aspect-ratio on images and embeds so the layout does not jump when they load.

Search Console [groups URLs that deliver similar experiences and assigns each group the status of its worst-performing metric](https://support.google.com/webmasters/answer/9205520). One template fix, such as image dimensions on a shared card component, can move many URLs at once. After you ship, use **Start Tracking** and wait the full 28-day window before Google marks the issue fixed.

Repeat the eight-step sequence after theme changes, plugin or app installs, and any tag manager deployment, plus a scheduled quarterly pass. Third-party scripts are a documented INP risk in [Google’s INP guidance](https://web.dev/articles/optimize-inp), which is why step 3 compares field data to a clean lab run. For crawl, indexing, and on-page work around this mobile check, see our [search engine optimization](https://www.strataigize.com/services/website-optimization/search-engine-optimization/) service.

## What if you use WordPress or Shopify

Both platforms get you most of the way with configuration rather than code:

-   A responsive theme, tested at 360px before you commit to it
-   Native lazy loading everywhere except the LCP image
-   Modern image formats served at correct dimensions, not desktop files shrunk with CSS (cascading style sheets)
-   Shopify Online Store 2.0 templates and section-level image sizing
-   An audit of installed apps and plugins, since each one usually adds render-blocking JavaScript

Re-run Lighthouse after every theme or app change. That is where mobile scores quietly slip. If the theme itself is the ceiling, the fix is a rebuild on a modern framework with performance and SEO engineered in from the start, which is what our [website development service](https://www.strataigize.com/services/development-services/website-development/) delivers.

## FAQ

### How do I check mobile friendliness now that Google’s test is gone?

Run Lighthouse in Chrome DevTools on the Mobile preset, check the Mobile tab in PageSpeed Insights, read the Core Web Vitals mobile report in Search Console, then confirm on a real phone. Bing’s Mobile Friendliness Test still gives a pass or fail verdict if you want one.

### What is the difference between mobile-friendly and responsive?

Mobile-friendly means the page is usable on a phone. Responsive design adapts the same page to different viewports with fluid layouts and CSS media queries. Google [recommends responsive design for easier maintenance](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing), but also supports dynamic serving and separate mobile URLs.

### Do I need a separate mobile website?

No. A single responsive URL is simpler to maintain, avoids duplicate content handling, and gives one set of signals for SEO and [generative engine optimization](https://www.strataigize.com/insights/what-is-generative-engine-optimization/).

### Does Google penalize non-mobile-friendly websites?

Check content access and user experience separately. Google needs to access and render your mobile content for indexing. Core Web Vitals are used in ranking, but [Google still seeks relevant content even when page experience is sub-par](https://developers.google.com/search/docs/appearance/page-experience). A poor mobile score does not by itself prove deindexing, a penalty or a particular loss of rankings.

### Why do PageSpeed Insights and Search Console disagree?

Google states the two can differ. PSI lab data is one simulated run on one device profile. Search Console reports a 28-day rolling aggregate of real Chrome users across a URL group. [Google’s Core Web Vitals report documentation](https://support.google.com/webmasters/answer/9205520) and [web.dev’s lab versus field article](https://web.dev/articles/lab-and-field-data-differences) both tell you to treat field data as the verdict and lab data as the diagnostic.

## Four tools replaced the one badge

The single pass or fail badge is gone and it is not coming back. What replaced it is better: field measurement of real users, a lab audit you can run on staging, viewport emulation for layout, and a second crawler’s verdict from Bing. Build your process around those four, prioritise by what Search Console says real users experience, and fix templates rather than individual URLs.

We handle this out of Vancouver as [website optimization](https://www.strataigize.com/services/website-optimization/). If mobile performance is costing you rankings or conversions, a [growth audit](https://www.strataigize.com/audit/) is the place to start.

Author

**Ian McGavin**, Founded Strataigize in 2022. AI operations, business strategy, and AI-search visibility.

Next step

Traffic fine but conversion soft on phones? Twenty seconds tells you whether the page renders as a phone page at all.

[Test my page →](https://www.strataigize.com/tools/mobile-friendly-test/)

Talk to us

### Talk to the team that would run it

Tell us where to look and we reply within 24 hours with where we would start. No pitch until you see the value.

[Add us as a preferred source on Google](https://www.google.com/preferences/source?q=strataigize.com)

A free Google setting to see more of our relevant articles in your own search experience. You can change it any time.

[All Website & CRO articles →](https://www.strataigize.com/insights/topics/cro-lifecycle/)

## Your site can convert more than it does.

We find the leak, fix it, and prove the lift, with revenue as the scoreboard.

[Book a growth consult →](https://www.strataigize.com/audit/) [Rated **5.0** on Clutch](https://clutch.co/profile/strataigize)

[See website optimization →](https://www.strataigize.com/services/website-optimization/)