Mobile optimization: how to make your website mobile friendly

Why mobile optimization matters to visitors and to Google

Google settled the search side. On October 31, 2023 it announced that its move to mobile-first indexing was complete, with every site that works on mobile devices crawled primarily by its mobile crawler. The last few desktop-only sites followed: after July 5, 2024 Google crawls and indexes them with Googlebot Smartphone only, and a site whose content cannot be reached on a mobile device at all is no longer indexable. For indexing and ranking, the mobile version of your page is the one that counts.

The visitor side is plainer. Google's page experience guidance asks whether your content displays well on mobile devices and avoids intrusive interstitials, and it is candid about ranking: Core Web Vitals are used by its ranking systems, while the other page experience aspects do not directly help a page rank. They matter because, as Google's interstitials guidance puts it, people who find a site hard to use are unlikely to come back, and because a phone layout that hides content also hides it from Google.

There are three ways to serve pages to phones, and Google recommends responsive web design as the easiest to implement and maintain:

Everything below assumes responsive design, which is what a new build should use.

Start with the viewport meta tag

Without a viewport tag, mobile browsers lay the page out at a desktop width, usually about 980 pixels, then shrink it to fit the screen. Text turns tiny, and visitors pinch and zoom to read or tap anything. One line in the <head> fixes it:

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

width=device-width makes the page match the screen's width in device-independent pixels, so the CSS can reflow the content for that width. initial-scale=1 sets a 1:1 relationship between CSS pixels and device-independent pixels, so the page uses the full width when the phone is turned to landscape.

Leave out maximum-scale, minimum-scale and user-scalable=no. web.dev advises against them because they can stop people from zooming and cause accessibility problems. For a reader with low vision, a page that cannot be zoomed may be unreadable.

Lay out pages mobile first, with fluid grids

Mobile-first CSS means the default styles are the phone layout, and min-width media queries add columns as space appears. web.dev's advice is to design for the small screen first, widen the window until the content looks wrong and put the breakpoint there, rather than picking breakpoints for device classes, brands or operating systems. Between breakpoints the layout stays fluid: widths in percentages, fr units and minmax(), never a fixed pixel width wider than a phone.

/* Phone first: media never wider than its column */
img,
video {
  max-width: 100%;
  height: auto;
}

/* As many 18rem columns as fit, one column on a phone */
.cards {
  display: grid;
  gap: 1rem;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 18rem), 1fr));
}

/* A sidebar only once there is room for it */
@media (min-width: 60rem) {
  .page {
    display: grid;
    grid-template-columns: 1fr 18rem;
    gap: 2rem;
  }
}

The card grid needs no breakpoint at all: it fits as many columns as the container allows and falls back to one column on a narrow screen. Three checks keep a fluid layout honest:

• Nothing scrolls sideways at 320 CSS pixels. WCAG 2.2's reflow criterion (1.4.10, level AA) requires content to work at that width without scrolling in two directions; it is what a 1,280-pixel window becomes at 400% zoom. Content that needs two dimensions, such as a data table, is exempt and can scroll inside its own box, but the paragraphs around it must still reflow.
• Touch is detected, not assumed. The hover and pointer media features tell you whether the device can hover and how precise its pointer is. A menu or tooltip that only opens on hover needs another way in on a touchscreen.
• Full-height sections use the new viewport units. On phones, 100vh is sized as if the address bar and toolbars were already retracted, so a full-height hero is too tall when the page loads. 100svh (the small viewport) always fits the visible area, and 100dvh follows the toolbars as they appear and retract. Both work in all three browser engines.

Make text readable without zooming

Readable text on a phone is mostly a matter of not fighting the browser:

• Keep body text at the browser default or larger. That default is usually 16px. Set sizes in rem or em: MDN notes that font sizes in px are not accessible, because in some browsers the reader cannot then enlarge them.
• Keep lines a readable length. web.dev cites classic readability guidance of 70 to 80 characters per line. A phone column is naturally narrow; the limit matters on tablets and desktops, where a max-width of around 70ch keeps paragraphs from stretching across the screen.
• Let text grow. Never disable zoom, and avoid fixed-height boxes that clip text when a reader enlarges it; the reflow check above catches most of these.
• Keep contrast high. The contrast ratios WCAG requires, and how to measure them, are in our guide to improving website accessibility.

