Search Console Mobile Usability Report: How to Fix Each Error

Did Search Console just email you about “new Mobile usability issues” on your site? You are not alone. The Mobile Usability report lists the pages Google thinks are hard to use on a phone, and it tells you the exact problem for each one.

The good news is that there are only six errors, and each one has a clear fix. In this guide I explain what every error means, how I fix it, and how to get Google to confirm the fix.

What the Mobile Usability Report Shows

The Mobile Usability report lives in Google Search Console under the Experience section. It checks your indexed pages for problems that make them awkward to use on a small screen.

The report has two parts:

• A chart that shows how many of your pages have issues and how many don’t, over time.
• A details table that lists each error type, how many pages it affects, and the status of any fix you have asked Google to check.

Click any error row and you get a list of example URLs with that problem. Click a URL and you can open it in the URL Inspection tool or run a live test.

One thing to know up front: the report is based on what Googlebot saw the last time it crawled each page. It is not a live view. So a page you fixed yesterday can still show as an error until Google crawls it again.

Why Mobile Usability Still Matters in 2022

Google now crawls and indexes most sites with its smartphone crawler. This is called mobile-first indexing. It means the mobile version of your page is the version Google mainly looks at.

Mobile-friendliness is also one of the page experience signals. The page experience update finished rolling out for mobile search in August 2021. Google has said page experience will come to desktop in February 2022, but mobile-friendliness is not part of the desktop version.

Let me be honest about the ranking side. In my experience, fixing a few mobile usability errors rarely causes a big ranking jump on its own. Relevant, helpful content still matters far more. But these errors are real problems for real visitors. If people pinch, zoom and scroll sideways to read your page, many of them will leave.

So I treat this report as a user experience check first and an SEO check second.

The Six Mobile Usability Errors at a Glance

Here is a quick summary before we go through each error in detail.

How to Fix Each Mobile Usability Report Error

Before you change any code, open one affected URL in the URL Inspection tool and click Test live URL. If the live test says the page is mobile-friendly, the problem may already be gone, or it may have been a loading glitch. I explain those false alarms further down.

Uses Incompatible Plugins

This error means the page uses a browser plugin that most phones don’t support. Flash is the usual cause. Adobe stopped supporting Flash at the end of 2020, and modern browsers no longer run it at all.

To fix it:

• Replace Flash video with a normal HTML5 <video> element or an embedded player like YouTube.
• Rebuild Flash animations or games with HTML5, CSS or JavaScript.
• If the old content is no longer useful, remove it from the page.

I rarely see this error now, but it still shows up on old pages nobody has touched in years. It is a good reason to review those pages anyway.

Viewport Not Set

The viewport is the visible area of a page on the screen. The viewport meta tag tells the phone’s browser how wide the page should be and how to scale it.

Without this tag, a phone browser shows the page as if it were on a desktop screen and then shrinks it down. Everything looks tiny. This one missing line often triggers other errors too, like small text and tap targets that are too close.

The fix is to add this line inside the <head> of every page:

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

On WordPress and most site builders, this tag comes from the theme. If it is missing, check whether a custom header template or a plugin is removing it. I usually see this problem after someone builds a custom landing page template by hand.

Viewport Not Set to “Device-Width”

Here the page does have a viewport tag, but it sets a fixed width. For example:

<meta name="viewport" content="width=1024">

A fixed width means the page can’t adjust to different screen sizes. A phone that is narrower than 1024 pixels will have to shrink the whole page.

The fix is to replace the fixed number with width=device-width, as in the tag shown above. If your layout breaks after that change, the page was never built to be responsive (able to adjust its layout to any screen size). In that case, the real fix is to update the theme or template, not the tag.

While you are there, I’d also remove maximum-scale=1 or user-scalable=no if you see them. Search Console doesn’t flag these, but they stop people from zooming in, which hurts readability and accessibility.

Content Wider Than Screen

This error means something on the page is wider than the phone screen. The visitor has to scroll sideways to see it all. That is a poor experience because people expect to scroll down, not across.

Common causes I see:

• Images with a fixed width in pixels, like width: 800px.
• Wide data tables that can’t shrink.
• Embedded videos, maps or iframes with a fixed width.
• Long URLs or code lines that don’t wrap.
• CSS that sets a container to a fixed width instead of a percentage.

To find the element causing it:

1. Open the page in Chrome and press F12 to open DevTools.
2. Turn on the device toolbar (the phone icon) and pick a small phone size.
3. Scroll right and look for the element that sticks out past the edge.
4. Inspect that element to see which CSS rule sets its width.

Then fix it with flexible sizes. For images, this simple CSS rule solves most cases:

img {
  max-width: 100%;
  height: auto;
}

For wide tables, wrap the table in a container that scrolls on its own. That way only the table scrolls sideways, not the whole page:

.table-wrap {
  overflow-x: auto;
}

For long words and URLs, add overflow-wrap: break-word; to your text styles.

Text Too Small to Read

This error means a large part of the text on the page is too small to read on a phone without zooming in.

First check that the viewport tag is set correctly. If the viewport is missing, text will look small no matter what font size you use.

