Google completed its rollout of mobile-first indexing for all sites in 2023. That means the Googlebot Smartphone crawler is what Google uses to render, parse, and index your pages. If your mobile version is missing content, structured data, or internal links that exist on your desktop version, Google never sees them. The ranking signals you think you have may not actually exist in the index — and you would not know from looking at your desktop site.
What Mobile-First Indexing Actually Means
Before mobile-first indexing, Google primarily used the desktop version of a page for indexing decisions. It understood mobile, but desktop was the primary signal. The inversion matters because for many sites — particularly older ones built when mobile was an afterthought — the mobile experience is stripped down: content hidden behind tabs, structured data not rendered, images not loading, navigation inaccessible. Google now scores you based on that stripped-down version, not the full desktop experience.
Mobile-first does not mean mobile-only. Google still crawls desktop. But the mobile crawl is what drives indexing decisions. If a piece of content is visible on desktop but hidden on mobile via display:none in CSS or a JavaScript conditional, Google may not fully index or weight that content. The degree of devaluation depends on how the hiding is implemented, but the safest rule is: if it matters for rankings, make sure it is present and visible in the mobile version.
Responsive Design vs. Separate Mobile Site
Responsive design — one URL, CSS that adapts to screen size — is the recommended approach and the cleanest for indexing. Google sees the same HTML on both desktop and smartphone crawlers; the display differences are purely cosmetic. No canonical confusion, no content parity issues between versions, no separate sitemap to maintain. For new builds, responsive design is the only reasonable choice. For legacy sites with separate m. subdomains, the migration to responsive is worth the investment — the ongoing maintenance overhead and parity risk of a separate mobile site are real costs.
If you are on dynamic serving (same URL, different HTML served based on User-Agent), content parity is a constant risk. The mobile HTML needs to include the same primary content, structured data, and internal links as the desktop HTML. This needs to be verified explicitly, in the rendered output, not just assumed from the code structure.
Content Parity: The Real Risk Area
The most common failure mode I see in audits: content that is collapsed or visually hidden on mobile to save screen space. Accordion tabs, read-more truncation, off-canvas drawers, and tab panels are all patterns that can hide content from Googlebot depending on implementation. Google has stated it will index content inside JavaScript-rendered interactive elements, but it may weight fully visible content more heavily than content that requires interaction to reveal.
Test this directly with Google Search Console: use the URL Inspection tool, click ‘Test Live URL,’ and examine the rendered HTML under the mobile crawl. Compare it against your desktop-rendered source. Any content present in the desktop version but absent from the mobile render is not in the index. Any content present but hidden inside a collapsed element may be weighted differently. This inspection is worth doing on your most important page templates, not just your homepage.
Structured Data on Mobile
If your structured data is injected by a JavaScript that only fires on desktop, or if it lives in a section of the page that is not rendered in the mobile view, Google’s smartphone crawler will not see it. This is a real risk for sites where structured data was added later via a desktop-only script or a plugin that conditionally loads on device type. Verify that your schema markup appears in the mobile-rendered source via the URL Inspection tool. The tool shows both the rendered HTML and any structured data it detected — use both views to confirm parity.
Schema markup and structured data are central to my technical SEO work through Salterra. Mobile-first indexing adds a verification step that many practitioners skip — confirming the markup is actually present in the mobile-crawled version, not just the desktop version.
Internal Linking on Mobile
Navigation on mobile is often a hamburger menu that renders links inside a JavaScript-driven drawer. Google can crawl these links, but if the drawer is not present in the initial rendered HTML — if it is built purely client-side after a click event — there is some risk those links pass less equity than fully visible navigation links. Ensure your mobile navigation includes the same important internal links as your desktop navigation, and that they are present in the rendered HTML even if they are visually hidden behind a toggle. Server-side rendering of navigation HTML is the safest approach for link equity.
Page Speed on Mobile
Mobile users are often on slower connections and less powerful devices than desktop users. Core Web Vitals field data in Search Console segments scores by desktop and mobile separately — you can see distinct LCP, CLS, and INP scores for each device category. A site that passes Good on desktop and Poor on mobile is failing the mobile-first indexing performance signals. Address mobile performance as a separate concern from desktop optimization; do not assume a fast desktop score carries over. The mobile SEO audit process covers this segmentation systematically.
Images and Resources on Mobile
Make sure your mobile pages load the same images — in appropriate sizes via srcset — and not a stripped-down version that omits key visual content. Some mobile implementations skip below-fold images entirely on small viewports via JavaScript conditions; this affects how Google understands the page content. Resources referenced in the page HTML should be crawlable and accessible to Googlebot Smartphone — do not block image or script paths in robots.txt that the mobile crawler needs to fully render the page.
Verifying Mobile Crawl Health
In Google Search Console, the Page Indexing and Coverage reports reflect the mobile crawl. If you see a sudden drop in indexed pages or a spike in crawl errors, check whether a recent site update altered mobile rendering or accidentally blocked a resource Googlebot needs. Run the Mobile Usability report in Search Console before and after any significant template change — it surfaces viewport configuration errors, small tap targets, content wider than the screen, and other mobile-specific issues that affect both user experience and crawlability.
Mobile-first indexing intersects with nearly every other technical concern: crawl efficiency, structured data, page speed, and internal linking. A website audit covers all of these in one pass, including explicit mobile parity checks. For the crawl side specifically, see crawl budget and indexation issues — both areas where mobile-first indexing creates failure modes that are easy to miss without a systematic review.