AI AI Tools Guidebook
Troubleshooting

Indexing Dropped After Google Switched Your Site to Mobile-First

Search Console confirms mobile-first indexing, then two weeks later valid pages and impressions fall 15-40%. The cause is almost always content the mobile HTML is missing. Here's how to diagnose and close the gap.

Published: Updated: Author: AI Productivity Guide Team 🌐 查看中文版本

Search Console sends the notice, then one to two weeks later the Pages report shows fewer valid pages and impressions slide 15-40%. Mobile-first indexing means Google crawls, indexes, and ranks the mobile rendering of your page as the canonical version. Anything the desktop version has and the mobile HTML does not — body text, structured data, internal links, image alt — is effectively invisible to Google.

Fastest fix: fetch the same URL with a mobile user-agent, view the raw HTML (not the live DOM), and diff it against the desktop HTML. Close every gap in body content, JSON-LD, <a href> links, and alt text, then request re-indexing on the worst-hit pages. Full recovery typically takes 4-8 weeks.

This article is about missing desktop-only signals, not about mobile usability (covered separately). As of June 2026 mobile-first is the only mode Google runs — there is no opt-out and no desktop fallback for sites that have a mobile version.

One thing to clear up first: accordions and tabs are fine

A common false lead: people see content tucked into accordions or tabs on mobile and assume that is the problem. It is not. Google’s own guidance is explicit:

You can have a different design on mobile to maximize user experience (for example, moving content into accordions or tabs); just make sure that the content is equivalent to the desktop site.

Googlebot reads collapsed accordion and tab content regardless of its visible state, as long as the text is present in the rendered HTML. What Google does not index is the next category.

Common causes

1. Primary content is lazy-loaded on user interaction

This is the one that actually deindexes content. If a section only fetches its body after a click, swipe, tap, or keystroke, Googlebot never sees it. Google states this directly:

Don’t lazy-load primary content upon user interaction. Google won’t load content that requires user interactions (for example, swiping, clicking, or typing) to load.

A “Show details” button that runs fetch() on click, or infinite-scroll comments that only load on scroll, fall into this trap. Accordions that already contain their text in the HTML do not.

How to spot it: open the mobile URL and use “View source” (the raw HTML), not “Inspect” (the live DOM). If a section body is absent from raw source and only appears after you interact, it is missing from the index.

2. Mobile site is a separate m.example.com subdomain with thinner content

A legacy m-dot setup built years ago: shorter intros, no FAQ, no related links. Google now treats m.example.com as canonical and ignores the desktop’s richer content.

How to spot it: compare m.example.com/article/x against www.example.com/article/x side by side. Count words, count internal links. If mobile is materially shorter, that is the problem.

3. Structured data only on the desktop template (or pointing at desktop URLs)

Desktop emits Article, Breadcrumb, Product JSON-LD; the responsive template skips JSON-LD on small viewports “to reduce payload,” or the mobile JSON-LD still hard-codes desktop URLs. Google requires parity here:

Make sure that your mobile and desktop sites have the same structured data… Make sure that URLs in the structured data on the mobile versions are updated to the mobile URLs.

How to spot it: mobile URL → view source → grep for application/ld+json. Compare the count and @type values against desktop, and confirm any URLs inside point to the mobile/canonical version.

Note: Google deprecated FAQ rich results on 7 May 2026, with the Search Console FAQ report and Rich Results Test support removed in June 2026. FAQPage markup is still valid Schema.org and Google still parses it (as do Bing and AI answer engines), so keep it — just don’t expect a visible FAQ panel in Google’s SERP, and don’t blame the indexing drop on missing FAQ rich results.

Desktop has a sidebar of 20 related articles, author bio, and archive links. Mobile collapses everything into a hamburger menu whose links are injected by JS only on tap. Googlebot loses those internal-link signals, which weakens crawl discovery and link equity.

How to spot it:

curl -s -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15" \
  "https://yoursite.com/article/x" | grep -o '<a href=' | wc -l

Compare that count against a desktop-UA fetch. A large drop means the mobile HTML is link-starved.

5. Images missing alt text or a thinner srcset on mobile

Desktop ships <img alt="detailed alt text">; mobile uses a different <picture> element without alt, or a thumbnail-only source. Image Search rankings collapse. Google’s requirement is explicit: “Make sure that the mobile site has the same alt text for images as the desktop site.”

How to spot it: mobile view source → grep <img. Look for missing alt= attributes or image URLs that differ from desktop.

6. Robots meta or canonical differs across viewports

A buggy template emits <meta name="robots" content="noindex"> only on the mobile viewport (or vice versa), or the canonical points to a different URL based on user-agent. Google’s rule: “Use the same robots meta tags on the mobile and desktop site.”

How to spot it: fetch the same URL with a desktop UA and a mobile UA, then compare the <meta name="robots"> and <link rel="canonical"> tags. Any difference is a bug.

7. Legacy AMP page set as the mobile canonical

If you still run AMP and the AMP variant is the indexed canonical, AMP validation errors or missing content there hurt the page directly. AMP is effectively end-of-life: it lost its Top Stories and badge advantages years ago, and the Search Console AMP report is being wound down. Standard HTML with good Core Web Vitals does everything AMP used to.

How to spot it: check whether your pages still serve <link rel="amphtml"> and whether Search Console reports the AMP URL as canonical. If so, retiring AMP and serving one responsive page is the durable fix.

Which bucket are you in?

