Mobile-Friendly Test

What it does

The Mobile-Friendly Test runs a lightweight static check of the page’s mobile readiness — viewport meta tag, initial scale, user-scalable settings, inline tiny fonts, fixed-width tables — and renders the URL in a 375px-wide iframe preview so you can see roughly what mobile users will get. It’s a stand-in for Google’s retired Mobile-Friendly Test, which Google shut down in December 2023.

Common situations

A page is performing badly in mobile-first indexing and you want to know whether the basic mobile checks pass. The viewport, scaling, and tap-target rules are where most mobile issues hide; the test surfaces missing or misconfigured ones immediately.

You have just rebuilt a template and want to verify it still meets mobile-readiness baseline before deploying. Test the new template; if any of the static checks fail, fix before going live.

You are auditing a legacy page that hasn’t been touched in years. Older pages often pre-date mobile-first indexing best practices — they may have fixed-width tables, missing viewport tags, or user-scalable=no (which is a hard accessibility violation). Test surfaces them.

A page is rendering correctly on your phone but underperforming on the search side. Sometimes “looks fine” doesn’t catch what crawlers see — particularly if the mobile rendering relies heavily on JavaScript that the static check (and Googlebot) can’t execute.

You need a quick check before publishing a new layout. The static results are instant; the iframe preview shows what mobile rendering looks like at the canonical 375px viewport (iPhone SE / iPhone 13 width).

What you need to know

Mobile-first indexing has been Google’s default since 2019 — the version of the page Googlebot crawls with a mobile user-agent is what Google indexes and ranks against. This means: the mobile experience is the SEO experience. A page that works on desktop but is broken on mobile is broken from Google’s perspective.

The five static checks the test runs:

Viewport meta tag: should be <meta name="viewport" content="width=device-width, initial-scale=1">. Without it, mobile browsers render as if the device were 980px wide and zoom out, which makes everything tiny. This is the single most important mobile readiness signal.

Initial scale = 1: the viewport’s initial-scale should be 1 (or 1.0). Different values cause unintended zoom-in or zoom-out on first paint. The default 1 is correct for almost every site.

User scalable: user-scalable=no (or =0) prevents users from pinch-zooming. This is an accessibility violation — users with low vision rely on pinch zoom. Lighthouse and WCAG flag it. Never set this.

Tiny inline fonts: text rendered at under 12px on mobile is hard to read. The test scans inline style attributes for font-size: declarations under 12px and flags them. Note: this check only sees inline styles — fonts in linked CSS files require deeper analysis the static test doesn’t do.

Fixed-width tables: <table width="500"> doesn’t reflow on narrow viewports, which means horizontal scrolling on mobile. Modern responsive tables use CSS to adapt; the test flags any fixed pixel widths over a threshold.

The iframe preview is informational rather than authoritative. Many sites set X-Frame-Options: DENY or CSP frame-ancestors 'none' which prevents embedding — those pages render as blocked in the iframe but the static checks still run on the fetched HTML. For sites that allow framing, the preview is a fast visual check.

What the test does NOT do: render JavaScript, measure tap target spacing precisely, check for fonts in linked stylesheets. For comprehensive mobile testing, Google’s Lighthouse covers more ground (and uses real Chromium rendering); for the quick static checks plus a visual preview, this tool is the substitute Google’s removal of their dedicated test left.

Frequently asked questions

Why did Google retire the Mobile-Friendly Test?

Google’s official notice in December 2023 framed it as the original tool no longer matching modern testing needs — Lighthouse covers more comprehensively, mobile-first indexing is mature enough that the standalone test was redundant. The retirement left a gap in the “quick free mobile-readiness check” space, which this tool fills.

Is mobile-friendliness a ranking signal?

Yes — Google has explicitly used mobile-friendliness as a ranking signal since 2015 (the “Mobilegeddon” update). Pages that fail mobile-friendliness check rank worse on mobile searches. The bar is fairly low (basic mobile readiness), but missing it is meaningfully penalised.

What’s the right viewport for mobile?

<meta name="viewport" content="width=device-width, initial-scale=1">. This tells the browser to use the device’s actual width and not zoom on first paint. It’s the universal correct answer for responsive design.

Why is user-scalable=no an accessibility issue?

Users with low vision use pinch-to-zoom to read text. Disabling user scaling removes that affordance. WCAG 2.1 Success Criterion 1.4.4 (Resize Text) is triggered, and Lighthouse explicitly checks for this.

What’s the minimum mobile font size?

12px is the practical floor. Apple’s iOS Human Interface Guidelines suggest 11pt minimum (~15px) for body text; Google’s Material Design suggests 14sp minimum. Most accessibility frameworks treat anything under 12px on mobile as a violation.

Why does the iframe preview not load some sites?

Sites with X-Frame-Options: DENY or strict CSP frame-ancestors prevent embedding. The static checks still run; the visual preview is just unavailable. This is more common on bank, government, and security-conscious sites.

Is the static check enough, or do I need Lighthouse?

The static check covers the most-common mobile issues fast. Lighthouse covers more — JavaScript-rendered content, real device performance, accessibility tree, layout shifts. Use the static check for rapid iteration; use Lighthouse for the comprehensive pre-launch audit.

Does the test care about touch targets?

Loosely — fixed-width tables and tiny fonts indirectly affect touch usability. For precise touch-target spacing analysis, Lighthouse’s accessibility audit measures gaps between interactive elements. The static check doesn’t go that deep.

Common problems

Problem: Iframe preview is blank but the page is fine in a real browser.

The page is sending an X-Frame-Options or CSP header that prevents embedding. Static checks still run on the fetched HTML; the visual preview is just unavailable. Test on a real device or in Chrome DevTools’ device emulation if visual confirmation is needed.

Problem: Static check passes but Google Search Console reports mobile usability issues.

Search Console runs more checks than the static test (touch target spacing, content wider than viewport, etc.). The static test is a fast first pass; if it passes but Search Console flags issues, follow Search Console’s specific guidance.

Problem: Tiny font check flags lots of elements but they’re styled larger via CSS.

The static check reads inline style attributes only — it doesn’t load and apply external stylesheets. If your CSS overrides inline styles to larger sizes, the visual rendering is fine; the inline tiny-font is technically still there but not visible. The flag is informational; the real font size is in the rendered DOM.

Problem: Page passes the test but Lighthouse flags layout shift issues.

Layout shift (CLS) is about elements moving during page load — it’s a separate concern from static mobile-friendliness. Layout shift is usually caused by images without dimensions, ads loading after content, or fonts loading late. Different category of issue.

Problem: Mobile experience is OK but search ranks are weak.

Mobile-friendliness is necessary but not sufficient. Pages that pass mobile-friendliness still need quality content, fast loading, and competitive optimisation. The test rules out one cause; if it passes, the issues are elsewhere.

Tips

• The viewport meta tag with width=device-width, initial-scale=1 is universal. Set it on every page; never disable user scaling.
• Test on a real device occasionally. Static checks and emulation are fast; real devices catch issues that emulation doesn’t (touch responsiveness, system UI overlay, real network jitter).
• Don’t fight responsive design. Use CSS media queries; don’t serve different HTML to different devices.
• Tap targets need 48×48 CSS pixel minimum spacing per Material Design. The test doesn’t measure this directly; Lighthouse does.
• After Google retired their dedicated test, Search Console’s URL Inspection became the canonical “is this page mobile-friendly?” answer. This tool is for fast iteration; URL Inspection is for pre-launch verification.

Related tools in this suite

The Mobile vs Desktop Diff compares what mobile and desktop crawlers receive — useful when mobile rendering and desktop rendering differ substantively. The Page SEO Audit reports the viewport meta tag presence and other mobile signals as part of the overall page report.

What this looks like at scale

For a single page, the test is fine. For a content site, mobile-friendliness should be enforced at template level — viewport meta in the master template, font-size rules in the design system, no fixed-width components. Per-page checks become unnecessary if templates are correct. The WP Beacon Plugin audits mobile signals across every page and surfaces template-level regressions.

Take it further

If a site has widespread mobile-friendliness issues, the fix is usually template-level — fix once, applies everywhere. A WordPress development engagement is the typical scope.