How to Fix a Failed Mobile-Friendly Test: 8 Common Issues
A failed mobile-friendly test result means one or more of six measurable criteria, viewport configuration, font size, tap target spacing, horizontal scroll, plugin compatibility, and intrusive interstitials, did not meet the minimum threshold required for a page to render correctly on a smartphone screen. Each failure has a specific cause, a specific fix, and a specific severity level that tells you how urgently it affects your visitors and your search visibility.
If you have not yet run a test and do not know which criterion failed, use Snapzain's free mobile-friendly test first, paste your URL and the result tells you exactly which of the 8 issues below applies before you touch any code. Understanding what mobile-friendly actually means and the full criteria behind, read our complete Mobile-Friendly Test Guide. It also helps if any fix below needs more technical context.
8 Mobile-Friendly Test Failures, and How to Fix Each One
These 8 mobile-friendly test failures account for virtually every failed result across the 9,217 impressions Snapzain's tool receives from site owners searching for a mobile usability check, ordered from most common to least common, with severity rated at the top of each entry so you can triage multiple failures immediately.
Issue 1: Missing or Broken Viewport Meta Tag
Severity: Serious
The viewport meta tag is the single line of HTML that tells a mobile browser how to scale a page to fit the device screen. Without it, the browser renders the page at a fixed desktop width, usually 980px, then shrinks the entire layout down proportionally, making all text and buttons microscopic until the visitor manually zooms in.
How To Spot it: Load your page on a phone without zooming. If the entire page appears at a scale where text is unreadably small and everything looks like a shrunken desktop version, the viewport tag is missing or misconfigured.
The fix: Add this exact line inside the <head> section of your HTML:
html
<meta name="viewport" content="width=device-width, initial-scale=1">
If the tag already exists but the page still fails, check for user-scalable=no or a fixed pixel value like width=1024, both will cause failures. Remove the fixed value and replace with device-width.
Note: If you are using WordPress, most themes insert this tag automatically. Check under Appearance → Theme Editor → header.php if the tag is missing from a WordPress site. The viewport tag was also the most frequently flagged issue in Google's original test before why Google's own checker disappeared, the standard it set for this criterion is unchanged.
Issue 2: Tap Targets Too Small or Too Close Together
Severity: Serious
A tap target is any element a visitor taps with a finger — buttons, links, nav menu items, form fields. Google's minimum standard is 48x48 pixels per target with at least 8px of clear space between adjacent targets. Below that size, an average fingertip covers multiple elements simultaneously, causing mis-taps and frustration.
How To Spot it: Open your page on a phone and try tapping links inside a paragraph, items in a navigation menu, or buttons near the bottom of a form. If you frequently land on the wrong element, the targets are too small or too close.
The Fix: In your CSS, set a minimum height and width for interactive elements:
css
a, button, input[type="submit"] {
min-height: 48px;
min-width: 48px;
padding: 10px 16px;
}
For navigation menus specifically, add padding to each nav item rather than reducing font size to fit more items into a row, more padding, fewer mis-taps.
Issue 3: Font Size Too Small to Read Without Zooming
Severity: Moderate
Body text below 12px fails a mobile-friendly test. The recommended minimum for comfortable reading without zooming is 16px. Font size failures occur most often in pages built with a desktop-first stylesheet that assigns a small base size,13px or 14px is common, that was never overridden in a mobile media query.
How To Spot it: View the page source and find the font-size value on the body or p element. If it's in pixels below 16, or in relative units that resolve below 16px on a 375px-wide screen, it will fail.
The Fix: Set a base font size on the body element that applies across all screen widths, then scale it if needed for larger screens:
css
body {
font-size: 16px;
}
@media (min-width: 768px) {
body {
font-size: 18px;
}
}
Never use px values below 16 for body text. If your theme uses em or rem units, verify the computed pixel value in Chrome DevTools under Elements → Computed → font-size.
Issue 4: Content Wider Than the Screen (Horizontal Scroll)
Severity: Moderate
Horizontal scrolling occurs when one or more elements on a page render at a fixed pixel width wider than the device screen, forcing visitors to scroll sideways to see content that disappears off the right edge. It is one of the fastest failures for a test to detect and one of the most disorienting experiences for mobile visitors.
How To Spot it: Load the page on a phone and swipe right. If the page scrolls horizontally to reveal content or white space, something is overflowing the viewport width.
The Fix: Find the overflowing element using Chrome DevTools (resize the browser window to mobile width, then use the Inspector to check which element exceeds 100% of the viewport). Apply:
css
img, video, table, iframe {
max-width: 100%;
height: auto;
}
For tables specifically, wrap them in a scrollable container:
html
<div style="overflow-x: auto;">
<table>...</table>
</div>
Issue 5: Intrusive Interstitials Blocking Content
Severity: Moderate
An intrusive interstitial is a pop-up, overlay, or full-screen banner that covers the main page content immediately after a mobile visitor arrives, before they can read anything. Google has applied a ranking signal penalty for intrusive interstitials on mobile pages since January 10, 2017. Cookie consent notices and legally required age gates are exempt, provided they use a reasonable portion of the screen.
How To Spot it: Open the page on a phone in a private browser window (to bypass cookies already accepted). If a full-screen or large-area overlay appears before any main content is visible and requires a tap to dismiss, it fails.
The Fix: Resize pop-ups to occupy no more than 30% of the screen height. Position them as a bottom banner rather than a centred overlay. Set a short delay before the pop-up triggers, not on page load, but after the visitor has scrolled past the first screenful of content.
Issue 6: Unplayable or Incompatible Plugin Content
Severity: Mild
Flash-based video, animations, or interactive content cannot play on any modern mobile browser. Adobe Flash reached end-of-life on December 31, 2020, and was removed from all major browsers. A page with an embedded Flash element displays a blank area or a broken plugin icon where the content should appear.
How to Spot it: Search your page source for .swf, application/x-shockwave-flash, or <object> tags with Flash-specific MIME types. Legacy blog posts and older landing pages are the most common sources.
The Fix: Replace Flash video embeds with HTML5 video:
html
<video controls width="100%">
<source src="video.mp4" type="video/mp4">
</video>
For animations originally built in Flash, re-create them in CSS or a JavaScript animation library such as GreenSock (GSAP), or replace them with a static image if the animation was decorative.
Issue 7: Text Too Close Together (Line Height and Paragraph Spacing)
Severity: Mild
Insufficient line height and paragraph spacing are not a formal criterion in the same way as font size, but they produce a similar scanning failure, visitors cannot distinguish separate lines of text at a glance, which increases reading effort and bounce rate on mobile. Tests sometimes flag this as a readability sub-issue under font-size criteria.
How To Spot it: Read your page on a phone. If lines of text feel visually merged or paragraphs run together without a clear visual gap, the spacing is too tight.
The fix:
css
body {
line-height: 1.6;
}
p {
margin-bottom: 1.2em;
}
A line-height of 1.5 to 1.8 is the standard readable range for body text on mobile. Below 1.4, lines begin to visually merge on smaller screens.
Issue 8: Fixed-Position Elements Covering Content
Severity: Mild
A fixed header, sticky navigation bar, or persistent bottom banner that occupies too much vertical space on a small screen can leave less than half the viewport height available for actual content. On a 667px-tall screen (iPhone SE), a 120px fixed header consumes 18% of the visible area before a single word of body content appears.
How To Spot it: Scroll down the page on a phone and check how much of the visible screen is occupied by fixed elements. If the content area feels noticeably cramped even with the page partly scrolled, the fixed elements are too tall.
The Fix: Reduce fixed header height on mobile using a media query:
css
@media (max-width: 767px) {
header {
height: 56px;
padding: 8px 16px;
}
}
Alternatively, use a scroll-behavior trigger to shrink the header after the visitor scrolls past the first 100px, giving the full viewport to content once the page is in use.
How Do You Confirm the Fix Worked?
You confirm a fix worked by re-running the same URL through Snapzain's Mobile-Friendly Checker immediately after the change is live, the tool evaluates each criterion independently, so a result showing "Viewport: Pass, Tap Targets: Fail" tells you the first fix landed and one more remains.
Re-test on at least three page types: your homepage, a core product or content page, and a standard blog post. A fix applied to one template does not automatically propagate to all templates on the same site, a theme update can resolve the homepage viewport while leaving every inner page template unchanged.
Developer Checklist: Before You Publish Any New Page
This developer checklist covers the eight mobile-friendly criteria to confirm before you publish any new page template, theme update, or plugin change, run it once per template type, not once per individual page:
Viewport meta tag is present with width=device-width, initial-scale=1
Base font size is 16px or above
All tap targets are at minimum 48x48px with 8px spacing
No element is set to a fixed pixel width wider than 375px without max-width: 100%
No Flash or unplayable plugin content is embedded
No full-screen pop-up fires on page load before content is visible
Line height is 1.5 or above for body text
Fixed headers occupy less than 10% of viewport height on a 375px-wide screen
Frequently Asked Questions
What Does a Failed Mobile-Friendly Test Mean?
It means one or more of six criteria, viewport, font size, tap targets, horizontal scroll, plugin content, or interstitials, did not meet the minimum threshold on that URL.
Which Mobile-Friendly Test Failure is Most Common?
A missing viewport meta tag is the most common single failure. Without it, a mobile browser renders the entire page at desktop width, making all text and buttons unreadably small.
How Do I Fix Tap Targets That are Too Small?
In CSS, set a minimum height and width of 48px on all interactive elements and ensure at least 8px of clear space separates adjacent links, buttons, and nav items.
Does Fixing a Mobile-Friendly Test Issue Immediately Improve Rankings?
Not immediately, Google must re-crawl and re-index the updated page first. Mobile usability improvements typically reflect in ranking positions within two to six weeks of recrawling.
How Long Does it Take To Fix a Failed Mobile-Friendly Test?
A viewport tag fix takes under two minutes. Font size and tap target CSS fixes take 30 to 60 minutes. Flash content removal depends on how many embeds exist sitewide.
