How to Test if a Website Is Mobile Friendly Now That Google’s Mobile-Friendly Test Is Gone
To check whether a website is mobile friendly now that Google’s Mobile-Friendly Test is gone, combine four methods: Lighthouse (in Chrome DevTools or through PageSpeed Insights) for a detailed audit in phone emulation, DevTools device mode to see the page at 360–430 px wide, a real phone to catch what emulation misses, and our Mobile-Friendly Test for a quick, sign-up-free check of the page code — meta viewport, media queries, fixed widths, small text and tap targets — next to an iPhone screenshot.
Below: what exactly Google retired, what to use instead, a 15-minute checklist and copy-paste fixes for the most common problems.
What happened to Google’s Mobile-Friendly Test
In December 2023 Google switched off three things at once: the Mobile-Friendly Test itself, its API, and the Mobile Usability report in Search Console. The old address search.google.com/test/mobile-friendly now redirects to the Lighthouse overview — Google’s pointer to the replacement.
The tool went away; the requirement did not. Google still indexes sites with its smartphone crawler, so mobile usability matters as much as before. There is simply no ready-made "page is mobile-friendly" verdict from Google any more, so you have to check yourself.
Google Mobile-Friendly Test alternatives compared
| Method | What it shows | Runs JavaScript | Use it for |
|---|---|---|---|
| Lighthouse in Chrome DevTools | Audit in phone emulation: performance, accessibility, SEO, best practices, including a missing meta viewport | Yes, a real browser | A detailed look at one page, including pages behind a login or on localhost |
| PageSpeed Insights | The same Lighthouse in the cloud, plus real-user Chrome data (LCP, INP, CLS) when Google has enough of it | Yes | Mobile speed and Core Web Vitals |
| DevTools device mode | The page at a chosen screen width, with optional network and CPU throttling | Yes | Spotting overflow, overlaps and elements you cannot tap |
| A real phone | Real touch, keyboard, system fonts and browser bars | Yes | Final check of forms, menus and pop-ups |
| Our Mobile-Friendly Test | 8 HTML and CSS checks with transparent weights, a 0–100 score and an iPhone screenshot | No | A fast check of any URL, nothing to install |
Device mode is the phone-and-tablet icon in DevTools, or Ctrl+Shift+M (Cmd+Shift+M on a Mac). See the Chrome documentation for details.
How to check if a website is mobile friendly: step by step
- Start with the code. Run the page through the Mobile-Friendly Test. A missing viewport, a 960–1200 px wrapper or disabled zoom show up immediately, before you even open a browser.
- Look at it in DevTools. Turn on device mode and try 360 px (common narrow Android phones) and 390–430 px (recent iPhones). Scroll the whole page: is there a horizontal scrollbar, cut-off text, overlapping blocks?
- Run Lighthouse in mobile mode. Lighthouse tab → Device: Mobile → Analyze page load. Read the individual findings with element references, not just the scores.
- Check speed in PageSpeed Insights. If the report shows a real-user data section at the top, that is what Google sees. If it does not, the site has too little Chrome traffic, and the lab numbers are your guide.
- Open the page on an actual phone. Fill in a form, open the menu, close the pop-up, rotate the screen. Emulation will not tell you that a thumb misses the close button or that the keyboard covers the input field.
- Test several page types. Home pages are usually polished; problems hide in product pages, old articles with wide tables and blog templates.
- Compare mobile and desktop content. Text, headings, links, structured data and alt attributes should be present in both.
Common problems and how to fix them
No meta viewport
Without this tag, a phone lays the page out about 980 px wide and shrinks it, so all text becomes tiny. Add this to <head>:
<meta name="viewport" content="width=device-width, initial-scale=1">Leave out user-scalable=no and maximum-scale=1: blocking zoom hurts people with low vision, and our tool deducts points for it.
Fixed-width layouts
The classic of old templates is width: 960px on the wrapper — a guaranteed horizontal scrollbar on a phone. Cap the width instead:
.container { max-width: 1200px; width: 100%; margin: 0 auto; padding: 0 16px; box-sizing: border-box; }
img, video, iframe { max-width: 100%; height: auto; }Wide tables
A six-column table will never fit into 360 px. The simplest fix is to let it scroll inside its own box instead of breaking the whole page:
<div class="table-wrap"><table>…</table></div>
.table-wrap { overflow-x: auto; -webkit-overflow-scrolling: touch; }If there are many columns and the data matters, turn rows into cards on narrow screens with a media query.
Small text and small tap targets
Aim for body text around 16 px and use rem units. For tap targets, WCAG 2.2 success criterion 2.5.8 asks for at least 24×24 CSS px, and Material Design recommends about 48×48 with spacing between neighbouring links:
html { font-size: 100%; } /* 16px by default */
body { font-size: 1rem; line-height: 1.5; }
.nav a, button { min-height: 48px; padding: 12px 16px; display: inline-flex; align-items: center; }Media queries for narrow screens
Multi-column layouts should collapse into one column on a phone:
.grid { display: grid; grid-template-columns: repeat(3, 1fr); gap: 24px; }
@media (max-width: 768px) {
.grid { grid-template-columns: 1fr; }
}Full-screen pop-ups
Google’s guidance says not to cover the entire page with an interstitial unless it is legally required (cookie consent, age verification). Show newsletter or app-install prompts as a small banner that does not block reading.
Legacy technology
Flash, Java applets and framesets do not work on phones. Replace them with HTML5 video, normal layout and separate pages.
Why it matters: mobile-first indexing
Google uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking. That does not mean a site without a responsive layout disappears from search: Google says a mobile version is not required, but very strongly recommended. The practical takeaway is different: what the phone sees is what gets indexed. If the mobile version trims text, hides links or drops structured data, search does not get them either. More in our article on mobile-first indexing.
Core Web Vitals on mobile
Usability includes speed. Google recommends an LCP (main content loading) within 2.5 seconds, an INP (responsiveness) under 200 milliseconds and a CLS (layout shift) under 0.1. On phones these numbers are almost always worse than on desktop: slower CPUs, slower networks. Look at the mobile tab in PageSpeed Insights and at the Core Web Vitals report in Search Console, which splits mobile and desktop URLs. What each metric means is explained in Core Web Vitals; where to start speeding things up — in page load speed.
How to run the check in our Mobile-Friendly Test
Enter a URL in the Mobile-Friendly Test. The tool loads the HTML with an Android phone user agent, reads up to six stylesheets from your own domain and runs eight checks. Each one is worth a fixed number of points, and the weights are shown on the page:
| Check | Points | What it looks for |
|---|---|---|
| Meta viewport | 30 | Whether the tag exists and uses width=device-width |
| Responsive CSS | 20 | Width-based media queries; flex, grid or clamp without them earn partial points |
| Fixed widths | 10 | CSS rules and inline styles with width over 480 px |
| Horizontal scroll risk | 10 | Wide width attributes, images without max-width, nested table layouts |
| Font size | 10 | Base font under 12 px, many rules under 11 px |
| Tap targets | 10 | Links and buttons with tiny font or a size under 24 px in inline styles |
| Zoom | 5 | user-scalable=no or maximum-scale below 2 |
| Legacy plugins | 5 | Flash, Java, frames |
Next to the findings you get a screenshot in iPhone emulation. If it shows cut-off text or a scrollbar, trust the screenshot over the score. Pop-up signals and page weight are shown as hints and do not affect the score. Without an account you get 15 checks a day, 45 with a free account, and no limit on Pro.
Other tools that help
- Website screenshot — mobile and desktop captures to show a developer the problem or compare before and after. How to read them: website screenshot online.
- Page speed analyzer — HTML, image, CSS and JS weight plus load time: heavy images are a frequent reason for a slow mobile page.
- Search Console — the Core Web Vitals report with separate mobile and desktop data.