Mobile-Friendly Test
Check if Google sees your page as mobile-friendly. Find viewport, tap target, and font-size issues that hurt mobile rankings.
By Deepak Shukla — Founder & CEO, Pearl Lemon
What This Tool Checks
- Viewport meta tag presence and configuration
- Text legibility (font size ≥16px to prevent iOS zoom)
- Tap target size and spacing (≥44px per Apple HIG)
- Content fits within viewport without horizontal scroll
- Mobile-specific Lighthouse audits and overall score
Why This Matters
Google switched to mobile-first indexing in 2019 — the mobile version of your page is the one that ranks, even for desktop searches. A page that fails the mobile-friendly test silently loses ranking across every device.
How to Fix Issues
- 1.Add `<meta name="viewport" content="width=device-width, initial-scale=1">`
- 2.Set base font-size to at least 16px to stop iOS zoom-on-focus
- 3.Make tap targets at least 44×44px with 8px gaps between them
- 4.Use responsive units (rem, %, vw) instead of fixed pixel widths
- 5.Test at 360×640 — the median smartphone viewport
Google's mobile-friendly test was retired as a standalone Google tool in December 2023, but the underlying signals never went away — they're still baked into Lighthouse and the mobile ranking algorithm. This free checker runs the same audits against your URL and explains every issue in plain English instead of cryptic Lighthouse jargon.
Why mobile-first indexing changes the maths
Since 2019, Googlebot crawls your site primarily as a smartphone. If your mobile page hides content that exists on desktop, Google sees the smaller content. If your mobile page is slower or has tap targets too close together, your desktop rankings suffer too. Mobile is not a 'version' of your site — it's the only version Google ranks.
The four hard requirements
First, the viewport meta tag must exist and use width=device-width. Without it the browser zooms out to a 980px desktop layout and you fail every other test. Second, body text must be at least 16px — anything smaller triggers iOS to zoom in on focus, which is a known UX killer. Third, tap targets must be at least 44×44 CSS pixels with adequate spacing; cramped buttons cause mis-taps that get logged as bounces. Fourth, content must fit in the viewport without horizontal scrolling — a width: 800px div ruins everything.
The soft signals nobody talks about
Mobile-friendly is not just the binary checklist. Google's mobile usability signals also include time-to-interactive on slow networks, layout shift from web fonts, and how your page behaves when the soft keyboard appears. A form that pushes the submit button under the keyboard fails this silently. So does a sticky header that consumes 30% of an iPhone SE's viewport.
Why progressive enhancement still matters
The fastest, most resilient mobile sites are the ones that render meaningful content from the server-side HTML before JavaScript runs. SPAs with a 4MB JS bundle frequently pass the mobile-friendly test (because the viewport tag is set) while delivering a blank screen for 6 seconds on a Moto G — and Googlebot Mobile gives up before the bundle parses. If you're running a Vite or Next.js SPA, prerender or SSR your critical routes.
Test from the device, not just the tool
After fixing what the tool reports, pick up an actual budget Android phone, throttle to slow 4G, and use the site like a customer. The vast majority of real mobile UX failures — frustrating modal triggers, off-screen close buttons, accidental zoom — never show up in automated reports.
Methodology
We load the URL in a headless Chromium with the Lighthouse mobile preset (Moto G4 user agent, 360×640 viewport, 4× CPU slowdown, 4G throttling). We then inspect the rendered DOM and computed styles for the four Google mobile-usability checks: viewport configuration, font sizes, tap-target dimensions and spacing, and content overflow. Each failing element is captured with its CSS selector so you can fix the exact node, not just be told 'tap targets too small'. Lighthouse's broader mobile audits (passive event listeners, viewport zoom enabled, etc.) are included as supplementary signals. A single test takes 10–20 seconds; we never instrument your real users.
Frequently Asked Questions
Related Free Tools
Core Web Vitals
Test LCP, INP, and CLS for any URL. Get the same Lighthouse-grade scores Google uses to rank your pages.
Image Optimization
Find oversized, uncompressed, or wrong-format images on any page. Get exact byte savings for WebP/AVIF conversion.
Font Loading
Audit how your web fonts load. Find FOIT, missing `font-display: swap`, and oversized font files dragging down LCP and CLS.
Lazy Loading
Find images and iframes that should be lazy-loaded. See how many requests you can defer below the fold.
HTTP Status Code Reference
Understanding HTTP status codes helps you diagnose issues found by this tool: