Mobile-Friendly Test

What it costs you when this is wrong

• Phones render at 980px and zoom out

  With no viewport tag setting width to the device, a phone lays the page out as if it were a desktop and shrinks the whole thing to fit. Nothing errors and nothing looks broken in a desktop browser, so it survives every review and reaches visitors as unreadable body text.

• The zoomed-out version is the one indexed

  Google indexes the mobile rendering by default. So a page that only lays out correctly at desktop width is not being marked down for mobile: the broken rendering is the copy being ranked. Nothing in Search Console flags it any more.

• user-scalable=no locks out magnification

  One attribute inside a viewport tag, usually copied in from a template or an app shell, stops low-vision visitors enlarging the page at all. A maximum-scale below 5 does the same thing more quietly. Those visitors do not file a bug report. They leave.

Why run it here

• A viewport tag can be present and still wrong

  Presence and content are checked separately. A tag reading content="initial-scale=1" sets no width, so the phone still lays out at desktop size. It passes any check that only counts whether the tag is there.

• Read from the served HTML and the rendered page

  The static rules parse what your server sent. A WCAG 2.2 rule engine then runs inside a real browser against the rendered DOM, so a viewport tag written or rewritten by script is judged as the browser sees it, including a maximum-scale that caps text below 500%.

• Every finding carries a dated citation

  This runs inside the full audit of 986 rules, so a viewport problem arrives ranked against everything else found on the page rather than in isolation. Each rule declares its severity and confidence tier and links a source you can open, with the date that source was last checked and how often it is rechecked.

This check runs on its own here, and as part of the full audit alongside the other 985 rules. Either way the findings carry their evidence and their citation, and the report is never published or kept.

1. 1

   Add the viewport meta tag with width=device-width and initial-scale=1.

2. 2

   Make sure nothing overflows horizontally — the page body should never scroll sideways, however wide the content inside it is.

3. 3

   Give tap targets a minimum size of about 44x44px with enough spacing that a thumb cannot hit two at once.

4. 4

   Keep body text at 16px or larger so a mobile browser does not zoom out to fit.

5. 5

   Serve the same content and structured data to mobile as to desktop. Content hidden only on mobile is content that is not indexed.

1. 1

   Enter your address

   Just the domain is enough — example.com, with or without the https. No account, no card, no crawl of your whole site.

2. 2

   We render it like a visitor

   Your page opens in a real browser and JavaScript runs to completion, so what gets audited is the page a person actually sees — not the raw HTML your server sent. A screenshot comes back with the report as evidence of exactly what we measured.

3. 3

   You get findings you can act on

   Up to 986 checks run against that rendered page. Each finding names the rule, quotes the evidence found on your page, cites the public specification behind it, and says what to change. Nothing is a judgement call — run it twice on an unchanged page and the score is identical.

What runs this check

• Real browser rendering
• W3C property grammars
• WCAG 2.2 rule engines

Named because provenance is the product. Every finding in your report says which of these produced it, so you can check the reasoning rather than take a score on faith.

• Mobile viewport declared

  High

  Without a viewport meta tag mobile browsers render at desktop width and zoom out, which Google treats as not mobile-friendly.

  SEO_VIEWPORT_META scored

• Zoom is not disabled

  High

  user-scalable=no or a low maximum-scale prevents low-vision users from magnifying the page at all.

  A11Y_VIEWPORT_ZOOM scored

• Document declares a viewport

  High

  Without a viewport meta tag mobile browsers render at a 980px virtual width and scale down, so the page arrives zoomed out and unreadable regardless of how good the responsive CSS is.

  HTML_META_VIEWPORT_PRESENT scored

• No sub-legible font sizes

  High

  Text below about 3px is invisible to a human but fully indexable. Whether or not it is deliberate, it matches the keyword-stuffing pattern that ranking systems demote for.

  CSS_NO_INLINE_FONT_SIZE_TINY scored

• Users should be able to zoom and scale the text up to 500%

  Medium

  Ensure <meta name="viewport"> can scale a significant amount Evaluated against the live rendered page by a WCAG rule engine, so it only runs on a full scan.

  A11Y_AXE_META_VIEWPORT_LARGE scored

• Zooming and scaling must not be disabled

  Medium

  Ensure <meta name="viewport"> does not disable text scaling and zooming Evaluated against the live rendered page by a WCAG rule engine, so it only runs on a full scan.

  A11Y_AXE_META_VIEWPORT scored

• WCAG 2.5.8 — Target size (minimum)

  Low

  Interactive targets must be at least 24x24 CSS pixels (WCAG 2.2). Static structural indicator for success criterion 2.5.8; the live WCAG engine performs the full runtime evaluation when a browser is available.

  A11Y_WCAG_2_5_8 detection

• Apple touch icon declared

  Low

  Without it, iOS uses a screenshot of the page when a user adds the site to their home screen.

  SEO_APPLE_TOUCH_ICON detection

• Media attributes used on stylesheets

  Low

  A media attribute lets the browser deprioritise stylesheets that do not apply to the current viewport.

  CSS_MEDIA_QUERIES detection

• iOS web app title declared

  Low

  iOS web app title is a supplementary signal browsers and platforms may use. Informational.

  SEO_META_APPLE_MOBILE_WEB_APP_TITLE detection

• MobileApplication schema detected

  Low

  Reports whether the page declares a schema.org mobile application. Informational: pages that are not a mobile application are not expected to declare one, so this never affects the score.

  SCHEMA_TYPE_MOBILEAPPLICATION detection

Also checks

This page answers these searches too — they are the same job, so they share one page rather than being split across near-identical ones:

• mobile usability test
• responsive design checker
• tap target size
• mobile seo checker

Other checkers

• HTML ValidatorW3C markup conformance, checked by a real parser
• CSS ValidatorStylesheets parsed and checked against the W3C property grammars
• Schema Markup ValidatorJSON-LD parsed, expanded to real schema.org IRIs, and checked
• Rich Results TestWhich search features your structured data qualifies for
• Website Scam DetectorThe trust signals people and payment processors check before believing a site
• AI ValidatorWhether AI models can find, read, quote and operate your site
• Broken Link CheckerEvery link on the page requested, with blocked and broken told apart
• SEO CheckerTitles, meta, canonicals, indexability and internal linking
• Accessibility CheckerTwo WCAG engines — one in a real browser, one on your markup
• Security Headers CheckerResponse headers, CSP quality, and the TLS certificate underneath
• Core Web Vitals CheckerMeasured for real, plus the page-weight causes behind the numbers
• AI Agent Readiness CheckerCan an agent find your buttons, read your labels and finish the task
• W3C ValidatorMarkup and stylesheet conformance in one pass
• Answer Engine CheckerWhether AI answer engines can quote you, and attribute it
• AI Crawler CheckerWhich AI crawlers your robots.txt actually lets in
• SSL Certificate CheckerA real handshake: certificate, expiry, protocol and cipher
• robots.txt CheckerWhat your robots.txt actually allows, group by group
• Meta Tag CheckerTitles, descriptions, canonicals and robots directives
• Open Graph CheckerHow your link looks when someone shares it
• Image SEO CheckerAlt text, dimensions, formats and lazy loading
• Website CheckerEvery module, one scan, one prioritised fix list