Poor Mobile Readability

What this issue means

On a phone, the page is a struggle: tiny fonts, cramped line spacing, text that requires zooming, or tap targets too close together. Since Google indexes the mobile version of your site, mobile readability is not optional.

What makes this issue slippery is that nothing is technically broken. The HTML is valid, the page returns a 200, the content is all present in the DOM, and every automated crawl passes. The failure is entirely in the rendering, and it only appears when a real person holds the page at arm's length on a bus. That is why readability problems survive for years on sites that otherwise run tight technical audits.

There is also a specific trap in how the problem is usually introduced. Almost nobody sets out to build a 12 pixel body font. It arrives through inheritance: a component library sets font-size: 0.8rem for a card, that card gets reused inside another component that already applied 0.9em, and the compounding produces text nobody chose. This is why the real fix is almost always at the base rather than in the component that looks wrong.

Why it matters

The majority of searches are mobile, and Google uses mobile-first indexing: the mobile experience is the experience it evaluates. Poor mobile readability raises bounce and weakens the engagement signals that correlate with rankings.

Two consequences follow that teams often miss. First, mobile-first indexing means content that is visually unusable on mobile is still the content being assessed for relevance, so there is no desktop version quietly saving you. Second, readability interacts with Core Web Vitals: pages with cramped tap targets generate mis taps, and a mis tap that triggers a heavy handler shows up in your INP measurements as a real interaction delay. The usability problem and the performance metric are not separate.

It is worth being precise about what Google does and does not do here. The old Mobile Usability report in Search Console, which explicitly flagged "text too small to read" and "clickable elements too close together," was retired in December 2023. Those checks are no longer surfaced as a standalone report, which is exactly why teams have stopped noticing the problem. The underlying signals still matter for the humans doing the reading, and page experience remains part of how Google assesses a result. The report went away, the issue did not.

How to detect it

You cannot eyeball this reliably, because your own reading distance and screen are unrepresentative. Measure it instead. Three checks catch nearly everything, in order of speed.

The last one is worth automating because horizontal overflow is the single most common cause of "the text is tiny" complaints. A page that overflows makes the browser zoom out to fit, shrinking everything at once. One rogue element does it: a wide table, an unbroken URL, a fixed width embed. This snippet in the console names the culprit immediately:

// paste into DevTools console at a 375 px viewport
[...document.querySelectorAll('*')]
  .filter(el => el.getBoundingClientRect().right > document.documentElement.clientWidth)
  .forEach(el => { el.style.outline = '2px solid magenta'; console.log(el); });

How to fix it

1. Use a base font size of ~16px+ with comfortable line height (~1.5).
2. Keep line length readable and paragraphs short on small screens.
3. Space tap targets at least ~48px apart.
4. Test on real devices and in Chrome's device emulator.

The implementation, concretely

Fix the base first, then stop overriding it. Most sites can resolve the bulk of this issue with a small set of rules applied globally rather than a per component audit.

html { font-size: 100%; }          /* respect the user's browser setting */

body {
  font-size: 1rem;                 /* 16px baseline, never smaller */
  line-height: 1.5;
  text-wrap: pretty;
}

p, li { max-width: 68ch; }         /* caps line length on wide screens */

/* fluid heading that never gets cramped on a phone */
h1 { font-size: clamp(1.75rem, 5vw, 2.5rem); line-height: 1.2; }

/* every interactive element gets a thumb sized hit area */
a, button, input, select, [role="button"] {
  min-height: 48px;
  min-block-size: 48px;
}

/* stop the wide element that causes zoom out */
img, video, table, pre { max-width: 100%; }

Three notes on the details. Setting html { font-size: 100% } rather than a pixel value preserves the reader's own browser text size preference, which matters more than any of the other rules for people who have already told their device they need larger text. The ch unit for max-width caps line length in characters rather than pixels, which is what the readability research actually measures. And min-height on interactive elements is more reliable than padding, because padding can be overridden by a component further down the cascade while a minimum height survives.

One anti pattern to remove wherever you find it: user-scalable=no or maximum-scale=1 in the viewport tag. It disables pinch zoom entirely, which turns a mild readability problem into an accessibility failure for anyone who needs to magnify. There is no good reason to keep it on a content page.

Where the problem usually comes from

If this check flagged on your site, the two neighbouring checks worth running at the same time are font size too small for mobile and mobile viewport issues, since they share root causes with this one. For the wider context on why the phone rendering is the version that gets assessed, see mobile-first indexing.

FAQ