What does mobile-first indexing mean now? Two end dates

Mobile-first indexing means Google builds its index, the database it ranks pages from, out of the version of each page a phone receives. It finished in two steps. On October 31, 2023, Google said the move was complete, and kept reading what it called “a very small set of sites” that failed on phones with its old desktop crawler.¹ That fallback ended on July 5, 2024, 248 days later, and a page a phone cannot load stopped being indexable at all.² Any check that still counts on a desktop crawler to pick up what a mobile template drops rests on a safety net that is gone.

Google finished mobile-first indexing on October 31, 2023, and kept a desktop crawler for holdout sites until July 5, 2024.

What does mobile-first indexing mean now?

Mobile-first indexing means Google indexes and ranks the mobile version of a site’s content, fetched by Googlebot Smartphone, the program that requests pages the way a phone would. Google’s best-practices page says it uses “the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking.”⁸ Since July 5, 2024, that is true of every site Google indexes.

A crawler is the program a search engine uses to fetch pages. Googlebot is the shared name for two of Google’s, Googlebot Smartphone and Googlebot Desktop.⁶ Each one identifies itself with a user agent, a line of text sent with every request that names the program asking.

Google never built a second index for phones. When the migration began, it said “We do not have a ‘mobile-first index’ that’s separate from our main index.”⁴

Being moved to mobile-first indexing carried no ranking boost either. The same post said the change was “about how we gather content, not about how content is ranked.”⁴

When did mobile-first indexing finish?

Google announced mobile-first indexing complete on October 31, 2023, in a Search Central blog post titled “Mobile-first indexing has landed.” The post said “the trek to Mobile First Indexing is now complete,” and it carved out one exception in the same breath. Sites that did not work on phones at all would still be crawled with “our legacy desktop Googlebot crawler for the time being.”¹

Google named three failures behind that exception. The page showed errors to every mobile visitor, or every mobile page redirected to the homepage. The third was a mobile version blocked in robots.txt, the file at a site’s root that tells crawlers which paths to skip, whereas the desktop version was allowed. Google called these “issues that Google can’t resolve” and said it would re-check the list “a few times a year.”¹

The same post removed a signal site owners had used to track the move. Google turned off the setting in Search Console, its free reporting tool for site owners, that showed which crawler indexed a site. Its reasoning was that “all websites that work on mobile devices are now being primarily crawled with our mobile crawler.”¹

What changed on July 5, 2024?

On July 5, 2024, Google stopped using desktop Googlebot to index the last sites that failed on phones. Google announced the date on June 3, 2024, in a post titled “Mobile-indexing-vLast-final-final.doc”: “After July 5, 2024, we’ll crawl and index these sites with only Googlebot Smartphone.”² For sites a phone could not load, that date ended their presence in the index.

The next sentence of that post carries the consequence. “If your site’s content is not accessible at all with a mobile device, it will no longer be indexable.”² Between October 2023 and July 2024 such a site still had a desktop crawler reading it, and after July 5 nothing did.

The practical date is the second one. A mobile template that errors, redirects everything home, or sits behind a robots.txt block no longer has a fallback. A mobile page that loads but carries less content is a milder case. Google’s best-practices page warns that its owner can “expect some traffic loss,” since “indexing on your site comes from the mobile site.”⁸

The following timeline places Google’s four dated statements on one axis. The first two are both dates Google gives for the start. The last two are the two ends, 248 days apart.

When did mobile-first indexing start, 2016 or 2018?

Google dates the start of mobile-first indexing two ways. On November 4, 2016, Google said it had “begun experiments to make our index mobile-first.”³ On March 26, 2018, it announced that “after a year and a half of careful experimentation and testing, we’ve started migrating sites.”⁴ Google’s own 2023 post then gives the earlier date: “in 2016, we started mobile-first crawling and indexing.”¹

A third year circulates too. A December 18, 2017 post is often cited as the start, and it was a readiness guide. It recapped that Google had announced “almost a year ago” that it was “experimenting with mobile-first indexing” and gave tips for getting ready.¹⁰

