Mobile-First Indexing Explained: What It Means for Your Site
By Kavi, SEO Consultant · Last updated: 3 September 2026
Mobile-first indexing means Google uses the mobile version of your page for indexing and ranking. If content, links, or structured data appear only on your desktop version, Google will not see them. Google completed the transition to mobile-first indexing for all sites, so the mobile page is now the page as far as search is concerned.
What is mobile-first indexing?
Mobile-first indexing is Google crawling and indexing your site with a smartphone Googlebot user-agent and using what that crawler sees as the basis for indexing and ranking. It is not a separate mobile index; there is one index, populated from the mobile rendering of your pages.
The name misleads people into thinking it is about mobile rankings. It is not. It determines what Google knows about your page for all rankings, desktop results included. If your mobile template hides half your content behind a collapsed section that never loads, that content is not in the index for anyone.
For most modern responsive sites this is a non-event, and that is worth saying plainly rather than manufacturing urgency. The sites where it still bites are those serving different markup to mobile, and those hiding content on small screens. Both are worth checking during any technical SEO review.
Quick facts
| Item | Detail |
|---|---|
| Status | Applies to all sites; transition complete |
| Crawler | Googlebot Smartphone |
| Separate mobile index? | No. One index, mobile-based. |
| Affects desktop rankings? | Yes. The mobile version is the source for everything. |
| Best configuration | Responsive design, one URL, identical content |
| Riskiest configuration | Separate m-dot site with reduced content |
| Hidden-in-accordion content | Indexed if present in the DOM |
Why it matters
The practical consequence is a single rule: content that is not on your mobile page does not exist. That applies to body text, internal links, images, structured data, and meta tags.
Historically, many sites shipped trimmed mobile templates for performance: fewer paragraphs, a shortened navigation, no sidebar, no schema. Under mobile-first indexing every one of those omissions is a deletion from the index.
The distinction that trips people up: content inside a collapsed accordion or an inactive tab is indexed, provided it is present in the delivered DOM. Google has confirmed it indexes this content normally. What is not indexed is content that does not exist until the user interacts, because Google does not click. “Visually hidden” and “not loaded” are completely different situations, and conflating them causes people to rebuild working designs for no reason.
Configurations compared
| Configuration | How it works | Risk level | Recommendation |
|---|---|---|---|
| Responsive design | One URL, one HTML, CSS adapts layout | Lowest | Use this |
| Dynamic serving | One URL, different HTML by user-agent | Medium | Requires the Vary header; keep content identical |
| Separate mobile URLs (m-dot) | m.example.com serves mobile | Highest | Migrate to responsive |
If you still run an m-dot site, that is where your effort belongs. It requires maintaining two templates, two sets of annotations, and two chances to diverge, and the mobile version is the one Google indexes.
How to check your site
Step 1: Compare mobile and desktop content
Open a page on desktop, then load the same URL in a mobile viewport with device emulation in your browser’s dev tools. Compare the text, the internal links, and the navigation. Anything present on desktop and absent on mobile is missing from the index.
Step 2: Use URL Inspection
Run a live test in Search Console and open “View tested page”, then the HTML tab. This is what Googlebot Smartphone actually received. Search it for your key content and your structured data.
Step 3: Verify structured data parity
Structured data must be present on the mobile version. A common historic pattern was rendering schema only in a desktop template, which under mobile-first indexing means no schema at all.
Step 4: Check internal links
Collapsed mobile navigation is fine if the links exist in the DOM. It is a problem if the menu builds itself only after a tap. Google follows hrefs in the delivered markup; see JavaScript SEO and rendering.
Step 5: Confirm images and alt text carry over
Images that are removed rather than resized on mobile are not indexed, and their alt text goes with them. Lazy loading is fine when implemented with native loading="lazy" or an intersection observer that Googlebot triggers; a scroll-only loader is not.
Step 6: Check meta tags match
Titles, meta descriptions, canonicals, and robots directives must be identical across mobile and desktop. Divergence here produces contradictory signals; see canonical tags and duplicate content.
Mobile usability factors
Separate from indexing, these affect user experience and, through Core Web Vitals, page experience signals:
- Viewport meta tag present and correctly configured.
- No horizontal scrolling at common device widths.
- Tap targets large enough and adequately spaced.
- Legible text without zooming.
- No intrusive interstitials covering content on arrival from search.
- INP performance, which is typically worse on mobile hardware. See Core Web Vitals explained.
Common mistakes
| Mistake | Consequence | Fix |
|---|---|---|
| Shorter content on mobile | The removed content is not indexed | Serve identical content |
| Structured data on desktop only | No rich results at all | Include schema in the mobile template |
| Reduced mobile navigation | Fewer internal links; weaker signal flow | Keep links in the DOM |
| Images removed on mobile | Images and alt text not indexed | Resize rather than remove |
| Different meta tags per version | Contradictory signals | Keep them identical |
| Blocking resources for mobile crawling | Broken rendering | Allow CSS and JS in robots.txt |
| Content loaded only on tap or scroll | Never seen by Google | Include it in the delivered DOM |
| Intrusive interstitials on entry | Poor experience; possible demotion | Use a small banner instead |
| Assuming this affects mobile rankings only | Desktop rankings suffer too | Treat mobile as the canonical version |
Decision guide
- Responsive site with identical content: nothing to do. Verify once and move on.
- Responsive but hiding sections on mobile: check whether the content is in the DOM. If it is, you are fine.
- Dynamic serving: verify the Vary header and confirm content parity between the two responses.
- m-dot site: plan a migration to responsive. This is the real work.
- WordPress with a mainstream theme: almost certainly responsive already; spend your time on performance instead.
Checklist
- Mobile and desktop serve identical body content
- All internal links present in the mobile DOM
- Structured data present on mobile
- Titles, descriptions, canonicals, and robots tags identical
- Images present on mobile with alt text
- CSS and JavaScript crawlable
- Viewport meta tag configured
- No horizontal scroll at common widths
- Tap targets adequately sized and spaced
- No intrusive interstitials on arrival from search
- URL Inspection rendered HTML contains all key content
- Core Web Vitals passing in mobile field data
Frequently asked questions
Is content in accordions and tabs indexed?
Yes, provided it is present in the delivered DOM. Google has confirmed it indexes visually hidden content of this kind normally. Content that only loads after a tap is a different matter and may never be seen.
Does mobile-first indexing affect desktop rankings?
Yes. There is one index built from the mobile version, so what your mobile page contains determines what can rank anywhere.
Do I need a separate mobile site?
No, and you should not build one. Responsive design is Google’s recommended configuration and avoids every parity problem described here.
How do I know if my site is mobile-first indexed?
All sites are. You can confirm the crawler in URL Inspection, which will report Googlebot Smartphone as the crawler used.
Should mobile content be shorter for usability?
Shortening the visible layout is fine; removing content from the markup is not. Use progressive disclosure with the full content in the DOM, so users get a clean experience and Google gets everything.
What about AMP?
AMP is no longer required for any Google Search feature, including Top Stories. If you maintain AMP pages, the canonical version must still contain equivalent content. Most sites can retire AMP in favour of a fast responsive page.
Does mobile page speed affect rankings?
Core Web Vitals are part of page experience signals, and they are measured on mobile field data. The effect is real but modest compared to relevance and content quality.
Key takeaways
- Google indexes the mobile version of your page and uses it for all rankings.
- Content missing from mobile is missing from the index entirely.
- Accordion and tab content is indexed if it is in the DOM.
- Content requiring a tap or scroll to load is not indexed.
- Structured data, meta tags, and internal links must match across versions.
- Responsive design is the recommended configuration; m-dot sites are the real risk.
- For most modern responsive sites, this requires verification rather than work.
Conclusion
Treat your mobile page as the canonical version of your site, because to Google it is. Run one URL Inspection live test on your most valuable template, search the rendered HTML for your key content and schema, and confirm nothing is missing. If your site is responsive and serves the same markup everywhere, that check is the whole job.
Related articles
- Technical SEO guide
- Core Web Vitals explained
- JavaScript SEO and rendering
- How to do a technical SEO audit
- Site architecture and URL structure
External references
- Google Search Central: Mobile-first indexing best practices
- Google Search Central: Understanding page experience
