Mobile SEO Checklist

TL;DR — Mobile SEO is now just SEO. Google indexes and ranks your site using the mobile version of your pages, so the checklist comes down to three things: make sure your mobile pages have the same content as desktop, make sure they load fast and feel responsive on a phone, and make sure they’re easy to use with a thumb. And ignore the old Mobile-Friendly Test — Google killed it.

Evidence for this claim Google predominantly uses the mobile version of a site's content for indexing and ranking. Scope: Google mobile-first indexing behavior. Confidence: high · Verified: 2026-07-14 Google Search Central: Mobile-first indexing Evidence for this claim Google recommends responsive web design as the easiest mobile configuration to implement and maintain. Scope: Google's implementation recommendation; other supported configurations can work. Confidence: high · Verified: 2026-07-14 Google Search Central: Mobile site configurations

Why mobile SEO is the whole game now

For years “mobile SEO” was a side project — you optimized for desktop, then made sure the site didn’t look broken on a phone. That’s over. Since July 2024 Google uses only the mobile version of your page to decide how you rank, for everyone — including people searching on a desktop. If your phone version is worse than your desktop version, that worse version is the one Google judges you on.

So the modern mobile SEO checklist is short to say and important to get right:

1. Same content on mobile as desktop (“content parity”)

This is the big one. Whatever you want Google to see — your headings, your body text, your images and their alt text, your internal links, your structured data — has to be present in the mobile version of the page. If your mobile template quietly drops a section, hides a paragraph by removing it from the page (not just collapsing it), or trims your internal links, Google may never see that content.

Hiding content inside tabs or accordions on mobile is fine — Google still reads it as long as it’s actually in the page’s code. The problem is content that’s truly missing.

2. Speed and responsiveness on a phone (Core Web Vitals)

Google measures three “Core Web Vitals” separately for mobile and desktop:

• LCP — how fast the biggest thing on screen loads (aim for 2.5 seconds or less).
• INP — how quickly the page reacts when you tap (aim for 200 milliseconds or less).
• CLS — how much the page jumps around as it loads (aim for 0.1 or less).

Mobile usually scores worse than desktop because phones have slower networks and slower chips. The single most common, most damaging mistake: lazy-loading your main hero image. Don’t. Lazy-load images below the fold, never the big one at the top.

3. Easy to use with a thumb

• A correct viewport tag so the page fits the screen: <meta name="viewport" content="width=device-width, initial-scale=1">.
• Tap targets big enough to hit — about 48×48 pixels, with a little space between them.
• Body text at least 16px so nobody has to pinch-zoom.
• No giant popup covering the page the moment someone arrives from search.

The tools you’ve heard of are gone

If a guide tells you to “run Google’s Mobile-Friendly Test,” it’s out of date. Google retired that tool and the Mobile Usability report in Search Console in December 2023. Use these instead: PageSpeed Insights (pagespeed.web.dev), Lighthouse in Chrome, the URL Inspection tool in Search Console, and the Core Web Vitals report.

Want the full audit version — content parity edge cases, the LCP lazy-loading trap with Google’s own admission, INP vs. the old FID metric, interstitial exemptions, the AMP reality, and how Bing differs? Switch to the Advanced tab.

TL;DR — Mobile-first indexing is complete (finalized July 5, 2024) — Google uses your mobile HTML to rank you for all queries on all devices. So the checklist is: (1) content parity — same body text, titles/descriptions, headings, images, alt text, internal links, and structured data on mobile as desktop; (2) Core Web Vitals on mobile — LCP ≤ 2.5s (never lazy-load the LCP image), INP ≤ 200ms (INP replaced FID on March 12, 2024), CLS ≤ 0.1; (3) usability — correct viewport, 48×48px touch targets, ≥16px font, no intrusive interstitials (with real exemptions); (4) audit with current tools — Lighthouse, PageSpeed Insights, URL Inspection, and the CWV report, because the Mobile-Friendly Test and GSC Mobile Usability report were retired December 2023. Responsive design is Google’s recommended setup. AMP gives no ranking advantage since June 2021. Bing does not use mobile-first indexing.

Evidence for this claim Google predominantly uses the mobile version of a site's content for indexing and ranking. Scope: Google mobile-first indexing behavior. Confidence: high · Verified: 2026-07-14 Google Search Central: Mobile-first indexing Evidence for this claim Google recommends responsive web design as the easiest mobile configuration to implement and maintain. Scope: Google's implementation recommendation; other supported configurations can work. Confidence: high · Verified: 2026-07-14 Google Search Central: Mobile site configurations

