Mobile usability. Mobile-first indexing, viewport fundamentals, and the 2026 mobile experience checklist.

What mobile-first indexing means

Mobile-first indexing is the policy that Google uses the smartphone Googlebot to crawl and the mobile version of your site as the primary source of truth for indexing and ranking. The rollout started in 2016 as an experiment, became the default for new sites in 2019, and finished migrating older sites by October 2023. Every public site is now mobile-first.

The practical effect: if a piece of content is on your desktop site but missing from your mobile site, Google does not see it. If your mobile site loads more slowly than your desktop site, Google ranks based on the slow version. If your mobile structured data is incomplete, that is the data Google uses. Mobile is the canonical version, even when the user is on a 27-inch desktop monitor.

Responsive design effectively short-circuits the problem because the HTML served to both devices is identical. The desktop and mobile versions are the same document with different CSS. Mobile-first indexing of a responsive site is just indexing. The risk only really materialises on sites with separate mobile templates, dynamic serving by user agent, or apps that strip content on mobile to "simplify" the experience.

What changed in December 2023

Google retired two long-standing mobile tools in December 2023.

The standalone Mobile-Friendly Test, which lived at search.google.com/test/mobile-friendly. The tool ran a one-shot mobile rendering of any URL and returned pass or fail with screenshot. It was the canonical "is this mobile-friendly" check for a decade.

The Mobile Usability report in Search Console, which used to list mobile issues across all your indexed URLs (text too small, clickable elements too close together, content wider than screen, viewport not configured).

Both were retired because the underlying checks duplicated work that Lighthouse and the Page Experience report do better. The replacement workflow is:

1. Run the page through PageSpeed Insights or Chrome DevTools Lighthouse with the mobile preset.
2. Read the Accessibility and SEO sections for tap target, font size and viewport issues.
3. Use the GSC Core Web Vitals report to see mobile-specific Vitals at URL-group scale.
4. Use the GSC URL Inspection tool to confirm what Googlebot smartphone sees on any single URL.

Net effect: the checks are the same, the tools are different. Sites that already passed the old Mobile-Friendly Test typically pass Lighthouse mobile without issue.

The viewport meta tag

The single most important line of HTML for mobile rendering:

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

Without it, mobile browsers render the page at a 980-pixel virtual width and then scale the whole thing down. Text becomes tiny. Users have to pinch-zoom. Tap targets become unreachable. Lighthouse flags the missing viewport as a critical accessibility and SEO issue.

The right viewport tag tells the browser "render this page at the actual device width and start at 100 percent scale". The browser then applies your CSS responsively. This template includes the viewport tag at the top of every Learn Hub page. Most modern frameworks include it by default. Verify it exists on every template by viewing source on a representative URL.

Do not set maximum-scale=1 or user-scalable=no. Both block users from zooming, which is an accessibility regression and triggers a Lighthouse warning. The default is fine.

Text size and tap targets

Two old-school usability checks Lighthouse still runs.

Body text at 16 CSS pixels or larger. Smaller body text triggers iOS Safari to auto-zoom when a user focuses a form field, which yanks the layout sideways. It is also hard to read on small screens. Google's mobile audit flags body text below 16px. Set the base font size on html or body to 16px (or 1rem) and scale typography from there.

Tap targets at 48 by 48 CSS pixels minimum, with 8px gaps between adjacent targets. The 48px figure comes from average finger pad width measurements. Smaller targets are hard to hit accurately. The classic offender is a list of footer links spaced at 4px line height: each link is technically tappable but the user hits the wrong one every second time. Add padding, increase line-height to 1.5 or 1.6, give the navigation real breathing room.

Some specifics that catch teams out:

• Icon-only buttons. A 24px Bootstrap icon with no padding is a 24px tap target. Wrap it in a button with at least 12px of padding all around. Visually the icon is still 24px; the tap target becomes 48px.
• Inline links inside body text. An inline link is part of a body-text run and Lighthouse rates it against the line height, not the character height. A 16px font at line-height 1.5 gives a 24px line which qualifies. Inline links in 12px footnote text fail.
• Close-X buttons. The X on a modal or banner is often drawn at 16px. Add at least 8px padding on every side. 48px hit area, 16px visual element.

Content parity between desktop and mobile

Under mobile-first indexing, content missing from the mobile site is invisible to Google. This is the single most common technical SEO problem we still see on sites built before 2020.

Patterns that break content parity:

• Hidden accordions that only load on tap. If the content is in the HTML but visually hidden via CSS, Google still indexes it. If the content is fetched via JavaScript after a tap, Google may or may not index it depending on rendering behaviour.
• "View more" links to dedicated mobile pages. A mobile homepage that strips the bottom 60 percent of content with a "Read more on desktop" link is a content-parity failure. The 60 percent of content is invisible to Google.
• Mobile sidebars hidden behind tabs. Generally fine for indexing, but watch for cases where the tab content is loaded async only on click. Server-render the content or ensure it is in the initial HTML.
• Different structured data between desktop and mobile. Easy to introduce by accident with separate templates. Mobile-first means Google uses the mobile schema; if the mobile template ships without your schema markup, the rich result is gone. See the schema markup chapter for the wider picture.
• Different internal linking between desktop and mobile. A mobile menu that omits 40 percent of the desktop nav reduces the link equity flowing to those pages. Internal linking on mobile counts equally to internal linking on desktop.

