Mobile-first indexing: what it means for your site

What it means

The Almanac states that Google completed its migration to mobile-first indexing in 2023, meaning the mobile version of a site now determines how it is treated in search. Whatever the exact mechanics, the practical lesson is simple: the page a phone receives is the one that matters. If it is missing text, links or tags that the desktop page has, those things may as well not exist.

The Almanac's data shows that the web has moved to one page for all devices. Only about 1% of pages sent a Vary: User-Agent header, which was the old signal of a site serving different HTML to phones. The viewport tag is on 93.1% of desktop pages and 95.2% of mobile pages. The Almanac reads this as sites using the same responsive design for all devices, instead of keeping separate mobile and desktop versions.

Separate mobile addresses, such as an m. subdomain, cost speed as well. The Lighthouse documentation on redirects advises using responsive design instead of redirecting phones to a mobile version. See redirects and status codes.

The viewport tag

Without a viewport tag, MDN explains, some mobile browsers draw the page in a virtual window wider than the screen, then shrink the result to fit. Visitors must zoom and pan. The recommended setting sets the viewport to match the device:

<meta name="viewport" content="width=device-width">

MDN adds that initial-scale=1 is usually unnecessary. Without it the browser chooses the starting zoom and may zoom out if content overflows. Add it if overflowing content causes unwanted shrinking, though you should usually avoid horizontal overflow in the first place.

Do not block zoom. MDN warns that user-scalable=no prevents people with low vision from reading the page, and that WCAG requires at least 2× scaling, with 5× as a best practice. Lighthouse 13.5 treats this as critical: its meta viewport audit is in the accessibility category with a weight of 10.

The viewport also affects speed. Lighthouse's Optimize viewport for mobile insight says tap interactions may be delayed by up to 300 ms when the viewport is not optimized for mobile. It carries a weight of zero, so it does not change the score, but the delay is real for visitors.

The same content on both

With one responsive page, a phone receives the same HTML as a computer, and CSS changes the layout. Check these:

• Text. The main text should be in the phone's HTML. The Almanac found that median home page word counts on mobile and desktop were close: 378 words on mobile and 413 on desktop. Collapsed accordions and tabs keep their text in the page, and that is fine.
• Tags. The title, meta description, canonical link, robots rules and language links should match. See canonical tags and hreflang.
• Structured data. Keep it on the phone version. See structured data basics.
• Links. If the phone menu hides links that the desktop menu shows, crawlers may find fewer pages. See internal linking.
• Images and alt text. A phone can have smaller files, but the same images and the same alt text. See responsive images.
• Content loaded by script. If a phone loads content only after a tap or a scroll, a crawler may not see it. See JavaScript and SEO.

You can check whether a site sends different HTML to phones by asking for the page twice with different user agents:

M="Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Mobile Safari/537.36"
D="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36"
curl -s -A "$M" https://example.com/ | wc -c
curl -s -A "$D" https://example.com/ | wc -c
curl -sI -A "$M" https://example.com/ | grep -i '^vary'

I ran these against a small test server that deliberately sent different HTML to phones. The byte counts differed (46 and 107), the title differed, and the Vary: User-Agent header showed. A responsive site gives equal counts. Small differences, such as a changing token, are normal, so compare the titles and the main text, not only the sizes.

Tapping and reading

On a phone, fingers replace the mouse. Lighthouse's target size audit, in the accessibility category with a weight of 7, says touch targets with enough size and spacing help people who have difficulty with small controls. MDN's summary of WCAG 2.2 gives the numbers: a target should be at least 24 by 24 CSS pixels, with an exception when enough space surrounds smaller ones, and 44 CSS pixels for the stricter AAA level.

Text size matters too. Do not shrink body text to make a desktop layout fit. Zoom must keep working, and MDN's viewport warning above applies.

Speed on a phone

Phones are slower than the computers on which sites are built, and their connections are less steady. The Almanac found that around 60% of pages delivered a good overall Core Web Vitals experience on desktop in 2025, against just over 50% on mobile, and that Largest Contentful Paint was the weakest metric, near 55 to 60% on mobile. Lighthouse's own mobile test runs on an emulated phone with a throttled connection. See how to improve Core Web Vitals.

Test on the real thing as well. See testing on real phones.

How to check

1. Look at your pages on a phone, or in DevTools device mode. Does anything overflow, shrink or hide?
2. View the source for name="viewport", and make sure there is no user-scalable=no.
3. Run the user-agent comparison above on three pages.
4. Run Lighthouse in mobile mode and read the accessibility results for the viewport and target size.
5. Open the menu on a phone and confirm it holds the same links as on a computer.
6. Check Core Web Vitals for the phone, in field data where it exists. See lab and field data.

Mistakes to avoid

• No viewport tag.
• Zoom disabled.
• A separate mobile site with less content.
• Menu links that exist only on desktop.
• Tiny buttons close together.
• Content that loads only after a tap.
• A phone version missing structured data or tags.
• Judging speed on a fast office computer.

Check your own page

Run the free audit, then open your home page on a phone and tap through the menu. Compare the titles and main text you get from the two curl commands.

Sources

• SEO chapter, Web Almanac 2025: mobile-first indexing, viewport use, the Vary header, home page word counts and Core Web Vitals pass rates.
• MDN: the viewport meta tag and Understanding WCAG: Operable.
• The Lighthouse 13.5 default configuration and audit texts: meta viewport, target size and the viewport insight. The Lighthouse documentation on avoiding multiple page redirects.