Mobile Usability

TL;DR — Mobile usability is whether your page is easy to use on a phone: text you can read without pinching to zoom, buttons big enough to tap without hitting the wrong one, content that fits the screen with no sideways scrolling, and no full-screen popups blocking the content. Google used to have a report that flagged these problems for you — it retired it in December 2023 — but the things it checked still matter.

What mobile usability is

Mobile usability is exactly what it sounds like: how usable your page is when someone opens it on a phone. Not how fast it loads, not whether Google indexes it — just whether a real person on a small touchscreen can read it, tap it, and get where they’re going without fighting the layout.

There are four things that make or break it:

1. Readable text. If someone has to zoom in to read your paragraphs, the text is too small.
2. Tappable buttons and links. Fingers aren’t as precise as a mouse. Targets that are tiny or crammed together get mis-tapped.
3. Content that fits the screen. No horizontal scrolling — the page should fit the width of the phone.
4. No pop-ups blocking the content. A full-screen ad or newsletter overlay that covers the page the moment you arrive is a usability problem (and can hurt you in search).

Why it matters

Most people search on their phones, so a page that’s frustrating on mobile is frustrating for most of your visitors. And Google now reads the mobile version of your page to decide how you rank (that’s a separate idea called mobile-first indexing — more on the difference in a second). So mobile experience isn’t a side concern anymore; it’s the main one.

”Wait, where did the Mobile Usability report go?”

If you used to check mobile problems in Google Search Console, you’re not imagining things — that report is gone. Google retired the Search Console Mobile Usability report and its standalone Mobile-Friendly Test tool on December 1, 2023. That doesn’t mean mobile usability stopped mattering; Google said the opposite. It just means the dedicated report went away because better tools (like Lighthouse, built into Chrome) do the job now. So if a tutorial tells you to “open the Mobile Usability report,” it’s out of date.

How to check it now

The easiest option: open your page in Chrome, right-click → Inspect, and run Lighthouse (or use PageSpeed Insights at pagespeed.web.dev). Both flag small fonts, cramped tap targets, and viewport problems. You can also just resize your browser or use Chrome’s phone-preview mode and look at the page on a small screen — a lot of usability problems are obvious the moment you do.

Don’t confuse it with two similar things

• Mobile-first indexing — that’s about which version of your page Google reads (the mobile one). Different topic.
• Core Web Vitals — those measure speed and stability. Related, but a separate set of numbers.

Want the exact thresholds (how big is “big enough” for a tap target?), the full retirement story, and every way to test mobile usability today? Switch to the Advanced tab.

TL;DR — Mobile usability = ease of use on a touch device, driven by four signals: legible text (Lighthouse passes at 12px on ≥60% of text; 16px is the practical body-copy baseline), tap targets (Lighthouse fails below 48×48 CSS px or when ≥25% of the target within 48px of center overlaps a neighbor; ~8px spacing is a starting point — WCAG 2.2’s separate 24×24 CSS px minimum is an accessibility floor, not a Google ranking rule), content sized to the viewport (needs a proper viewport meta tag, but the tag alone doesn’t guarantee responsive layout; no horizontal scroll), and no intrusive interstitials. Google retired the Search Console Mobile Usability report, the Mobile-Friendly Test tool, and the API on December 1, 2023 (confirmed Dec 4) — not because the signals stopped mattering, but because Lighthouse matured and mobile-first indexing was effectively complete. Check it now with Lighthouse, PageSpeed Insights, DevTools device emulation, Bing’s still-live test, and crawlers. Distinct from mobile-first indexing (which version is indexed) and Core Web Vitals (loading/interactivity/stability). It’s one page-experience signal, not a standalone heavily-weighted ranking factor.

The definition, precisely

Mobile usability is whether a page is easy to use on a mobile/touch device. It’s a user-experience concept that lives inside Google’s broader page experience model, and it comes down to four concrete signals. The rest of this section is each one with its real threshold and citation — because the specific numbers are exactly what most competing articles skip.