The baseline: mobile-first indexing is finished

This is the context that makes everything else make sense. Google announced majority completion of mobile-first indexing in October 2023, and the final enforcement landed July 5, 2024: any site that wasn’t accessible to Googlebot Smartphone simply stopped being indexed. There is no desktop-first crawling left.

The implication is the one people still under-rate: the mobile version of your page is the version that determines your rankings for every query, on every device — including desktop searches. You are not optimizing “a mobile experience” off to the side; you’re optimizing the canonical version of your site.

1. Content parity — the #1 technical requirement

If you fix one thing on this list, fix this. Google’s guidance is explicit: “Make sure that your mobile site contains the same content as your desktop site.” That means headings, body text, images, alt text, and internal links all need to match between versions, and “Make sure that the title element and the meta description are equivalent across both versions.”

Practical parity checks:

• Body content present on mobile, not stripped by a leaner mobile template.
• Titles and meta descriptions equivalent across versions.
• Headings (the same H1/H2 structure) present in the mobile HTML.
• Images with the same descriptive alt text, captions, filenames as desktop.
• Internal links present on mobile — don’t drop your link graph in a “simplified” mobile nav.
• Don’t “lazy-load primary content upon user interaction” — if content only appears after a tap, Google may not see it.

Two parity nuances worth internalizing: tabs and accordions are fine. Content reorganized into collapsible UI is still indexed as long as it’s in the DOM — the myth that hiding content in accordions hurts SEO is just that. The real failure mode is content that’s removed from the markup entirely on mobile. And robots meta tags must match — “Use the same robots meta tags on the mobile and desktop site” — or you can accidentally noindex the version Google actually uses.

2. Structured data parity

Same rule, applied to schema. Google’s December 2018 guidance: “If you use structured data on the desktop versions of your pages, you should have the same structured data on the mobile versions of the pages, since with mobile-first indexing, we’ll only use the mobile version of your page for indexing.” Validate it with the Rich Results Test (still active — not deprecated). For separate-URL (m-dot) setups, the URLs inside your structured data must reference the correct mobile URLs.

3. Crawlability and robots

• Don’t block resources (CSS, JS) in robots.txt that are needed to render the mobile page — if Google can’t render it, it can’t see your parity.
• Robots meta tags identical across versions (above).
• For separate URLs, get canonicalization right: the desktop canonical on both versions, rel="alternate" on desktop pointing to the mobile URL.

4. Core Web Vitals on mobile

Google measures CWV “segmented across mobile and desktop devices” at the 75th percentile, and “Core Web Vitals are used by our ranking systems.” Mobile is where the gap shows up — slower networks and CPUs mean roughly 48% of mobile pages pass all three vs. ~56% of desktop, with LCP and INP driving the difference.

The thresholds (good / needs improvement / poor):

• LCP — ≤ 2.5s / 2.5–4.0s / > 4.0s.
• INP — ≤ 200ms / 200–500ms / > 500ms.
• CLS — ≤ 0.1 / 0.1–0.25 / > 0.25.

LCP — never lazy-load the hero image. This is the single most damaging mobile performance mistake, and it’s everywhere. web.dev is blunt: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” Hint priority instead with fetchpriority="high" (a preload or directly on the <img>). Google’s own Martin Splitt admitted Google shipped this bug: their CMS “defaults all images to lazy loading, which is not great.” If Google can do it by accident, so can you.

INP — and why it’s not FID. INP (Interaction to Next Paint) replaced FID on March 12, 2024. FID only measured the delay before the browser could begin processing the first interaction; INP measures the worst interaction delay across the entire page lifetime. That makes it far more sensitive to slow JavaScript on mobile, where touch events on weak CPUs blow past the 200ms threshold easily. If your older audit notes still talk about FID, they’re stale.

CLS — reserve space. Set explicit width and height (or aspect-ratio) on images and embeds, reserve space for ads and late-loading content, and don’t inject content above the fold after load.

5. Images and videos on mobile

