For most businesses the majority of traffic is now mobile. "Mobile-friendly" stopped being a nice-to-have years ago — it is the default experience, and the desktop is the adaptation — the reasoning behind designing mobile-first in the first place. Search engines index the mobile version of your site as the primary one, so a page that works on a laptop and struggles on a phone is being ranked on the version that struggles. What follows are nine practices, each with a concrete check, that separate a site that merely fits on a phone from one that actually works in a hand.
1. Design for thumbs, not cursors
Touch targets need room. Buttons and links that are trivial to click with a mouse become frustrating on a phone held one-handed on a moving train. Size and spacing are accessibility, not decoration.
There are numbers behind this rather than taste. Apple's guidance has long been around 44pt, Android's around 48dp, and WCAG 2.2 added a Target Size criterion setting a floor of 24 by 24 CSS pixels. Treat 44 as the target and 24 as the absolute minimum, and remember that spacing counts too: two correctly sized buttons with no gap between them still produce mis-taps. Put primary actions in the lower part of the screen where a thumb rests, and keep destructive actions away from the ones people tap most.
2. Get the viewport and text size right
The viewport meta tag is the single line that tells a phone to render the page at device width instead of pretending to be a desktop and shrinking everything. Without it, nothing else on this list matters. With it, text should be readable without zooming — around 16 pixels for body copy is the practical floor — and the page should never disable zooming. Users with low vision rely on pinch-to-zoom, and a page that blocks it fails accessibility checks and frustrates real people for no benefit.
3. Respect the network
Your users are not all on office Wi-Fi. Heavy images, blocking scripts and huge fonts turn a beautiful design into a blank screen on a real mobile connection.
The failure mode that matters is not slowness but uncertainty — a screen that shows nothing while it waits, with no indication whether it is working or broken. Getting something meaningful painted early, even an incomplete version, changes how the wait is experienced far more than shaving a few hundred milliseconds off the total. Serve images sized for the viewport in modern formats, load fonts with a fallback so text shows immediately, defer scripts that are not needed for the first paint, and set a performance budget so the page does not slowly regain the weight you removed.
4. Make forms work with a software keyboard
Forms are where mobile sessions die. The fixes are small and mostly about telling the browser what each field is for: type="email" brings up a keyboard with an @ sign, type="tel" a number pad, inputmode="numeric" for codes and quantities. Autocomplete attributes let the browser fill name, address and payment details in one tap. Labels should be visible and stay visible, not placeholders that vanish on focus. Validation should be inline, next to the field, in plain words. And nothing fixed to the bottom of the screen should sit on top of the field someone is typing into.
5. Never let the page scroll sideways
A single element wider than the viewport — an image without max-width, a table, a long unbroken string, a fixed-width container — forces the whole page to scroll horizontally, and every other interaction on the screen breaks with it. Give images and embedded media a maximum width of 100 percent, wrap tables in their own scrolling container, and test every page at a narrow width. This is the most common mobile defect and the easiest to catch.
6. Do not depend on hover
Anything that reveals on hover — a menu, a tooltip, a product's secondary image — either does not work on a touch screen or requires a phantom first tap that does something unexpected. Every interaction has to work on tap alone. Navigation menus in particular need a tap-to-open pattern that also works with a keyboard and a screen reader, because the hover-only version excludes all three.
7. Reserve space so nothing jumps
Layout shift is when content moves after a reader has started reading — an image loads and pushes the paragraph down, a banner injects itself at the top, a font swaps and re-flows the text. On a phone this means tapping the wrong thing. Give every image and embed explicit width and height attributes so the browser reserves the space, load ads and banners into fixed-size containers, and preload fonts. Cumulative Layout Shift is one of Google's Core Web Vitals, and it is the cheapest one to fix.
8. Keep content parity
Hiding sections on small screens to "simplify" the mobile experience is usually a sign that the desktop page had too much on it. If information is important enough for a desktop visitor, it is important enough for a mobile one, who is often the same person on a different device. Mobile-first indexing also means content hidden on mobile may not count for search. Reorganise and prioritise instead of hiding, and if something truly is not worth showing on a phone, ask whether it is worth showing at all.
9. Test on the device, not the simulator
Browser device emulation is useful for layout and misleading about everything else. It does not reproduce touch accuracy, the software keyboard covering half the viewport, the performance of a three-year-old processor, or what happens when the signal drops in a lift. Complete the main flow — landing, browsing, form, purchase or sign-up — once on a real mid-range phone, alongside whatever automated checks already run, on mobile data, before every significant release. This check is worth more than the eight above it, and it is the one most often skipped.
The things that actually break on phones
Most mobile problems are not visual. They surface in the parts of a page teams rarely test on a real device:
- Forms. Wrong input types mean the wrong keyboard. No autocomplete attributes mean no autofill. Both turn a thirty-second task into a two-minute one.
- Fixed elements and the keyboard. A sticky footer CTA that sits on top of the field you are typing into is a bug that only ever appears on a phone.
- Hover-dependent interfaces. Anything that reveals on hover either does not work or requires a phantom first tap.
- Tables and wide content. A table that forces the whole page to scroll sideways breaks every other interaction on the screen.
- Modals with no reachable close. Perfectly placed on a desktop, off-screen or under the notch on a phone.
- Popups and cookie banners. An overlay that covers the content the moment a visitor arrives from search is both a usability failure and a ranking signal against you.
The checks worth running today
- Tap targets comfortably sized, with real spacing between them
- Readable text without zooming, and a viewport that permits zooming anyway
- No horizontal scrolling on any page at any width
- Correct input types and autocomplete attributes on every form field
- Images with intrinsic dimensions so nothing jumps as they load
- Interactive elements that work on tap without a hover state
- Content parity with desktop — no important information hidden on small screens
- Core Web Vitals passing in field data for mobile, not just in a lab run
- The whole flow completed once on a real mid-range phone, on mobile data
Where to start if everything above is failing
If a site fails most of these checks, the order matters. Fix the viewport tag and horizontal scrolling first, because they break everything else. Then the forms, because that is where money is lost. Then images and layout shift, which are usually a day of work and move the Core Web Vitals immediately. Leave the visual polish for last; a plain page that works in a hand beats a beautiful one that does not.
Frequently asked questions
How do I check if my website is mobile-friendly?
Open it on a mid-range phone over mobile data and try to complete the main task. Then run a Lighthouse audit for the mobile profile and check the Core Web Vitals report in Search Console, which shows how real visitors experience the site. If the phone test is frustrating, the tools will tell you why.
Does mobile-friendliness affect search rankings?
Yes. Google indexes the mobile version of a page as the primary version, and page experience signals including the Core Web Vitals are measured on mobile. A site that is slow, shifts around or is hard to use on a phone is at a disadvantage against one that is not.
Is a responsive site enough, or do we need a separate mobile site?
A single responsive site is the right approach for almost everyone. Separate mobile sites double the maintenance and split the search signals. The exception is a genuinely different product for mobile users, which is rare — and at that point the question is usually whether it should be an app.
Mobile-friendly is table stakes, and the bar keeps rising. We help teams find the gap between a design that looks right in a browser window and a product that works in a hand.