Signal 1: legible text

If people have to pinch-zoom to read your body copy, the font is too small. There are two numbers worth keeping straight, and conflating them is a common mistake:

• The audit-pass bar is 12px. Lighthouse’s Document uses legible font sizes audit says: “Aim to have a font size of at least 12 px on at least 60% of the text on your page.” That’s the threshold to technically pass the automated check.
• The practical baseline is ~16px. 12px passing an audit doesn’t mean 12px is comfortable to read on a phone. 16px is the generally recommended floor for mobile body text, with headings larger. Don’t design to the audit’s minimum.

So: 12px/60% is the pass line; 16px is what you should actually aim for on body copy.

Signal 2: tap targets

Fingers are blunt instruments. Lighthouse’s Tap targets are not sized appropriately audit fails a target on two conditions: when “the target is smaller than 48 px by 48 px,” and when “at least 25% the target area within 48 px of the center of the target overlaps with another target.” A few practical notes from the same doc:

• Targets sized 48×48 CSS px consistently pass.
• The tappable area is what counts, not the visual size — you can keep a small icon and expand its hit area with padding to reach 48px. (This kills the myth that every button must look 48px.)
• ~8px between targets is a reasonable starting point but “is not always enough spacing to pass the audit especially for very small targets.”

Older Google guidance framed this as roughly 7mm targets with ~5mm spacing; at typical mobile densities that’s broadly consistent with the 48px figure. Cite the 48px/8px numbers as current; the mm ones are historical color.

There’s a second, separate number worth knowing so you don’t conflate standards: WCAG 2.2’s Success Criterion 2.5.8 (Target Size Minimum, Level AA) sets a 24×24 CSS px minimum (with spacing/inline/essential exceptions) — an accessibility-conformance rule from the W3C, not a Google Search ranking threshold. It’s smaller than Lighthouse’s 48px audit bar because the two come from different bodies measuring different things: meeting Lighthouse’s 48px figure clears WCAG’s 24px floor too, but don’t cite either number as a fixed, timeless “Google requires N px” rule — Lighthouse’s is a Chrome tooling audit threshold, WCAG’s is an accessibility conformance criterion.

Signal 3: content sized to the viewport

Content should fit the width of the phone — no horizontal scrolling, no page rendered at desktop width and shrunk to unreadable. The mechanism is the viewport meta tag. Without it (or misconfigured), mobile browsers assume a desktop-width canvas and scale everything down. The fix is one line in the <head>:

<meta name="viewport" content="width=device-width, initial-scale=1">

Google’s guidance: “make sure your page content fits the width of the viewport, keeping in mind that not all mobile devices are the same width.” So don’t hard-code fixed pixel widths that only fit one phone.

The tag is necessary but not sufficient. It aligns the layout viewport with the device width — it doesn’t, by itself, make fixed-width content responsive. A page can ship a correct viewport meta tag and still fail mobile usability if individual elements (a wide table, an unbreakable long string, a fixed-pixel container) are hard-coded wider than the viewport. The tag sets the canvas; your CSS still has to actually fit it.

Signal 4: no intrusive interstitials

A full-screen popup that blocks your content the moment a visitor arrives from search is both a usability problem and a search problem. Google: “intrusive interstitials and dialogs are page elements that obstruct users’ view of the content, usually for promotional purposes,” and it warns that they “make it hard for Google and other search engines to understand your content, which may lead to poor search performance.” The guidance is blunt — “don’t obscure the entire page with interstitials” — and it points to small banners taking only a fraction of the screen as the acceptable alternative. (The full treatment of what’s penalized vs. exempt lives in the intrusive interstitials deep dive.)

What happened to the Mobile Usability report?

This is where most guides — including some published in the last year — are flatly wrong, so it’s worth getting the timeline exactly right.

