What mobile-first indexing actually means
Mobile-first indexing is Google's policy of using the mobile version of a page as the version it crawls, renders, indexes and ranks. The mobile version is the canonical one. The desktop version is treated as a secondary representation.
The shift happened gradually. Google announced the policy in 2016, started moving sites onto mobile-first indexing in 2018, and completed the rollout to all sites by 2023. Today every site Google indexes is on mobile-first. There is no opt-out.
What this means in practice depends on how your site is built. For responsive sites (one HTML, CSS adapts the layout for screen size), the desktop and mobile versions are functionally identical. Mobile-first indexing changes nothing because both versions are the same. For sites with separate desktop and mobile templates, or sites that conditionally hide content on mobile, the mobile version is what Google reads. Anything missing from mobile is missing from the index, regardless of whether it appears on desktop.
Why it matters
Three reasons.
One. Content parity. If your desktop page has 1,200 words and your mobile page (whether through a separate template or aggressive content hiding) has 400, only the 400 words count for indexing. The other 800 are invisible to Google.
Two. Structured data parity. If you have FAQ schema on the desktop page but stripped it for performance reasons on mobile, Google will not show the rich result because the canonical (mobile) version has no schema.
Three. Internal link parity. If your mobile navigation hides links that the desktop navigation shows (a common pattern with "burger menu" navigation that omits certain sections), those links carry less weight than they would if Google saw them on desktop. The mobile site is the authoritative source for internal link structure.
What to check on your site
Six checks on any site that might differ between desktop and mobile.
1. Content parity
Use Search Console URL Inspection on a key page. Click "Test live URL" and view the tested page. Confirm the rendered content matches what your desktop visitors see. Pay attention to body copy, headings, image captions and bylines. Anything missing is missing from the index.
2. Structured data parity
Check that any schema markup (Article, FAQ, Product, LocalBusiness, BreadcrumbList) appears in the mobile rendered HTML. Some templates strip schema on mobile for "performance" reasons. The schema is small. Keep it.
3. Internal links parity
If your mobile navigation differs from desktop (a smaller burger menu, hidden footer links, no related-articles widget), be aware that the links visible on mobile are the links Google counts. Critical internal links should be present on both.
4. Meta tags parity
Title tag, meta description, canonical, hreflang and robots directives all need to be identical between desktop and mobile. Some CMS platforms accidentally generate different metadata for different views; audit this on a sample of pages.
5. Image parity
If you serve different images at different sizes (good practice for performance), that is fine. If you serve no images at all on mobile (sometimes done to save bandwidth), the alt text and image SEO signals disappear. Keep the images, just optimised.
6. Lazy-loaded content
Content that only appears after a user interaction (click to expand, scroll to load) is not reliably indexed. If important content is buried behind interactions on mobile, surface it. Hide it visually with CSS if you want, but keep it in the initial HTML.
Responsive design vs separate mobile sites
Three architectures exist for serving mobile users. Google's recommendation has narrowed to one of them.
Responsive design (recommended). One HTML template, one URL. CSS uses media queries to adapt the layout to the screen size. Content is identical across devices. This is what nearly every modern site uses. Maintenance is simple, SEO is straightforward, mobile-first indexing is effectively invisible.
Dynamic serving. One URL, different HTML served based on user-agent detection. Common in legacy systems. Google can handle it but you need the Vary: User-Agent HTTP header to be set correctly. Audit content parity carefully.
Separate mobile URLs (m-dot). Desktop content at example.com, mobile content at m.example.com. The older pattern. Google still supports it but it requires hreflang-like annotation linking the two and is the most error-prone option. Consolidate into responsive if you have one.
If you are starting a new site in 2026, build responsive. If you have an m-dot site, plan a migration. The complexity of m-dot has no remaining benefit over responsive.
Common mistakes
- Audit content parity with Search Console URL Inspection quarterly.
- Keep all critical body copy, headings and meta tags identical between desktop and mobile.
- Include structured data on the mobile template, not just desktop.
- Use responsive design for new sites. Consolidate m-dot sites into responsive over time.
- Test on actual mobile devices, not just by resizing the browser window.
- Hide content from mobile users with the assumption that desktop is what Google sees. It is not.
- Strip schema markup from the mobile template to save bytes.
- Lazy-load above-the-fold content on mobile. It will not be indexed reliably.
- Use mobile-only burger menus that hide important section links.
- Build new sites with separate mobile URLs. The architecture has no upside today.
Tools and checklists
- Search Console URL Inspection. Free. The authoritative answer for what Googlebot sees on mobile. The "Test live URL" feature renders the page as the mobile crawler would.
- PageSpeed Insights. Free. Defaults to mobile metrics. Use the mobile view to test performance.
- Chrome DevTools device emulation. Free. The device toolbar simulates different screen sizes and user-agents. Useful for spot checks but not a replacement for real-device testing.
- Screaming Frog with mobile user-agent. Configurable user-agent setting lets you crawl as Googlebot-Mobile. Compare a mobile crawl to a desktop crawl to spot template differences.
- Our free SEO audit tool. Defaults to mobile testing in line with Google's priorities. Run a free audit.
Perth and WA context
Three mobile-first patterns we see on Australian sites.
The accordion-hidden FAQ. A Perth professional services site (legal, healthcare, financial) puts the FAQ in mobile accordions that load on click. The FAQ schema is in the desktop HTML but the accordion content is injected by JavaScript on click. Google indexes neither the schema nor the content because neither is in the initial HTML. The fix is to put the FAQ text and the FAQ schema in the initial mobile HTML, and use CSS to control the accordion visual state.
The desktop-heavy comparison table. A Cockburn or Joondalup ecommerce site shows a detailed product comparison table on desktop and a stripped-down "tap to expand" version on mobile. Google indexes the stripped version. The product detail that helps the page rank for long-tail queries is missing from the index. The fix is to surface the same content on mobile, just laid out differently.
The legacy m-dot survivor. A Fremantle or Mandurah business with a separate m.example.com mobile site set up in 2012 and never consolidated. The desktop site ranks; the mobile site indexes separately; the two compete for some queries; canonical and hreflang-style annotations are inconsistent. The fix is migrating to responsive and 301-redirecting the m-dot URLs to the main domain. The chapter on site migration covers the process.
One pattern across all three. The site was designed for desktop first and mobile was bolted on later, with various corners cut to save bytes or to declutter the small screen. Each shortcut quietly cost indexability. The audit is the first time anyone has lined up the desktop and mobile renderings side by side and asked which one Google is actually using.
Related guides
- Back to the Technical SEO pillar for the 12-chapter index.
- JavaScript SEO essentials. JavaScript rendering happens on the mobile version first.
- The technical SEO audit. Stage seven checks mobile parity.
- Canonical tags explained. Canonical points at the mobile URL if you have separate URLs.
- Core Web Vitals pillar. Mobile CWV is the version Google uses for ranking.
- Header tags. H1 has to be visible on mobile.
- Image SEO. Mobile image handling matters more than desktop.
- Why SEO matters in Australia. Mobile traffic share in AU is well above the global average.