Mobile Friendly Test: How Your Site Handles Phone Screens

What is a mobile friendly test and what does it look at?

A mobile friendly test is an automated check of how a page renders and behaves on a phone sized screen. Most tools borrow the same four signals from Google's old tool: a viewport tag, legible font sizes that need no pinch to zoom, no content wider than screen width and tap targets big enough to hit, with room between them.

Four terms get mixed up constantly. Responsive web design is the technique, a fluid layout plus CSS media queries, and mobile friendly is what the visitor actually experiences. A site can be responsive and still miss on phones: the media queries are there, but the nav links are only 24 pixels tall and packed edge to edge, so thumbs hit the wrong one. Mobile-first design is the order you write your CSS in, while mobile-first indexing means Google crawls and ranks the phone version through Googlebot Smartphone. That last one is why this matters for mobile SEO.

Testers come in three kinds. A render test captures a screenshot at phone width, a rule test searches your HTML and CSS for known signals, and a lab test such as a Lighthouse mobile audit measures speed and accessibility in simulation. Our report is a rule test with a phone width snapshot attached.

Google retired its Mobile Friendly Test: what people use now

Google switched off the Mobile-Friendly Test, its API and the Mobile Usability report in Google Search Console on December 1, 2023, and pointed site owners toward Lighthouse.

Pair one rule based check with one real device check, because neither catches everything alone. A report is fast and repeatable, while a real phone shows whether the page feels usable. Lighthouse gives no single mobile friendly verdict, so read its findings as a list of problems.

How SEO Site Checker runs its mobile friendly test

Our check is a responsive CSS presence test, not a full usability audit. It does not measure tap target size, font size or sideways scrolling, and only the media query part decides the result, even though the report card also mentions rendering.

The exact rule: the check searches each stylesheet it downloads for @media followed by an opening bracket, ignoring case. That matches @media(max-width: 600px) and the range syntax from W3C Media Queries Level 4, such as @media (width >= 40rem). Any word between @media and the bracket breaks the pattern.

What the check reads

After a headless Chromium browser renders your page, the report collects the first 8 stylesheet links from the rendered HTML. Each file is downloaded with a 3 second request limit, inside a 10 second cap for the whole step. Relative paths are joined to the domain root. Style elements, CSS-in-JS libraries, @import files and anything after the eighth stylesheet are never read. The media attribute on a link tag does not count either, so a file loaded with a media attribute of (min-width: 768px) that holds plain rules shows nothing to the check unless the file also contains its own @media rule.

What pass and fail mean

There is no warning state, only a pass or a fail. The table shows where the line sits for common media query forms.

• Pass: one bracketed media query in the first 8 stylesheets is enough.
• Fail: no bracketed @media rule in the first 8 stylesheets, including a file that timed out, could not be fetched or came after the eighth.
• Not tested: tap target size, font size, sideways scrolling and the viewport tag.

Say a WordPress theme loads 11 stylesheets and keeps all its breakpoints in the ninth. The site is fully responsive, yet the report fails it, because the check stops reading after the eighth file. It counts as one check in the overall score.

What the Mobile Snapshot shows

The Mobile Snapshot is a 430 by 932 pixel screenshot of the top of your page, taken after loading. It never changes the pass or fail result. The browser uses a desktop identity with a narrow window, so it shows what your CSS does at that width, not a true phone render. The viewport meta tag is not applied in this capture, so a page without it can look fine in the snapshot and still render zoomed out on a real phone. The website screenshot generator captures any address on its own.

Check my website

How to run a mobile friendly test yourself in four steps

1. Run the free report. Start with the free SEO report and read two things: the pass or fail on responsive CSS and the Mobile Snapshot image. A fail tells you where to look.
2. Preview in Chrome DevTools. Open the Chrome DevTools device mode, switch on the device toolbar and test at 360, 390 and 430 pixel widths. Emulation is only an approximation, but it exposes sideways scrolling and cut off menus.
3. Run Lighthouse in mobile mode. Use the Lighthouse panel in DevTools or PageSpeed Insights, then read the performance and accessibility results.
4. Pick up a real phone. Real device testing on an iPhone in iOS Safari and an Android phone in Chrome catches what emulators miss, such as a keyboard covering a button. Rotate the screen, tap the menu and fill in one form field. For a ticket, capture both views with a screenshot generator.

How to fix a failed mobile friendly test

Steps 2 and 5 change our result. The others fix real phone problems that the report does not measure.

