The Mobile-Friendly Test was a free Google tool that let you paste in any URL and get back a yes-or-no verdict on whether the page worked properly on mobile devices, along with a list of specific issues if it didn’t. Google retired it in December 2023, so if you’ve gone looking for it recently and hit a dead page, that’s why.
That doesn’t mean mobile-friendliness stopped mattering. It means the way Google wants you to measure it has changed, and the replacement tools give you better information than the old test ever did.
What the Mobile-Friendly Test Actually Did
You pasted a URL into the tool. Google would crawl with its mobile Googlebot, render it the way a phone browser would, and spit out a screenshot plus a verdict: “Page is mobile friendly” or “Page is not mobile friendly.” If something was wrong, it listed the problems: text too small, clickable elements too close together, content wider than the screen, viewport not set.
It also showed rendered HTML and page loading issues, which made it useful for catching rendering problems and blocked resources.
A Brief History
Google launched the Mobile-Friendly Test in November 2014, a few months before the “Mobilegeddon” algorithm update of April 2015 that started using mobile-friendliness as a ranking signal. The timing was deliberate.
For nearly a decade it was one of the most-used free SEO tools on the web. By 2023, mobile-friendly testing was so routine that most people assumed the tool would just always be there.
Why Google Retired It in December 2023
Google deprecated the Mobile-Friendly Test on December 1, 2023, along with the Mobile-Friendly Test API and the Mobile Usability report in Search Console. Three reasons drove the decision:
- Mobile-first indexing is universal. Google finished migrating every site to mobile-first indexing in 2023. A separate test asking “is this mobile-friendly?” became redundant.
- Core Web Vitals and Page Experience are the framework now. The binary mobile-friendly verdict was blunt. Core Web Vitals measures actual loading performance, interactivity, and visual stability with real user data.
- Tooling consolidation. Google had overlapping tools doing similar jobs. Pushing people toward Lighthouse and Search Console concentrated the engineering effort.
What to Use Instead
| Tool | What it tells you | When to use it |
|---|---|---|
| Search Console Page Experience report | Site-wide Core Web Vitals status, HTTPS, mobile usability signals | Monthly health check of your whole site |
| Search Console Core Web Vitals report | Which URLs are slow, sluggish, or visually unstable | Finding real-world performance problems at scale |
| Chrome Lighthouse | Lab audit of a single page covering performance, accessibility, SEO | Auditing one specific page in depth |
| Chrome DevTools mobile emulation | Manual visual check at different screen sizes | Catching layout issues during development |
| PageSpeed Insights | Both lab data (Lighthouse) and field data (real users) for a URL | One-URL diagnostic when something feels off |
If you only learn one of these properly, make it the Core Web Vitals report in Search Console. It uses real data from real visitors, not a simulated test.
What “Mobile-Friendly” Still Means
- Responsive design. The layout adapts to screen width instead of forcing pinch-and-zoom.
- Readable text without zooming. Body copy at roughly 16px or larger on mobile.
- Tap targets sized correctly. Buttons and links big enough to hit with a thumb (around 48px), with enough space between them.
- No horizontal scrolling. Content fits within the viewport.
- A correctly configured viewport meta tag. Tells mobile browsers to render at device width.
Common Mistakes I Still See
Testing only on desktop
If you build and proofread your site exclusively on a 27-inch monitor, you’ll miss mobile problems. Get into the habit of pulling up every new page on your actual phone.
Assuming responsive design equals optimized
A responsive theme means the layout doesn’t break on mobile. It doesn’t mean the page is fast, the images are appropriately sized, or the JavaScript isn’t blocking render. I see sites with beautiful responsive layouts that take eight seconds to become interactive on mid-range Android.
Ignoring INP and CLS on mobile specifically
Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital in March 2024. It measures how fast your page responds when someone taps. Cumulative Layout Shift (CLS) measures whether elements jump around as the page loads. Both are usually worse on mobile. Check both in Search Console with the device filter set to mobile.
The Short Version
The Mobile-Friendly Test was a useful free tool from 2014 to 2023, then Google retired it because mobile-first indexing made the question obsolete and Core Web Vitals gave them a better way to measure the same thing. Use Search Console’s Page Experience and Core Web Vitals reports for site-wide monitoring, Lighthouse and PageSpeed Insights for individual page diagnostics, and your actual phone for the gut check.