Mobile and desktop content parity

Google has indexed the mobile version of every site since 2019. The mobile DOM is the canonical DOM. If content exists on desktop but not on mobile — collapsed inside display: none, behind a “Read more” that never expands server-side, or simply omitted from the responsive template — Google may not see it at all.

Why it matters

The crawler that reads your site is Googlebot Smartphone, a Chromium-based renderer with a mobile viewport. What it sees in the rendered mobile HTML is what gets indexed. Common patterns that silently kill content:

• Desktop has a full footer with 40 site-wide links; mobile has 4. The 36 missing links don’t pass internal authority on the mobile version.
• Desktop renders 2,000 words of product detail; mobile collapses the same content behind a tab and only renders the heading. If the tab content requires a click to render server-side, it’s not indexed.
• Desktop and mobile are served from separate codebases (m.example.com vs www.example.com) and have drifted apart over years.

This is not about visual hiding (display: none on rendered content is fine — Google sees the DOM, not the styles). It’s about content that’s structurally absent or loaded only on user interaction.

How to detect it

The fastest signal: use Search Console → URL Inspection → Test Live URL → View Tested Page. The “HTML” tab shows exactly what Googlebot Smartphone rendered. Compare it byte-for-byte against your desktop HTML.

A quick programmatic check:

# Mobile rendering
curl -A "Mozilla/5.0 (Linux; Android 10) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Mobile Safari/537.36" \
  -s https://example.com/some/page > mobile.html

# Desktop rendering
curl -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" \
  -s https://example.com/some/page > desktop.html

# Diff word counts
wc -w mobile.html desktop.html

A material gap — more than ~10% — is worth investigating. Note that this only captures the initial HTML response. If the site relies on client-side rendering, you need a headless browser to compare rendered DOMs.

The fix

Universal — same content, different presentation

The principle: render the same content to mobile and desktop. Use CSS to change presentation, not server logic to change content.

<!-- Good: same content rendered, CSS controls display -->
<section class="product-details">
  <h2>Specifications</h2>
  <div class="specs">…full content…</div>
</section>

<style>
  /* Collapsed on mobile but content is in the DOM */
  @media (max-width: 768px) {
    .specs { max-height: 200px; overflow: hidden; }
    .specs.expanded { max-height: none; }
  }
</style>

<!-- Bad: content omitted server-side based on user agent -->
{{ if not isMobile }}
  <section>…2,000 words of detail…</section>
{{ end }}

If desktop has a navigation menu with 40 links, the mobile menu must contain the same 40 links — even if it’s behind a hamburger button. The links must be in the rendered DOM, not loaded on click.

Tabs and accordions

Server-render the panel content. Use CSS or JS to hide and show — not to fetch.

<!-- Right -->
<div class="tabs">
  <button aria-controls="tab1">Overview</button>
  <button aria-controls="tab2">Specs</button>
  <div id="tab1">…full overview content…</div>
  <div id="tab2">…full specs content…</div>
</div>

<!-- Wrong: fetched on click -->
<button onclick="fetch('/api/specs').then(...)">Specs</button>
<div id="tab-content"></div>

WordPress

Themes that switch to a stripped-down mobile template via wp_is_mobile() are a red flag. Most modern themes use responsive CSS instead — verify by viewing source on mobile and desktop and confirming the same DOM is delivered.

Next.js / React

Don’t conditionally render based on a UA check that runs server-side. Render the full content; toggle presentation via CSS media queries or a client-only useMediaQuery hook (which still renders the content into the initial HTML).

Common pitfalls

• m.example.com separate site. Mobile subdomains were the 2012 pattern. Google still supports them, but maintaining content parity across two codebases is the actual problem. Consolidate to one responsive site.
• AMP as the mobile version. AMP is deprecated as a discovery requirement. Google indexes the canonical (non-AMP) URL; AMP pages no longer get preferential treatment in Top Stories. Remove AMP if it’s drifted from the canonical.
• Lazy-loaded sections. A section loaded via IntersectionObserver when the user scrolls is fine — Googlebot scrolls. A section loaded only on click is not.
• Different titles or H1s per viewport. Pick one. The mobile version wins under mobile-first indexing.