What a Mobile Friendly Test Actually Checks
A mobile friendly test checks whether a webpage is usable on a phone or tablet, not just a full-size desktop screen - readable text without zooming, no horizontal scrolling, a layout that reflows instead of forcing a shrunken desktop view into a small window. Enter a URL above and this tool runs that test two ways: pick any modern phone, tablet, laptop, or desktop from the dropdown for a live spotlight preview, see a fixed four-device showcase (desktop, laptop, tablet, mobile) alongside it, and get a 0-100 responsiveness score built from the page's real HTML and CSS - viewport configuration, media query breakpoints, responsive images, flexible layout, text readability, and mobile meta tags.
Most free mobile-friendly checkers stop at the visual preview and leave you to judge the CSS by eye. This one also fetches the page's linked stylesheets and parses the real @media rules inside them, so the score reflects what the code actually does, not just what one screenshot suggests. It's built for SEO consultants running a mobile-friendliness audit, developers verifying a responsive fix before deploying it, agencies adding a QA step before a client site goes live, and site owners who just want to know if their site works on a phone. This is one of AudEsto's free SEO utilities - no account is needed to run a check.
How to Test If Your Website Is Mobile Friendly
- Enter the URL. Paste the full address of the page you want to test, including the protocol (https://).
- Verify you're human. Click Check Responsiveness and complete the quick reCAPTCHA check - this keeps the tool from being scripted and abused, so it stays free and fast for everyone.
- Pick a device and look at the showcase. Choose any device from the dropdown for a close-up spotlight preview, and scan the four-device showcase for overflow, squished text, or elements that don't reflow.
- Read the score and checklist. The score ring shows the overall 0-100 result; each of the six scored signals below explains exactly what's wrong and how to fix it.
Each browser or IP gets a set number of checks per day. That's enough to test a handful of key templates in one sitting - the homepage, a representative landing page, and a product or article template, since a fix on one template page typically applies to every page built from it.
What Happened to Google's Mobile-Friendly Test?
If you've searched for "google mobile friendly test" recently, the tool you might remember is gone. Google retired its standalone Mobile-Friendly Test in December 2023. Mobile-first indexing had made a separate pass/fail checker less central to how Google evaluates pages, so the equivalent checks moved into the URL Inspection tool inside Search Console and the Rich Results Test. That works well if you own the site and have it verified in Search Console - it's not much help for checking a competitor's page, a client's site before you're onboarded, or a page on a platform you don't administer. This tool fills that gap for anyone with a URL, and adds a breakdown of exactly which CSS and markup signals are driving the result, rather than a single verdict.
How the Responsiveness Score Is Calculated
The 0-100 score is a weighted sum of six components, each scored independently from the page's real, live HTML and CSS - nothing here is guessed from the visual preview:
| Signal | Max Points | What It Checks |
|---|---|---|
| Viewport Meta Tag | 20 | Presence of a correctly configured <meta name="viewport"> tag, and whether it disables pinch-to-zoom |
| Media Query Breakpoints | 25 | Real @media rules parsed from every linked stylesheet plus inline <style> blocks, and whether mobile/tablet/desktop bands are all covered |
| Responsive Images | 15 | Use of srcset, sizes, or <picture> so images can adapt to different screen widths |
| Flexible Layout | 15 | Flexbox/grid/percentage-width usage weighed against fixed wide-pixel containers not gated behind a media query |
| Text Readability & Zoom | 15 | Sub-12px font-size declarations and whether the viewport tag blocks zooming |
| Mobile Meta & Icons | 10 | Apple touch icon, theme-color, mobile-web-app-capable, and web app manifest |
Grades map to the total: A (90-100), B (75-89), C (60-74), D (45-59), and F (below 45).
How the Check Works
The tool fetches the page's HTML directly, then finds every linked stylesheet (up to 8) and downloads each one to search for real @media rules and their pixel breakpoints, combining that with any inline <style> blocks on the page. It checks the viewport meta tag's exact content string, counts <img> tags using srcset/sizes/<picture>, scans the collected CSS for flexbox/grid/percentage-width usage versus fixed wide-pixel widths sitting outside any media query, and reads font-size declarations for anything under 12px. The device previews, shown separately above the score, embed the actual URL in scaled iframes entirely in your browser - they need no extra server round trip and consume no extra credit.
Honest limitation: the score is computed from the page's raw CSS, not a rendered browser engine - it can tell you that media queries and flexible layout techniques exist and roughly how they're distributed, but it can't verify every element visually reflows the way you'd want. That's exactly why the device previews sit right next to the score: use them for a visual gut check and the checklist for what to fix.
Reading Your Results
The results panel breaks into three parts:
- The device picker and showcase let you inspect the real page at any modern screen size, plus a desktop/laptop/tablet/mobile lineup side by side - the fastest way to spot obvious breakage like overlapping text or a horizontal scrollbar.
- The score ring shows the 0-100 total and letter grade at a glance - use it to track whether a change actually moved the needle after you run the check again.
- The checklist lists all six scored signals individually, color-coded green/amber/red, each with a plain-language explanation of what was found and, where relevant, what to do about it.
Why Mobile-Friendliness Matters for SEO
It's worth being precise about what's a direct ranking factor here and what isn't. Google has used mobile-first indexing since 2019 - the mobile version of a page is what gets crawled and evaluated, full stop, which is a direct mechanical fact about how indexing works. Whether a specific layout bug costs you rankings is a different, indirect question: a broken mobile layout doesn't trigger a penalty by itself, but it does drive up bounce rate and drive down time-on-page, and those engagement signals feed back into rankings over time. Treat the score below as a diagnostic, not a ranking score in itself.
- The viewport tag is foundational, not optional. Without it, every other responsive technique on the page is effectively disabled, since the mobile browser renders at a fixed desktop-like width regardless of what the CSS says - this is why it carries real weight in this tool's score.
- Media queries do the actual adapting. A page can have a viewport tag and still look broken on mobile if its CSS never changes anything at narrower widths - this is the single most commonly missed piece, and the main thing this tool checks that a purely visual preview can't.
- Fixed-width containers are a frequent silent bug. A single
width: 1200pxon a wrapper div, left ungated by a media query, is enough to force horizontal scrolling on every mobile visitor even if the rest of the page is perfectly responsive. - Small text and zoom-locking compound each other. Disabling pinch-to-zoom is a genuine accessibility failure (WCAG 1.4.4) precisely because it removes the one workaround users have for text that's too small to read comfortably.
A Practical Example
A five-year-old blog theme, checked with the Samsung Galaxy S23 selected in the dropdown.
Score of 52/100 (D): the viewport tag was present and correct (20/20), but only 2 media queries were found and neither covered the mobile band under 600px (5/25), and a .container { width: 980px; } rule sat outside any media query, triggering a fixed-width penalty (4/15).
The showcase confirmed it visually: the mobile frame showed the desktop layout shrunk down with a horizontal scrollbar, exactly what the fixed 980px container and missing mobile breakpoint predicted.
Add a @media (max-width: 600px) block that overrides .container to width: 100%; max-width: 100%; first - that single change would likely resolve the mobile overflow and move both the media-query and flexible-layout scores up significantly.
Common Causes of a Failed Mobile Friendly Test
- Missing or misconfigured viewport tag. The most common single cause - without
width=device-width, nothing else the CSS does matters on mobile. - No media queries, or ones that don't cover mobile. A stylesheet with desktop-only breakpoints leaves phones stuck rendering the desktop layout.
- Fixed-pixel containers. A wrapper, table, or embed with a hardcoded wide pixel width forces horizontal scrolling regardless of how well everything else adapts.
- Non-responsive images. A full-width hero image with no
srcseteither overflows the viewport or forces a phone to download a desktop-sized file. - Tiny, unreadable text combined with a zoom lock. Small font sizes are recoverable if users can zoom - disabling zoom removes that fallback entirely.
Real-World Use Cases
- Pre-launch and post-redesign checks. Confirm a new theme or template actually works across device widths before it goes live.
- Agency QA checklists. Add a mobile friendly test alongside meta tag, speed, and broken-link checks before a client site ships.
- Before/after verification. Fix one issue - add a breakpoint, remove a fixed-width container - and re-run the check to confirm the score and preview both improved.
- Template and theme validation. Check one representative page from a shared template; a fix there usually applies to every page built from it.
- Client reporting. The device showcase is an easy, non-technical way to show a client exactly what a mobile visitor sees, without them needing to squint at their own phone.
Common Mistakes to Avoid
- Trusting the visual preview alone. A page can look fine in a quick preview scroll and still have real underlying issues (tiny text, a barely-there breakpoint) that only show up on an actual device - use the checklist alongside the preview, not instead of it.
- Adding a viewport tag without testing further. A viewport tag alone earns 20 of the available 100 points - it's necessary but not sufficient; the layout still needs media queries and flexible sizing to actually adapt.
- Fixing the preview but not the CSS. If a device frame looks fine because the target site happens to have a narrow max-width already, don't assume the underlying breakpoint coverage is strong - check the score, not just the preview.
- Assuming one page represents the whole site. A homepage built on a modern responsive theme and a legacy landing page can have very different scores - check more than one template before drawing conclusions site-wide.
Expert Recommendations
Fix in the order the score weights things: the viewport tag first if it's missing (20 points, and it unlocks everything else), then media query coverage for the mobile band specifically (worth the most - 25 points), then flexible layout and responsive images. Small font sizes and mobile meta polish matter but move the needle less - don't spend disproportionate time there before the structural fixes are done.
One thing worth knowing before you chase a perfect score: a site can pass every check here and still feel awkward on a real phone, because CSS-level correctness and touch usability are related but not identical. Real-device testing on your own phone (not just this preview) is still worth five minutes before a launch, specifically for tap-target spacing and anything that depends on hover - a menu that only opens on mouseover, for instance, can have flawless media queries and still be unusable on a touchscreen.
Re-run the check after every meaningful change rather than batching several fixes and testing once - it's the only way to confirm which specific change actually improved the device preview and the score, especially since CDN or browser caching can make an old version look unchanged for a few minutes after a real fix ships.
Limitations to Keep in Mind
- Some sites block iframe embedding (X-Frame-Options/CSP
frame-ancestors) - when that happens the device preview stays blank even though the score and checklist, which come from a direct fetch, still work normally. - The score is computed from the page's raw CSS, not a rendered browser engine - it measures whether responsive techniques exist and how they're distributed, not a pixel-by-pixel visual diff.
- Up to 8 linked stylesheets are fetched and analyzed per check - a page with far more than that will still get an accurate read on its most common breakpoints, with the rest simply not contributing further evidence either way.
- Content loaded by JavaScript after the initial page load (some single-page apps) isn't included in the HTML/CSS analysis, though it will still appear in the device preview since that's a real browser render.
- This tool doesn't replicate Google's own crawler or its rendering environment - it's an independent mobile friendly test, not a guarantee of how Search Console would evaluate the same page.
Run the mobile friendly test above against any live URL to see its device preview and full score in a few seconds - it's free, and no account is required.