Size tap targets for fingers, not cursors

A mouse pointer lands on a single pixel; a finger does not. WCAG 2.2 success criterion 2.5.8 Target Size (Minimum), at level AA, asks for every pointer target to be at least 24 by 24 CSS pixels, with five exceptions:

• Spacing: a smaller target passes if a 24 CSS pixel circle centred on it does not intersect another target or another small target's circle.
• Equivalent: the same function is available through another control on the page that meets the size.
• Inline: a link inside a sentence is exempt, because the line height of the text sets its size.
• User agent control: the browser's own control, left unstyled, is exempt.
• Essential: the target's exact presentation is essential or legally required.

The spacing test is the one that catches toolbars of icon buttons. In W3C's own example, a row of 20 by 20 pixel icons with 4 pixels between them passes, and the same icons placed edge to edge fail, because their imaginary 24-pixel circles intersect.

Treat 24 pixels as the floor, not the goal: W3C recommends meeting the size itself where you can, rather than relying on spacing. The AAA criterion 2.5.5 Target Size (Enhanced) asks for 44 by 44 CSS pixels, and W3C suggests aiming for it on important links and controls. In CSS the fix is usually a bigger hit area, not a bigger icon:

.icon-button {
  display: inline-grid;
  place-items: center;
  min-width: 44px;
  min-height: 44px; /* the visible icon can stay 20px */
}

.menu a {
  display: block;
  padding-block: 0.75rem; /* taller rows for links in a menu */
}

Build forms that suit a phone keyboard

Every character typed on a phone is effort, so a mobile form should ask the phone for help. The attributes that do it are already in HTML, and web.dev's form guidance explains each:

• type picks the keyboard. type="email" and type="tel" bring up keyboards suited to an address or a phone number and turn on the browser's built-in validation.
• inputmode="numeric" gives a number pad without the side effects of type="number", which adds increment arrows that make no sense for card, account or phone numbers.
• autocomplete says which saved value belongs in the field, so the browser can fill it: name, email and tel for contact details, street-address, address-line1 and country for addresses, and cc-number, cc-name, cc-exp-month and cc-exp-year for payment cards. Without these values, visitors type everything on a small keyboard.
• Every field has a visible <label>. Tapping a label moves focus to its field, which also gives a finger a larger target.

<form action="/quote/" method="post">
  <label for="name">Full name</label>
  <input id="name" name="name" autocomplete="name" required />

  <label for="email">Email</label>
  <input id="email" name="email" type="email" autocomplete="email" required />

  <label for="phone">Phone</label>
  <input id="phone" name="phone" type="tel" autocomplete="tel" />

  <label for="address">Address</label>
  <textarea
    id="address"
    name="address"
    autocomplete="street-address"
  ></textarea>

  <button type="submit">Request a quote</button>
</form>

Card numbers follow the same pattern: <input inputmode="numeric" autocomplete="cc-number"> rather than type="number".

Serve responsive images that do not shift the layout

Images cause two separate problems on phones: a small screen downloading a file sized for a large one, and text jumping as images arrive.

The first is solved with srcset and sizes. srcset lists the same image at several widths, each with a w descriptor; sizes tells the browser how wide the image will be displayed at different viewport widths, so it can pick the smallest file that still looks sharp. web.dev's responsive images guide points out that when you use width descriptors, sizes is required, and that the browser only downloads the larger files when it needs them.

The second is solved with width and height attributes. The browser uses them to work out the aspect ratio and set aside the space before the file arrives, even when CSS scales the image. Images, ads, embeds and iframes without dimensions are among the most common causes of a poor Cumulative Layout Shift (CLS) score, along with content injected later and web fonts.