• Use modern formats (WebP/AVIF) and supported formats only — a JPG inside inline SVG won’t be indexed.
• Responsive images via srcset + sizes; explicit width/height to prevent CLS.
• Don’t use images that are too small or low-resolution, and avoid constantly-changing image URLs (per-page-load URL generation breaks image indexing).
• Identical alt text, titles, captions, filenames to desktop.
• Videos: supported formats in valid HTML tags (<video>, <embed>, <object>), stable URLs, matching video structured data, placed prominently to minimize scrolling.

6. Mobile usability

• Viewport: <meta name="viewport" content="width=device-width, initial-scale=1">. width=device-width is mandatory. Avoid maximum-scale=1 or user-scalable=no — they block pinch-zoom and Google flags them as accessibility violations. Without a viewport tag at all, mobile browsers render at ~980px desktop width and shrink, which is unusable.
• Touch targets: 48×48 CSS pixels minimum, with at least 8px spacing between adjacent targets (Lighthouse / Material Design standard).
• Font size: ≥16px body text to avoid the “text too small to read” flag.
• Forms: use appropriate input types (tel, email, number) so phones show the right keyboard.

7. Interstitials and ads — and the exemptions

The “any popup will tank your rankings” framing is overstated. What’s penalized is the intrusive kind: “Don’t obscure the entire page with interstitials” and “Don’t redirect the user to a separate page for their consent or input” — full-screen popups before the user engages, standalone interstitial pages.

What’s explicitly allowed: legally required cookie consent banners, login dialogs for genuinely paywalled content, small banners using reasonable screen space, and age gates required by law. And note the ranking nuance — the interstitials signal is not a Core Web Vitals metric. As Google puts it, “Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results. However, they can make your website more satisfying to use.” For ads, follow the Better Ads Standard.

8. AMP: neutral, not dead, not required

AMP lost its ranking advantage in June 2021, when Google removed the AMP requirement for Top Stories eligibility. Any page with good Core Web Vitals can appear in Top Stories now. AMP pages still function — they just offer no SEO benefit over a well-optimized standard page. If you’re on AMP today, weigh migration cost against benefit; the SEO incentive to adopt it is gone.

9. Site configuration: responsive is the recommended path

Three setups, in Google’s order of preference:

1. Responsive design (recommended): same HTML on the same URL; CSS handles layout. One URL, no duplication risk, no parity gap by construction.
2. Dynamic serving: same URL, different HTML by user-agent. Risk: accidentally serving desktop HTML to mobile users.
3. Separate URLs (m-dot): different HTML on different URLs. Requires careful canonicalization and the most parity discipline. John Mueller’s long-standing advice: “At some point all of these sites with separate mobile URLs should just move to a responsive design.”

10. Audit with current, non-deprecated tools

This is the credibility check on any 2025-era mobile checklist. Google retired the Mobile-Friendly Test tool, the Mobile-Friendly Test API, and the GSC Mobile Usability report in early December 2023. Their statement: “Today we’re sunsetting Search Console’s Mobile Usability report, Mobile-Friendly Test tool and Mobile-Friendly Test API,” reasoning that “many other robust resources for evaluating mobile usability have emerged.”

Use these instead:

• PageSpeed Insights (lab + field, mobile tab).
• Lighthouse (Chrome DevTools, mobile mode).
• GSC Core Web Vitals report (field data, filter to mobile).
• GSC URL Inspection (how Googlebot renders a specific page).
• Rich Results Test (validates structured data).
• CrUX Vis (cruxvis.withgoogle.com) — the CrUX Dashboard was deprecated; CrUX Vis is Google’s current historical field-data tool for mobile CWV trends.

Bonus: Bing is different — desktop-first

A genuine divergence most guides miss: Bing does not use mobile-first indexing. Bing’s primary crawl target remains the desktop version of your pages. Mobile-friendliness has been a Bing ranking signal since 2015, but it is not Bing’s indexing methodology. So mobile parity still matters for Bing — for ranking reasons, not because Bing only sees your mobile HTML. Use Bing Webmaster Tools to monitor mobile-related crawl errors, submit sitemaps, and validate structured data.

AI summary

A condensed take on the Advanced version:

