Article
Mobile-Friendly Website Guide
Mobile-friendly does not mean the desktop site squeezed until it fits. It means a person can read, tap, and complete the job on a phone held in one hand, often on an uneven network. For many markets WEBCETRA serves, that person is the primary visitor, not an edge case.
WEBCETRA Editorial · · · 9 min read
Google indexes with a mobile user-agent. Core Web Vitals are reported for mobile separately. Accessibility overlap is large: tap targets, contrast and labels help everyone. Use WCAG 2.2 (https://www.w3.org/WAI/WCAG22quickref) as the bar, not a mobile-friendly afterthought in a theme setting.
Contents
- Responsive is necessary, not sufficient
- Layout, type and tap targets
- Navigation that does not hide the offer
- Forms, calls and WhatsApp realities
- Performance on real phones
- Content that works at a small width
- QA you can do without a lab
Responsive is necessary, not sufficient
A fluid grid that still presents a 12-column dashboard, hover-only menus, and tiny links is responsive and unusable. Design the mobile template as a first-class layout: one column, priority content, sticky access to the next step if it helps.
If you only test by dragging a desktop browser narrower, you will miss font boosting, notches, and how keyboards cover submit buttons. Use real devices when you can.
Layout, type and tap targets
Body text should stay readable without pinching. Line length on a phone is short; keep paragraphs tight. Contrast must hold outdoors. Tap targets need space — WCAG 2.2 has explicit target size criteria; crowding Call next to Menu is how people tap the wrong thing.
Do not disable zoom. Users with low vision need it. Horizontal scroll for main content is a failure unless you are showing a data table with a clear alternative.
Navigation that does not hide the offer
Hamburger menus are fine if the important action (Enquire, Shop, Call) is still visible. Do not bury contact behind three nested accordions. Sticky bars that cover half the viewport are not navigation; they are ads.
Megamenus that worked on desktop must collapse into a scannable list, not a maze. For service businesses, a short list of services plus contact often beats a clever icon nav.
Forms, calls and WhatsApp realities
Use the right input types (email, tel, number) so the correct keyboard appears. Autocomplete attributes reduce typing. Do not use a 20-field form as the only conversion path on mobile; offer a phone link and, where it is a real channel for you, a WhatsApp link that you actually monitor.
Click-to-call should use a real tel: link. International numbers need the country code. If you generate leads from export markets, say who will answer and in which hours — false availability is worse than a form.
Performance on real phones
Mid-range Android devices and congested 4G are the design constraint, not a plugged-in laptop. LCP images, chat widgets and unoptimised fonts hurt here first. Follow blog/how to improve website speed and blog/core web vitals explained.
Interstitials that block content on small screens are hostile and can affect search. If you need a cookie banner, keep it compact and operable.
Content that works at a small width
Tables should scroll inside a container or become stacked definition lists. PDFs as the only catalogue are painful on a phone; HTML product or capability pages win. Huge background videos should not be the only brand moment.
Pop-ups, exit intents and chat bubbles stack and hide the form. Audit the live mobile page, not the design frame.
QA you can do without a lab
Open the site on your phone on cellular data. Complete the primary action. Rotate the device. Use a screen reader for five minutes if you can. Ask someone who is not on the project to find the phone number.
Development work that claims mobile-first should show this QA in the handover, not only desktop screenshots. That is part of how we scope services/web development.
Questions
Do we still need a separate mobile site?
Almost never. One responsive site with the same URLs is the standard. Separate m-dot sites create duplicate-content and maintenance cost. Exceptions are rare and should be argued, not assumed.
Is AMP required?
No. AMP is not a requirement for ranking. Fast, valid HTML on your own templates is the durable approach.
Should we hide content on mobile for speed?
Do not hide unique important content that desktop users see if you want that content indexed and useful. You can change layout and priority; omitting the offer is a different, worse decision.
Author
WEBCETRA Editorial. Practical articles from WEBCETRA on websites, SEO and digital systems. Written for business readers, not for ranking tricks.
Further reading on Google Search Central (developers.google.com/search/docs), Core Web Vitals on web.dev, and accessibility on the WCAG 2.2 quick reference.