Mobile-first indexing: mobile content, viewport setup, and touch friendliness
1. What mobile-first indexing actually changes
Google began testing mobile-first indexing in 2019 and made it mandatory sitewide in July 2024. What changed isn’t the ranking algorithm, it’s how Google sees your site.
| Before (desktop-first) | Now (mobile-first) | Impact on B2B sites |
|---|---|---|
| Crawls the desktop page for indexing | Crawls the mobile page for indexing | Desktop tables hidden on mobile don’t get indexed |
| Mobile was just a UX optimization | Mobile is the only indexing source | Schema rendered only on desktop might as well not exist |
| A separate m.example.com subdomain was acceptable | A separate mobile subdomain is costly to maintain | Use one responsive site and retire the m. subdomain |
| Backlink authority passed through the desktop version | Backlinks are evaluated on the mobile version too | A slow mobile version hurts rankings as well |
To check whether you’ve been switched: Search Console’s homepage shows “This site is indexed with mobile-first indexing.” If it doesn’t show yet, Google is still crawling you under the old rules, but the switch is only a matter of time, so don’t wait.
2. The four hard checks: viewport, content, touch, Schema
Compliance with mobile-first indexing breaks down into four things, each with clear standards.
| Checklist | Pass criteria | Common mistake | Validation tools |
|---|---|---|---|
| viewport | <meta name=”viewport” content=”width=device-width, initial-scale=1″> | Hardcoded width=1200 or no viewport | Mobile-Friendly Test |
| Content parity | Visible content is identical on desktop and mobile | Tables and specs hidden on mobile with display:none | Compare the mobile URL’s page source |
| Touch friendly | Tap targets ≥ 48×48 CSS pixels, spacing ≥ 8px | 24px buttons, links crammed together | Chrome DevTools mobile emulation |
| Structured Data | The mobile page source contains the full JSON-LD | Schema output only in the desktop template | Rich Results Test on the mobile URL |
Example: An industrial parts site had a full spec table (30 rows) on desktop, but on mobile the whole table was set to display:none to “simplify” things. After mobile-first indexing rolled out, all 12 long-tail keywords for that product page dropped out of the top 20 pages, because Google only saw a paragraph of intro text on the mobile version and had no idea what specs the product had. After switching the table to horizontal scroll on mobile, 8 keywords were back in the top 10 pages within two weeks.
Content parity doesn’t mean desktop and mobile have to look identical. It means the text, tables, images, and Schema all have to be there. Layout can collapse, but content can’t be deleted.
3. Responsive vs. dynamic serving vs. m. subdomain
Google officially supports three mobile setups, but they aren’t all recommended equally.
| Solution | Implementation | Maintenance cost | Recommendation |
|---|---|---|---|
| Responsive web design | Same HTML, adapted with CSS media queries | Low | First choice |
| Dynamic serving | Same URL, different HTML served by user agent | Medium | Works |
| Separate m. subdomain | A separate set of templates on m.example.com | High | Not recommended, legacy baggage |
| No mobile version | Desktop version scaled down | None | Prohibited, not mobile-friendly |
Counterintuitive point: a separate m. subdomain looks “controllable,” but in reality you’re maintaining two sets of templates, two sets of Schema, and two sets of hreflang. The moment they fall out of sync, you get content parity problems. Migrating to responsive is itself a site migration, so you need 301 mapping. Multilingual sites also need to check whether Hreflang for multilingual sites the mobile template breaks it.
4. Mobile-specific work for images, fonts, and performance
Mobile-first indexing isn’t just about whether the page “looks okay.” Google also uses mobile data to evaluate Core Web Vitals.
| Project | Common desktop practice | What mobile must change |
|---|---|---|
| Images | One large image for everything | srcset + sizes, adapted to DPR and width |
| Fonts | All 3 weights loaded | Load only 2 weights, font-display: swap |
| Navigation | Horizontal top menu | Hamburger menu, to avoid overflow on mobile |
| Forms | All fields expanded | type adapted for number/email, to avoid popping up the full keyboard |
| Ads and pop-ups | Sidebar | No interstitial pop-ups covering content on mobile |
Example 2: A B2B blog had a mobile LCP stuck at 4.5 seconds because the hero image used the original 2400px-wide desktop file. After adding srcset with 640px and 1080px versions, mobile LCP dropped to 2.1 seconds with no impact on desktop. The change was just two attributes on the img tag, with no design changes.
Mobile pop-ups are a specific target for Google: if a mobile page uses an interstitial pop-up to cover the main content, it gets flagged as “not mobile-friendly.” The Newsletter pop-up common on B2B sites needs to become a bottom bar or not appear at all on mobile.
5. Self-check list and verification process
| Checklist | Tools | Pass criteria | Frequency |
|---|---|---|---|
| Mobile-friendly test | Google Mobile-Friendly Test | All pass, no warnings for text too small or tap targets too close | Run once after a redesign |
| Content parity | Chrome mobile emulation + view source | Visible text on desktop and mobile is exactly the same | Sample 10 pages every quarter |
| Schema mobile rendering | Rich Results Test on the mobile URL | Detects every Schema type | After a template change |
| CrUX mobile data | Search Console experience report | All three CWV checks pass on mobile | Monthly |
| Mobile indexing status | Search Console home | Shows “Indexed using mobile-first indexing” | Monthly |
Mobile experience fixes and Website accessibility (WCAG) overlap heavily: tap target size, contrast, keyboard navigation. Fix them once and both sides benefit.
6. How to adjust your content after mobile-first indexing
Mobile-first indexing isn’t just a technical change. Your content has to change with it. On desktop you can pile on long tables, multi-column specs, and long arguments. On mobile, visitors hold the phone in one hand and read at a completely different pace. Rebuild your content structure for a single vertical column.
| Content element | Typical desktop approach | Recommended mobile approach |
|---|---|---|
| Long tables | Wide tables with 8+ columns | Break into cards or horizontal scroll, put key columns first |
| Paragraph length | 200+ words per paragraph | No more than 3 to 4 lines per paragraph, short sentences, more line breaks |
| Internal link anchor text | Inline links | Put link text on its own line so fingers can tap it |
| Charts | High-density data charts | Make a simplified mobile version with a text takeaway |
| CTA buttons | Small button in the top nav | One large button mid-article and one at the bottom |
Draft your content in a single mobile column first, then adapt it for desktop. That way it reads well on both, instead of looking polished on desktop and crammed on mobile. Every quarter, sample ten published articles and check them in Chrome’s mobile emulator. If you find tables overflowing, buttons too small, or links hugging the edge, add them to the next round of fixes.
Forms are where mobile loses the most conversions. On desktop you can put a dozen fields on one screen, but on mobile visitors type one-handed, and every extra field costs you signups. Cut your inquiry form down to three or four required fields: company name, email, and a short description of what you need. Collect everything else after the deal closes. For fields like phone number, telephone, and country that you can infer from the email and company domain, don’t make visitors type them. Every five-point gain in mobile form conversion rate moves your inquiry volume up a notch.
FAQ
When did Google start enforcing mobile-first indexing?
Does hiding content with display:none on mobile hurt SEO?
Should I keep the separate m.example.com subdomain?
What’s the minimum tap target size?
Can I output Schema on the desktop version only?
Why are mobile interstitials penalized?
Final thoughts
Mobile-first indexing isn’t about “making a mobile version” and calling it done. It’s the only way Google reads your site. No matter how complete your desktop version is, if it’s not visible on mobile, it doesn’t exist.
Three steps to get started: this week, spot-check 10 core pages in Chrome DevTools mobile emulation and confirm desktop and mobile content match; next week, fix the three hard failures: viewport, tap targets, and Schema rendering on mobile; in week three, confirm in Search Console that the mobile-friendly test passes and your CrUX mobile data is up to standard.
One line worth remembering: mobile-first indexing isn’t asking you to build a shrunken desktop site. It’s asking you to accept that what Google sees is what visitors see on their phones.