Free Mobile Friendly Test
Enter a page address and this checks the things that decide whether a phone visitor can use it: the viewport tag, whether zoom has been blocked, fixed pixel widths that force sideways scrolling, text set too small to read, images sized for a desktop, and whether your phone number is one tap away. Every finding comes with the fix.
What this checks
Viewport meta tag: whether the page declares one at all, and whether it is the correct width=device-width version.
Fixed-pixel-width elements are pinned to a width in pixels, which is what pushes a layout wider than the screen it is on.
Sideways scroll unwrapped tables and no-wrap rules are the two most common reasons a page drags horizontally on a phone.
Responsive images how many images offer a srcset, so a phone gets a phone-sized file instead of the desktop original.
Image dimensions width and height attributes, without which the page shuffles about as each image arrives.
Text size: base font size and any rules setting text below the point at which it stops being readable at arm's length.
Tap to call: whether your phone number is a tel: link a visitor can dial in one tap, or plain text they have to copy.
What a phone downloads: server response time, page weight, request count, and image size, because on mobile data, all of it costs twice as much.
Tap targets links sitting close enough together that a thumb is likely to hit the wrong one.
Pinch zoom whether user-scalable=no or a maximum-scale is stopping anyone enlarging the text.
Mobile-first indexing: the phone version is the one that ranks
Google crawls and indexes with a smartphone crawler. The mobile version of your page is the version it stores, reads, and ranks — the desktop version is not a fallback it consults later. If content exists on desktop and not on mobile, for practical purposes it does not exist. If your structured data, your headings or your internal links are hidden on small screens, that is the version Google works from.
On a well-built responsive site, this is a non-event, because both versions are the same markup. It bites on sites with a separate mobile theme, sites where a builder hides whole sections on mobile to tidy the layout, and sites where the mobile menu drops half the navigation. Hiding a section with CSS is fine; not outputting it at all on mobile is a decision about what Google reads.
Google retired its own Mobile-Friendly Test tool in December 2023, along with the mobile usability report in Search Console, on the grounds that the web had largely caught up. That is context rather than a claim about what Google does now — mobile-first indexing did not go anywhere, and neither did the sites that still break on a phone.
The viewport meta tag, properly explained
This one line decides everything else, and it is worth understanding rather than copying. Phones default to pretending they are about 980 pixels wide, then shrinking the whole rendered page down to fit the real screen. That behaviour exists so that websites written in 2006 are still viewable. It means a modern responsive site, with no viewport tag, is rendered at desktop width and then zoomed out — so your media queries never fire, the text arrives tiny, and every button is too small to hit.
The tag that stops that is: a meta element named "viewport" with the content "width=device-width, initial-scale=1". The first half tells the phone to lay the page out at its actual width, so your responsive CSS applies. The second tells it to start at 100 per cent rather than zoomed. That is all you need, and adding anything else to it is usually a mistake.
Every current WordPress theme puts it in the head for you. So when this report says the tag is missing, the cause is nearly always something bypassing the theme header — a landing-page plugin with its own blank template, a custom page template someone wrote, or a builder canvas template with a stripped-down head. Find the template, add the line, and every other mobile finding on the report usually resolves with it.
Never block pinch zoom
The other viewport fault is the opposite of missing: a tag with user-scalable=no or a maximum-scale bolted on. It is usually added by someone trying to stop an iPhone zooming in when a form field is focused, or by a slider or popup plugin doing it without asking. The result is that nobody can enlarge anything on the page, ever.
For a chunk of your audience, that is the end of the visit. People with less than perfect eyesight zoom as a matter of course, and on the sort of site that sells services to adults, that is not a small group. It is also a straightforward accessibility failure — WCAG expects content to be resizable, and disabling zoom removes the one control a visitor has over that. There is no design reason worth it.
The fix is to delete the extra parameters, leaving width=device-width and initial-scale=1 and nothing else. If the tag looks clean in your theme and the report still flags it, check your slider, popup, and cookie-banner plugins — one of them is writing its own viewport tag after the theme has written the right one.
The small fixes that change the enquiry count
The headline faults are worth fixing because they stop the page from working. These next ones are worth fixing because they change what happens after it works, and they take an afternoon to fix.
Start with the phone number. A number typed as plain text has to be memorised or copied over to the dialer; the same number as a link is one tap. Write it as a tel: link with the number in international format in the href, everywhere it appears, and test a sticky call button on mobile while you are at it. On a site whose visitors are already holding a phone, this is the single change most likely to show up in the enquiry count rather than the score.
Then the rest. Give every tappable thing a hit area of roughly 48 by 48 pixels, with padding rather than by making the text bigger, so a thumb stops landing between two links. Set body text to at least 16 pixels — if the design looks crowded at 16, the answer is line height and spacing, not smaller type. Put width and height attributes on every image so the page stops shuffling while it loads, because that shuffle lands exactly when someone is reaching for a button. And insert images through the media library so WordPress generates the responsive sizes; the ones that miss out are nearly always hard-coded into a template, a custom field or a builder background.
What this mobile test cannot see
This reads your markup rather than rendering the page in a phone browser. It does not take a screenshot, does not simulate a touchscreen and does not run your JavaScript. So what it finds are the structural causes of a bad mobile experience — the missing viewport tag, the blocked zoom, the fixed pixel widths, the images with no dimensions — rather than a picture of the result.
That is a real limit and worth stating. A page can pass everything here and still look wrong on a phone, because a menu overlaps a heading or a background image crops badly at 390 pixels. Equally, some findings are indicators rather than verdicts: a fixed width inside a media query may be perfectly deliberate, and the report marks that kind of thing as something to look at rather than something that is wrong.
So use this to find the faults that are invisible from your desk, then do the thing no tool replaces: open the page on an actual phone, on mobile data rather than the office wifi, and try to contact yourself. Five minutes of that will tell you more about the mobile experience than any report, including this one.
Questions people ask
Google shut down its Mobile-Friendly Test. Is this a replacement?
It covers the same ground from a different angle. Google retired that tool in December 2023, and it worked by rendering the page in a simulated phone and showing you a screenshot. This reads the markup instead, so it names the cause — the viewport tag, the fixed width, the missing dimensions — rather than showing you the symptom.
For the rendered view, Google's URL Inspection tool in Search Console still shows you how Googlebot sees a page on your own verified site. The two together are a good pairing: this finds what is wrong, that confirms what Google ends up with.
What does mobile-first indexing actually mean?
It means Google crawls your site with a smartphone crawler and indexes the mobile version of each page. That version is what gets ranked, for desktop searches as well as mobile ones. If something is on your desktop page but not output on mobile, it is effectively not part of the page as far as search is concerned. On a normal responsive site both versions are the same markup, so nothing changes — the risk is on sites that serve different content to phones.
Is this mobile-friendly test free?
Yes. No account, no card, nothing to install. A fair-use limit stops it being used as a bulk scanner, and beyond that you can run it on as many pages as you want.
Do I need to give you my email address?
Not for the score, the breakdown or the first fixes. The rest of the fix list asks for an email address, which is what pays for a free tool. You are asked once.
Does running this change anything on my site?
No. It requests your page as a visitor would and reads what comes back. It never logs in, never submits a form and never writes anything. Your site is exactly as it was before you ran it.
My theme is responsive. Why has this found problems?
A responsive theme handles the layout it controls. Most mobile faults come from what was added on top: a table pasted into a page with no wrapper, a width in pixels typed into a builder's advanced tab, a plugin writing its own viewport tag, images dropped into a template rather than inserted through the media library. The theme is fine and the page still breaks — which is why this checks the page rather than the theme.
Why does it matter if I have disabled pinch zoom?
Because it removes the only tool a visitor has for making your text readable. Anyone with less than perfect eyesight zooms by habit, and on a phone that habit is near universal past a certain age. Blocking it is an accessibility failure under WCAG and it costs you visits from exactly the people most likely to pick up the phone. Remove user-scalable=no and maximum-scale from the viewport tag and the problem is gone.
How often should I run this?
After any redesign, after adding a page builder plugin or a popup, and whenever you publish a landing page that uses a template other than your normal one. Those templates are where the viewport tag goes missing. Beyond that, once a quarter alongside your other checks is plenty.
Want the phone version put right?
Most of your visitors are on a phone and so is the version Google ranks. Send us the address and we will tell you what is broken on mobile, what it takes to fix and what it is likely to be costing you in enquiries.