Symptom in the mobile raw HTMLLikely causeSection
Section bodies appear only after click/scrollLazy-load on interaction#1
Word count far below desktop, separate hostm-dot thin content#2
application/ld+json count lower than desktopConditional structured data#3
<a href> count far below desktopJS-injected nav links#4
<img> tags lack alt or use different URLsMobile image template#5
robots/canonical differ by UATemplate/UA bug#6
Page serves rel="amphtml", AMP is canonicalBroken/legacy AMP#7

Shortest path to fix

Step 1: Audit content parity

Pick 20 representative pages. For each, capture desktop and mobile HTML and compare word count, link count, JSON-LD blocks, image count, and alt text.

for url in /article/a /article/b /category/c; do
  echo "=== $url ==="
  printf 'desktop words: '
  curl -s -A "Mozilla/5.0 (X11; Linux x86_64)" "https://yoursite.com$url" | wc -w
  printf 'mobile words:  '
  curl -s -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" "https://yoursite.com$url" | wc -w
done

Any gap over 10% needs closing. (curl shows the server-rendered HTML, not the JS-hydrated DOM — which is exactly the view that matters for the interaction-lazy-load trap. To see what Googlebot renders after JS, use the URL Inspection tool’s “View crawled page” / “Test live URL” and read the rendered HTML there.)

Step 2: Move interaction-gated content into the rendered HTML

If a section’s body only arrives after a user action, it will not be indexed. Put the text in the HTML and let CSS or a toggle control visibility.

<!-- Bad: body only renders on click -->
<button onclick="loadSection()">Show details</button>
<div id="details"></div>

<!-- Good: content is in the HTML, hidden by CSS, JS only toggles visibility -->
<details>
  <summary>Show details</summary>
  <div>The actual content lives here in the raw HTML.</div>
</details>

Step 3: Consolidate m-dot into responsive

If you still run m.example.com, the durable fix is one responsive site at www.example.com. Short-term, give the m-dot the same content, structured data, and internal links as desktop, with correct bidirectional rel="alternate" (desktop → mobile) and rel="canonical" (mobile → desktop).

Step 4: Emit structured data on every viewport

JSON-LD must be in the HTML regardless of screen size, and any URLs inside it must point to the canonical/mobile URL. Never inject it conditionally on viewport width or user-agent.

The hamburger menu’s links should be real <a href> elements present in the HTML and hidden by CSS, not links injected by JS on tap:

<nav class="mobile-nav">
  <a href="/categories/">Categories</a>
  <a href="/authors/">Authors</a>
  <a href="/archive/">Archive</a>
</nav>

CSS then shows or hides the nav on toggle.

Step 6: Unify meta tags

Confirm <meta name="robots">, <link rel="canonical">, and <meta name="description"> are identical across desktop and mobile viewports. Render them server-side, not from JS.

Step 7: Resubmit affected URLs

After parity is restored, open URL Inspection on the worst-hit pages and click “Request indexing.” Search Console caps manual submissions at roughly 10-12 URLs per day per property, so prioritize and let your XML sitemap carry the rest. A single recrawl is usually picked up in 24-48 hours; full recovery of impressions typically takes 4-8 weeks.

How to confirm it’s fixed

  1. Live test: URL Inspection → “Test live URL” → “View crawled page” → “More info” → “HTML.” The rendered HTML now contains the formerly-missing text, links, and JSON-LD.
  2. Parity diff: re-run the Step 1 curl loop. Desktop and mobile word counts are within 10%.
  3. Search Console, 2-4 weeks out: the Pages report shows valid pages climbing back, and the Performance report shows impressions recovering on the affected queries. Filter Performance by the impacted pages to watch the curve specifically.

When this is not on you

Some impression movement after the mobile-first transition is normal even with perfect parity — the SERP itself shifts. Drops over 25% concentrated on your own pages are almost always a content-parity gap, not noise.

Easy to misdiagnose as

A Core Web Vitals or page-experience change. Page experience is real but acts as a tiebreaker between otherwise comparable results; it does not erase 30% of impressions on its own. A sharp drop right after the mobile-first switch is almost always a content-parity issue, not CWV. (Separately, a known Search Console reporting glitch caused phantom impression drops in early 2026 — verify the loss in the live Performance report, not a cached dashboard, before you start fixing.)

Prevention

  • Single responsive codebase; avoid m-dot subdomains.
  • Never gate primary content behind a JS-required interaction on mobile.
  • All structured data lives in the server-rendered HTML, with mobile URLs inside it.
  • Run a desktop-vs-mobile HTML diff in CI for a sample of pages.
  • Audit alt text on every image regardless of viewport.

FAQ

  • Can I opt out of mobile-first indexing? No. As of June 2026 it is the only mode; there is no toggle and no desktop fallback for sites with a mobile version.
  • Does Google still look at desktop content at all? Only as a rare fallback for sites with no mobile version. If you have a mobile page, assume desktop-only content is unseen.
  • Are accordions and tabs safe on mobile? Yes, as long as the text is in the rendered HTML. Google reads collapsed content. The danger is content that loads only after a user interaction.
  • Will retiring AMP hurt my rankings? For almost all sites, no. AMP lost its ranking advantages years ago; a fast responsive page with good Core Web Vitals matches it. Migrate carefully with redirects so the canonical doesn’t break.
  • How fast does re-indexing happen after I request it? A single URL is usually recrawled within 24-48 hours, but impression recovery across affected pages typically takes 4-8 weeks.

Tags: #SEO #Troubleshooting #Indexing #Search Console #mobile-first #responsive

Related Articles