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

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: paste a URL and get the viewport, fixed-width, tiny-text, weight and crawl checks scored, with the fix for each. No email.

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, and the sunset was confirmed in public coverage on December 4, 2023. 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 and redirected Search Console mobile usability URLs to the property overview. In the April 2023 announcement, Google points people at Lighthouse 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. 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.

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 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.

Run a mobile audit with PageSpeed Insights and Lighthouse

Start with PageSpeed Insights. 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. 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. 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.

Source: web.dev Core Web Vitals thresholds, current as of 2026. INP replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024, 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), 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. 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: 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 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 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 or 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, 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 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, 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, 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
• 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 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, 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. 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.

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, 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 in more depth. The same metrics sit inside how we approach 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.

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. 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 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. Compress the hero, serve a modern format, preload the LCP element, and do not lazy-load it.
• High INP: optimize Interaction to Next Paint. Break up long tasks and defer or remove third-party JavaScript that blocks the main thread.
• High CLS: optimize Cumulative Layout Shift. 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. 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, 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 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 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, 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.

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. 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 and web.dev’s lab versus field article 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. If mobile performance is costing you rankings or conversions, a growth audit is the place to start.