Skip to main content
Card class: Sensitivity • Category: Mobile Usability
Pages failing the mobile-friendly test, Google de-ranks these on mobile (>60% of ecom traffic for most DTC brands).

​
At a glance

A real-time count of pages on your verified property that Google Search Console reports as failing mobile usability checks: text too small to read, clickable elements too close together, content wider than the screen, or a missing/incorrect viewport. These are not cosmetic warnings. Google indexes mobile-first, so a page that fails on mobile is the version Google ranks, and mobile-unfriendly pages are systematically demoted in the mobile SERP. When that page is a revenue-bearing landing page (category, product, or campaign destination), the cost is direct lost organic traffic.
What it countsThe number of distinct URLs on the verified property currently in an error state across Search Console’s mobile usability checks. Each error URL may carry one or more specific issue types (small font, tap targets too close, content wider than screen, viewport not set, viewport not on device-width, incompatible plugins).
Data sourceGoogle Search Console mobile usability data, surfaced via the Search Console API enhancement report for the property. The card reads the current error roster, not a historical aggregate.
What “error” means hereA URL Google has crawled, rendered on a mobile viewport, and judged not mobile-friendly. It is distinct from a “valid” URL (passes) and from URLs Google has not yet re-evaluated after a fix.
Revenue weightingThe card cross-references each error URL against the pages that earn organic clicks (from the Performance report). An error on a zero-traffic utility page is low priority; an error on a top-clicked landing page trips the sensitivity alert.
Mobile-first framingSince Google moved all sites to mobile-first indexing, the mobile rendering of a page IS the indexed page. A desktop-only-fine page that breaks on mobile is ranked on its broken mobile form. This is why a single error can move rankings, not just mobile UX scores.
Time windowRT (real-time roster of the current error set; Search Console re-evaluates URLs on its own crawl cadence, so the underlying state can lag a fix by days).
Alert trigger>0 on revenue-bearing landing pages. A non-zero count limited to low-traffic pages stays amber/informational; any error touching a page that earns organic clicks fires the sensitivity alert.
Rolesowner, marketing

​
Calculation