• April 2023 — announced. In The role of page experience in creating helpful content, Google said: “Also starting December 1, 2023, we’ll be retiring Search Console’s ‘Mobile Usability’ report, the Mobile-Friendly Test tool and Mobile-Friendly Test API. This doesn’t mean that mobile usability isn’t important for success with Google Search.” Its reasoning: “in the nearly ten years since we initially launched this report, many other robust resources for evaluating mobile usability have emerged, including Lighthouse from Chrome.”
• December 1, 2023 — retired. The report, the Mobile-Friendly Test tool, and the API all went away. Google removed the corresponding mentions from its search help docs the same day. The old Mobile-Friendly Test URL (search.google.com/test/mobile-friendly) now redirects to Lighthouse documentation, and trying to open the Mobile Usability report in Search Console redirects to the GSC overview page.
• December 4, 2023 — confirmed. Google’s Search Console account confirmed the sunset publicly, thanking site owners “for working with us on this journey.”

Why now? Two forces. First, mobile-first indexing was effectively complete — Google announced “the trek to Mobile First Indexing is now complete” on October 31, 2023 — so a dedicated GSC report split out by device made less sense. Second, Lighthouse had matured into a better, more actionable checker than the old standalone tool. The signals didn’t stop mattering; the dedicated report did.

The practical correction: stop telling people to “check the Mobile Usability report” or “run the Mobile-Friendly Test.” Both are gone. (I’ll be candid — my own Ahrefs guide, Mobile-First Indexing Goes Mobile-Only, last updated June 2024, still points readers to those two now-defunct destinations in one spot; that’s exactly the kind of stale advice this article exists to fix, and it’s on my list to correct there too.)

How to check mobile usability today

Since there’s no single dedicated report anymore, you assemble it from a few tools:

• Chrome Lighthouse (DevTools → Lighthouse) — the direct replacement. Runs the legible-font, tap-target, and viewport audits and gives you the specific failing elements.
• PageSpeed Insights (pagespeed.web.dev) — runs Lighthouse in the cloud on the mobile profile; good for a quick shareable URL-level check.
• Chrome DevTools device toolbar — emulate a phone, eyeball horizontal scroll, tiny text, and cramped controls at real dimensions.
• Bing’s Mobile Friendliness Test Tool — a genuine differentiator: Bing still runs a live mobile-friendliness test in Bing Webmaster Tools, even though Google’s is gone. Bing’s own pitch: “making pages mobile-friendly increases user engagement on mobile devices. It can also help you rank better in Bing search results on mobile devices.” Handy for a second opinion on rendering.
• Third-party crawlers — Ahrefs Site Audit and similar can crawl with a mobile user-agent and surface mobile-specific issues at scale (connect the PageSpeed Insights API for the mobile checks).
• A real device. Nothing beats opening the page on an actual phone.

No single tool proves end-to-end usability on its own — combine an automated audit (Lighthouse or PageSpeed Insights), an emulated visual check (DevTools device toolbar), and at least one real-device pass before calling a page fixed.

Mobile usability vs. mobile-first indexing vs. Core Web Vitals

These three get blurred together constantly. They’re related but distinct:

A site can be fully on mobile-first indexing and still have terrible mobile usability (tiny text, cramped buttons), and vice versa. The mobile-first indexing deep dive and the Core Web Vitals material cover those two in full — this article is strictly the usability layer.

Does mobile usability affect rankings?

Yes, but keep it in proportion. Mobile usability contributes to page experience, which Google treats as a set of signals within broader ranking systems — not a single heavily-weighted factor with a fixed score. Google’s own caution: site owners “should not focus on only one or two aspects of page experience,” and “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” So fix usability because it helps real users (and it’s the right thing to do) — not because you expect a magic ranking bump. It’s a contributor, not a kingmaker.

Where this sits in the mobile-seo cluster

This is one piece of the wider mobile SEO picture. Mobile-first indexing covers which version Google reads and the content-parity rule; the mobile SEO checklist is the run-it-down audit; the interstitials, AMP, and responsive-vs- dynamic-serving topics each get their own treatment. This article deliberately stays in its lane — the usability signals — so it complements those rather than repeating them.

AI summary

A condensed take on the Advanced version:

