Mobile UX Audit: 6 Layout Flaws That Ruin Mobile Conversions (and Fail Google's Mobile Test)
When 80% of your traffic is a mid-range Android on mobile data, the desktop layout is close to irrelevant. These six faults are what actually costs you conversions.

For most Indian D2C, lead-gen and local service businesses, 70–85% of traffic arrives on a phone — and for anything driven by Instagram or Facebook ads it is higher still. Despite that, most sites are designed on a 27-inch monitor and checked on mobile at the end, in a browser devtools emulator, at 390px, on wifi.
The emulator hides exactly the problems that matter. Here are the six that cost real conversions, in the order worth fixing.
1. Something is wider than the screen
A single overflowing element gives the whole page a horizontal scroll. The layout looks subtly wrong, text runs off the edge, and the visitor can swipe the content sideways by accident while scrolling. It is the most common mobile fault and among the easiest to fix.
Find the culprit in the console on a real device width:
// Lists every element wider than the viewport
[...document.querySelectorAll('*')]
.filter(el => el.getBoundingClientRect().right > document.documentElement.clientWidth + 1)
.forEach(el => console.log(Math.round(el.getBoundingClientRect().right), el))Usual causes: a table with fixed column widths, a code block with a long unbroken string, a fixed-width image, a URL in body text with nowhere to break, or a negative margin that made sense at desktop width.
/* Long strings and URLs cannot force the page wide */
.prose { overflow-wrap: anywhere; }
/* Tables and code scroll inside their own box, not the page */
.scroll-x {
overflow-x: auto;
-webkit-overflow-scrolling: touch;
position: relative; /* contains absolutely-positioned children */
}
/* Media never exceeds its container */
img, video, iframe, svg { max-width: 100%; height: auto; }position: sticky elsewhere on the page. Find the element and constrain it.2. Tap targets too small, or too close together
A fingertip contact area is roughly 9mm. Google's mobile usability check flags targets under about 48×48 CSS pixels or with less than 8px between them, and the real-world consequence is a visitor tapping the wrong link and leaving.
The worst offenders are footer link lists, social icon rows, and pagination — all designed as compact desktop elements and never reconsidered.
/* Minimum comfortable target, without changing visual size */
.icon-btn {
position: relative;
min-width: 48px;
min-height: 48px;
display: inline-grid;
place-items: center;
}
/* Or extend the hit area beyond a small visual element */
.small-link::after {
content: '';
position: absolute;
inset: -12px;
}
/* Space stacked links so a thumb cannot span two */
.footer-nav li + li { margin-top: 12px; }3. Tapping a field zooms the page
iOS Safari automatically zooms when a focused input has a font size below 16px. The page scales, the layout jumps, and the visitor has to pinch back out to see the rest of the form. On a lead form this is a measurable drop-off, and it is one CSS line.
input, select, textarea { font-size: 16px; }The tempting alternative — user-scalable=no in the viewport meta — suppresses the zoom by removing the visitor's ability to zoom at all. That is an accessibility failure and browsers increasingly ignore it. Use the correct viewport tag and fix the font size:
<meta name="viewport" content="width=device-width, initial-scale=1.0">
4. The keyboard is wrong, and autofill does not work
Asking for a phone number and getting a full alphabetic keyboard adds friction to every submission. The attributes that fix it take minutes and are routinely missing.
| Field | Attributes |
|---|---|
type="email" autocomplete="email" inputmode="email" | |
| Phone | type="tel" autocomplete="tel" inputmode="numeric" |
| Name | type="text" autocomplete="name" |
| PIN code | inputmode="numeric" autocomplete="postal-code" |
| OTP | inputmode="numeric" autocomplete="one-time-code" |
The one-time-code value is worth singling out: it lets iOS and Android offer the OTP from the SMS directly above the keyboard. For any flow with phone verification — which in India is most of them — it removes an app-switch from the critical path.
5. The important thing is outside the thumb zone
On a phone held one-handed, the comfortable reach is the lower two-thirds of the screen. The top corners require a grip change. Yet primary actions are routinely placed in the top-right because that is where they sit on desktop.
- Primary CTA within the first screen, but not pinned to the top corner.
- On long forms, a sticky submit button at the bottom of the viewport — with
padding-bottom: env(safe-area-inset-bottom)so it clears the home indicator. - Menu toggles in the top bar are fine; destructive or primary actions there are not.
- Keep the CTA reachable after the on-screen keyboard opens, which removes roughly half the visible height.
.sticky-submit {
position: sticky;
bottom: 0;
padding: 12px 16px calc(12px + env(safe-area-inset-bottom));
background: #fff;
box-shadow: 0 -2px 12px rgba(11,19,43,.08);
}6. The page moves while they are reading it
Layout shift is worse on mobile because there is less screen and more of it moves. An image loading without reserved dimensions, a cookie banner appearing above the content, or a font swapping at different metrics all push the page around — and the CTA ends up somewhere other than where the thumb was heading.
/* Reserve the space before the content arrives */
.hero-img { aspect-ratio: 16 / 9; width: 100%; }
.promo-strip { min-height: 48px; }Always set width and height attributes on <img> even when CSS resizes it — the browser uses them to compute the aspect ratio and reserve the box. The Core Web Vitals article covers the measurement side and why this feeds your paid CPC as well as your conversion rate.
Test on the device your customers actually use
A devtools emulator at 390px on a fast laptop is not a test. It has the wrong CPU, the wrong network, the wrong touch input and the wrong font rendering.
- Test at 320px as well as 390px. It is still the narrowest realistic width and it surfaces overflow that wider viewports hide.
- Use a real mid-range Android on mobile data, not office wifi.
- Test with the keyboard open — half the viewport disappears and layouts break there specifically.
- Test in landscape once. Many sites are unusable in it.
- Test with system font size increased, which a large share of users over 40 have set.
If you cannot get a real device in front of you, at minimum throttle the CPU 4× and the network to a slow 4G profile. The difference between that and an unthrottled run is usually the difference between "feels fine" and what your customers experience.
The Mobile & Design module checks viewport configuration, horizontal overflow, tap target sizing and font legibility at real phone widths — automatically.
Run a mobile auditWhere to start if the list is long
Fix the overflow first. It is usually one element, it affects every page it appears on, and it makes everything else easier to evaluate. Then the 16px input rule, which is a single line and removes a real drop-off on every form you run.
Tap targets and the thumb zone come next, and they are worth doing properly rather than nudging a few pixels. Layout shift last — it matters, but it is the one that needs measurement to know whether you have actually improved it.
