Mobile-friendly website: what does your site need to get right?

The foundation is responsive design: one URL and one codebase that adapts the layout to the screen width. Columns stack, menus collapse, images scale. Technically it starts with the viewport meta tag. Without it, the phone shows a zoomed-out desktop site where text is unreadably small and buttons become unreachable.

On top of that come the details that separate workable from pleasant. Text large enough to read without zooming (in practice often at least 16 CSS pixels). Buttons and links with enough space around them. Forms that open the right keyboard per field, for example digits for a phone number. No content wider than the screen, so you do not have to scroll horizontally.

Mobile-friendliness is no longer a separate 'mobile site'. A subdomain such as m.example.com means double maintenance, redirect risk and the chance that phone content drifts from desktop. One responsive site has been the standard for years, and that is exactly what search engines and visitors expect.

Google uses mobile-first indexing: the crawler primarily views and indexes the mobile version of your pages. Content hidden or omitted on phones therefore does not count for visibility. A site that looks complete on desktop but stripped-down on mobile competes in the search results with its weakest version.

Speed also weighs heavier on mobile, because connections are less stable and devices have less processing power. The Core Web Vitals are measured on real visitors, and on most sites more of them are on phones than on desktops. Mobile-friendliness and load speed are two sides of the same job: what is slow or unusable on a small screen hurts both conversion and ranking.

In practice this means: publish the same core content, metadata and links on mobile as on desktop. Do not hide important text behind tabs that only collapse on phones without accessible controls. Test whether your product pages, checkout and contact form work on a real device, not only in your browser's desktop emulator.

The problems scans find most often are rarely spectacular, but they are disruptive. Tap targets placed too close together, so you hit the wrong one: a navigation link above a button, two icons touching. Font sizes below 16 pixels that become unreadable on a small screen. Tables or wide images that make the page overflow. Pop-ups that occupy a corner on desktop but block the entire screen on mobile without a reachable close button.

For touch targets there is a concrete lower bound in the accessibility guidelines. WCAG 2.2 requires at least 24 by 24 CSS pixels for a touch target; in practice designers aim for roughly 44 to 48 pixels for comfortable thumb use. This is where mobile and digital accessibility meet: what is hard to hit with a thumb is even harder with a tremor or limited vision.

Other classics: sticky headers that consume too much vertical space, cookie banners that cover the CTA, and carousels that only work with a swipe and no buttons. Each of those patterns fails the mobile pillar and often criteria from WCAG. Teams that design for desktop first and then "make it responsive" almost always bake these mistakes in.

On a phone everyone depends equally on clear focus, sufficient contrast and operable buttons. Zoom, voice control and screen readers work better when the HTML is semantic and buttons are real buttons, not clickable divs. The European Accessibility Act (see also the Dutch government overview) enforces for many e-commerce services what good mobile UX already required: nobody should drop out because a checkout only works with a mouse or only on a large screen.

For shops and booking flows that is not abstract compliance. If your order button is too small, your form labels are missing or your error messages are unclear, you lose conversion with every visitor, not only people with impairments. Mobile-friendliness is therefore also an accessibility investment: you remove measurable barriers that the scan can flag in both pillars.

The quickest first check is your own phone, not only the developer view. Open the site on a real device, preferably an older model with a smaller screen, and try the three most important tasks: finding something through the menu, filling in a form, reading a page. Wherever you zoom, misclick or wait, so does your visitor.

For a systematic check, WebYes scans measurable points within the mobile pillar: viewport configuration, readable font sizes, tap targets and content overflowing the screen. The scan covers up to six pages per run; findings are listed per page in the report. Automated WCAG 2.2 AA checks sit under the accessibility pillar, but often overlap with mobile (contrast, labels, target size).

The WebYes quality mark requires an average score of at least 80 and at least 60 per pillar. A strong desktop site with a weak mobile score therefore does not pass. Fix the blockers that hit visitors first, re-scan, then plan the finer improvements. That way you know whether your site is truly mobile-friendly, instead of only looking responsive in a mockup.

Open the site on a phone you do not use daily for development. Walk through three tasks: navigation via the menu, a form or checkout step, and reading a long page. Note where you zoom, scroll horizontally or accidentally hit the wrong control. Those notes are often more valuable than an abstract responsive preview.

Check sticky headers and cookie banners: together they should not take more than a third of the viewport on a small screen. Test whether buttons stay reachable when the soft keyboard is open. If the primary CTA then disappears behind the bar, the flow fails in practice even if the CSS is called 'responsive'.

Then compare with the WebYes report. Findings about tap targets, font size and overflow should match what you felt on the device. If lab differs from your experience, note the exact URL and re-scan after a fix; the full audit covers up to fifteen pages so deeper templates can be included.