<img
  src="/images/dashboard-800.jpg"
  srcset="
    /images/dashboard-480.jpg   480w,
    /images/dashboard-800.jpg   800w,
    /images/dashboard-1600.jpg 1600w
  "
  sizes="(min-width: 60rem) 50vw, 100vw"
  width="1600"
  height="900"
  alt="Monthly traffic chart on the site's analytics dashboard"
  fetchpriority="high"
/>

<img
  src="/images/office-800.jpg"
  srcset="/images/office-480.jpg 480w, /images/office-800.jpg 800w"
  sizes="100vw"
  width="1600"
  height="1067"
  alt="Server racks in a data centre aisle"
  loading="lazy"
/>

The first image sits at the top of the page, so it is loaded early; the second sits further down and waits until the reader scrolls near it. loading="lazy" is right for images below the fold and wrong for the main image: web.dev's LCP guide says to never lazy-load the LCP image, because it delays the very element Largest Contentful Paint times. fetchpriority="high" does the opposite and asks the browser to fetch that image first.

Keep pop-ups and banners from covering the page

On a phone, a newsletter pop-up or an app-install prompt can hide the entire page. Google's interstitials and dialogs guidance separates the two: interstitials cover the whole page, dialogs cover part of it. It asks for:

1. Banners instead of full-page interstitials, taking up a small fraction of the screen. For app installs that can be a browser-supported banner, such as Safari's Smart App Banners, or a small HTML banner that links to the app store.
2. No interstitial that obscures the entire page, and no redirect to a separate page to collect consent or input.
3. Overlays, not redirects, where an interstitial is legally required, such as an age gate, so Google can still index at least some of the content behind it.

Google says intrusive dialogs make content harder for search engines to understand and may lead to poor search performance. Ads are held to the same logic: the mobile-first indexing guide points to the Better Ads Standard and warns that ads at the top of a page can take up too much room on a phone. Consent notices required by law are exempt from the interstitial advice, but a compact banner that leaves the content readable still serves visitors better than a full-screen wall.

Hit Core Web Vitals on real phones

Core Web Vitals are the part of page experience that Google's ranking systems use. web.dev sets the "good" thresholds and says to measure them at the 75th percentile of page loads, segmented across mobile and desktop:

A page passes only when all three are good. Read the mobile figures, not the desktop ones: a page that feels instant on a developer's laptop can still fail on a phone, and DevTools can slow down the CPU and the network to show you why (see the testing section below). The fixes, by metric:

• LCP: put the main image in the HTML with its dimensions and fetchpriority="high", never lazy-load it, and serve it at the size the phone needs.
• INP: an interaction's time splits into input delay, processing duration and presentation delay. Long tasks on the main thread cause the input delay, so ship less JavaScript, break long tasks up by yielding to the main thread, and defer work that does not change what is on screen.
• CLS: give images, video, ads, embeds and iframes their dimensions, reserve space for anything injected later, and load fonts so that swapping them does not reflow the text.

Tip 10 of our SEO tips for websites covers where the numbers come from and how Search Console reports them. When the fix is a rebuild, our web design and development work enforces Core Web Vitals budgets in CI and checks WCAG 2.2 AA with automated and manual tests, so a change that makes a key template slower fails its checks before it ships.

Make sure Google's smartphone crawler sees everything

Because Google indexes the mobile version, the SEO question is not whether the phone layout looks good but whether it carries everything the desktop page does. Google's mobile-first indexing best practices come down to parity:

• The same primary content. If the mobile page has less content than the desktop page, Google gets less information from it. To save space, move content into accordions or tabs rather than removing it; Google suggests exactly that.
• The same headings, structured data and metadata. Use the same clear headings, the same structured data (if you must prioritize, Google suggests starting with Breadcrumb, Product and VideoObject) and an equivalent <title> and meta description.
• The same robots meta tags. A noindex or nofollow that exists only on the mobile version can keep the page out of the index.
• Crawlable resources and the same images. Do not block the mobile page's resources, images included, with a robots.txt disallow rule; use the same alt text on both versions, and avoid image URLs that change on every page load.