The card takes the set of URLs Search Console currently classifies as error in its mobile usability evaluation for the verified property, then intersects that set with the pages that have earned organic clicks in the trailing performance window. The headline number is the count of error URLs. The alert state is driven by the revenue-bearing subset, not the raw total. In plain terms: 
mobile_usability_errors = count(URLs where Google's mobile render = "not mobile-friendly")
revenue_at_risk_errors  = count(error URLs that also appear in the Performance report with clicks > 0)
alert = (revenue_at_risk_errors > 0)
The specific issue types Search Console can attach to an error URL are a fixed vocabulary: viewport not set, viewport not set to device-width, content wider than screen, text too small to read, clickable elements too close together, and incompatible plugins (for example Flash). A single URL can hold several at once; for triage, the issue type tells the engineer what to change, while the URL tells the marketer what is at risk. There is no averaging or rolling window applied to the count itself: it is a live roster. The only time dimension is Google’s own re-crawl latency, which is why a page you fixed yesterday can still appear here until Google re-renders it.

​
Worked example

A UK skincare brand on Shopify, property https://www.brightskin.co.uk/, verified in Search Console. On 18 Apr 26 the card moves from green (0) to red (3) and fires the sensitivity alert.
URLIssue type(s)Organic clicks (last 28 days)Alert weight
/collections/vitamin-c-serumsClickable elements too close together4,120High, revenue-bearing
/products/glow-drops-30mlText too small to read2,870High, revenue-bearing
/pages/ingredient-glossaryContent wider than screen18Low, informational
Three observations:
  1. Two of the three errors land on top-clicked pages, so the alert is justified. The vitamin-C collection and the hero serum product together earn ~7,000 organic clicks a month. If Google demotes their mobile rankings even one position, the brand loses a meaningful slice of organic revenue, and mobile is roughly 60 to 70% of this brand’s sessions. The glossary page error is real but low priority.
  2. The root cause was a single theme deploy. A 14 Apr 26 update to the collection and product templates shrank a “size guide” link and tightened the spacing of the add-to-basket and wishlist buttons on small viewports. The desktop layout was unaffected, which is exactly why the team did not notice in QA. The “text too small to read” and “clickable elements too close together” issues both trace to that one commit.
  3. Fix-to-clearance latency is Google’s, not ours. The engineer shipped the CSS fix on 19 Apr 26 and used URL Inspection, Test Live URL in Search Console to confirm the live page now passes. The card, however, still showed the two URLs as errors until Google re-rendered them on 22 Apr 26, three days later. Do not wait for the card to clear before validating: use the live test to confirm the fix, then let Google catch up.
Rule of thumb. Any non-zero count is worth a look; a non-zero count on a page that appears in your top organic landing pages is a drop-everything fix. The mobile render is the ranked render.

​
Sibling cards merchants should reference together

CardWhy pair it with Mobile Usability Errors
Mobile vs DesktopShows how much of your organic performance is mobile. The higher the mobile share, the more a usability error costs you.
Clicks by DeviceConfirms the device split on clicks specifically, so you can size the revenue exposure of a mobile error.
CTR by DeviceIf mobile CTR sags after a deploy, a usability error may be the cause even before rankings move.
Position by DeviceThe ranking read-out. A mobile usability error often shows up here as mobile average position drifting below desktop.
Pages Losing TrafficCross-check whether the error URLs are the same pages bleeding organic clicks.
Index Coverage Drop AlertA different failure mode (de-indexing) that can masquerade as a usability problem; rule it out.
Rich Results ErrorsThe other enhancement-report alarm. Both share the same “Google flagged this page” mechanic.
Mobile Ranking DistributionShows where your mobile rankings cluster, so you can see the aggregate effect of usability errors over time.

​
Reconciling against the source

Where to look in Google Search Console:
Search Console, the Mobile Usability / Page Experience area is the native home of this signal. Open the property, find the mobile usability report, and you will see the same error/valid split and the same fixed list of issue types (text too small, tap targets too close, content wider than screen, viewport problems). Click an issue to see the affected URLs, then use URL Inspection, Test Live URL to validate any fix in real time.
The Search Console API enhancement endpoint returns the machine-readable version of the same roster, which is what the card reads. If the card and the UI disagree, the API and UI almost always agree with each other; the difference is timing (see below).
Why the card may legitimately differ from the Search Console UI:
ReasonDirection of divergence
Re-crawl latency. Search Console re-evaluates URLs on its own crawl schedule. A page you fixed may still show as an error in both the card and the UI for days.Card and UI lag the real (fixed) state.
Data delay. Search Console data is typically 2 to 3 days behind real time. The error you introduce today may not appear for a couple of days.Card lags new breakage by 2 to 3 days.
Revenue weighting. The card’s alert is driven by the revenue-bearing subset; the UI shows the raw error list with no traffic weighting.Card alert can be amber while the UI shows a non-zero raw count.
Row caps. The Search Console UI and Performance report cap at 1,000 rows. On very large sites, the traffic-intersection step may not see every long-tail error URL’s clicks.Marginal under-weighting on large catalogues.
Anonymised queries. Rare-query anonymisation in the Performance report does not affect the usability roster, but it can slightly understate clicks on niche error pages when sizing exposure.Marginal under-weighting of click exposure.
The native mobile-friendly tooling, not the card, is the source of truth for a single URL. When you need a definitive yes/no on one page after a fix, run URL Inspection, Test Live URL in Search Console. The card is the always-on roster and revenue lens across the whole property; the live test is the per-URL adjudicator.

​
Known limitations / merchant FAQs

I fixed the page yesterday but the card still shows it as an error. Is the card wrong? No. Search Console re-evaluates URLs on its own crawl cadence, and its data is typically 2 to 3 days delayed. The card reflects Google’s last-known state, not your live state. Confirm your fix with URL Inspection, Test Live URL in Search Console, then let Google re-crawl. The card will clear once Google re-renders the page as mobile-friendly. The count is non-zero but the card is amber, not red. Why no hard alert? The hard alert fires only when an error touches a revenue-bearing landing page (a URL that earns organic clicks). A non-zero count limited to zero-traffic or near-zero-traffic pages is real but low priority, so the card stays informational. Check the affected URLs: if they are utility pages no one finds via search, you can deprioritise. Does a mobile usability error actually hurt my rankings, or just my UX score? It hurts rankings. Google indexes mobile-first, so the mobile render of a page is the version Google ranks. A page that fails mobile usability is systematically demoted in mobile results, and mobile is the majority of traffic for most DTC brands. This is a ranking risk, not a cosmetic one. One URL shows several issue types at once. Do I fix them all? Yes, a URL stays in the error state until every flagged issue is resolved. The issue types map to specific front-end causes: “text too small” to base font size and viewport scaling, “clickable elements too close together” to tap-target spacing, “content wider than screen” to overflow or fixed-width elements, “viewport not set” to a missing or wrong viewport meta tag. Fix all of them, then re-test the live URL. My desktop site looks perfect. How can these pages be failing? Because the checks run on a mobile viewport render, not desktop. A theme change that only affects small-screen CSS (button spacing, font scaling, an element that overflows on narrow widths) will pass desktop QA and still fail here. Always QA template changes on a real mobile viewport or with the live URL test. Can a page disappear from this card without me doing anything? Yes, in two ways. Either Google re-crawled it and now passes it (the good case), or the URL stopped being indexed (for example you no-indexed or removed it), in which case it leaves the usability roster but you have lost the page entirely. If a revenue page drops off this card, confirm it is still indexed via Index Coverage Drop Alert rather than assuming the problem is solved. How fast will a fix show up here? Plan for days, not hours. Re-crawl plus Search Console’s 2 to 3 day data delay means a confirmed-fixed page can sit on the card for the better part of a week before clearing. Validate with the live URL test for immediate confidence; treat the card’s clearance as the lagging confirmation.

​
Tracked live in Vortex IQ Nerve Centre

Mobile Usability Errors is one of hundreds of KPI pulses Vortex IQ tracks across Google Search Console and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.