1. Add the viewport tag. Put one meta tag in the head of every template, with the name viewport and the content width=device-width, initial-scale=1. Our meta viewport tag guide covers the details and why phones need it.
2. Write responsive rules. Style for phones first, then add @media (min-width: 768px) blocks for wider screens, written without the word screen so our check can match them, using flexbox or CSS grid columns that stack on narrow screens. Our media query guide covers mobile breakpoints, and the MDN media queries guide documents the syntax. If your site already looks right on a phone and only uses the screen form, the fail is a limit of our check, not a bug in your CSS. Adding one plain bracketed block for the main layout is enough.
3. Make text readable. Keep body text near 16 pixels, use relative units such as rem units and avoid fixed widths wider than a phone. Never set user-scalable=no, because visitors need pinch to zoom.
4. Make buttons easy to hit. Aim for a touch target size of about 48 by 48 CSS pixels with roughly 8 pixels between targets. WCAG 2.2 Success Criterion 2.5.8 sets only a 24 pixel floor, while Material Design touch targets use 48 and the Apple Human Interface Guidelines ask for 44 points.
5. Make the rules visible to the check. Keep at least one @media rule in an external stylesheet among the first 8, not only in a style element. Combine files if you load more than 8, and the CSS minifier helps shrink the merged result. Moving the stylesheet that holds your breakpoints higher in the head also works, but reordering changes which rules win, so check the page afterwards. Merging the files in their current order is the safer route.
6. Retest. Check DevTools device mode first, then run the report again after clearing your cache.

<meta name="viewport" content="width=device-width, initial-scale=1">

img {
  max-width: 100%;
  height: auto;
}

.layout {
  display: block;
}

/* Matched by our check */
@media (min-width: 768px) {
  .layout {
    display: grid;
    grid-template-columns: 2fr 1fr;
    gap: 24px;
  }
}

The base rules describe the phone layout, and the media query only adds the wide screen columns. To confirm a rule works, open the page in DevTools at 360 pixels and widen the window slowly until the two column layout appears at 768.

Frameworks such as Bootstrap and Tailwind CSS already ship bracketed @media rules in their compiled stylesheets, so a fail on a framework site usually points to a stylesheet count or ordering problem rather than missing breakpoints. Open the built CSS file the browser downloads, not your source, and look for the rule there.

When a mobile friendly test and your own phone disagree

False fails: your phone shows the finished page, but the check only sees what it can download and match. Rules written as @media screen and (...), rules in a style element (our inline CSS guide covers that trade off) CSS that a script writes into the page and a split desktop file that relies only on a media attribute on its link tag are all invisible to it. So is any stylesheet past the eighth. An optimizer plugin that turns a stylesheet link into a preload causes the same miss.

The fetching step causes more misses. A protocol relative URL such as //cdn.example.com/site.css is requested without a scheme, so the download fails. A relative href is resolved from the domain root, so a file in a sub folder can return an error page, and the check reads that page instead, which rarely holds a matching rule.

False passes happen too. Any bracketed @media rule counts, even prefers-reduced-motion, so a page with no responsive layout can still pass.

Rule of thumb: trust the real phone first, because it shows the finished page, then treat the report as a quick signal that tells you which stylesheet to open next.

Why a mobile friendly test matters for rankings and visitors

Google uses the mobile version of a page for indexing and ranking, which Google Search Central calls mobile-first indexing. So read the official Google mobile-first indexing guide before you assume your desktop layout counts.

Picture a 390 pixel wide phone with a menu overlapping the logo, a 12 pixel link your thumb keeps missing or a wide table pushing the page sideways. Anyone who hits those has a reason to leave. Mobile friendliness is a foundation for usability and indexing, not a standalone ranking switch with a known weight, and with the Search Console Mobile Usability report gone your own checks fill that gap. For load speed and layout stability on phones, including Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint, our Core Web Vitals guide picks up where this page stops.

Mobile friendly checklist before you retest

• Viewport tag. The meta viewport tag is present on every template, not only the home page.
• Visible media query. At least one @media rule with an opening bracket sits in an external stylesheet among the first 8.
• No sideways scroll. Pages fit between 360 and 430 pixel widths without horizontal scrolling.
• Readable text and tap targets. Body text is near 16 pixels and buttons are about 48 pixels with spacing.
• Flexible media. Images and embeds scale with max-width 100%.
• Clear content. Nothing large, such as an intrusive interstitial or a pop-up, covers the main content on a phone.