The end date slipped as well. In November 2021, Google wrote that “we thought that we could complete the move to mobile-first indexing by March 2021,” and that it had no “specific final date.”⁵ Nearly seven years from first experiment to completion, three candidate start years and a missed deadline explain much of the blur. My read: most people remember one event called “mobile-first indexing happened,” and the date they attach to it depends on which post they read.

Does desktop Googlebot still crawl websites?

Desktop Googlebot still crawls websites after July 5, 2024, for jobs other than indexing sites that fail on phones. Google’s 2024 post said “You may still find Googlebot Desktop in your server logs and reporting,” naming product listings and Google for Jobs, its job-search feature, among its uses.² Google’s Googlebot page expects “a minority using the desktop crawler.”⁶

This site’s own log shows that minority. I keep a daily log of crawler requests from Cloudflare, the network that serves this site and records its traffic, because a static site has no server log of its own.

Over 68 days, from July 16 to September 21, 2026, I counted the requests carrying each Googlebot user agent Google lists.⁹ The smartphone string made 613 requests. Of the two, desktop made up about a quarter, with 217 requests spread across 28 of the 68 days.⁷

A third string makes the raw total misleading. Google lists Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) as a desktop user agent it uses “Rarely.”⁷ Here it was the most common Googlebot string of all, with 3,918 requests.

A path breakdown for September 20 to 22 shows it mostly fetching robots.txt and the sitemap, the file listing every page a site wants crawled. It also made 36 requests for /v2/.env, a configuration file that on some servers holds passwords, which is what vulnerability scanners go looking for.⁹

No Google crawler has a reason to request that file, so some of this traffic only borrows the name. A user agent claiming to be Googlebot proves nothing by itself covers why a user agent is a claim. None of my counts is verified. My Cloudflare plan does not expose the network each request came from, so these are counts of the name, not of Google’s visits.

The name also cannot be split in robots.txt. Google’s Googlebot page says both crawlers “obey the same product token (user agent token) in robots.txt, and so you cannot selectively target either Googlebot Smartphone or Googlebot Desktop using robots.txt.”⁶ How far each Google crawler name reaches is its own question, covered in Google ignores meta name=“googlebot-image”. For this piece, the consequence is narrower. A desktop Googlebot line in your log is no evidence that Google indexes your desktop pages.

How do you check a site for differences between mobile and desktop?

The quickest check for a mobile parity gap, a difference between what a phone and a desktop receive, is to request the same page as each crawler and compare the two responses. Google describes three ways to build for phones. Responsive design sends the same HTML to every device. Dynamic serving sends different HTML at the same address, and separate URLs send each device to its own address.⁸

Only the last two can drift apart. Of its own parity checklist, Google says “The contents of this guide only apply to dynamic serving and separate URL configurations.”⁸ Dynamic serving relies on the Vary header, a line in the response telling caches that the page changes with the device asking.

I ran the check on this site on September 22, 2026, against one article page. Requests as Googlebot Smartphone, as Googlebot Desktop and as a desktop Chrome browser each returned status 200, the code for a successful request. Each response I got back was exactly 51,536 bytes.

A line-by-line comparison of the three found one differing line, a per-request token in Cloudflare’s bot-check script with no device logic in it. None of the three responses carried a Vary header. That is what a site with no device switching looks like from the outside.

To run the same check on your own site, follow these steps.

1. Pick one URL from each template that matters, such as a product page, a category page and an article, since a homepage check says nothing about the others.
2. Fetch each URL twice with a command-line tool such as curl, once with the Googlebot Smartphone user agent and once with the Googlebot Desktop one. Google publishes both strings.⁷
3. Compare the two files. Ignore lines that change on every request, such as security tokens, and look for missing text, headings, links or structured data, the code that labels a page’s content for search engines.
4. Check the response headers for Vary: User-Agent. If it is there, the site serves by device, and Google’s list of what must match applies, from robots meta tags to image alt text.⁸
5. Fix any gap on the mobile side. Google indexes what the smartphone crawler receives.

This check reads raw HTML only. Content a script adds after the page loads, differently per device, will not show up in it. A script that changes the page by device produces the same false confidence that Google’s crawler split documents for structured data, where “desktop-only validation produces false confidence.”