• Mobile usability = ease of use on a touch device. Four signals: legible text, tap targets, content sized to the viewport, no intrusive interstitials.
• Legible text: Lighthouse passes at 12px on ≥60% of text, but 16px is the practical body-copy baseline. Don’t design to the audit minimum.
• Tap targets: Lighthouse fails below 48×48 CSS px or when ≥25% of the area within 48px of center overlaps a neighbor. The tappable area (via padding) is what counts, not the visual size. ~8px spacing is a starting point. WCAG 2.2’s Target Size Minimum (SC 2.5.8, Level AA) sets a separate 24×24 CSS px accessibility floor — a W3C conformance rule, not a Google ranking threshold.
• Viewport: <meta name="viewport" content="width=device-width, initial-scale=1">; content must fit the phone width with no horizontal scroll. The tag aligns the layout viewport with the device width but doesn’t by itself make fixed-width content responsive — individual elements can still overflow.
• Intrusive interstitials: full-page overlays on entry obstruct content and hurt search performance; small banners are the acceptable alternative.
• The report is gone. Google retired the Search Console Mobile Usability report, Mobile-Friendly Test tool, and API on Dec 1, 2023 (confirmed Dec 4) — because Lighthouse matured and mobile-first indexing was effectively complete (Oct 31, 2023), not because the signals stopped mattering.
• Check it now with Lighthouse, PageSpeed Insights, DevTools device emulation, Bing’s still-live Mobile Friendliness Test, and third-party crawlers.
• Distinct from mobile-first indexing (which version is indexed) and Core Web Vitals (loading/interactivity/stability).
• Ranking: one page-experience signal within broader systems, not a standalone heavily-weighted factor. Google will still surface the most relevant content even with a sub-par experience.

Official documentation

Primary-source documentation from the search engines.

Google

• The role of page experience in creating helpful content (Apr 2023) — the announcement that retired the Mobile Usability report, Mobile-Friendly Test tool, and API as of Dec 1, 2023, and pointed to Lighthouse.
• Understanding Google page experience — where mobile usability sits as a signal, the self-assessment questions, and the “don’t over-index on one signal” caution.
• Avoid intrusive interstitials and dialogs — the interstitials definition and the small-banner alternative.
• Mobile-first indexing has landed (Oct 2023) — the “trek is now complete” milestone that made a dedicated device-split report unnecessary.

Chrome / Lighthouse

• Document doesn’t use legible font sizes — the 12px/60%-of-text audit threshold.
• Tap targets are not sized appropriately — the 48×48 CSS px audit and the overlap/spacing rules.

Bing / Microsoft

• Bing Mobile Friendliness Test Tool — still live, unlike Google’s; test any URL for mobile-friendliness in Bing Webmaster Tools.

W3C

• Target Size (Minimum) — WCAG 2.2 Understanding SC 2.5.8 — the 24×24 CSS px accessibility-conformance floor, distinct from Lighthouse’s 48px audit threshold.

Quotes from the source

On-the-record statements from Google, Chrome/Lighthouse, and Bing. Each link is a deep link that jumps to the quoted passage where the source page supports it.

Google — retiring the report and tools (Apr 2023 announcement)

• “Also starting December 1, 2023, we’ll be retiring Search Console’s ‘Mobile Usability’ report, the Mobile-Friendly Test tool and Mobile-Friendly Test API. This doesn’t mean that mobile usability isn’t important for success with Google Search.” — Google Search Central Blog. Read the post
• “In the nearly ten years since we initially launched this report, many other robust resources for evaluating mobile usability have emerged, including Lighthouse from Chrome.” Read the post

Google — page experience framing

• “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” — Google Search Central docs. Jump to quote

Google — intrusive interstitials

• “Intrusive interstitials and dialogs are page elements that obstruct users’ view of the content, usually for promotional purposes.” — Google Search Central docs. Jump to quote

Google — mobile-first indexing complete (context)