• Mobile-first indexing is complete (finalized July 5, 2024). Google ranks you on your mobile HTML for all queries on all devices, including desktop searches.
• Content parity is rule #1. Same body text, titles/meta descriptions, headings, images + alt text, internal links, robots meta tags, and structured data on mobile as desktop. Tabs/accordions are fine; missing content is not.
• Core Web Vitals, measured separately for mobile: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1, at the 75th percentile. Mobile lags desktop (~48% vs ~56% passing).
• Never lazy-load the LCP image — the most common, most damaging mobile mistake; use fetchpriority="high". Google admitted shipping this bug itself.
• INP replaced FID on March 12, 2024 — it measures all interactions across the page lifetime, not just the first, so it’s harsher on slow mobile JS.
• Usability: correct viewport (no user-scalable=no), 48×48px touch targets, ≥16px font, mobile-appropriate form input types.
• Interstitials have exemptions: cookie consent, paywall logins, small banners, legal age gates are allowed; the signal isn’t a CWV metric.
• AMP is neutral — no ranking advantage since June 2021; still functional.
• Responsive design is Google’s recommended setup (vs. dynamic serving and m-dot).
• Tools: Lighthouse, PageSpeed Insights, URL Inspection, CWV report, Rich Results Test, CrUX. The Mobile-Friendly Test and GSC Mobile Usability report were retired December 2023.
• Bing does NOT use mobile-first indexing — it’s desktop-first; mobile-friendliness is a ranking signal, not its indexing method.

Official documentation

Primary-source documentation from the search engines.

Google

• Mobile-First Indexing Best Practices — content parity, viewport, images/videos, robots meta tags, and the three site-configuration options.
• Mobile-first indexing — completion (June 2024) — the final July 5, 2024 milestone.
• Mobile-first is here (October 2023) — the earlier majority-completion announcement.
• Mobile-first indexing and structured data (December 2018) — structured data must match across versions.
• Avoid intrusive interstitials and dialogs — what’s penalized and what’s exempt.
• Understanding page experience in Google Search — how CWV and other page-experience aspects relate to ranking.
• Core Web Vitals and Google Search results — CWV as a ranking input.
• web.dev — Web Vitals (thresholds) — the LCP/INP/CLS thresholds, measured at the 75th percentile across mobile and desktop.
• web.dev — Optimize Largest Contentful Paint — “never lazy-load your LCP image” and fetchpriority.

Bing / Microsoft

• Bing Webmaster Guidelines — mobile-friendliness as a ranking signal (Bing remains desktop-first for indexing).

Quotes from the source

On-the-record statements from Google. Each link is a deep link or the source page for the quoted passage.

Google — content parity

• “Make sure that your mobile site contains the same content as your desktop site.” — Google Search Central docs. Jump to quote
• “Make sure that the title element and the meta description are equivalent across both versions.” Jump to quote
• “Don’t lazy-load primary content upon user interaction.” Jump to quote

Google — structured data parity

• “If you use structured data on the desktop versions of your pages, you should have the same structured data on the mobile versions of the pages, since with mobile-first indexing, we’ll only use the mobile version of your page for indexing.” — Google Search Central blog, December 2018. Source

Google — interstitials

• “Don’t obscure the entire page with interstitials” and “Don’t redirect the user to a separate page for their consent or input.” Source

Google — page experience nuance

• “Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results. However, they can make your website more satisfying to use.” Source

Google — Core Web Vitals

• “Core Web Vitals are used by our ranking systems. We recommend site owners achieve good Core Web Vitals for success with Search.” Source
• “a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” — web.dev. Jump to quote

Google (web.dev) — LCP and lazy loading

• “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” Source

Martin Splitt, Google (via Search Engine Journal)

• “If you are using lazy loading on an image that is immediately visible, that is most likely going to have an impact on your largest contentful paint.” — and on Google’s own CMS: “defaults all images to lazy loading, which is not great.” Read the coverage

Google — retiring the mobile tools

• “Today we’re sunsetting Search Console’s Mobile Usability report, Mobile-Friendly Test tool and Mobile-Friendly Test API.” — and the rationale: “In the nearly ten years since we initially launched this report, many other robust resources for evaluating mobile usability have emerged.” Read the coverage

John Mueller, Google (via Ahrefs’ mobile SEO guide)

• “At some point all of these sites with separate mobile URLs should just move to a responsive design.” Source

The mobile SEO checklist

Work top to bottom. The first group is non-negotiable; the rest sharpen it. Clearing every box below removes the technical blockers Google has named — it doesn’t guarantee rankings, indexing, or identical search-result treatment. Content quality and relevance still decide the rest.