The simplest check: open a representative URL on a desktop browser at full width, then resize the browser to 360px wide. Anything that disappears or changes is a content-parity risk. For dynamic content, use the GSC URL Inspection tool's "Test Live URL" view to see exactly what Googlebot smartphone renders.

Mobile UX patterns that hurt rankings

Beyond the basic checks, four mobile UX patterns we see hurt rankings indirectly through engagement metrics.

Sticky elements that consume too much viewport. A sticky header at 80px, a sticky footer banner at 60px, a sticky promotional bar at 40px, and a sticky chat widget. That is 180px out of a ~700px effective viewport, leaving 520px for actual content. Users scroll more, get tired faster, leave sooner. Mobile bounce rates climb. Keep total sticky chrome under 15 percent of viewport height.

Aggressive interstitials. Pop-ups, full-screen ads, app-install prompts that cover the main content on landing from search results. Covered in detail in the intrusive interstitials chapter. Google has a specific Page Experience demotion for these.

Slow form fields. Forms on mobile suffer when the form is too long, when fields autofill incorrectly, when keyboards do not match the field type (number keyboard for postcode fields, telephone keyboard for phone fields). Set inputmode and type attributes correctly on every input.

Horizontal scroll. Any horizontal scroll on a mobile page is a failure. A single oversized image, a table that does not wrap, a code block with long lines, a div with a fixed pixel width: any of these can force horizontal scroll. Add overflow-x: hidden on body as a safety net and audit each template for the actual cause.

Common mistakes

Assuming Mobile-Friendly Test results from 2022 still count. They do not. The tool is gone. Old reports are stale. Run a fresh Lighthouse mobile audit on every key template.

Confusing mobile usability with mobile performance. They are separate. Usability is layout, viewport, tap targets, text size, content parity. Performance is Core Web Vitals: LCP, INP, CLS. Both matter. Both are mobile-weighted. Different fixes. See LCP optimisation and INP explained for the performance side.

Forgetting that internal linking moves with mobile. A mobile site missing 40 percent of its desktop nav links is leaking link equity. The internal linking chapter covers this in depth.

Building separate mobile URLs in 2026. The m-dot pattern was best practice in 2011 and is a liability in 2026. New builds should be responsive. Existing m-dot sites should plan a migration. The complexity cost rarely pays for itself.

Tools and checklist

Free tools for the full mobile usability workflow:

• Lighthouse mobile preset. The replacement for the Mobile-Friendly Test. Run from Chrome DevTools or PageSpeed Insights.
• Chrome DevTools device emulation. Toggle device toolbar, select a real device like Pixel 5 or iPhone 12, throttle to Slow 4G.
• GSC URL Inspection tool. Shows exactly what Googlebot smartphone sees on any indexed URL.
• GSC Core Web Vitals report. Mobile and desktop tabs separately. Field data, URL-group level.
• BrowserStack or LambdaTest. Real-device testing across iOS Safari, Chrome Android, Samsung Internet. Useful for edge-case Safari behaviour.

Pre-launch mobile checklist:

• Viewport meta tag present on every template, no maximum-scale or user-scalable=no
• Body text at 16px or larger across all templates
• Tap targets at least 48 by 48 CSS pixels with 8px gaps
• No horizontal scroll at 360px viewport width
• Content parity between desktop and mobile verified on key templates
• Structured data identical between desktop and mobile
• Sticky chrome under 15 percent of viewport height
• Form inputs have appropriate type and inputmode attributes
• Lighthouse mobile audit passes Accessibility and SEO sections

Perth and WA context

Two mobile usability patterns we see across Perth and WA businesses.

Older WordPress themes with non-responsive admin sections. A Perth law firm site we audited last year had a responsive front end but a non-responsive booking widget loaded inside the contact page. Mobile users could not tap the date picker. The widget had been the same since 2014 and nobody had noticed. Legal SEO sites and healthcare SEO sites are particularly prone to this because the booking and intake widgets often come from external suppliers who never updated for mobile.

Map embeds that block half the viewport. Perth service-area businesses often embed a large Google Map showing their service radius on the contact page. On desktop it is helpful. On mobile it can consume 70 percent of the visible viewport and feel like the page is broken. Set a fixed reasonable height (300 to 400px) on the map iframe and let the rest of the contact details breathe. Local SEO Perth sites all face this tradeoff.

For broader work, the website audits service covers mobile usability at template scale. New sites should start with a free SEO audit. The speed optimisation service handles the performance side of mobile. For geography see Perth services, Fremantle and Bunbury. Related Learn Hub chapters: Core Web Vitals explained, LCP optimisation, INP explained, CLS fixes, Lighthouse explained, and the technical SEO pillar.