Fastest fix: 80% of “not mobile-friendly” pages are missing one line in <head>. Add <meta name="viewport" content="width=device-width, initial-scale=1"> to your base layout, redeploy, and re-run the page through PageSpeed Insights on the Mobile tab. If the viewport is already there, the cause is almost always tap targets, horizontal overflow, or text under 16px — diagnose those below.
A quick note on tooling, because the article you are reading may be older than the tools it describes. Google retired the standalone Mobile-Friendly Test, the Mobile Usability report in Search Console, and the Mobile-Friendly Test API on December 1, 2023. If you are looking for a “Mobile Usability” tab or a single green “Page is mobile friendly” verdict, it no longer exists. Google’s own guidance is to use Lighthouse (in Chrome DevTools) and PageSpeed Insights instead. Mobile-first indexing has been fully rolled out since 2023 — Googlebot crawls and ranks the mobile rendering of every page — so a page that is unusable on a phone still gets degraded indexing and ranking, you just diagnose it with different tools now.
Which bucket are you in
| Symptom on a real phone | Likely cause | Jump to |
|---|---|---|
| Whole page renders tiny, text needs pinch-zoom | Missing viewport meta | Cause 1 |
| Buttons/links register the wrong tap, hard to hit | Tap targets too small or crowded | Cause 2 |
| Page scrolls sideways, content runs off the edge | Element wider than the viewport | Cause 3 |
| Body text is readable on desktop but small on phone | Font below 16px | Cause 4 |
| A modal/banner covers the article on load | Intrusive interstitial | Cause 5 |
| Blank or unstyled flash for 1-2s before layout appears | CSS loads client-side only | Cause 6 |
Common causes
1. Missing viewport meta (most fatal)
Without this line, mobile browsers fall back to a 980px desktop viewport and shrink the page to fit, so everything looks tiny:
<meta name="viewport" content="width=device-width, initial-scale=1">How to confirm:
curl -sL https://yourdomain.com/page | grep -i viewport
# No match = missing2. Tap targets too small or too close
Lighthouse flags interactive elements (buttons, links, form controls) under 48 x 48px; targets at or above 48 x 48px never fail the audit. The accessibility standard is slightly looser — WCAG 2.2 SC 2.5.8 Target Size (Minimum), Level AA, requires 24 x 24 CSS px unless there is enough spacing around the target. Aim for 48px to clear both. Keep at least 8px between adjacent targets so a fingertip can’t hit two at once.
How to confirm: Run the page in Lighthouse (DevTools → Lighthouse → Mobile → Analyze) and check the SEO section for “Tap targets are not sized appropriately,” which lists every offending element. Or use Chrome DevTools → Device Mode and inspect each button’s box size directly.
3. Horizontal scroll / content overflows the viewport
One element with a hardcoded width larger than the screen (e.g. width: 600px on a 360px phone) makes the whole page scroll sideways. Usual culprits:
- Large images without
max-width: 100% - Non-responsive tables
- Code blocks (
pre) without overflow handling - iframes with a hardcoded
width
/* Universal patch */
img, video, iframe {
max-width: 100%;
height: auto;
}
pre {
overflow-x: auto;
}
table {
display: block;
overflow-x: auto;
}How to confirm: In DevTools Device Mode, paste this into the Console to list every element wider than the viewport:
document.querySelectorAll('*').forEach(el => {
if (el.scrollWidth > document.documentElement.clientWidth)
console.log(el);
});4. Font size too small
Desktop 14px reads like roughly 10px at arm’s length on a phone. Keep body text at 16px or larger.
body {
font-size: 16px;
line-height: 1.6;
}
@media (max-width: 480px) {
body { font-size: 17px; } /* slightly bigger on small screens */
}5. Intrusive modals / consent banners blocking content
Google’s “intrusive interstitial” guidance penalizes overlays that cover the main content right after a user arrives from search. Cookie/consent prompts should sit as a thin bar at the top or bottom, not a full-screen modal. Legally required GDPR/cookie banners are tolerated only if they use a reasonable amount of screen space.
6. Critical CSS only loads client-side
If base styles aren’t server-rendered or inlined, mobile first paint shows unstyled content for 1-2 seconds, which drives a poor CLS (layout shift) score and a flash of unstyled content.
How to confirm: Chrome DevTools → Command menu (Cmd/Ctrl+Shift+P) → “Disable JavaScript” → reload. If the page is now unstyled, your critical CSS depends on JS.
Shortest path to fix
Step 1: Get the specific errors from PageSpeed Insights
https://pagespeed.web.dev/?url=https://yourdomain.com/your-pageRun it and stay on the Mobile tab. It runs a Lighthouse audit and lists the actual issues — missing viewport, tap targets, font legibility, plus the Core Web Vitals (LCP, INP, CLS). Note: INP replaced FID as the responsiveness Core Web Vital on March 12, 2024 — a good INP is under 200ms at the 75th percentile.
Step 2: Add the viewport meta (solves ~80% of cases in one line)
In every page template’s <head>, near the top:
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
...
</head>Never add user-scalable=no or maximum-scale=1 — it blocks pinch-zoom, which hurts accessibility and fails the Lighthouse “has a [user-scalable=no]” / viewport audit.
Step 3: Responsive CSS safety net
Add to your global stylesheet:
* { box-sizing: border-box; }
html, body { overflow-x: hidden; }
img, video, iframe { max-width: 100%; height: auto; }
pre, code { white-space: pre-wrap; overflow-x: auto; }
table { display: block; overflow-x: auto; }
button, a {
min-height: 48px;
min-width: 48px;
padding: 12px 16px;
}
body { font-size: 16px; line-height: 1.6; }Step 4: Test locally in Chrome DevTools Device Mode
1. Open DevTools, toggle the device toolbar (Cmd/Ctrl+Shift+M)
2. Pick a real device profile, e.g. "iPhone 15 Pro" or "Pixel 8"
3. Walk every template, watching for horizontal scroll / tiny text / cramped buttons
4. Throttling: set "Mid-tier mobile" to see the real load experienceStep 5: After deploy, verify in Search Console
There is no “Mobile Usability” report anymore, so verify with URL Inspection instead:
Search Console → URL Inspection → paste the fixed URL → Test live URL
→ View tested page → ScreenshotThe rendered screenshot should show a normal mobile layout (correct width, no clipping). For ongoing health, watch Search Console → Core Web Vitals → Mobile, which reports field data segmented by device; URLs move from “Poor” to “Good” as real-user data accumulates (typically 28 days of field data after the fix is live).
Step 6: Add a site-wide check to CI
A standalone Mobile-Friendly Test API no longer exists, so guard the cheap, high-value invariant yourself — every page must have the viewport meta and must not disable scaling:
// scripts/check-mobile-friendly.mjs
import fg from "fast-glob";
import fs from "node:fs";
const issues = [];
for (const f of fg.sync("dist/**/*.html")) {
const html = fs.readFileSync(f, "utf8");
if (!html.match(/<meta\s+name=["']viewport["']/i)) {
issues.push(`MISSING viewport: ${f}`);
}
if (html.match(/user-scalable\s*=\s*["']?no/i)) {
issues.push(`BAD viewport (user-scalable=no): ${f}`);
}
}
if (issues.length) { console.error(issues.join("\n")); process.exit(1); }For deeper coverage, run Lighthouse CI (@lhci/cli) against a few representative URLs on every deploy and assert a minimum SEO/accessibility score.
How to confirm it’s fixed
- PageSpeed Insights → Mobile tab shows no viewport/tap-target/legibility flags.
- DevTools Device Mode on a phone profile: no horizontal scroll bar, no pinch needed, every button is comfortably tappable.
- Search Console → URL Inspection → live test screenshot renders a clean mobile layout.
- Over the next ~4 weeks, the page’s Core Web Vitals status trends toward “Good” on the Mobile breakdown.
Prevention
- New templates get tested on a real phone (Pixel/iPhone) before launch, not just the desktop browser.
- Use a CSS framework with sane responsive defaults (Tailwind, Pico.css) so the base scales automatically.
- Body text always 16px or larger; interactive targets always 48 x 48px.
- The viewport meta lives in the base layout, so no template can omit it.
- CI blocks the build when a page is missing the viewport meta or sets
user-scalable=no.
FAQ
Where did the Mobile-Friendly Test go? Google retired it, the Mobile Usability report, and the test API on December 1, 2023. Use Lighthouse in Chrome DevTools or PageSpeed Insights instead — those are Google’s recommended replacements.
Is “not mobile friendly” still a ranking factor in 2026? Yes, indirectly. Mobile-first indexing means Google ranks the mobile rendering of your page. A page that’s hard to use on a phone gets worse Core Web Vitals (page-experience signals) and a worse rendered crawl, both of which can suppress rankings.
My CSS is responsive but Google still flags problems. Why? Responsive layout isn’t the same as mobile-first parity. Common gaps: a mobile menu that hides links present on desktop (so internal link equity differs), content collapsed behind tabs Googlebot doesn’t expand, or lazy-loaded main content that doesn’t render for the crawler. Inspect the rendered HTML via URL Inspection → View tested page → HTML.
How small can a tap target be? Lighthouse’s audit passes at 48 x 48px. The accessibility floor (WCAG 2.2 SC 2.5.8, Level AA) is 24 x 24 CSS px with adequate spacing. Build to 48px to satisfy both.
How long until Google re-evaluates after I fix it? The live URL Inspection test reflects the fix immediately. Field-data signals in the Core Web Vitals report lag, because they’re built from ~28 days of real-user data, so expect the status to update over roughly four weeks.
Related
Tags: #SEO #Google #Search Console #Indexing