Mobile-first indexing is the system Google uses to index and rank a page based on its mobile version, the one fetched by its smartphone crawler. It applies to desktop searchers too: what Google reads is the page as a phone sees it.
Two of the nine guides on Google UK's first page for this topic were written in 2018 and March 2021, before the switch was finished, and the top result still says that Google prioritises mobile sites "in their indexing and ranking". The transition actually ended between October 2023 and July 2024. To see what's left to check today we did two things: we counted which Googlebot crawls our own site, and we downloaded 52 pages ranking on page one of Google Italy, first as a smartphone and then as a desktop, comparing the two versions field by field.
What mobile-first indexing means
Mobile-first indexing means that, for every URL, Google downloads and analyses the version a smartphone receives. The text, links, structured data, meta tags and images that go into the index are the ones in that version. The Google Search Central documentation puts it in one line: Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking.
There's no separate index for phones. There is one index, and what changes is the source that feeds it. If a sentence appears only in the desktop version of a page, for Google that sentence doesn't exist, and the page won't rank for searches containing it, even when the user searches from a PC.
It's an indexing mechanism, downstream of crawling. It decides which version gets read; it doesn't reward pages that look better on a phone. For how the two stages fit together with ranking, see our guide to how search engines work.
The transition is over: the dates
It took Google almost eight years to move the whole web onto the mobile crawler. The milestones, all announced on the Search Central blog:
| When | What happened |
|---|---|
| March 2018 | Rollout begins on sites that are ready |
| May 2019 | Announcement: from 1 July 2019 new domains are mobile-first by default |
| March 2020 | Google announces the switch for the whole web; the deadline is then pushed back several times |
| 31 October 2023 | Transition declared complete; desktop crawling is reduced and sites that don't work on mobile stay on the desktop crawler for now |
| 5 July 2024 | The last sites move to Googlebot Smartphone too. A site whose content isn't accessible on mobile is no longer indexable |
The June 2024 announcement is signed by John Mueller and includes a detail most guides barely mention: Googlebot Desktop isn't going away. Google writes that you may still see it in your server logs, because it's used, among other Search features, for product listings and Google for Jobs.
What we see in our logs: 91% is Googlebot Smartphone
To see how much the desktop crawler still counts, we read the access log of visilay.com from 31 August to 30 September 2026. We kept only requests with a Googlebot user agent coming from 66.249.x.x addresses, the network Google crawls from, and discarded the other 148: a user agent can be faked in one line, and some of that traffic was almost certainly bots pretending to be Google.
| Crawler | Requests | Share of main crawler |
|---|---|---|
| Googlebot Smartphone | 1,157 | 91.4% |
| Googlebot Desktop | 109 | 8.6% |
| Googlebot-Image | 177 | not counted |
| Other Google user agents | 9 | not counted |
| Total from 66.249.x.x | 1,452 |
The most useful figure is where the desktop crawler goes. Of its 109 requests, 45 were for XML sitemaps and 7 for robots.txt: almost half (48%). Another 24 were the home page. The remaining 33 were spread over single pages, nearly all visited just once in the month, against more than a thousand smartphone requests. The content that ends up in the index is read by the phone.
If you want to run the same count on your site, the Crawl stats report in Google Search Console splits requests by Googlebot type. The server log is more precise, because it also shows the URLs. To tell real bots from fake ones, follow the steps in our guide to web crawlers.
In the UK four in ten page views still come from a desktop
There's an asymmetry here that explains a lot of problems. According to Statcounter, in September 2026 53.56% of UK page views came from smartphones, 41.78% from desktops and 4.66% from tablets. In the United States, in the same month, the split was almost even: 49.1% mobile and 48.47% desktop (Statcounter, United States). Guides that open with "most traffic is mobile" are only half true on either side of the Atlantic.
And Google dominates search on phones: 98.03% of mobile searches in the UK go through it (Statcounter, September 2026). So four in ten visitors to a UK site look at it on a monitor, but the engine that brings in almost all organic visits reads it as a smartphone. And whoever decides what the site should look like usually signs it off on a laptop.
Our test: 49 Italian pages read as a smartphone and as a desktop
We ran this test in Italy, where most of our clients are. We took the organic results and related sites shown by Google.it for four Italian commercial searches: "impresa di pulizie milano" (cleaning company Milan), "commercialista torino" (accountant Turin), "serramenti in pvc prezzi" (uPVC windows prices) and "macchine caffè professionali" (commercial coffee machines). That gave us 52 pages, from small businesses and professional practices to directories and large e-commerce sites such as Leroy Merlin, Tecnomat and Cimbali. On 3 October 2026 we downloaded each one twice, with the user agent of Chrome on Android and with that of Chrome on Windows, and compared the HTML we received. Three pages didn't respond (one domain didn't resolve, one 404, one 500 error), which leaves 49.
| What we compared | Pages with the same version on mobile and desktop |
|---|---|
| Redirect to a separate mobile URL (m.) | 49 of 49: no site uses separate URLs |
| Title | 49 of 49 |
| Meta description | 49 of 49 |
| Meta robots and canonical | 49 of 49 |
| Structured data (number of blocks and schema.org types) | 49 of 49 |
| Word count of the page text | 40 of 49 |
| Number of links | 43 of 49 |
| Difference above 5% in words or links | 5 pages of 49 (10%) |
| Pages declaring Vary: User-Agent | 6 of 49 |
| Pages with no meta viewport in either version | 1 of 49 |
| Pages with no JSON-LD structured data at all | 10 of 49 (20%) |
The news is that the problems people wrote about in 2018 are gone. No m. sites, no differing titles, no mobile-only noindex, no structured data disappearing on the phone. Responsive design has done the job that years of articles asked people to do by hand.
The differences are in the body of the page, and where they exist they go both ways:
- the listing pages of Pagine Gialle and Pagine Bianche, the Italian Yellow Pages and White Pages, send smartphones less text (9.8% and 5.9% fewer words) and fewer images (6 against 8, 16 against 35);
- a Milan cleaning company does the opposite: its mobile version has 33% more words, probably blocks designed for the phone that are left out on desktop;
- a Turin accountancy practice serves smartphones a different template, with the viewport fixed at 320 pixels and 22.7% more links;
- the website of a professional body has no meta viewport in either version: on a phone it looks like a shrunken desktop page.
Two limits, because the test should be read for what it is. We compared the HTML the server delivers, without running JavaScript: some of the content missing on the listing pages might arrive after rendering. And we used Chrome user agents, not Googlebot's, because many firewalls block anything that claims to be Googlebot without coming from Google's addresses. A site that recognises the crawler and serves it a dedicated version is invisible to us.
What must match between mobile and desktop
Google's best practices ask for the mobile version to be equivalent to the desktop one on these points:
- Main content. If the mobile version has less content, Google warns you to expect a loss of traffic. Text can be arranged in tabs and accordions to save space, as long as it stays in the HTML.
- Title and meta description the same in both versions. Our guide to meta tags explains which ones Google actually reads.
- Meta robots. A noindex or nofollow present only on mobile applies to the whole page.
- Structured data present in both versions, with priority for Breadcrumb, Product and VideoObject. Details in our guide to schema markup.
- Images of the same quality, with stable URLs and the same alt text.
- Lazy loading. Google doesn't load content that needs a user action such as scrolling, clicking or typing. The main text shouldn't load on tap.
- Resources and robots.txt. CSS, JavaScript and images needed for mobile rendering mustn't be blocked, and the rules must be the same for both versions.
In its troubleshooting section Google lists sixteen typical errors, from "missing structured data" to "mobile page is blocked by robots.txt". At least five apply only to sites with separate mobile URLs (mobile page error, fragment # in the URL, several desktop pages pointing to the same mobile page, redirect to the mobile home page, mobile server capacity): a setup that nobody in our sample uses any more.
Responsive, dynamic serving or separate URLs
There are three possible setups. With responsive design the URL and HTML are the same for everyone and only the layout changes through CSS: this is the one Google recommends. With dynamic serving the URL is the same but the server delivers different HTML depending on the device, and it should say so with the Vary: User-Agent header. With separate URLs there's an m.domain.co.uk site linked to the desktop one with rel="alternate" and canonical.
Dynamic serving is declining worldwide too. The HTTP Archive Web Almanac 2024, which analyses millions of sites, found the Vary header on 1% of desktop pages and 2% of mobile pages, against 12% and 13% in 2022. In our sample no site uses separate URLs. Six pages out of 49 send Vary: User-Agent, but in only three did the HTML we received actually change; on the other hand the Turin practice with the 320-pixel viewport switches template without declaring it. Vary: User-Agent is also the header that shows up when a caching plugin keeps separate copies for phone and computer. That's where the risk lies: the cache gets cleared, one of the two copies regenerates with a module missing, and the site Google reads is no longer the one the marketing team checks on a laptop.
How to check your site
The Mobile-Friendly Test and the Mobile Usability report in Search Console no longer exist. This is how you check today:
- URL Inspection in Search Console. The live test shows the HTML Googlebot Smartphone received and a screenshot of the rendered page. Search the HTML for a sentence from the main text and for your structured data.
- Crawl stats. Under Settings, the report by Googlebot type tells you whether the smartphone crawler really is the main one, as with our 91.4%.
- Two crawls with a crawler tool. Screaming Frog, Sitebulb or Ahrefs' Site Audit let you crawl the site with a smartphone user agent and then a desktop one. Compare word count, internal links, title and structured data for each URL, as we did in the test.
- Lighthouse in Chrome DevTools for mobile performance and to check viewport, font size and button size. This is where Core Web Vitals come in, which Google also measures in the field.
If the versions don't match, the priority is to bring all the main content into the mobile version. This check is one of the first steps in the SEO audit we run before an SEO consultancy project, along with the rest of technical SEO.
Mobile-first indexing, mobile-friendly and ranking are different things
A site can be indexed by the mobile crawler without any trouble and still be awkward to use on a phone: tiny text, buttons crammed together, pop-ups covering the page. Mobile-first indexing is about what Google reads. The mobile experience is about how the page is used, and it feeds into ranking through page experience signals, starting with speed measured on phones.
That's why "my site is responsive, so I'm fine" is true for indexing and says nothing about ranking. A common reason a site doesn't show up on Google for a specific search is text that's there on desktop and only loads after a tap on the phone. Real user experience needs a separate analysis.
Frequently asked questions
No. It decides which version of the page Google reads, the smartphone one, and gives no points to pages that look better on a phone. The mobile experience affects ranking through other signals, such as Core Web Vitals measured on mobile devices.
Yes, if the content isn't accessible from a mobile device. Since 5 July 2024 Google has crawled every site with Googlebot Smartphone and has said that a site whose content isn't accessible on mobile is no longer indexable. A site that looks bad on a phone but can still be read stays in the index.
Yes, but not much. Google says it still uses it for some features such as product listings and Google for Jobs. On our site, in September 2026, it made up 8.6% of the main crawler's requests, and almost half of those were for sitemaps and robots.txt.
Yes, if it's in the HTML when the page loads. Google accepts that on mobile text is gathered into tabs or accordions to save space. It doesn't read content that only loads after a click, a scroll or typing.
No. Google recommends responsive design, and separate URLs need consistent rel=alternate, canonical and redirects for every page. In our test of 49 Italian pages ranking on page one, none used an m. site.
In the Crawl stats report in Search Console, which splits requests by Googlebot type, or in your server logs by filtering Googlebot user agents coming from Google's addresses. URL Inspection shows the HTML Googlebot Smartphone received for a page.
Something the industry rarely says
In 2026 the mobile-first indexing problem is mostly about who looks at the site. In the UK four in ten page views come from a monitor, and the people who sign off copy and layouts nearly always work from one. Google, on the other hand, at least on our site, uses the desktop crawler almost only for sitemaps and the home page. The result is that the version of the site discussed in meetings is the one that matters least for indexing.
A practical rule: every change to an important page gets approved by looking at it on a phone first, and once a month the two versions are compared with a crawler. It takes an hour. In our test titles, meta tags and structured data matched everywhere; the exceptions were nearly all in the body of the page, which is exactly the part people approving from a laptop take for granted.
