Google doesn’t look at your website the way you do on your laptop. It looks at the phone version first, and for most sites, that’s the only version it looks at when deciding how you rank. This is mobile-first indexing, and it changes what “optimizing your site” actually means. It’s also very important for both user experience and SEO.
What mobile-first indexing means
Mobile-first indexing means Google’s crawler visits your site using a smartphone user agent and builds its index from what that crawler finds. The content, structure, links, and metadata on your mobile pages become the basis for how Google ranks you in search results, on both mobile and desktop.
There’s only one index. Google doesn’t maintain a separate mobile index and desktop index that it juggles depending on who’s searching. It maintains a single index, and since 2023, that index is built from the mobile version of your pages for effectively every site on the web. If your mobile page is missing content, links, or structured data that your desktop page has, that content doesn’t count toward your rankings, on desktop searches either.
This reverses the older model. Google used to crawl and index the desktop version, then treat the mobile version as a secondary, stripped-down copy. Under that system, a business could invest in a polished desktop site, bolt on a thin mobile version for appearances, and rank fine. That gap doesn’t exist anymore. Your phone version carries the weight.
Why Google made the switch
The shift tracks a change in how people actually search. Mobile devices account for roughly 59% of global web traffic, and in most consumer verticals that share is higher. Google’s own logic is straightforward: if the majority of searches happen on phones, ranking pages based on a desktop experience most searchers never see produces worse results. Indexing the mobile version aligns the ranking signal with the actual user experience.
The rollout took the better part of a decade. Google first flagged mobile-friendliness as a ranking factor with the Mobilegeddon update in 2015, began testing mobile-first indexing on select sites in November 2016, and moved to a default mobile-first setup for new sites in July 2019. The pandemic pushed back the full rollout timeline, but by May 2023 the migration was effectively complete across the web. From July 2024 onward, Google has stated that sites with no mobile-accessible version risk becoming unindexable altogether, not just deprioritized.
None of this is optional or something you opt into. Every site that’s been crawled by Google in the last few years is already being judged this way.
The three ways sites serve mobile content, and why it matters
Google recognizes three configurations for serving mobile content, and which one your site uses determines how much manual work mobile-first indexing requires from you.
Responsive Design
Responsive design serves the same HTML through the same URL for every device, and uses CSS to adjust the layout based on screen size. This is the configuration Google recommends, and it’s what the vast majority of modern WordPress themes, including GeneratePress, use by default.
Because there’s only one URL and one set of markup, there’s no separate mobile template to fall out of sync with the desktop one. Content parity, structured data, and metadata stay aligned automatically, because they’re the same code being reflowed, not two codebases being maintained in parallel.
Dynamic Serving
Dynamic serving sends different HTML to the same URL depending on the device making the request, detected through the user agent.
The URL stays constant, but the markup differs. This setup requires a Vary: User-Agent HTTP header so caching systems and crawlers know the content changes by device, and it creates more chances for the mobile and desktop versions to drift apart over time, since they’re technically separate templates being maintained side by side.
Separate URLs
Separate URLs (the m.example.com pattern) serve mobile visitors an entirely different URL from desktop visitors, connected through rel=alternate and rel=canonical tags.
This is the oldest and most maintenance-heavy approach, and it’s the one most exposed to mobile-first indexing problems, because the mobile URL is a distinct page with its own content, its own links, and its own chance to fall behind the desktop version it’s supposed to mirror.
If you’re running WordPress with a responsive theme, you’re already on the configuration that creates the fewest structural risks. That doesn’t make you immune to the content-level mistakes covered below. It just means the plumbing is right; what goes wrong from here is almost always a builder setting or a plugin, not the underlying architecture.
How to check where your site stands
Open Google Search Console and go to Settings, then look at the Crawler section under Crawl Stats. It tells you which crawler Google is using on your site, Googlebot Smartphone or Googlebot Desktop, and when the switch happened if your site made the transition later than most.
The URL Inspection tool gives you a page-level view. Run any URL through it and check “Crawled as” under the coverage details. If it says Googlebot Smartphone, that page is being indexed from its mobile rendering. Google’s Mobile-Friendly Test tool (accessible through Search Console’s mobile usability reports since the standalone tester was retired) will also flag broken layouts, unreadable text, and elements placed too close together for a touchscreen.
If your site runs on a single responsive template, this check usually comes back clean; the mobile and desktop versions serve identical HTML through the same URL, so there’s no parity gap to create in the first place. The risk concentrates in sites running separate mobile URLs (m.example.com), dynamic serving setups, or older themes that hide content on smaller viewports rather than reflowing it.
Here it is as plain text — same content, same wording, just readable prose with headers.
What Google actually checks on the mobile version
Content parity is the core requirement, and it’s more literal than most site owners assume.
Content parity
Your mobile page needs the same primary content as your desktop page: the same body text, the same headings, the same product details, the same reviews. You don’t need pixel-identical layouts. Tabbed content, accordions, and “read more” toggles are fine; Google stopped discounting content that’s hidden behind an interaction back when mobile-first indexing first rolled out, as long as that content is present in the page’s code and accessible to a user who taps to expand it.
What Google penalizes is content that’s removed from the mobile version entirely, not content that’s collapsed for space.
Structured data
Structured data has to match too. If your desktop page carries schema markup for products, reviews, articles, or FAQs, your mobile page needs the same markup.
A common failure mode: a site adds schema to its desktop template during a redesign and never ports it to the mobile-specific template, so Google’s mobile crawl finds none of it.
Internal linking
Internal linking has to survive the move to mobile. Sites frequently trim their navigation for smaller screens, cutting breadcrumbs, footer links, or secondary menu items to save space.
Every link you cut changes how PageRank flows through your site, because the mobile version is what Google actually crawls. A footer full of links to your best-converting service pages does nothing for your rankings if that footer only exists on desktop.
Metadata
Metadata needs to match as well. Title tags, meta descriptions, canonical tags, hreflang tags, and robots directives should be identical (or functionally equivalent) across both versions.
A mismatched canonical tag on the mobile template, or a stray noindex left over from a staging setup, can quietly remove pages from the index without any visible symptom on the front end.
Images
Images need alt text, proper file references, and crawlable paths on the mobile version specifically. A background image swap or a mobile-only hero graphic that lacks alt text represents lost signal that the desktop version might otherwise carry.
Where WordPress sites lose ground on mobile-first indexing
Most of the general advice on mobile-first indexing assumes a hand-coded or custom-built site. In practice, the majority of small and mid-sized business sites run on WordPress, and the failure points there are specific enough to call out separately.
Responsive display settings that hide instead of reflow
Responsive display settings hide content instead of reflowing it. Page builders, including GenerateBlocks, let you set an element to hide on mobile with a toggle. That’s useful for a sidebar widget or a decorative element. It’s a liability when it’s applied to a paragraph of service description, a trust badge, or a secondary CTA, because “hide on mobile” in most builders applies a CSS display:none rather than removing the element from markup.
Google’s smartphone crawler still renders the page and can, in many cases, tell the difference between content that’s collapsed behind an interaction and content that’s suppressed outright with no way for a mobile visitor to ever see it. Treat every “hide on mobile” toggle as a content decision, not just a layout decision, before you apply it to anything that carries ranking value.
Mega menus reduced to skeleton menus
Mega menus get replaced with skeleton menus. A desktop mega menu with dozens of category links often gets swapped for a three-item hamburger menu on mobile, because nobody wants to build a mobile equivalent of a forty-link dropdown. That’s a legitimate UX call, but it strips internal links that Google’s crawler will no longer find, since it’s crawling the mobile menu. The fix isn’t cramming all forty links into the mobile nav.
It’s making sure the links that matter for rankings (your core service and location pages, not every filtered category variant) exist somewhere reachable on mobile, even if that’s a sitemap-style link on the page itself rather than the primary nav.
Lazy-loading libraries that block first-paint content
Lazy-loading libraries block first-paint content from crawlers. Plugins that lazy-load images or sections on scroll sometimes gate that content behind JavaScript that fires only on user interaction, not on page load or crawl. Googlebot renders JavaScript, but it doesn’t scroll or click.
Content that only appears after a scroll event, rather than loading into the DOM on initial render (even if visually deferred with a blur-up placeholder), risks not being seen at all. Native lazy loading (loading=”lazy”) is safe. Scroll-triggered content injection is not, unless it’s paired with a fallback that puts the content in the initial HTML.
Popups and interstitials
Popups and interstitials built for mobile conversion often violate Google’s interstitial guidelines. An exit-intent popup or a floating “Book Now” bar that covers meaningful screen real estate on a phone, especially right after the page loads, can trigger a usability penalty.
Google’s guidance allows small banners and legally required interstitials (cookie notices, age gates); it doesn’t allow full-screen takeovers that block the main content shortly after arrival.
Orphaned AMP pages
Old AMP setups create orphaned duplicate content. Sites that adopted AMP in the 2018-2020 window and later abandoned it sometimes still have AMP URLs live, with their own separate content and their own crawl footprint, disconnected from the canonical mobile-first version of the page.
Since AMP fell out of favor as a Google ranking requirement, these pages usually just sit there as duplicate, half-maintained content with no one checking them.
WooCommerce checkout divergence
WooCommerce checkout flows often diverge between desktop and mobile without anyone intending it. A checkout page built and tested on a desktop screen frequently ships with form fields, trust badges, or payment method descriptions that overflow or get truncated on mobile viewports, and get patched with a mobile-specific override that quietly removes rather than reflows.
Since checkout and product pages tend to carry commercial intent and get evaluated for both usability and content, a stripped-down mobile checkout affects conversion and crawl signal at the same time.
Custom fonts and third-party embeds
Custom fonts and third-party embeds can block rendering long enough that Googlebot times out on slower mobile simulations before your actual content loads.
This shows up more on mobile because Google’s rendering budget for a given crawl is tighter on the mobile pass, and a page that loads acceptably on a fast desktop connection during testing can still stall under mobile network conditions during an actual crawl.
What a mobile-first indexing problem looks like after a redesign
Why the damage is hard to trace
Rankings rarely drop the day a redesign goes live. They usually slide over the following two to six weeks, as Google recrawls the site and gradually replaces its old index with the new pages.
That lag is what makes these problems hard to diagnose after the fact: the team has usually moved on to the next project by the time traffic reports start showing the damage, and the instinct is to blame the new design broadly rather than trace it to a specific missing element.
The usual causes
The pattern is usually traceable to one of a small number of causes. A theme migration that changed the mobile menu structure and dropped internal links to pages that used to rank. A new page builder that introduced its own “hide on mobile” defaults that got applied without anyone reviewing what got hidden.
A redesign that moved schema markup into a plugin that only fires on desktop templates. A staging site that had a sitewide noindex tag that didn’t get fully removed from every template before launch.
Catching it before launch
Checking mobile parity, mobile schema, and mobile crawl status before launch, not after, catches nearly all of this. It takes an hour with Search Console’s URL Inspection tool run against a handful of your top-performing pages. Catching it after a three-week ranking slide takes considerably longer.
Common questions on mobile-first indexing
Does responsive design automatically make a site compliant?
It removes the structural risks that come from maintaining separate mobile and desktop templates, but it doesn’t protect against builder settings that hide content, block scripts, or strip metadata on smaller screens. Compliance is still a content and configuration question, not just a template choice.
Does a B2B site with mostly desktop visitors still need to worry about this?
Yes. Mobile-first indexing determines how Google indexes and ranks the page for every searcher, desktop included. A site can get 90% of its traffic from desktop users and still lose desktop rankings because its mobile version, the one Google actually crawls, is thin or broken.
Is there a way to opt out or request desktop-only indexing?
No. Google made this a sitewide default with no opt-out. The only sites still being crawled primarily with a desktop user agent are a small number of legacy cases Google has flagged for technical reasons specific to that site, not a setting anyone can request.
Does page speed on desktop count for anything?
Core Web Vitals and the page experience signals tied to ranking are pulled from the mobile report specifically. A fast desktop site attached to a slow mobile version gets judged on the slow number.
Core Web Vitals run on the mobile number
Page speed and interactivity scores are measured against your mobile performance specifically, not an average of mobile and desktop, and not your desktop score. Check Search Console under Experience, then Core Web Vitals, and confirm you’re looking at the mobile report rather than desktop.
The three metrics that matter:
- Largest Contentful Paint measures how long the largest visible element (usually a hero image or heading) takes to render. Under 2.5 seconds is good.
- Interaction to Next Paint measures how quickly the page responds after a user taps something. Under 200 milliseconds is good.
- Cumulative Layout Shift measures how much the page jumps around as it loads, from images without reserved dimensions, late-loading ads, or fonts that swap in after text has already rendered. Under 0.1 is good.
Mobile devices generally have less processing power and slower, more variable connections than the desktop machines most sites get built and tested on. A site that scores well in Chrome DevTools on a developer’s desktop can still fail every one of these metrics on a mid-range Android phone over a 4G connection. Test on throttled mobile conditions, not just your own machine.
A working audit checklist
- Run through this on your own site, or hand it to whoever manages it:
- Confirm your crawl status in Search Console (Settings, Crawl Stats) and verify Googlebot Smartphone is listed as your active crawler.
- Compare your mobile and desktop pages side by side for body content, headings, and any collapsed sections, and confirm nothing is missing on mobile that exists on desktop.
- Check that structured data validates on the mobile version using Google’s Rich Results Test, run against the live mobile URL, not a cached desktop version.
- Review your mobile navigation and footer for dropped links to pages you actually want ranked.
- Pull up your title tags, meta descriptions, and canonical tags on mobile and confirm they match desktop.
- Check Core Web Vitals under the mobile report in Search Console, not desktop.
- Audit any “hide on mobile” settings in your page builder for content that carries SEO or conversion value, not just decorative elements.
- Test your site on an actual phone, on actual mobile data, not a browser window resized to look like one.
What this means if you’re planning a redesign
Every one of these checks belongs in a redesign process, not as an afterthought after launch. A redesign that swaps themes or rebuilds a site from scratch without carrying over mobile menu links, mobile-specific schema, and mobile metadata is a redesign that can quietly tank rankings that took years to build, even when the new site looks and performs better to a human visitor.
If you’re auditing your site for a redesign anyway, mobile-first indexing gives you a second lens to run alongside speed, navigation, and conversion checks. A site that fails these checks is usually failing the human-facing signs too: slow load times, a confusing mobile menu, missing trust content. The two problems tend to travel together, because both come from treating mobile as an afterthought to the desktop build rather than the version that actually decides how the site ranks.
