Mobile SEO Checklist

Mobile-First Indexing means Google predominantly crawls and indexes using a smartphone user agent. There is one index, built from mobile rendering. Three consequences drive this checklist:

1. Content parity is mandatory — content missing on mobile does not exist for ranking.
2. Rendering must work — if mobile JavaScript fails to hydrate, the crawler sees less.
3. Mobile performance is the performance — mobile field data is what Google aggregates.

The practical implication is uncomfortable for teams that design on a large monitor and "check mobile later." Every late-stage mobile fix is really a content or indexing fix, because the desktop version that looked complete was never the version being judged.

Parity is the first failure mode because it is invisible in a desktop browser. Developers often collapse sections, lazy-load lists, or hide navigation to simplify small screens — and remove that content from the index without realizing it.

• Mobile and desktop pages contain the same body content, not a trimmed version.
• All headings present on both versions.
• All internal links present on both versions.
• Images and media on mobile do not hide meaningful content behind interactions.
• Tabs, accordions, and carousels do not hide content from the crawler.
• No content blocked by interstitials or "open in app" walls.
• Structured data present on mobile exactly as on desktop.

The test is mechanical: fetch both DOMs and diff the visible text and links. If the mobile DOM is materially shorter, that is the page Google is ranking.

Metadata is cheap to get wrong because it is usually templated per layout rather than per page. A mobile layout missing a canonical tag, or emitting a different title, produces two competing signals from one URL.

• Title tags identical across versions.
• Meta descriptions identical across versions.
• Meta robots identical — no accidental noindex on mobile only.
• Canonical identical and self-referencing (or correctly pointing for separate mobile URLs).
• hreflang present on mobile if used.
• Structured data present and identical on mobile.

A single noindex that exists only in the mobile template is one of the most damaging and least obvious bugs a site can ship. Verify it in the rendered mobile HTML, not the source template.

Rendering determines whether the crawler sees your content at all. Server-rendered and statically generated pages pass by default; client-rendered apps need deliberate verification.

• Content is present in the served HTML or reliably rendered after JavaScript.
• Test with a live URL inspection to see what the crawler actually receives.
• Avoid lazy-loading primary content that the crawler may not trigger.
• Confirm client-side rendering does not delay or drop content.
• Check for resources blocked by robots.txt that are needed to render.
• Ensure hydration failures degrade to visible content, not a blank state.

The three Core Web Vitals and their official "good" thresholds:

• LCP ≤ 2.5s — optimize the largest contentful element (often the hero image).
• INP ≤ 200ms — keep interactions responsive; break up long tasks.
• CLS ≤ 0.1 — reserve space for images, ads, and embeds to stop layout shifts.
• Measure with field data (real users), not lab tools alone.
• Compress and serve modern image formats; size images for mobile.
• Defer or remove non-critical third-party scripts.
• Test on mid-range devices and slow connections, not just a flagship phone.

Each metric maps to a specific engineering fix. LCP usually means unoptimized hero media or render-blocking resources; INP usually means long JavaScript tasks on the main thread; CLS usually means images or ads without reserved dimensions. Measure the 75th percentile of field data, because a fast office network hides what real users experience.

Usability is not a ranking factor in isolation, but it governs whether the visit becomes a task completion — and engagement behavior feeds back into performance.

• Viewport meta tag set so the page scales correctly.
• Tap targets large enough and spaced to avoid mis-taps.
• Font sizes readable without zoom.
• No intrusive interstitials covering content on load.
• Navigation usable with one hand and a thumb.
• Forms have appropriate input types and autocomplete.
• Sticky elements do not consume most of the viewport.

Mobile menus are the most common source of accidental SEO damage: pages reachable on desktop become unreachable when the mobile menu is a JavaScript-only drawer that the crawler cannot open.

• Breadcrumbs present and usable on mobile.
• Primary navigation reachable without hover-only interactions.
• No orphan pages created by a mobile-only menu.
• URLs identical between versions (responsive design) or correctly alternated.
• Internal links render as real anchors in the mobile DOM.

• Review the Core Web Vitals report for mobile separately from desktop.
• Watch Crawled but Not Indexed for mobile-specific failures.
• Compare mobile and desktop impressions in Google Search Console.
• Re-audit after any template, framework, or third-party script change.

Mobile problems rarely announce themselves. They surface as one of four symptoms, each pointing at a different section above:

• The page ranks on desktop but not mobile — usually a mobile-only noindex, a missing canonical, or rendering that drops content.
• Mobile rankings decay after a redesign — usually content or link parity broke when the layout changed.
• Impressions exist but positions are poor — often a page-experience or engagement problem rather than relevance.
• The page is missing entirely from mobile results — crawl or render failure; check Crawled but Not Indexed.

Start diagnosis from the symptom, not from the checklist top.

Responsive design — one URL, CSS-controlled layout — remains the lowest-risk architecture and the recommended default. Separate mobile URLs (m.example.com) require bidirectional annotations and careful canonical handling, and they multiply every parity risk in this checklist. Dynamic serving (same URL, different HTML by user agent) is technically valid but easy to misconfigure. Unless there is a hard legacy constraint, responsive is the choice that makes most of this page pass by default.

1. Fetch the mobile-rendered HTML and diff content and links against desktop.
2. Verify title, meta robots, and canonical in the rendered mobile output.
3. Check the Core Web Vitals report for mobile and list failing URLs.
4. Open the site on a mid-range device over a throttled connection.
5. Confirm the mobile menu exposes every primary page to the crawler.
6. Log any new issue against the relevant section above and assign a fix.

Run this after every template or framework change; regression is the norm, not the exception.

• Hiding content on mobile to simplify layout, which removes it from the index.
• Assuming responsive design solves everything — responsiveness does not guarantee parity or performance.
• Optimizing only the desktop page while mobile carries the index.
• Blocking render-critical resources in robots.txt.
• Chasing perfect scores on every metric instead of fixing real user problems (Technical Perfectionism).
• Testing only on fast devices and Wi-Fi.
• Treating mobile as a QA step rather than the primary rendering target.

1. Content and metadata parity — without these, nothing else counts.
2. Rendering correctness — make sure the crawler sees the page.
3. Core Web Vitals — field-data pass on the 75th percentile.
4. Usability — tap targets, viewport, interstitials.
5. Polish — everything else.

• Mobile-First Indexing · Core Web Vitals
• Frontend vs Backend Rendering (SEO Impact) · Crawled but Not Indexed
• Breadcrumb Navigation SEO · Structured Data (Schema.org)
• On-Page SEO · Technical Perfectionism
• Technical SEO Audit Checklist · SEO Checklist
• SEO for Developers — rendering and performance for engineers

Mobile is where the index lives, so the checklist should be an operating routine. The XKnow SEO Vault collects the technical notes, testing procedures, and per-industry assets behind this page in Markdown and Obsidian. Use the free checklist here; run the full system from the Vault →.