一句话答案
移动优先索引的过渡已全面完成。自2024年7月起，Google 仅使用你网站的移动版进行索引和排名。如果某些内容、结构化数据或内链在桌面端存在但在移动端不存在，Google 就看不到它们。到2026年，这带来了三个大多数网站所有者尚未应对的新变化：INP 取代 FID 成为 Core Web Vital 指标，AI Overviews 从移动端渲染内容中提取信息，以及 2026年3月核心算法更新提高了移动端页面体验的排名权重。
以下是完整的审计工作流——以及一个可直接复制粘贴的 Codex skill，能帮你自动运行大部分检查。
2026年「仅限移动端」的真正含义
Google 从2018年开始将网站迁移到移动优先索引。这一过渡历时六年多。截至2024年7月，所有仍然在桌面端存在但移动端没有对应内容的网站，其桌面端独有的内容已从 Google 索引中消失。没有退出选项，也没有桌面端回退机制。
但故事并未就此结束。2025至2026年的三个变化改变了「移动优先」对你网站的要求：
变化一：INP 取代了 FID——大多数移动站点未能达标
2024年3月，Google 用 Interaction to Next Paint（INP） 取代了 First Input Delay（FID），将其作为 Core Web Vital 指标。INP 衡量的是页面在整个访问会话内对点击、触摸和键盘输入的响应速度，而不仅仅是首次交互。
关键数据：约有 40% 通过 FID 的网站未能通过 INP。在移动端，仅有约 65% 的网站达到「良好」阈值（200 毫秒或以下）。2026年3月核心算法更新进一步提升了 Core Web Vitals 的排名权重。移动端 INP 不合格的网站，其排名正在被速度更快的竞争对手夺走。
变化二：AI Overviews 和 AI 爬虫读取你的移动端内容
截至2026年年中，Google 的 AI Overviews 出现在约 47% 的搜索结果中。当 Google 的 AI 系统生成答案时，它们从与常规搜索相同的移动端索引内容中提取信息。第三方 AI 爬虫（GPTBot、ClaudeBot、PerplexityBot）也会访问你移动端渲染的页面。
如果你的移动版缺少结构化数据、清晰的标题层级或关键正文内容，AI 系统就无法引用你——即使桌面版本包含这些内容。
变化三：内容一致性差距已有可衡量的排名影响
2026年，移动端与桌面端内容不一致的网站，其自然搜索曝光量平均比内容完全一致的网站低 31.2%。移动端最常见的内容缺失包括：隐藏标签页内容、侧边栏链接、结构化数据标记、图片 alt 文本和内链导航。
内容元素 | 移动端缺失该元素的网站占比 |
|---|---|
结构化数据（JSON-LD） | 23% |
内链（菜单、面包屑导航） | 18% |
图片 alt 文本 | 27% |
标签页/折叠面板中的完整文本 | 15% |
Meta robots 标签 | 9% |
如何检查你的网站是否达标（2 分钟版本）
在进行全面审计之前，先检查以下三个信号。每个检查不到一分钟，可以帮你判断是否需要深入排查。
信号一：Google Search Console 索引状态
打开 Google Search Console → 点击设置（左下角齿轮图标）→ 查看「关于」部分。如果「索引爬虫」下显示「Googlebot 智能手机」，说明你的网站已启用移动优先索引。到2026年，这适用于几乎所有网站——但仍需确认。
同时检查：URL 检查工具 → 输入任意重要页面 → 展开「抓取」→ 确认「抓取方式：Googlebot 智能手机」。查看 Google 提供的屏幕截图——这就是 Google 实际看到的内容。如果截图中缺少关键内容，那么索引中也同样缺少。
信号二：PageSpeed Insights 的真实移动端数据
访问 PageSpeed Insights，输入你的 URL，查看「了解你的真实用户正在经历什么」部分。这是 Chrome User Experience Report（CrUX）的真实用户现场数据——与 Google 用于排名的数据完全一致。
如果移动端报告显示 INP（Interaction to Next Paint）为橙色或红色，你正面临一个活跃的排名劣势。绿色通过阈值为低于 200 毫秒。
信号三：Chrome DevTools 移动视口快速检查
打开 Chrome DevTools（F12 或 Cmd+Option+I），点击设备工具栏图标（Ctrl+Shift+M），选择一个移动设备预设（如「Pixel 7」）。重新加载页面。扫描以下问题：
- 需要横向滚动的文本
- 尺寸过小、难以点击的按钮或链接（低于 48×48 CSS 像素）
- 被「阅读更多」折叠隐藏、但 HTML 源文件中不存在的内容
- 覆盖屏幕大部分区域的弹窗
以上每一项，如果背后隐藏的内容或链接与桌面端用户看到的有所不同，就都是移动端索引问题。
30 分钟移动优先审计（配合 Codex）
如今运行完整移动优先审计最快的方式，是交给 AI 编程代理——Claude Code 或 Codex——一个结构化的任务。代理会读取你网站的源代码、对照规则检查，并生成一份按优先级排序的修复清单。
以下是一个完整的 skill 文件。将其复制到你的项目中，然后让你的代理运行。
步骤一：创建 skill 文件
在 .claude/skills/mobile-first-audit/SKILL.md（适用于 Claude Code）或 .codex/skills/mobile-first-audit/SKILL.md（适用于 Codex）中创建一个文件：
name: mobile-first-audit
description: Audit a URL or list of URLs for mobile-first indexing readiness. Checks content parity, Core Web Vitals, structured data, mobile UX, and AI crawler access.
# Mobile-First Indexing Audit
Run a structured mobile-first indexing audit on one or more URLs. The agent must report findings, not make edits, unless the user explicitly approves a fix plan.
## Input
The user provides one or more page URLs. If they provide a sitemap URL or a list of more than 5 URLs, sample 5 URLs that represent different page types (homepage, product page, article, category page, landing page).
## Audit Checklist
For each URL, check and report on all eleven items below. Mark each item as `PASS`, `WARN`, or `FAIL`. Include the evidence for every WARN and FAIL.
### 1. Viewport Meta Tag
Check that `<meta name="viewport" content="width=device-width, initial-scale=1">` is present in the HTML `<head>`. If missing or if it sets a fixed width or disables user-scaling without a valid accessibility reason, mark FAIL.
### 2. Content Parity (Text)
Fetch the page with a desktop user-agent and a mobile user-agent (Googlebot Smartphone). Compare the visible text content. If any text block over 50 words exists on desktop but not in the mobile HTML source, mark WARN. If important body text, headings, or product descriptions are missing, mark FAIL.
### 3. Structured Data Parity
Extract all JSON-LD blocks from both desktop and mobile fetches. If any schema type present on desktop is missing from mobile, mark FAIL. If schema content differs between versions, mark WARN.
### 4. Meta Tags Parity
Compare title, meta description, canonical, robots, and hreflang tags between desktop and mobile versions. Any difference is a WARN. A missing canonical or conflicting robots tag is FAIL.
### 5. Internal Links and Navigation
Count the number of internal `<a href>` links in the desktop and mobile HTML. If the mobile version has 20%+ fewer internal links, mark WARN. If breadcrumb links, category navigation, or footer links present on desktop are missing from mobile, mark FAIL.
### 6. Image Alt Text
Count images in the mobile HTML. Report the number and percentage missing alt attributes. If more than 10% of images lack alt text, mark WARN. If hero images or product images lack alt text, mark FAIL.
### 7. Core Web Vitals (Field Data)
Look up the URL's Chrome UX Report (CrUX) field data. If accessible via PageSpeed Insights API or a direct CrUX lookup, report LCP, INP, and CLS for mobile. Mark thresholds: LCP > 2.5s = WARN, > 4.0s = FAIL. INP > 200ms = WARN, > 500ms = FAIL. CLS > 0.1 = WARN, > 0.25 = FAIL.
If CrUX data is unavailable (insufficient traffic), note this and use lab data from Lighthouse as a fallback with the caveat that lab data is not used for ranking.
### 8. Tap Target Sizing
Inspect CSS for buttons, links, and interactive elements. Flag any element whose computed height or width is under 48 CSS pixels. Flag adjacent interactive elements with less than 8px spacing. Mark WARN for 1-3 violations, FAIL for 4+.
### 9. Font Sizing
Check that body text uses a computed font-size of at least 16px. Flag any text below 12px. Mark WARN if body text is 14-15px, FAIL if below 12px.
### 10. Interstitials and Pop-ups
Visually inspect the mobile viewport. If a pop-up, banner, or interstitial covers more than 30% of the initial viewport and is not legally required (cookie consent, age verification), mark WARN. If the pop-up prevents scrolling or reading content, mark FAIL.
### 11. AI Crawler Access
Check robots.txt for rules blocking GPTBot, ClaudeBot, PerplexityBot, Google-Extended, or OAI-SearchBot. If any AI crawler is blocked, note that as a deliberate choice. If AI crawlers are allowed but the page has no structured data, mark WARN (AI systems rely on structured data for citations).
## Output Format
Produce a Markdown report:
```markdown
# Mobile-First Audit Report
**Date:** YYYY-MM-DD
**URLs audited:** N
**Overall score:** X/11 PASS items per URL average
## Summary
| Check | URL 1 | URL 2 | URL 3 | URL 4 | URL 5 |
|-------|-------|-------|-------|-------|-------|
| 1. Viewport | PASS | PASS | ... | ... | ... |
| ... | ... | ... | ... | ... | ... |
## Detailed Findings
### URL 1: [url]
**FAIL items (must fix):**
- [Item name]: [evidence and fix instructions]
**WARN items (should fix):**
- [Item name]: [evidence and fix instructions]
**PASS items:** [list]
### Priority Fix Queue
1. [Highest priority fix] — affects indexing directly
2. [Next fix] — affects ranking
3. ...Rules
- Do not make any changes to the site without explicit user approval of a fix plan.
- If you cannot check an item because the page requires authentication, note it as "NOT CHECKED — authentication required."
- For CrUX data, use the official Chrome UX Report API or PageSpeed Insights API if available. If neither is accessible, use Lighthouse mobile audit as a fallback.
- Never fabricate metrics, scores, or check results. If data is unavailable, say so.
- Do not access or expose API keys, cookies, tokens, or credentials.
### 步骤二：运行审计
向你的代理发送以下提问：
```text
Run the mobile-first audit skill on [your URL]将你要检查的 URL 替换掉方括号内的占位符，粘贴进去。代理会生成一份报告，针对全部11项检查给出 PASS/WARN/FAIL 结果，以及一个按优先级排序的修复队列。
如果你想一次检查多个页面，可以使用以下提问：
Run the mobile-first audit on these 5 URLs: [URL1, URL2, URL3, URL4, URL5]将你要检查的五个 URL 替换掉占位符。
修复#1：内容一致性——首先检查什么
内容一致性是影响最大的修复项，因为它直接决定了 Google 能够索引哪些内容。以下是最容易出问题的地方及对应的修复方法。
标签页和折叠面板中的隐藏内容
许多网站在移动端会将长内容折叠到标签页、折叠面板或「阅读更多」切换按钮中。这没问题——只要内容在 HTML 源文件中即可——Google 已不再对出于用户体验原因而隐藏的内容进行降级处理。但如果你的标签页是通过 JavaScript 在用户点击后才加载内容的，Googlebot 并不会触发那次点击。这些内容 Google 完全看不到。
如何检查： 在 Chrome DevTools 中，右键点击隐藏内容并选择「检查」。如果在 Elements 面板中能看到文本，说明它在 DOM 中，Google 可以看到。如果 Elements 面板在点击标签页之前显示的是空容器，那说明内容是动态加载的，Google 捕捉不到。
如何修复： 将隐藏内容在服务端渲染到 HTML 中。使用 CSS（display: none 或可见性切换）来控制显示/隐藏行为，而不是通过 JavaScript 注入内容。
移动端缺失结构化数据
结构化数据（JSON-LD）必须存在于移动端 HTML 中。如果你的移动端主题或 AMP 版本使用了不同的模板，这一点很容易被忽略。
如何检查： 打开移动端页面，查看源代码（Cmd+Option+U），搜索 application/ld+json。然后在桌面端做同样的操作。两边应该出现相同的 JSON-LD 块。
如何修复： 确保你的结构化数据在服务端渲染，并以相同的 HTML 响应同时发送给移动端和桌面端。如果你使用的是 CMS，请检查你的 schema 插件或主题是否基于设备检测有条件地加载脚本。
移动端菜单中删除的导航链接
移动端菜单通常会简化或删除桌面端导航中的链接：面包屑导航、分类链接、页脚栏目、侧边栏链接。Google 利用内链来理解网站结构并分配 PageRank。在移动端缺失的链接，在 Google 的链接图中也是缺失的。
如何检查： 分别统计桌面端源代码和移动端源代码中的 <a href> 标签数量。响应式设计的链接数量应当大致相当。如果移动端少 30% 以上，就需要调查哪些链接消失了。
如何修复： 将缺失的导航链接添加到移动端菜单、汉堡菜单或页脚中。优先添加指向重要分类页面、关键文章和父级页面的链接。
修复#2：INP——大多数网站忽视的移动端速度指标
Interaction to Next Paint（INP）衡量的是用户在点击、触摸或按键后，页面在视觉上做出响应所需的时间。阈值是 200 毫秒或以下。
FID 只测量首次交互的输入延迟，而 INP 不同，它测量每一次交互，并报告最差的那一次。这使它的测试标准比 FID 严格得多。
是什么拖累了移动端 INP
按常见程度排序：
- 繁重的 JavaScript 在主线程上运行。 庞大的打包文件、未经优化的 React/Vue 组件以及跟踪脚本会阻塞浏览器对点击做出响应。
- 点击事件处理函数在更新 UI 之前执行了过多工作。 如果一次点击触发了 API 调用、状态更新和 DOM 变更，却没有先显示任何视觉反馈，INP 就会受到影响。
- 第三方标签脚本。 分析脚本、聊天挂件、广告网络和个性化脚本——尤其是当多个标签脚本争抢主线程时。
如何诊断 INP
- 打开 PageSpeed Insights，输入你的 URL，滚动到「了解你的真实用户正在经历什么」部分。「移动端」下的 INP 值就是 Google 所使用的数据。
- 在 Chrome DevTools 中，打开 Performance 面板，点击录制，与页面交互（点击按钮、打开菜单、在输入框中输入内容），然后停止录制。查看长任务（标记为红色，200ms+）。这些就是你的 INP 问题所在。
- 你也可以向你的 AI 代理提问：
**"Check the Core Web Vitals for [URL] and tell me specifically what is hurting INP on mobile. Give me the top 3 fixes in priority order."**如何修复 INP（按优先级排序）
Priority 1: Defer or delay non-critical third-party scripts.
→ Load chat widgets, analytics, and ad tags after the page is interactive.
→ Use <script defer> or load them 3-5 seconds after page load.
Priority 2: Break up long JavaScript tasks.
→ Code-split by route. Lazy-load components below the fold.
→ Move heavy computation to requestIdleCallback() or a Web Worker.
Priority 3: Make click handlers update the UI immediately.
→ Show a loading state, spinner, or disabled button in the first 50ms.
→ Run the actual work (API call, state update) after the visual response.修复#3：AI 爬虫就绪（2026 年新维度）
移动优先索引现在有了一个 AI 层面的维度。当 Google AI Overviews 或第三方 AI 系统回答问题时，它们从同样的移动端索引内容中提取信息。如果你的移动端页面缺少 AI 系统所关注的那些信号，你就会失去引用机会。
AI 系统需要从你的移动端页面获取什么
信号 | 为什么重要 | 快速检查方法 |
|---|---|---|
结构化数据（JSON-LD） | 帮助 AI 系统理解实体、产品、文章和 FAQ | 查看源代码 → 搜索 |
清晰的标题层级 | AI 提取器使用 H1-H4 来解析页面结构 | 浏览你的页面：每个部分是否有描述性标题？ |
简洁的回答块 | AI Overviews 更倾向于页面顶部 2-4 句话的答案 | 你的页面在前 200 字内是否回答了主要问题？ |
robots.txt 允许 AI 爬虫访问 | 如果被阻止，AI 系统无法获取你的内容 | 检查 robots.txt 中是否有 |
llms.txt 文件 | 帮助 AI 系统高效发现你的关键内容 | 检查 |
给你的代理的 AI 就绪快速检查提示词
**"Check [URL] for AI search readiness. Tell me: (1) is JSON-LD structured data present and valid? (2) is there a clear answer to the page's main question in the first 200 words? (3) are AI crawlers allowed in robots.txt? (4) does llms.txt exist at the root? Give me a PASS/FAIL for each and tell me what to fix first."**面向初学者的完整移动优先审计提示词
以下是一组你现在就可以复制到 Claude Code 或 Codex 中使用的提示词。每个提示词完成一项特定的工作——无需任何额外配置，只需要打开代理并指向你的项目或 URL 即可。
提示词 1：单页面移动端审计
Run a mobile-first indexing audit on [YOUR URL HERE].
Check these 8 things and report PASS or FAIL for each with the evidence:
1. Viewport meta tag is correct
2. All body text visible on desktop is also in the mobile HTML source
3. JSON-LD structured data is the same on desktop and mobile
4. Title tag, meta description, and canonical are identical across desktop and mobile
5. Internal link count is roughly equal (not 20%+ fewer on mobile)
6. Images have alt text
7. Mobile Core Web Vitals (LCP, INP, CLS) from CrUX field data if available
8. AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) are not blocked in robots.txt
For each FAIL, give me the exact fix in one sentence.提示词 2：多页面类型的批量审计
I need to audit mobile-first readiness across different page types on my site. Here are 5 URLs, each representing a different template:
1. [HOMEPAGE URL]
2. [PRODUCT PAGE OR SERVICE PAGE URL]
3. [BLOG POST OR ARTICLE URL]
4. [CATEGORY OR COLLECTION PAGE URL]
5. [ABOUT OR CONTACT PAGE URL]
For each URL, check: viewport meta tag, content parity (text + structured data), meta tags consistency, internal links, image alt coverage, and mobile font/tap-target sizing.
Then produce a single table with all 5 URLs as columns and each check as a row. Color-code PASS green, WARN yellow, FAIL red (use emoji 🟢 🟡 🔴 if colors are not supported). Below the table, list the top 3 fixes across all pages in priority order.提示词 3：内容一致性深度排查
Fetch [URL] with both a desktop user-agent and the Googlebot Smartphone user-agent (Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)).
Compare the two versions and report any differences in:
- Visible text content (highlight blocks missing from mobile)
- Structured data (JSON-LD blocks)
- Meta tags (title, description, canonical, robots, hreflang)
- Internal link count and which sections lost links
- Image alt attributes
Do not make any edits. Just produce a diff report.提示词 4：INP 诊断与修复方案
Analyze [URL] for Interaction to Next Paint (INP) issues on mobile.
1. Check if CrUX field data is available and report the current mobile INP value.
2. If CrUX data is unavailable, run a Lighthouse mobile audit and report the Total Blocking Time (TBT) as a proxy indicator.
3. Identify the top 3 JavaScript tasks blocking the main thread during page load and after user interaction.
4. For each problem, give me: the specific file or script causing it, the impact on INP, and the one-line fix.
Format the output as a table: Problem | Source | Impact | Fix.提示词 5：AI 爬虫 + 结构化数据审计
Check [URL] for AI search and AI crawler readiness:
1. Crawl robots.txt at the domain root. List all rules that mention these user-agents: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, OAI-SearchBot, Amazonbot, Bytespider. If any are blocked, flag it.
2. Extract all JSON-LD blocks from the page. Validate each against Schema.org types. Report which types are present and whether they are complete (all required properties filled).
3. Check if /llms.txt exists at the domain root. If it does, report its content summary. If it does not, note that as a missing AI discovery asset.
4. Check if the page has a clear, self-contained answer (2-4 sentences) to its main topic within the first 200 words of body text.
5. Score the page on AI readiness: 0-100. Deduct points for: missing structured data (-30), blocked AI crawlers (-20 per crawler), no llms.txt (-15), no clear answer block (-20), headings not descriptive (-15).常见问题
问：我还能使用独立移动站（m.example.com）吗？技术上可以，但 Google 推荐响应式设计。独立移动端 URL 会增加复杂性：你必须在两套 URL 上保持相同的内容、canonical 标签和 hreflang。一旦出现任何不同步，Google 就会索引最后抓取到的那个版本。响应式设计可以完全消除这一风险。
问：如果我的网站只有桌面版——没有移动版怎么办？如果 Googlebot 智能手机无法访问和渲染你的内容，这些内容就不会被索引。没有例外。2026年一个只有桌面版的网站，对 Google 来说几乎是不可见的。如果你处于这种情况，切换到响应式主题是你最优先的任务。
问：我需要考虑平板尺寸吗？ Googlebot 以智能手机身份抓取，而非平板。因此专注于智能手机视口即可。但平板用户是真实用户——请确保你的响应式设计在中等宽度（768-1024px）下不会出现布局问题。
问：我如何知道我的网站是否已经完成了移动优先过渡？打开 Google Search Console → 设置 → 查看「关于」部分的「索引爬虫：Googlebot 智能手机」。如果显示的是这个，说明你已经处于移动优先索引。到现在为止，几乎所有网站都是如此。
问：Google 还会用桌面端 user-agent 来抓取我的网站吗？会的。Google 偶尔会用桌面端 user-agent 进行抓取，用于特定检查（关联验证、部分结构化数据的重新处理等）。如果你在日志中看到桌面端 Googlebot，不必惊慌。这些访问并不意味着你的网站是桌面优先索引。
问：修复移动优先问题会提升我的 AI Overview 曝光度吗？修复移动优先索引问题能够打好基础。如果你的移动端内容、结构化数据和页面速度都是扎实的，你的内容就具备了被引用的资格——但 Google 的 AI 系统仍会根据相关性、权威性和答案质量来选择引用哪些内容。修复移动优先问题能消除障碍，但并不能保证被 AI 收录。
Author: Julian Mercer，Auspia 14年技术 SEO 从业者。Julian 撰写关于可抓取性、渲染、Schema、网站架构以及使内容可被搜索引擎和 AI 系统发现所需的技术基础的文章。