Content parity (the #1 requirement)

• Mobile page contains the same body content as desktop (nothing stripped by a leaner mobile template).
• Title and meta description are equivalent across mobile and desktop.
• Same heading structure (H1/H2…) present in the mobile HTML.
• Same images with the same descriptive alt text, captions, filenames.
• Same internal links present on mobile.
• Structured data matches desktop (validate with the Rich Results Test).
• Robots meta tags identical across versions (no accidental mobile noindex).
• No primary content lazy-loaded on user interaction (tap-to-reveal).

Technical setup

• Configuration is responsive design where possible (vs. dynamic serving / m-dot).
• robots.txt doesn’t block CSS/JS needed to render the mobile page.
• If using m-dot: desktop canonical on both versions, rel="alternate" on desktop → mobile, error pages return matching status codes, both verified in GSC.

Performance / Core Web Vitals (mobile field data)

• LCP ≤ 2.5s — and the LCP image is NOT lazy-loaded (use fetchpriority="high").
• INP ≤ 200ms — audited as INP, not the retired FID.
• CLS ≤ 0.1 — explicit width/height on images/embeds; space reserved for ads and late content.
• Modern image formats (WebP/AVIF), responsive srcset/sizes, stable image URLs.

Usability

• Viewport tag present: width=device-width, initial-scale=1.
• No maximum-scale=1 / user-scalable=no (pinch-zoom not blocked).
• Touch targets ≥ 48×48px with ≥ 8px spacing.
• Body font ≥ 16px.
• Forms use appropriate input types (tel, email, number).
• No intrusive interstitial on the search-to-page transition (cookie/age/login exemptions aside).

Tools (use current ones only)

• Audited with Lighthouse (mobile mode) and PageSpeed Insights.
• Checked the GSC Core Web Vitals report, filtered to mobile.
• Verified rendering with GSC URL Inspection.
• Did not rely on the retired Mobile-Friendly Test or GSC Mobile Usability report (gone since December 2023).

Mobile SEO cheat sheet

What to check → tool → pass/fail

Core Web Vitals thresholds (mobile, 75th percentile)

Fast facts

• Mobile-first indexing completed July 5, 2024 — mobile HTML ranks you everywhere.
• INP replaced FID on March 12, 2024.
• Mobile-Friendly Test + GSC Mobile Usability report retired December 2023.
• AMP — no ranking advantage since June 2021 (Top Stories no longer requires it).
• Bing — desktop-first; mobile-friendliness is a ranking signal, not its index.

The mental models

1. Mobile is the canonical version. Stop thinking “desktop site + a mobile experience.” Since July 2024 the mobile HTML is the version Google indexes and ranks for everyone. Every audit question becomes: “What does Googlebot Smartphone actually see on this page?”

2. Parity → Performance → Usability, in that order. If content is missing on mobile, no amount of speed tuning saves the page — Google can’t rank content it never sees. Get parity right first, then chase Core Web Vitals, then polish thumb-level usability. Spending CWV effort on a page with a parity gap is optimizing the wrong layer.

3. Field data, not lab data, is the ranking input. Lighthouse gives you a lab score in a controlled environment; CrUX/GSC give you real users’ field data at the 75th percentile, and that’s what the ranking systems use. Use the lab to diagnose, the field to judge. A green Lighthouse run with poor field CWV is still a problem.

4. “Use X instead of Y” — the tool-currency rule. The fastest credibility tell in mobile SEO is whether someone still recommends dead tools. Mobile-Friendly Test → Lighthouse / PageSpeed Insights. GSC Mobile Usability report → CWV report + URL Inspection. FID → INP. If your process references the left side of any of those arrows, it’s stale.

5. Penalties have exemptions — read the actual rule. Interstitials don’t universally tank rankings; the rule targets intrusive ones, and cookie consent, paywall logins, small banners, and legal age gates are exempt. When a “rule” sounds absolute, check the source for the carve-outs before you redesign around a myth.

Monthly mobile SEO health check

1. Review mobile field data. Open the Search Console Core Web Vitals report and PageSpeed Insights for representative templates. Record affected URL groups and the metric that changed. Done means every new issue has an owner or a documented reason to monitor.
2. Sample content parity. Compare mobile and desktop crawls for titles, robots, canonicals, headings, primary copy, internal links, images, and structured data. Done means material differences are either intentional layout changes or tickets.
3. Inspect changed templates as Googlebot Smartphone. Use URL Inspection for a sample from each recently released page type. Done means primary content and signals appear in rendered HTML without interaction.
4. Run hands-on usability checks. Test common phone widths for zoom, horizontal overflow, touch targets, forms, navigation, and interstitials. Done means blocking defects are reproducible and assigned.
5. Annotate and compare performance. Segment Search Console mobile performance by template and record releases, migrations, and campaigns. Done means anomalies have a scoped investigation rather than an unqualified site-wide conclusion.

Mobile audit mistakes to avoid

Using retired Google tools as the audit plan

The Mobile-Friendly Test and Search Console Mobile Usability report are gone. Use Lighthouse, PageSpeed Insights, URL Inspection, the Core Web Vitals report, and direct device testing.

Checking only visual layout

A page can look responsive while mobile HTML omits copy, links, directives, images, or structured data. Compare indexable output, not screenshots alone.

Lazy-loading the LCP image

Deferring the primary visual delays the resource that defines LCP. Keep it discoverable in initial markup and prioritize it instead.

Treating accordion content as missing content

Collapsed content is not the problem when it remains in the DOM. Focus on content that the mobile template removes or loads only after interaction.

Applying one lab score to the whole site

One Lighthouse run is diagnostic, not representative field performance. Sample page types and pair lab findings with mobile field data.

Common mobile SEO audit failures

Mobile HTML is missing desktop content

Symptom: A crawl diff shows fewer headings, links, images, or schema items on mobile. Likely cause: Separate templates or user-agent rules have drifted. Fix: Restore the elements from the shared content source and confirm them with a mobile fetch plus URL Inspection.

Lighthouse looks good but field data is poor

Symptom: A controlled lab run passes while mobile Core Web Vitals groups fail. Likely cause: Real devices, networks, interactions, or templates differ from the single test. Fix: Identify affected URL groups and metric distributions, reproduce on representative devices, and optimize the shared bottleneck rather than the sample URL alone.

Pages overflow horizontally on some phones

Symptom: Users must pan sideways despite a viewport meta tag. Likely cause: A fixed-width child, long unbroken value, table, media embed, or transformed element exceeds its container. Fix: Inspect the overflowing node at the failing width, constrain responsive media, and retest zoom plus landscape layouts.

Prompts for mobile SEO auditing

Triage a mobile/desktop crawl diff

Review this crawl comparison with mobile and desktop columns for status, title,
robots, canonical, H1, word count, internal-link count, image count, and structured
data types. Identify material content-parity exceptions, separate likely layout-only
differences, group issues by template, and give a direct verification step for each
group. Do not infer missing content from count differences alone.

[paste CSV]

Convert field-data findings into tickets

Turn these mobile Core Web Vitals findings into implementation tickets. For each URL
group, preserve the observed metric and evidence, distinguish field data from lab
diagnostics, list the most likely shared template causes as hypotheses, and define a
pass/fail validation step. Do not invent a cause or promise a ranking change.

[paste findings]

Test yourself: Mobile SEO

Five quick questions on auditing mobile SEO in a mobile-first world. Pick an answer for each, then check.

Resources worth your time

My related writing

• The Beginner’s Guide to Technical SEO — where mobile fits in the bigger technical picture.
• Mobile SEO (Ahrefs blog, Jamie Grant) — the companion deep dive, including Mueller’s “move to responsive” line.
• Core Web Vitals — the metric hub: LCP, INP, CLS, thresholds, and field vs. lab data.
• Largest Contentful Paint — the LCP deep dive, including the lazy-loading trap.
• Interaction to Next Paint — what INP measures and why mobile struggles with it.
• Mobile-First Indexing — the indexing concept and the verified timeline.

Official

• Google — Mobile-First Indexing Best Practices.
• web.dev — Web Vitals and Optimize LCP.
• Bing Webmaster Guidelines.

From around the industry

• Google Officially Drops Mobile Usability Report, Mobile-Friendly Test Tool and API (Search Engine Land, Dec 2023) — the deprecation, with Google’s statement.
• Google: Why Lazy Loading Can Delay Largest Contentful Paint (LCP) (Search Engine Journal) — Martin Splitt on the LCP lazy-loading trap, including Google’s own CMS mistake.
• Mobile SEO (Ahrefs, Jamie Grant) — comprehensive mobile SEO walkthrough.
• Your Mobile SEO Checklist (Nostra.ai) — checklist-format reference with mobile traffic context.
• r/TechSEO — the community for mobile crawl/render/parity debugging.

Changelog