• “We’re delighted to announce that the trek to Mobile First Indexing is now complete.” — Google Search Central Blog, Oct 31, 2023. Jump to quote

Chrome / Lighthouse — the thresholds

• “Aim to have a font size of at least 12 px on at least 60% of the text on your page.” — Chrome for Developers / Lighthouse docs. Jump to quote
• Tap targets fail when “48 px by 48 px” isn’t met, and when target areas overlap within 48px of center. Jump to quote

Bing — the still-live tool

• “Making pages mobile-friendly increases user engagement on mobile devices. It can also help you rank better in Bing search results on mobile devices.” — Bing Webmaster Tools, Mobile Friendliness Test. Open the tool

The report’s gone — how do I check mobile usability now?

The old “just open the Mobile Usability report” answer no longer works. Which current tool you reach for depends on what you’re trying to do. Click through it.

Mobile usability checklist

A pass across the four signals, run against the mobile rendering of the page (DevTools device mode or a real phone):

• Body text is legible without zooming — ~16px baseline; at minimum passes Lighthouse’s 12px-on-≥60%-of-text audit.
• Tap targets are 48×48 CSS px (or a smaller icon with padding expanding the tappable area to 48px).
• Tap targets aren’t crowded — adjacent targets don’t overlap within 48px of center; ~8px+ spacing, more for very small ones.
• Viewport meta tag present — <meta name="viewport" content="width=device-width, initial-scale=1">.
• No horizontal scrolling — content fits the viewport width; no fixed-pixel elements wider than the screen.
• No intrusive interstitial on entry from search — full-page overlays are out; small banners and legally required gates are fine.
• CSS/JS not blocked in robots.txt — Googlebot needs them to render the mobile page and judge usability.
• Audited with Lighthouse / PageSpeed Insights — not the retired Mobile-Friendly Test or GSC Mobile Usability report.
• Spot-checked on a real device — some issues only show up on actual hardware.

The mental models

1. Four signals, one question. Legible text, tap targets, viewport fit, no intrusive interstitials. Every mobile usability issue is one of those four — diagnose by asking which one is failing before you touch anything.

2. The audit bar is not the goal. Lighthouse passes text at 12px and tap targets at exactly 48px. Those are floors, not targets. Aim for 16px body copy and comfortably-spaced controls — passing the audit and being pleasant to use aren’t the same thing.

3. Tappable area, not visual size. A small icon can pass the tap-target audit if padding expands its hit area to 48px. Design the hit area, not just the pixels you can see.

4. The three “not the same as.”

• Mobile usability ≠ mobile-first indexing (that’s which version is indexed).
• Mobile usability ≠ Core Web Vitals (that’s loading/interactivity/stability).
• Mobile usability ≠ a single heavy ranking factor (it’s one page-experience signal among several).

5. The tooling moved — update your muscle memory. The dedicated GSC report and Mobile-Friendly Test are gone (Dec 2023). Reach for Lighthouse / PageSpeed Insights / DevTools / Bing’s test / a crawler instead. If a process doc still says “check the Mobile Usability report,” the process doc is the bug.

Mobile usability — cheat sheet

The four signals + thresholds

The viewport one-liner

<meta name="viewport" content="width=device-width, initial-scale=1">

Dates to know

• Apr 2023 — Google announces the retirement.
• Oct 31, 2023 — mobile-first indexing declared complete.
• Dec 1, 2023 — Mobile Usability report + Mobile-Friendly Test tool + API retired.
• Dec 4, 2023 — sunset confirmed publicly.

Where the old tools went

• Mobile-Friendly Test URL → redirects to Lighthouse docs.
• GSC Mobile Usability report → redirects to the GSC overview.

Check it now: Lighthouse · PageSpeed Insights · DevTools device mode · Bing Mobile Friendliness Test (still live) · third-party crawler · real device.

Don’t confuse with: mobile-first indexing (which version is indexed) · Core Web Vitals (LCP/INP/CLS).

SOP: audit a page’s mobile usability (post-report era)

A repeatable procedure now that there’s no one-click report. ~10 minutes per page.

