Your website is responsive. It shrinks to fit a phone and looks fine on your office screen. Yet on phones — check the split in your analytics — visitors browse and leave without calling, messaging or enquiring. The fault is rarely the resize. It is the order, weight and touch design inherited from a desktop layout. Run the seven checks below on your phone, in order, noting each result: pass, fix or rebuild.
The short answer: run these seven checks on your own phone first
One: can you call the business within seconds of landing, without scrolling or opening a menu? Two: can you start a WhatsApp chat just as fast? Three: can you reach every main service through the mobile menu in two taps or fewer? Four: are buttons and menu links big enough to tap first time? Five: does the first mobile screen answer what a visitor came for? Six: does the page load within the published Core Web Vitals thresholds? Seven: can you complete the enquiry form one-handed, and does everything important on desktop also exist on mobile?
The problem: "responsive" on paper, broken where your visitors actually are
Responsive design means a layout adapts to the screen size. Mobile-first means the phone version came first and desktop expanded from it. Most older SME sites are the reverse: a desktop design compressed afterwards. Compression passes a casual check while hiding faults — contact actions demoted below long introductions, menus collapsing into deep tap chains, and desktop-sized images delivered to phones.
There is also a search consequence. Google's mobile-first indexing documentation states that Google uses the mobile version of a site's content for indexing and ranking, and advises that it carry the same content, headings, metadata and structured data as desktop. Compare your analytics: mobile visits against mobile calls and enquiries — that gap is the only statistic needed. Our overview of responsive web design services explains how the service version of this work is scoped.
Check 1–2: can a mobile visitor call or WhatsApp you without hunting?
Open your homepage on your phone as a stranger would. Check 1: time finding a tappable phone number. If the number lives only in a footer, behind a menu, or as text that does not dial when tapped, the check fails — on a phone, a call is one tap or it is lost. Check 2: repeat for WhatsApp. In the UAE, many visitors prefer messaging to calling; if the path requires copying a number, the check fails.
The fix is placement: a persistent call or WhatsApp action visible without scrolling, and tap-to-call numbers wherever the number appears.
Check 3–4: menus, tap targets and the hover interactions touch can't use
Check 3 is the menu. Count the taps needed to reach your main service page and your contact details. Desktop mega-menus compressed into accordions often need four or five taps, with contact details at the bottom. Two taps to any main service is a fair pass mark. Check 4 is target size. Tap every menu item, button and icon with your thumb, not a fingertip. The W3C's WCAG criteria set 24 by 24 CSS pixels as the minimum target size, with 44 by 44 CSS pixels as the enhanced level — treat anything you can mis-tap as a fail.
While tapping, watch for hover. Hover-only dropdowns and links have no touch equivalent; on a phone they are unreachable or misfire. Anything hover-only fails this check.
Check 5: content order — what mobile shows first vs what visitors need first
On desktop, a page can open with a brand statement and introduction, because the service links and contact button stay visible alongside. Stacked on a phone, that order pushes the offer down. Check 5 asks: on the first mobile screen, can a visitor tell what you do, where you serve, and how to enquire?
Content ordered by internal preference — company history before services — is a desktop inheritance. Reordering is usually a fix, not a rebuild: the content exists, sequenced for the wrong device. This ordering discipline is one of the essential principles of effective web design applied to the smallest screen first.
Check 6: weight and speed — desktop images on mobile networks (with the vitals thresholds)
Check 6 is weight. Desktop-first sites commonly ship full-width desktop images to phones, displayed smaller. Run your key pages through Google PageSpeed Insights and read the mobile result against the published Core Web Vitals thresholds from web.dev: Largest Contentful Paint at or below 2.5 seconds, Interaction to Next Paint at or below 200 milliseconds, and Cumulative Layout Shift at or below 0.1, at the 75th percentile of real visits.
Causes are identifiable: oversized hero images, scripts loaded before content, and elements that shift as fonts load. Resizing and compression are fixes; a theme loading desktop assets regardless of device points to rebuild. Our Core Web Vitals launch checklist covers the launch-stage version of these checks.
Check 7: forms built for keyboards, and content that exists only on desktop
Check 7 has two halves. First, complete your own enquiry form on your phone. Keyboard-designed forms ask too much, summon the wrong keyboard (text for a phone number), and hide labels. A mobile form should ask the minimum, set the right input type per field, and be completable one-handed. Second, compare content: open your five key pages on desktop and mobile side by side. Anything missing on mobile — a service, a price table, a FAQ — fails, because under mobile-first indexing the mobile version is what Google indexes. (Arabic pages carry extra layout risks; our Arabic form design guide covers the RTL faults.)
Fix or rebuild? Reading your audit results (table)
| Audit result | Likely cause | Verdict |
|---|---|---|
| Call or WhatsApp action missing or buried | Desktop header carried over | Fix — add persistent tap actions |
| Menu needs 3+ taps to main services | Compressed mega-menu | Fix if it can flatten; rebuild if the template forces depth |
| Repeated mis-taps | Targets sized for a cursor | Fix — resize and respace targets |
| Key action works only on hover | Desktop interaction pattern | Fix — rebuild that component for tap |
| Offer invisible on first screen | Content ordered for desktop | Fix — reorder for mobile priority |
| Vitals fail on image weight alone | Desktop images served to phones | Fix — resize, compress, lazy-load |
| Vitals fail across all templates | Heavy theme or builder | Rebuild — the platform is the bottleneck |
| Content missing on mobile | Stripped mobile template | Rebuild if parity cannot be restored |
| Form fails on a real phone | Keyboard-first form design | Fix — fewer fields, correct input types |
Count your verdicts. Fixes only: schedule them as one mobile pass. Any rebuild verdict in the last three rows means the template itself is the fault.
Common mistakes when "fixing" mobile as an afterthought
The commonest mistake is testing on a resized desktop browser, not a real phone: the window shrinks, but touch, network speed and one-handed use are never simulated. Next is bolting on a separate mobile plugin or theme, creating a second version where content drifts out of parity. Owners fix the homepage only, while service and contact pages keep the faults.
Finally, avoid chasing a PageSpeed score instead of the thresholds: the goal is LCP, INP and CLS inside published limits on real visits, not a perfect lab score. If you are comparing providers for the rebuild route, our web design company in Dubai page sets out how to judge the work.
FAQ
What is the difference between responsive and mobile-first design?
Responsive design is a technique: the layout adapts to any screen size. Mobile-first is a design order: the phone version is designed first, then expanded for desktop. A site can be fully responsive yet designed desktop-first — exactly the combination this audit tests for.
How do I check my site against Core Web Vitals on mobile?
Run the page through Google PageSpeed Insights and read the mobile assessment: Largest Contentful Paint at or below 2.5 seconds, Interaction to Next Paint at or below 200 milliseconds and Cumulative Layout Shift at or below 0.1 are the published good thresholds, at the 75th percentile of real visits.
Why does mobile-first indexing make missing mobile content an SEO problem?
Google's documentation states that indexing and ranking use the mobile version of a site's content. If a service, table or FAQ exists only on desktop, Google may never index it. Keep content, headings, metadata and structured data equivalent across both versions.
How big should tap targets be on a mobile website?
The W3C's WCAG criteria set a minimum target size of 24 by 24 CSS pixels, with 44 by 44 CSS pixels as the enhanced level. In practice, audit with your thumb: any target you can mis-tap on a real phone is too small or too crowded, whatever its measured size.
Can a desktop-first site be fixed, or does it always need a rebuild?
Most single faults — buried contact actions, wrong content order, oversized images, long forms — are fixes. A rebuild is warranted when the template itself forces the faults: deep menus that cannot flatten, desktop-weight assets on every page, or a mobile version that cannot hold the desktop content.
Get a mobile-first audit of your site (CTA)
If your run through the seven checks produced more fixes than expected — or a rebuild verdict you want a second opinion on — send us your URL. We will run the same audit on real devices, show you each fault where a visitor meets it, and set out the fix order in an itemised proposal within 24 business hours. Start with our responsive web design company page, or WhatsApp us at +971 52 595 3174.
