site fails google mobile-friendly check
google's mobile usability report flags your pages. on mobile, the layout breaks, taps miss, text is too small. usually 60 to 90 minutes of fixes.
google's mobile-friendly checks affect ranking only marginally, but they describe the experience that most of your visitors actually have. more than half of web traffic is mobile, and a site that fails the mobile checks is leaking visitors at every step — the tap that misses, the text too small to read, the layout that overflows. the public check screenshots your homepage at 390 px so you see the leak directly.
what this looks like to a visitor
- google search console reports 'mobile usability issues'
- tap targets are too close together on iphone
- text is smaller than 16 px in body copy
- horizontal scroll appears at 390 px width
what a public browser check can see
we check whether your html has a <meta name="viewport" content="width=device-width, initial-scale=1"> tag. without this, mobile devices render a desktop-sized page scaled down, which breaks everything.
we render your homepage at 390 px width and take a screenshot. you see exactly what an iphone user sees, including the parts that overflow.
we look for buttons and links smaller than 44×44 px or with less than 8 px spacing. these are the ones google flags as 'tap targets too close'.
we check that body text is at least 16 px on mobile and that line length is under 75 characters. either failing makes the page hard to read on a phone.
we do not log into your site. we do not scrape customer data. we open your public homepage in a real browser session and report what we see. no security claims unless we can prove them from the public surface.
the deeper picture
four patterns: (1) missing viewport meta. older sites or hand-built templates sometimes forget the viewport tag, so mobile browsers render the desktop layout and scale it down. the result is text that needs zooming and tap targets too small to hit. fix: add one line to the head. (2) absolute-positioned elements overflow. css positioned elements sized in pixels do not scale; on narrow viewports they push the page wider than the screen, causing horizontal scroll. fix: use percentages or max-width: 100%. (3) tap target spacing. text links right next to each other are unhittable on mobile. fix: pad them into 44 px tap areas. (4) fixed font sizes. body text smaller than 16 px causes ios safari to show the 'zoom on input' behaviour, which breaks form ux. fix: base 16 px, scale headings up from there.
fix it yourself
add the viewport meta tag to your <head> if it is missing. set base font size to 16 px on mobile (most css frameworks do this; squarespace and wix do it automatically). give buttons a minimum 44×44 px tap area through padding. use media queries to stack columns at narrow widths. test from a real phone, not desktop emulation — the emulator shows the layout, the real phone shows the slow tap, the missing keyboard padding, the bad scroll behaviour.
run the audit on YOUR site — check for "site fails google mobile-friendly check"
we open your homepage in a real headless browser and report what we see. no login, no plugin install.
public browser check · no signup · result on the next page
or pay us once.
you can fix all of this yourself if you are comfortable in your platform's css editor or theme code. if you are not, the $99 fix path covers the homepage and up to three additional pages: we ship a mobile pass that hits all four patterns, before/after screenshots, mobile lighthouse report. done in two days.
frequently asked
both, but usability is the bigger lever. google's mobile-friendly signal is real but small. visitors leaving in two seconds because they cannot read your headline is much bigger.
it might still fail on other devices. android browsers handle font sizing differently from ios safari. the public check uses a standard 390 px viewport which matches the majority of iphones in use.
no — responsive design (one site that adapts) is the standard and it is what google expects. separate m. sub-domains are a 2010 pattern and are no longer recommended.
google re-crawls on its own schedule. submit the affected urls in google search console → url inspection → request indexing. usually catches up within a week.
other fix guides
- why is my wordpress site slow— what an external browser sees when your wordpress homepage takes too long to render — and the four things that are almost always behind it.
- shopify checkout feels broken — how to find out why— a public browser check of your shopify storefront can surface the visible reasons people abandon. here is what we look for.
- contact form looks fine but i'm not getting emails— this is the most common silent failure mode of small-business websites. four reasons it usually is — and how a public check can rule out the wrong ones.
- wix site not showing on google — what a public check can tell you— your wix site exists, but it does not appear in google search results. four reasons that explain almost every case.
built by vøiddo — a small studio shipping ai-flavoured products, free dev tools, chrome extensions and weird browser games. legal · support@voiddo.com