1. Open the page in Chrome and run Lighthouse. DevTools (⌘⌥I / Ctrl+Shift+I) → Lighthouse tab → check SEO and Performance → Analyze page load (choose the Mobile device). Note any legible font sizes or tap targets failures — Lighthouse lists the specific elements.
2. Confirm the viewport tag. In DevTools Elements, search the <head> for name="viewport". It should read width=device-width, initial-scale=1. No tag, or a fixed width=980-style value, is the fix.
3. Emulate a phone and look. Toggle the device toolbar (⌘⇧M / Ctrl+Shift+M), pick a small device (e.g. iPhone SE width). Scroll the full page: any horizontal scrollbar or element bleeding off the right edge is a viewport-fit failure.
4. Test tap targets by hand. In device mode, try tapping adjacent links/buttons. If you’d realistically mis-tap, they’re too small or too close — target 48px hit areas with ~8px+ spacing.
5. Check for entry interstitials. Load the URL fresh (incognito) as if arriving from search. A full-page overlay before you can read the content is a problem; small banners and legal/consent gates are fine.
6. Cross-check with Bing’s live test (optional second opinion) at bing.com/webmaster/tools/mobile-friendliness, and/or PageSpeed Insights for a shareable record.
7. Verify on a real device if the page matters. Emulation is close, not perfect.
8. File fixes by signal — font size, tap sizing/spacing, viewport, interstitial — so devs get an actionable list, not “make it mobile-friendly.”

Mobile usability anti-patterns

The recurring mistakes — several of them baked into stale advice that’s still circulating.

• “Check the GSC Mobile Usability report.” It was retired December 1, 2023 and the URL now redirects to the overview page. If a doc or tutorial says this, it’s out of date — including, until it’s corrected, a passage in my own Ahrefs guide.
• “Run Google’s Mobile-Friendly Test.” Also retired Dec 1, 2023; the old URL redirects to Lighthouse docs. Multiple currently-live articles still describe this tool as working — it isn’t.
• Designing to the 12px audit floor. Passing Lighthouse’s font-size audit at 12px doesn’t make text comfortable to read on a phone. Use ~16px for body copy.
• Measuring the visible icon, not the tappable area. A 24px icon can still pass the tap-target audit if padding expands its hit area to 48px. Shrinking the hit area to match the graphic is the mistake.
• Omitting or misconfiguring the viewport meta tag. No tag (or a fixed-width one) makes mobile browsers render at desktop width and shrink everything. It’s a one-line fix that’s easy to forget.
• Full-screen interstitials on entry from search. Newsletter/app-install/ad overlays that block content the moment a visitor arrives obstruct the content and can hurt search performance. Use a small banner instead.
• Blocking CSS/JS in robots.txt. If Googlebot can’t fetch the assets, it can’t render the mobile page properly or judge its usability.
• Treating mobile usability as a big standalone ranking lever. It’s one page-experience signal, and Google will still surface the most relevant content even with a sub-par experience. Fix it for users, not for an imagined ranking jump.
• Conflating it with mobile-first indexing or Core Web Vitals. Different problems, different fixes, different tools. Keep them separate.

Quick checks you can run yourself

You don’t need the retired tools to spot the common failures. A few practical snippets.

Check the viewport meta tag from the command line

# Does the page ship a proper viewport meta tag?
curl -s https://example.com/ | grep -i 'name="viewport"'
# Expected: <meta name="viewport" content="width=device-width, initial-scale=1">
# No output = no viewport tag (a mobile-usability failure).

Find elements causing horizontal scroll (DevTools console)

Paste into the Chrome DevTools console while emulating a phone — it lists any element wider than the viewport, the usual cause of horizontal scrolling:

// Flag elements wider than the viewport
const vw = document.documentElement.clientWidth;
[...document.querySelectorAll('*')]
  .filter(el => el.getBoundingClientRect().right > vw + 1)
  .forEach(el => console.log(Math.round(el.getBoundingClientRect().right), el));