If the viewport is fine, raise your font sizes in CSS. My rule of thumb is a body text size of 16px and nothing important below 12px. Small print like captions can be a little smaller, but the main reading text should not be.

body {
  font-size: 16px;
  line-height: 1.5;
}

Also check for text set in fixed units inside headers, footers and sidebars. I often find the main content is fine, but a dense footer full of tiny links is what pushes the page over the line.

Clickable Elements Too Close Together

This error means links, buttons or other tap targets are packed so closely that a finger could easily hit the wrong one. Google flags it when tapping one element without touching its neighbour is too hard.

It usually shows up in:

• Footer menus with many small links stacked tightly.
• Rows of social sharing icons.
• Pagination links like “1 2 3 4 5”.
• Inline text links placed right next to each other.
• Small form checkboxes and radio buttons.

To fix it, make the tap area bigger and add space around it. I aim for tap targets of about 48 by 48 pixels with at least 8 pixels of space between them. You can grow the tap area with padding, so the button looks the same size but is easier to hit:

.footer-menu a {
  display: inline-block;
  padding: 12px 8px;
}

In my experience, this is the error that takes the most testing. Fixing it in one place can push something else out of line, so check the page at a few screen sizes after each change.

When the Error Is a False Alarm

Sometimes Search Console reports an error, but the page looks perfect on your phone. This is common, and it usually has one of these causes.

Blocked CSS or JavaScript Files

If your robots.txt file blocks the CSS or JavaScript files your page needs, Googlebot sees the page without its styles. To Google, an unstyled page looks like plain text squeezed together, with tiny fonts and links crammed in.

Run a live test in URL Inspection and look at the screenshot and the list of page resources that couldn’t be loaded. If key CSS files are blocked by robots.txt, remove that block. This is the first thing I check when an error doesn’t match what I see on my own phone.

Temporary Loading Problems

Googlebot may also fail to load some files during a crawl because of a slow server or a timeout. The page then gets flagged once and looks fine on the next crawl.

If the live test passes and the error affects only a handful of pages, I usually wait a week or two and see if the count drops on its own. If it keeps coming back, look at server speed and how many separate files each page loads.

Old Data in the Report

Because the report uses crawl data, it can show errors on pages you fixed weeks ago, or on pages you have already deleted. Deleted pages will drop out once Google sees they are gone. Fixed pages will clear when Google crawls them again or when you run a validation.

How to Validate Your Fixes

After you fix an error across your site, tell Google so it can check the affected pages again. Here is the process I follow:

1. Fix the issue in your template or theme, not just on one page, so every affected URL gets the fix.
2. Test a few example URLs with Test live URL in URL Inspection, or with Google’s Mobile-Friendly Test tool. Make sure they pass.
3. Go back to the Mobile Usability report and click the error type you fixed.
4. Click Validate Fix. Search Console starts checking the affected pages and shows the status as “Started”.
5. Wait. Google rechecks the pages over time, and validation can take a couple of weeks or longer for bigger sites.
6. Check the result. If it shows “Passed”, you are done. If it shows “Failed”, open the list of URLs that still have the issue, fix them and start validation again.

Don’t click Validate Fix before the fix is live on every affected page. If Google finds even one page that still has the problem, the validation fails, and you have to start over.

Common Mistakes I See

• Fixing one URL instead of the template. The report shows example URLs, but the cause is almost always shared code like a theme, header or footer.
• Testing only on your own phone. Your phone may have a larger screen than many visitors. Test at small widths in DevTools too.
• Blocking zoom to “fix” the layout. Disabling zoom hides problems from you, not from your users.
• Ignoring pop-ups. The report doesn’t flag intrusive pop-ups, but they still make pages hard to use on a phone. Google’s page experience signals include intrusive interstitials.
• Panicking over a sudden spike. A jump in errors after a theme update is real and worth fixing fast. A jump that disappears on the next crawl was likely a loading glitch.

How I Use This Report in Regular Audits

I don’t check the Mobile Usability report every day. For most sites, a quick look once a month is enough, plus a check after any theme change, redesign or new page template.

When I open it, I look at three things:

• Is the number of pages with issues going up or down?
• Is a new error type showing up that wasn’t there before?
• Do the affected URLs share a template, like blog posts or product pages?

That last question usually points straight at the cause. If every affected URL is a product page, I go straight to the product template.

A clean report doesn’t mean your mobile experience is great. It only means Google didn’t find these six basic problems. Speed, layout shifts and easy navigation matter too. For a wider view of what to work on this year, see my SEO checklist for 2022.

If you are building or rebuilding a site, start with responsive design. Google recommends it for mobile sites, and a good responsive layout prevents most of these errors before they happen. The responsive web design basics guide on web.dev is a good, plain starting point for you or your developer.

Conclusion

The Search Console Mobile Usability report looks scary when it fills up with errors, but the list of problems is short and the fixes are well known. Most errors come from a missing viewport tag, fixed widths, small fonts or crowded links, and most of them live in one shared template.

Your next step: open the Mobile Usability report, pick the error that affects the most pages, run a live test on one example URL, and fix the template behind it. Then click Validate Fix and move on to the next one.