Do your desktop pages look great, but your mobile pages are thinner, slower to show content or missing markup? Then Google is judging you on the weaker version. Mobile-first indexing means Google crawls, indexes and ranks your site using the mobile version of each page. That is true for searches on every device.
The switch is finished. What matters now is whether your mobile pages carry everything you want Google to see, and whether you can prove it. In this guide I cover both.
What Mobile-First Indexing Really Means
Google uses one crawler for almost all indexing: Googlebot Smartphone. It asks for your pages the way a phone would. It renders (builds) what it gets, and uses that content to decide what the page is about and where it ranks.
There is no separate “mobile index” and “desktop index”. There is one index, built from mobile content. A desktop searcher sees results ranked on what Googlebot found on your mobile pages.
That leads to the most important rule: anything that only exists on your desktop version may as well not exist for Google. That means text, links, structured data, image alt text, even the title tag.
What It Is Not
People often mix up mobile-first indexing with two other things:
- Mobile-friendliness. A page can be awkward to use on a phone and still be indexed. Mobile-first indexing is about which version of the content Google reads. It is not a pass/fail usability score.
- A ranking boost for mobile sites. Being indexed from mobile does not lift you above competitors. It just means your mobile content is the content that competes.
Google retired its Mobile Usability report and the stand-alone Mobile-Friendly Test in December 2023. If an old checklist tells you to “pass the mobile-friendly test”, that tool is gone. The checks in this guide replace it.
Is the Switch to Mobile-First Indexing Complete?
Yes. Google started testing mobile-first indexing in late 2016 and moved sites over in batches for years. At the end of October 2023, it said on the Search Central blog that the move was complete. The only exception was a very small set of sites that did not work on mobile devices at all.
Google dealt with those remaining sites in 2024. In June 2024, it said that after 5 July 2024 it would crawl and index them with Googlebot Smartphone only. It also said a site whose content could not be reached at all on a mobile device would no longer be indexable. You can read that statement in Google’s final mobile indexing announcement.
Two practical points follow:
- You don’t need to wait for a notice. Every site is already on mobile-first indexing.
- A few Googlebot Desktop requests in your server logs don’t mean you were left behind. Google has said the desktop crawler is still used now and then for specific purposes. But it is not what builds your entry in the index.
Search Console used to show an “Indexing crawler” line in Settings. Google said it would remove that once the move finished, because every site is now crawled for indexing as a smartphone.
Which Site Setup You Have, and Why It Matters
Google recognises three ways to serve mobile users. Your level of risk depends a lot on which one you use.
| Setup | How it works | Mobile-first risk |
|---|---|---|
| Responsive design | Same URL and same HTML for all devices; CSS adapts the layout | Low. Content is identical by default, unless scripts or CSS hide or drop things on small screens |
| Dynamic serving | Same URL, but the server sends different HTML depending on the user agent | Medium to high. Two HTML templates can drift apart |
| Separate URLs (m-dot) | Mobile pages live on a different host, such as m.example.com |
High. Two sets of URLs, templates, redirects and annotations to keep in sync |
Google recommends responsive design because it is the easiest setup to build and maintain. I agree. If you are planning a rebuild and still run an m-dot site, moving to responsive removes most of the problems below in one go.
Keep Content, Structured Data and Metadata the Same on Mobile
Google’s mobile-first indexing best practices come down to one idea. The mobile page should be equal to the desktop page. Here is what that means in practice.
Main Content
The mobile version should have the same main content as desktop. A different design is fine. Less content is the problem.
A common example is a product page. The desktop version shows the full specification table. The mobile template shows only a summary to “keep it clean”. With mobile-first indexing, those specs have been removed from Google’s view of the page.
If you want a shorter mobile layout, fold content into tabs or accordions instead of deleting it. Google reads content in the HTML even when it is visually folded away.
Headings
Use the same clear, meaningful headings on both versions. Mobile templates sometimes swap useful H2s for short labels like “Details” or “More”. That loses context Google uses to understand each section.
Internal Links and Navigation
This is the gap most audits miss, and it is the first thing I check. Many mobile menus show only top-level categories, and footers get trimmed. If links to important pages only exist in the desktop mega-menu or sidebar, Googlebot Smartphone never sees them.
The result is weaker internal linking. On large sites, it also means Google finds deep pages more slowly. Check that every link you rely on for crawling shows up somewhere in the mobile HTML.
Structured Data
Put the same structured data on mobile as on desktop. If your mobile template leaves out Product, Breadcrumb or VideoObject markup, those rich result features can disappear. That can happen even though the desktop HTML is correct.
On separate mobile URLs, update the URLs inside the markup to point to the mobile URLs. For a refresher on which markup still earns visible features, see our guide to FAQ and HowTo schema in Google Search.
Title and Meta Description
Make the title and meta description equal on both versions. Mobile templates sometimes use a shorter title or a generic description. Since Google reads the mobile version, that weaker title becomes the one it works from. Our guide to writing title tags Google keeps covers how to get it right from the start.
Robots Meta Tags
Use the same robots meta tags on mobile and desktop. A noindex or nofollow that slips into the mobile template is one of the most damaging mistakes you can make. That is because the mobile version is the one Google indexes. I’ve seen this kind of slip happen after theme changes more often than people expect.
The same goes for robots.txt. Don’t block CSS, JavaScript or image paths that only the mobile version uses. If you do, Google can’t render the page properly.
Lazy-Loading: What Google Can and Can’t Trigger
Lazy-loading (loading parts of a page only when they are needed) is fine in principle. The problem is content that only loads after a user does something.
Googlebot does not click, swipe, type or tap. Say your mobile page loads reviews only when someone taps “Show reviews”. Or it loads the next set of products only after a swipe. Then Google will not see that content.
Safe patterns:
- Native lazy-loading for images lower down the page, using
loading="lazy". - Content that loads when it comes into view, as long as it is triggered by being visible, not by an action.
- Paginated lists with real, crawlable URLs for each page.
Risky patterns:
- Main text loaded only on a button tap.
- Infinite scroll with no paginated URLs behind it.
- Hero or product images that only load after a gesture.
My rule of thumb: don’t lazy-load the main image or the main text of a page. Keep lazy-loading for supporting content further down.
Images and Videos on Mobile Pages
Images and videos are where mobile templates quietly differ. Often it is because a mobile theme uses different parts.
Images
- Quality: don’t serve tiny or heavily compressed images to mobile just to save bytes. Low-resolution images are less useful in image search.
- Stable URLs: avoid image URLs that change every time the page loads, such as URLs with random cache-busting parameters.
- Same alt text and context: keep alt text, captions, file names and nearby text equal across versions.
- Same image URLs where possible: if your mobile site uses different image URLs from desktop, expect a short dip in image search traffic while the new URLs build history.
- Supported formats: use formats and tags Google supports, and keep important images in standard
<img>elements.
Videos
- Use a supported video format and a standard tag such as
<video>,<embed>or<object>. - Keep video URLs stable. Don’t create new ones on each load.
- Use the same VideoObject structured data on both versions.
- Put the video where a mobile visitor can find it without scrolling through screens of other content. A video pushed to the very bottom of a long mobile page is harder for users and Google to treat as the main video.
Separate M-Dot Sites: The Problems to Fix First
If you run m.example.com next to www.example.com, you have twice as many places for mistakes. These are the ones that cause the biggest losses.
Many Desktop Pages Redirecting to the Mobile Home Page
When there is no mobile version of a page, some setups send phone users (and Googlebot Smartphone) to the mobile home page. Then Google can’t see those pages at all, and they can drop out of the index. Every desktop page needs a matching mobile page. If not, the desktop page should be served to phones as it is.
Mismatched Status Codes
Say a desktop URL returns 200 (OK) and its mobile twin returns 404 or a soft error page. Google sees an error. Error pages should behave the same on both hosts. Our guide to HTTP status codes and SEO explains what each response tells Google.
Fragment URLs
Mobile URLs that rely on a hash, such as m.example.com/#/product/123, generally can’t be indexed as separate pages. Each mobile page needs its own path-based URL.
Canonical and Alternate Tags
The desktop URL stays canonical (the main version). The two versions should point at each other like this:
<!-- On the desktop page: www.example.com/page -->
<link rel="alternate" media="only screen and (max-width: 640px)"
href="https://m.example.com/page">
<!-- On the mobile page: m.example.com/page -->
<link rel="canonical" href="https://www.example.com/page">Hreflang on International M-Dot Sites
Link mobile URLs to mobile URLs, and desktop URLs to desktop URLs. Mixing them breaks the set. An example would be a mobile English page pointing at a desktop French page.
Server Capacity and Search Console
- Make sure the mobile host can handle the crawl rate Googlebot now sends to it. Mobile servers set up years ago for light traffic can struggle.
- Verify both hosts in Search Console, so you see crawl, indexing and enhancement data for each.
- Keep robots.txt rules the same on both hosts.
Dynamic Serving Problems
Dynamic serving keeps one URL but sends different HTML based on the visitor’s user agent (the label a browser or bot sends to say what it is). It avoids the canonical and redirect problems of m-dot sites. But it has its own risks.
- Send the
Vary: User-AgentHTTP header. It tells caches and crawlers that the response changes by device. Then a desktop version is not cached and served to phones, or the other way round. - Watch user-agent detection. Your detection code might not see Googlebot Smartphone as a mobile device. Or it might treat it as a bot and serve a stripped-down page. Either way, Google indexes the wrong thing.
- Audit both templates together. Dynamic serving often means two templates looked after by different people. Content, links, structured data and robots tags drift apart over time.
All the content, metadata, structured data and image rules above apply to dynamic serving. The m-dot rules about canonicals, alternates and fragments don’t, because there is only one URL.
How to Check Your Site With URL Inspection
The URL Inspection tool in Search Console is the most direct way to see your page the way Google does. Here is the process I use on any site where I think the mobile template is holding pages back.
- Inspect a key URL. Paste an important page, such as a top category or product page, into the search bar at the top of Search Console.
- Confirm the crawler. Open the Page indexing details and look at the Crawl section. “Crawled as” should show Googlebot smartphone. That confirms you are looking at the mobile version Google indexed.
- Run a live test. Click “Test live URL”, then “View tested page”. Check the screenshot to see what Googlebot Smartphone rendered. Open the HTML tab to see the rendered code.
- Compare with desktop. Search the rendered HTML for your main content, key internal links, structured data, the title and the robots meta tag. Anything you see on desktop but can’t find here is missing for Google.
- Check resources and errors. Under “More info”, look for page resources that could not load, such as blocked scripts or images. Also look for JavaScript console errors.
- Check enhancements. Review the structured data items found in the inspection result. Compare them with what your desktop page has.
- Fix and test again. After you fix the mobile template, run the live test again. Then request indexing for the pages that matter most.
Other Quick Checks
- Crawl stats report. In Search Console Settings, the Crawl stats report splits requests by Googlebot type. Smartphone should make up most of them.
- Browser device emulation. Chrome DevTools can act like a phone. Load the page in mobile mode and compare it with desktop. This helps you spot removed sections. But it does not replace the live test, because it doesn’t show you how Googlebot renders the page.
- Crawler with a smartphone user agent. Run your SEO crawler as a smartphone and compare word counts, internal link counts and structured data with a desktop crawl. Big gaps point you to the templates that need fixing.
On a site with a few templates, inspecting one or two URLs per template is usually enough. In my experience, problems with mobile-first indexing are almost always in the template, not the single page.
A Quick Mobile-First Indexing Audit Checklist
- Main content is the same on mobile and desktop, even if some is folded away.
- Headings match and are descriptive.
- Important internal links show up in the mobile HTML.
- Structured data is on mobile, with mobile URLs on m-dot sites.
- Titles and meta descriptions are equal.
- No
noindexornofollowon mobile that is not on desktop. - No main content or main images loaded only after a user action.
- Images and videos use stable URLs, supported formats and matching alt text.
- m-dot sites: no mass redirects to the mobile home page, matching status codes, no fragment URLs, correct canonical and alternate tags.
- Dynamic serving:
Vary: User-Agentheader sent, and user-agent detection handles Googlebot Smartphone. - URL Inspection shows “Crawled as: Googlebot smartphone”, and the rendered HTML has everything you need.
Conclusion
Mobile-first indexing is no longer a move to prepare for. It is how Google reads every site. It has been since Google said the switch was complete in 2023 and dealt with the last holdouts in July 2024.
The job with mobile-first indexing now is parity (making both versions match). Make sure your mobile pages carry the same content, links, structured data, metadata and robots tags as desktop. Then confirm it with URL Inspection. My next step would be to inspect one URL from each of your main templates this week. If the rendered mobile HTML is missing anything, you have found your quickest technical SEO win. After that, look at how those templates show in results with our guide to SERP features and how to earn them.