Find text smaller than 16px (DevTools console)

// List text-bearing elements rendered below the 16px baseline
[...document.querySelectorAll('body *')]
  .filter(el => el.childNodes.length && [...el.childNodes].some(n => n.nodeType === 3 && n.textContent.trim()))
  .map(el => ({ px: parseFloat(getComputedStyle(el).fontSize), el }))
  .filter(x => x.px < 16)
  .forEach(x => console.log(x.px + 'px', x.el));

Bookmarklet: highlight small tap targets

Save as a bookmark, run on any page in mobile emulation — it outlines interactive elements whose rendered box is under 48×48 CSS px:

javascript:(()=>{document.querySelectorAll('a,button,input,select,textarea,[role=button]').forEach(el=>{const r=el.getBoundingClientRect();if(r.width<48||r.height<48){el.style.outline='2px solid red';}});})();

Remember the caveat: the tappable area (padding included) is what the audit measures — an element flagged here can still be fine if padding expands its hit area to 48px.

Tools for checking mobile usability

• Chrome Lighthouse (DevTools → Lighthouse) — the direct replacement for the retired Mobile-Friendly Test. Runs the legible-font, tap-target, and viewport audits and names the failing elements.
• PageSpeed Insights (pagespeed.web.dev) — Lighthouse in the cloud on the mobile profile; shareable URL-level results.
• Chrome DevTools device toolbar — phone emulation for eyeballing horizontal scroll, tiny text, and cramped controls at real dimensions.
• Bing Mobile Friendliness Test Tool — still live in Bing Webmaster Tools; a real second opinion now that Google’s dedicated tool is gone.
• Search Console URL Inspection — see the rendered mobile HTML and screenshot Googlebot smartphone saw (doesn’t grade usability, but confirms what renders).
• Ahrefs Site Audit — crawl with a mobile user-agent and surface mobile-specific issues across every page (connect the PageSpeed Insights API for the mobile checks).
• A real phone — the ground truth emulation approximates.

Mobile page looks fine in emulation but fails on a phone

Symptom: Chrome’s device toolbar looks clean, but users report clipped content, overlapping controls, or unusable dialogs. Likely cause: emulation did not reproduce the phone’s browser chrome, safe-area insets, text scaling, or operating-system keyboard. Fix: reproduce the task on at least one physical iOS device and one physical Android device. Test orientation changes, increased text size, and the on-screen keyboard, not just the landing state.

The page scrolls sideways

Symptom: a narrow strip of content extends past the right edge. Likely cause: a fixed-width element, unbroken string, table, image, or 100vw container is wider than the layout viewport. Fix: use DevTools to inspect the widest element, make media responsive, allow long text to wrap, and prefer width: 100% inside padded containers. Do not hide the evidence with overflow-x: hidden until you have fixed the source.

Tap targets still fail after increasing the icon

Symptom: Lighthouse still flags a control after its visible icon got larger. Likely cause: the interactive box remains small or neighboring links overlap its usable space. Fix: add padding to the clickable element itself, space adjacent targets, and verify the rendered hit box in DevTools. Enlarging only an SVG inside a tiny anchor does not enlarge the anchor.

Text becomes unreadable after load

Symptom: the initial HTML looks usable, then client-side code replaces it with tiny text or a desktop layout. Likely cause: responsive styles or components load late, fail at a breakpoint, or differ between server and client rendering. Fix: test the rendered state with JavaScript enabled, inspect the failing breakpoint, and keep the mobile layout in the initial critical CSS where practical.

Prove a mobile-usability fix worked

Test yourself: Mobile Usability

Five quick questions on mobile usability. Pick an answer for each, then check.

Resources worth your time

My writing

