Is your website mobile friendly? How to actually check

Test on a real phone, logged out, off wifi

Resizing a desktop browser window down to a narrow width tells you almost nothing about how your site actually behaves on a phone. A real phone has a touch interface instead of a mouse pointer, a keyboard that pops up and eats a third of the screen, and a connection that is often slower and less reliable than whatever you are using in the office. It also comes with a visitor who has far less patience - on desktop, people tolerate a clunky layout because they are already committed to the task; on mobile, they simply leave. To test properly, open your site on an actual phone over mobile data, in a private or incognito window so cached files and saved logins do not flatter the result. Then do not just glance at the homepage - try to complete the single most important action a visitor would come to do, whether that is filling in a contact form, adding something to a cart, or finding your phone number, and notice exactly where it gets awkward.

The four things that make a site fail on mobile

Four problems account for most mobile failures, and they tend to compound each other. Text set too small to read comfortably forces visitors to pinch and zoom just to get through a sentence - usually a sign the design was built for a desktop screen and never properly reconsidered for a smaller one. Tap targets such as menu items, buttons, and links packed closer together than roughly 44 pixels cause mis-taps, and a mis-tap on a phone is worse than a misclick on desktop because there is no cursor to correct with before you commit. Content wider than the viewport - a table, an embedded video, an image with a fixed pixel width - forces sideways scrolling, which almost nobody does voluntarily on a phone; they just leave. And popups or cookie banners that cannot be dismissed with a thumb, because the close button is too small or sits off-screen, block the page entirely. None of these are cosmetic complaints: Google measures mobile usability along very similar lines, so a site that irritates a human visitor on these points is very often flagging the same problems to the algorithm that ranks it.

The viewport tag - one line that changes everything

A missing viewport meta tag is a fairly binary problem: either it is present and your page adapts to whatever screen is showing it, or it is absent and the phone falls back to rendering your site as a full desktop page, then shrinking that entire layout down to fit - which is why some sites look like a readable page photographed from three metres away, with tiny text and a permanent need to zoom. The fix is one line of HTML in the page head, a viewport tag that tells the browser to match the page width to the device width, and it ships by default in every mainstream template and website builder released in recent years. Where it actually goes missing is in custom-coded sites, older templates built before mobile-first design was standard, some landing-page tools, and pages that have been hand-edited enough times that the head section has drifted from the original template. Worth checking directly rather than assuming, because it is invisible until you look at the page source itself.

Mobile speed is its own problem

Speed problems that are invisible on office broadband become obvious the moment a visitor opens your site from a car park, a train, or anywhere without a strong signal - ten seconds or more is not unusual on a slow connection carrying a page that was never built with mobile in mind. This is not just an inconvenience; Google measures it directly. Core Web Vitals are assessed separately for mobile and desktop, and the mobile numbers are almost always worse, because the same page has to do more work on less capable hardware over a slower connection. The usual culprits stack on top of each other: images exported at desktop resolution and never resized for a phone screen, JavaScript that has to fully download and execute before the page becomes interactive, and web fonts that load late enough to cause a visible flash or shift as the real typeface swaps in. Because mobile devices process all of this more slowly than a desktop machine, the same code costs more time on a phone than it does in whatever environment you tested it in.

Forms are where mobile visitors give up

Every field you add to a form reduces the number of people who finish filling it in, and that cost roughly doubles on mobile, where typing is slower and more error-prone than on a physical keyboard. The details matter more than they seem to: a phone number field should trigger the numeric keypad rather than the full alphabet keyboard, and an email field should bring up a keyboard with an @ symbol readily available - if it does not, the input was not built with the right field type set, and every visitor pays for that with extra taps. Autofill should also work, so returning visitors can complete a form in seconds rather than retyping an address by hand. And error messages need to stay visible without scrolling back up the page - a validation message that appears off-screen after a failed submission often reads as the form being broken rather than the field being wrong. A form that is mildly annoying to fill in on a desktop screen becomes something people abandon entirely once it is that fiddly on a phone.

Check it all in one pass

Working through all of this by hand - a real phone, four failure modes, the viewport tag, mobile Core Web Vitals, every form - takes real time, and most site owners do not have a spare afternoon for it. The AuditHQ technical suite runs these checks together: mobile responsiveness signals, viewport configuration, tap-target and text-size measurements, and mobile Core Web Vitals pulled directly from Google PageSpeed Insights, the same underlying data Google itself uses to judge your site. Every finding comes back explained in plain language and ranked by how much it is likely costing you, rather than as a raw technical score you have to interpret yourself. The free scan gives you the headline mobile picture in about 60 seconds, which is enough to tell you whether the deeper technical audit is worth running.

Frequently asked questions