The rule that catches modern front ends is about interaction: Google won't load content that requires user interactions, such as swiping, clicking or typing, to load. An accordion whose text is already in the HTML is fine. A "Load more" button that fetches the rest of an article, or reviews that are requested only when someone taps a tab, are invisible to the crawler.

With responsive design most of this is automatic, because there is only one HTML document. It breaks when the phone layout is built differently: a component that renders a shorter version on small screens, a section fetched on tap, or text that appears only after a script runs on scroll. The way to see what Google actually received is the live test in URL Inspection, covered next. The crawling side in general is explained in how the Google search engine works, and the full audit of crawling, rendering and indexing in technical SEO.

How to test a mobile site now that the Mobile-Friendly Test is gone

Older guides tell you to paste your URL into Google's Mobile-Friendly Test. That tool no longer exists. In an April 19, 2023 post, Google announced that from December 1, 2023 it would retire Search Console's Mobile Usability report, the Mobile-Friendly Test tool and the Mobile-Friendly Test API. It stressed that mobile usability still matters, and pointed to Lighthouse as one of the robust tools for evaluating it that had emerged since the report launched. The checks now live in general tools:

Run Lighthouse and device mode while you build

Lighthouse has its own panel in Chrome DevTools: open the page, choose the Lighthouse tab and click Analyze page load. Run it on each key template, not only the home page, and add Lighthouse CI to your build so a regression fails before it ships.

Device mode simulates a mobile viewport, touch input and a slower CPU and network. Drag the viewport down to 320 pixels to check reflow, and show the media query bars to see where your breakpoints fall. The DevTools documentation calls device mode a first-order approximation: your code still runs on a laptop, and some things about phones, such as their very different CPU architecture, it can never simulate.

Check what Google sees with URL Inspection

In Search Console, open the URL Inspection tool for a page, click Test live URL, then View tested page. The screenshot of the rendered page is available only in the live test; next to it are the HTML, the HTTP headers, JavaScript console output and the resources that loaded. The rendered page is how Google sees your page, so confirm the screenshot and the HTML contain all primary content, the same headings and the structured data you expect.

Read field data in PageSpeed Insights

PageSpeed Insights reports mobile and desktop separately. Its field data comes from the Chrome UX Report and covers real visits over the previous 28 days; a new page or one with little traffic may not have enough data, in which case it falls back to the whole origin. Its lab section is a Lighthouse run that simulates a mid-tier phone on a mobile network. When field data and lab data disagree, trust the field data for the verdict and use the lab data to find the cause.

Finish on real phones

Emulation misses what real hardware does. On Android, turn on USB debugging in Developer Options, connect the phone and open chrome://inspect#devices in desktop Chrome to inspect the page running on the phone. On an iPhone or iPad, turn on Web Inspector under Settings, Apps, Safari, Advanced, connect the device to a Mac and pick the page from Safari's Develop menu, as Apple describes. Test at least once on mobile data rather than office Wi-Fi.

A mobile optimization checklist

Run through this list for each key template, and again after any redesign:

1. The <head> has <meta name="viewport" content="width=device-width, initial-scale=1">, with no maximum-scale or user-scalable=no.
2. At 320 CSS pixels wide, nothing scrolls sideways except content that needs two dimensions, such as a data table, inside its own box.
3. Body text is at the browser default size or larger, set in rem, and pinch zoom works.
4. Every button, menu link and form control is at least 24 by 24 CSS pixels, or spaced so its 24-pixel circle touches nothing else; the main actions are 44 by 44.
5. Nothing important opens only on hover.
6. Every form field has a visible label, the right type or inputmode, and an autocomplete value.
7. Every image has srcset, sizes, width and height, and the main image at the top is not lazy-loaded.
8. No pop-up covers the page on arrival; required notices sit in a banner or overlay the content.
9. PageSpeed Insights shows LCP, INP and CLS as good for mobile, or you know why there is not enough field data yet.
10. The URL Inspection live test shows all primary content, and the tested HTML carries the same headings, structured data, title and meta description as the desktop version.
11. The key journeys (find a service, read an article, send the contact form) work on a real Android phone and a real iPhone on mobile data.