• Mobile-First Indexing Goes Mobile-Only (Ahrefs) — my deep dive on mobile-first indexing and mobile design best practices. Fair warning: as of its June 2024 update it still points readers to the retired GSC Mobile Usability report and Mobile-Friendly Test — the stale advice this article corrects, and something I plan to fix there.
• The Beginner’s Guide to Technical SEO (Ahrefs) — where mobile usability fits inside the broader technical-SEO picture.
• Core Web Vitals: What They Are & How to Improve Yours (Ahrefs) — the performance side of mobile experience, which people routinely conflate with usability.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawling, rendering, indexing, and ranking, including how Googlebot crawls as a smartphone. (Standing disclaimer: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From around the industry

• The role of page experience in creating helpful content (Google) — the April 2023 post that announced the report/tool retirement and pointed to Lighthouse.
• Google Officially Drops Mobile Usability Report, Mobile-Friendly Test Tool and API (Search Engine Land, Barry Schwartz) — the retirement, in plain language.
• Google Search Console’s Mobile Usability Report & Mobile-Friendly Tests Are Gone (Search Engine Roundtable, Barry Schwartz) — the Dec 4, 2023 sunset confirmation and where the old URLs now redirect.
• Document doesn’t use legible font sizes (Chrome / Lighthouse) — the 12px/60%-of-text audit threshold.
• Tap targets are not sized appropriately (Chrome / Lighthouse) — the 48×48 CSS px audit and spacing rules.
• Avoid intrusive interstitials and dialogs (Google) — the interstitials definition and the acceptable-banner alternative.
• Bing Mobile Friendliness Test Tool (Bing Webmaster Tools) — still live; test any URL for mobile-friendliness.

Stats worth citing

• Legible-font audit pass bar: 12px on ≥60% of text — Lighthouse’s documented threshold. Note it’s a pass floor, not the recommended ~16px body-copy baseline. Source
• Tap-target audit fails below 48×48 CSS px (and on ≥25% overlap within 48px of center) — Lighthouse. The tappable area, not the visual size, is what’s measured. Source
• WCAG 2.2 Target Size Minimum (SC 2.5.8, Level AA): 24×24 CSS px — a separate accessibility-conformance rule from the W3C, not a Google Search ranking threshold; smaller than Lighthouse’s 48px audit bar because it measures a different thing. Source
• Retirement date: December 1, 2023 — Google retired the Search Console Mobile Usability report, the Mobile-Friendly Test tool, and the API on this date (confirmed publicly Dec 4, 2023). Source
• Mobile-first indexing declared complete October 31, 2023 — the milestone that made a dedicated device-split usability report unnecessary. Source

Mobile Usability

Whether a page is easy to use on a mobile/touch device — legible text without zooming, tap targets sized and spaced to avoid mis-taps, content that fits the viewport with no horizontal scrolling, and no intrusive interstitials. Distinct from mobile-first indexing and Core Web Vitals.

Related: Mobile SEO, Mobile-First Indexing, Interstitials, Core Web Vitals

Mobile Usability

Mobile usability is how easy a page is to actually use on a phone or other touch device. Four things drive it: text that’s legible without zooming, tap targets big enough and far enough apart to avoid mis-taps, content sized to the viewport so there’s no horizontal scrolling, and no intrusive interstitials blocking the content.

It’s a user-experience concept that sits inside Google’s broader page experience framing, and it’s commonly confused with two neighbors. Mobile-first indexing is about which version of your page Google crawls and indexes (the mobile HTML) — mobile usability is about whether that page is pleasant to use once someone lands on it. Core Web Vitals measure loading, interactivity, and visual stability (LCP, INP, CLS) — related to usability, but a separate set of metrics.

Google used to surface mobile usability in a dedicated Search Console Mobile Usability report plus a standalone Mobile-Friendly Test tool and API. All three were retired on December 1, 2023 (confirmed publicly December 4, 2023) — not because the signals stopped mattering, but because better tooling (Lighthouse) had matured and mobile-first indexing was effectively complete. Today you check mobile usability with Lighthouse, PageSpeed Insights, Chrome DevTools device emulation, Bing’s still-live Mobile Friendliness Test, and third-party crawlers.

Related: Mobile SEO, Mobile-First Indexing, Interstitials, Core Web Vitals

Changelog