Free test
Mobile-friendly test
Google retired its own in December 2023. This one fetches your page twice — once as an iPhone, once as a laptop — and tells you what the phone was actually sent, with the markup it read printed next to each answer.
What it checks
Four things a response can settle
The viewport declaration
Whether the page asks a phone to lay it out at the device’s own width, pins it to a fixed one, or says nothing at all and gets shrunk. One line of markup, and the difference between a readable page and a tiny one.
Whether zooming is switched off
user-scalable=no stops anyone enlarging the text. It is an accessibility failure regardless of what it does for the layout.
Whether a phone is treated differently
Both user agents are fetched and compared. A mobile-only redirect, a consent wall or an app-install interstitial shows up as a different destination or a much smaller page — and is invisible to any test run from a laptop.
How long the server took
Measured either side of our own fetch. This is the server’s share of the wait, not the time until the page is usable, and the page says which.
If you came looking for Google’s
What it checked, and what settles each part now
The tool is gone and the question is not. Exactly one of the things it reported is settled by this test. The rest are not, and the pointers below are to whatever actually answers them — Google’s own suggestion at the time was Lighthouse.
“Viewport not set” / “not configured”
A declaration in the markup, so it is settled by reading the response. This test does it, and prints the tag it read.
“Page partially loaded”
This meant Googlebot could not fetch the page’s own CSS, JavaScript or images — nearly always a robots.txt rule blocking them. Not this test: we fetch the HTML document and never request a sub-resource, so we cannot see it. Search Console’s URL Inspection, then Test Live URL, then Page resources — that part was not retired.
“Text too small to read”, “clickable elements too close”, “content wider than screen”
Properties of the page once a browser has drawn it, so nothing reading markup can judge them. A real phone is the dependable answer. Lighthouse covers some of it and has moved: tap targets are now the accessibility audit target-size, judged against WCAG’s 24×24 CSS pixels rather than the old 48px rule; font size and viewport sit under Best Practices; and the content-width audit went with the PWA category in Lighthouse 12.
“Uses incompatible plugins”
Flash and friends. Obsolete rather than replaced — the plugins it warned about no longer run in any phone browser.
The Mobile Usability report in Search Console
Retired at the same time and not replaced. The nearest thing is Core Web Vitals, which answers a different question — how the page behaves, not whether it fits.
And one thing Google’s tool never checked, which is the reason this page exists: whether a phone is served something a laptop is not. A mobile-only redirect, a consent wall or an app interstitial is invisible to any test run from a desktop, and it is where most paid clicks land. That comparison is ours.
Common questions
Mobile-friendly testing, answered plainly
What happened to Google’s Mobile-Friendly Test?
Google retired the Mobile-Friendly Test tool and its API in December 2023, along with the mobile usability report in Search Console. Its reasoning was that the mobile web had matured enough that the report was no longer the most useful signal. That removed the simplest way to ask the question, which is why tools like this one exist.
How do I test if my website is mobile friendly?
Fetch the page as a phone and check three things you can settle from the response: that a viewport meta tag asks for the device width, that a phone is not redirected somewhere a laptop is not, and that the page a phone receives is not a stripped or walled version of the desktop one. Then open it on a real phone for everything else — tap targets, text size and horizontal overflow need the page rendered.
What is a viewport meta tag and why does it matter?
It is one line in the head of the page that tells a phone how wide to lay the page out. With content="width=device-width, initial-scale=1" the phone uses its own screen width. Without it, the phone assumes a desktop-width layout and shrinks the whole thing to fit, which is why a site can look complete and be unreadable. It is the single highest-value mobile fix and it is one line.
Can this test tell me if my tap targets are too small?
No, and no tool that only reads the response can. Tap target spacing, text size and horizontal overflow are properties of the rendered page, which means running the CSS and JavaScript in a real browser and measuring the result. This test reads what your server sent, which settles the declarations and the redirects and nothing about the painting.
Is there a replacement for the Google Mobile-Friendly Test API?
Not a first-party one. Google retired the API alongside the tool in December 2023, so there has been nothing official since. The closest replacements are both Google’s and both answer narrower questions: the PageSpeed Insights API runs the Lighthouse audits named above, which is where tap targets, font size and viewport live now, and the URL Inspection API in Search Console reports whether a URL is indexable, which is not the same as whether it is usable on a phone. We do not publish one. The check on this page fetches whatever URL it is handed, so an open endpoint is a request made from our address to someone else’s server on a stranger’s instruction, and that is not something to hand out without a real gate in front of it.
Does mobile-friendliness affect Google rankings?
Google indexes with a smartphone crawler, so the mobile version of a page is the version that gets indexed. A page that a phone cannot render properly is the page being assessed. That is separate from paid traffic, where a mobile-only failure is billed for directly: most ad clicks are phones, so a wall that only fires for a phone wastes the majority of the spend on that campaign.
Why a monitoring company publishes a mobile test. Because the two questions meet at one fact: most paid clicks are phones, so a page that fails only for a phone fails for the majority of what you paid for, and a test run from a laptop will never show it. The version of this problem worth money is not a layout that was always wrong — that one you find the first time you look. It is the page that was fine until a deploy at midnight, which is the other tool on this site, and the one we charge for.