Guide · mobile testing
Google Mobile-Friendly Test: what to use now it is retired
On this page
Google's Mobile-Friendly Test is gone: Google retired the tool, its API and Search Console's Mobile Usability report on December 1, 2023. To test a page now, run Lighthouse in Chrome DevTools or PageSpeed Insights, load the page in Chrome's device mode at phone widths, check Search Console's Core Web Vitals report and URL Inspection, then work through the six checks below: viewport tag, content wider than the screen, text size, tap targets, intrusive interstitials and the main journey.
Have a site ready to check? Test my site free. 10 browser runs a month after sign-up, without AI review. Review an editable mobile-layout goal in the console. Add a site you may test and inspect the plan before starting a run. See a sample report first.
First published · Facts checked
Is Google's Mobile-Friendly Test still available?
No. In April 2023 Google announced that “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 2016 post that launched the tool now carries the note “The Mobile Friendly Test and the Mobile Usability report have been retired.”
Google did not say mobile usability stopped mattering. The same announcement says it “remains a part of our page experience guidance”, and names Lighthouse from Chrome as one of the resources that now cover it.
What to use instead of the Google Mobile-Friendly Test
- Lighthouse in Chrome DevTools. Open DevTools, choose the Lighthouse panel, select Mobile and run it. The
meta-viewportaudit (Accessibility) checks your viewport tag and thetarget-sizeaudit checks tap targets. It is a lab test of one page load; it does not open menus or fill in forms. - PageSpeed Insights. Paste a public URL into pagespeed.web.dev. It runs Lighthouse on Google’s servers with a mobile profile and, when Chrome has enough real-user data for the URL or origin, shows field Core Web Vitals above the lab audit.
- Chrome device mode. Toggle the device toolbar in DevTools, pick a phone preset or type a width such as 320 or 375, and reload. This is the fastest way to see overflow, clipped text and menus that do not open. Device mode simulates the viewport and touch input; it is not a real phone, so check on one before launch.
- Search Console: Core Web Vitals report and URL Inspection. The Core Web Vitals report groups your URLs by real-user loading, interaction and layout-shift data on mobile and desktop. URL Inspection’s live test shows whether Googlebot can fetch and render the page. Neither checks layout or tap targets.
- A real-browser journey check. Load the published page at phone, tablet and desktop widths and walk the main path: open the menu, submit a form, reach checkout. A Sybqa free run does this with a real browser and gives you a report with screenshots; it does not report Google’s verdict.
For the width-by-width checklist, see the responsive design testing guide. For what Lighthouse scores and field data can and cannot tell you, see Lighthouse and PageSpeed Insights vs website QA.
Mobile-friendly checklist: 6 checks to run by hand
- Viewport meta tag. View source and confirm the page head has a viewport meta tag with
content="width=device-width, initial-scale=1", the setting web.dev recommends. Without it, phones render the page at desktop width and shrink it. Do not adduser-scalable=noor a lowmaximum-scale: Lighthouse’smeta-viewportaudit flags both because they block zoom. - Content wider than the screen. In device mode at 320 px wide, scroll sideways. If the page moves, something is too wide. In the console,
document.documentElement.scrollWidth > window.innerWidthreturnstruewhen there is horizontal overflow. WCAG 2.2 success criterion 1.4.10 (Reflow) asks for content that works at 320 CSS pixels without scrolling in two directions. Common causes are fixed-width images, wide tables, long URLs and code blocks. - Text size. Read the page at phone width without zooming. Lighthouse’s former font-size audit suggested at least 12 px for at least 60% of the page’s text; current Lighthouse versions removed that audit, so check by eye. Watch footers, form hints and table cells, where small text tends to collect.
- Tap target size and spacing. Buttons and links should be easy to hit with a thumb without catching the neighbouring control. WCAG 2.2 success criterion 2.5.8 (Target Size, Minimum) sets 24 by 24 CSS pixels, or enough spacing around a smaller target. Lighthouse checks this in its
target-sizeaccessibility audit, which replaced the old SEOtap-targetsaudit. - Intrusive interstitials. Open the page as a first-time visitor from a search result. Google describes intrusive interstitials and dialogs as elements that “obstruct users’ view of the content, usually for promotional purposes”. Check that newsletter, app-install and discount pop-ups do not cover the main content on a phone, and that their close button is visible and large enough to tap.
- The main journey. Open the navigation menu, use search, submit the main form and, on a shop, reach checkout, all at phone width. Lighthouse and PageSpeed Insights do not do this; it is where layout bugs usually cost you a visitor.
Which tool answers which mobile question
| Check | What to look for | Best evidence |
|---|---|---|
| Viewport | A width=device-width viewport tag that does not block zoom. | Lighthouse meta-viewport audit plus view source |
| Content width | No horizontal scrolling at 320 px. | Chrome device mode or a real-browser width check |
| Readable text | Text, headings and controls readable without pinch-zooming. | Real browser; current Lighthouse has no font-size audit |
| Tap targets | Controls at least 24 by 24 CSS px or well spaced. | Lighthouse target-size audit plus manual use |
| Content parity | Mobile shows the same important content and metadata as desktop. | Search Central mobile-first indexing guidance |
| Interstitials | No pop-up hides the main content on arrival. | Manual check as a first-time visitor |
| Journey behavior | Navigation, forms, checkout and dialogs work at phone width. | Real-browser journey test |
| Field performance | Core Web Vitals from real Chrome users. | PageSpeed Insights and the Search Console Core Web Vitals report |
What replaced the Mobile-Friendly Test API?
There is no one-to-one replacement for the retired API. For automated performance and best-practice checks, use the PageSpeed Insights API or Lighthouse CI. For a browser workflow, use a test runner or a service that records the route, viewport, outcome and evidence. Keep the distinction clear: a Lighthouse result is not a Google Search ranking guarantee, and a browser QA result is not Googlebot’s verdict.
If you want the same reviewed check on each release, the run Sybqa on every deploy guide describes the supported CI path. Sybqa checks the live browser experience; it does not claim to replace Google Search tools.
Mobile checks for AI-built sites
Sites built with Lovable, Bolt, v0 or Cursor often look finished at the builder’s desktop preview. Give extra attention to fixed-width hero sections, tables and code blocks that overflow, navigation menus that do not open on touch, and modals positioned outside the viewport. Test the published URL in a signed-out browser, then retest after each fix. The AI-built website testing guide covers the wider release checklist.
Common questions
Is Google's Mobile-Friendly Test still available?
No. Google retired the Mobile-Friendly Test tool, the Mobile-Friendly Test API and the Search Console Mobile Usability report on December 1, 2023.
What replaced the Google Mobile-Friendly Test?
There is no single replacement; Google’s announcement names Lighthouse from Chrome as one resource. Use Lighthouse in Chrome DevTools or PageSpeed Insights for audits, Chrome device mode to see the page at phone widths, Search Console’s Core Web Vitals report and URL Inspection for real-user data and rendering, and a real-browser check for layout and journeys.
How do I check if my website is mobile friendly?
Confirm the page has a width=device-width viewport meta tag, load it at 320 px wide and check for sideways scrolling, read the text without zooming, check that buttons are at least 24 by 24 CSS pixels or well spaced, make sure no pop-up covers the main content, and complete the main journey at phone width.
Is there a free mobile friendly test API?
There is no one-to-one replacement for the retired API. The PageSpeed Insights API and Lighthouse CI can automate related audits; a browser test runner can automate your own layout and journey checks.
Does mobile-friendliness still affect Google rankings?
Mobile usability remains part of Google’s page experience guidance, but Google says there is no single page-experience signal and a good tool result does not guarantee top rankings. Mobile-first indexing means Google uses the mobile version of site content for indexing and ranking.
How do I test if my website is mobile friendly without coding?
Run the URL through PageSpeed Insights, open it on a phone or in Chrome device mode, and try the main journey. Check sideways scrolling, text size, tap targets, pop-ups, menus and forms. A Sybqa free run can add a real-browser layout and journey check with screenshots.
Sources
- Google Search Central: The role of page experience in creating helpful content (retirement announcement, April 2023)
- Google Search Central: The Search Console mobile friendly testing tool (retired)
- Google Search Central: Understanding page experience in Google Search results
- Google Search Central: Avoid intrusive interstitials and dialogs
- Google Search Central: Mobile-first indexing best practices
- Google Search Central: Core Web Vitals
- Search Console Help: URL Inspection tool
- Chrome Developers: Lighthouse overview
- Chrome Developers: Simulate mobile devices with device mode
- Lighthouse changelog (tap-targets replaced by target-size; font-size audit removed in 13.0)
- Chrome Developers: Lighthouse font-size audit (former 12 px / 60% guidance)
- web.dev: Responsive web design basics (viewport meta tag)
- W3C: Understanding WCAG 2.2 SC 1.4.10 Reflow
- W3C: Understanding WCAG 2.2 SC 2.5.8 Target Size (Minimum)
Related
- Signup form test cases: a practical checklist for staging
- Responsive design testing: a repeatable layout checklist
- Lighthouse and PageSpeed Insights vs website QA: what each one tests
- Automated accessibility testing: what it is, what it catches and what it misses
- Website testing checklist for Lovable and vibe-coded apps
- Best pre-launch website testing tools for AI-built sites (2026)
Try Sybqa on your site
Explore bugs, UI consistency and user journeys from a reviewed plan. Inspect browser evidence and visual review leads in the report. The free plan gives 10 runs a month without AI review after you sign up. See pricing.
Add your public page link here. Review and edit the suggested mobile-layout goal in the console, then inspect the test plan before starting a run. Review the planned phone and desktop widths and keep the check read-only. The report describes what was tested; it is not a Google mobile-friendly verdict.