Search Console 像个红色警报喷泉。多数是噪音——Google 的索引 pipeline 本身就不稳，会涌出几十个”问题”，其实是上报伪影，不是真的排名问题。对每个红色都做出反应会耗光你一周，还很少真的拉动排名。这套流程把 AI 当分流助理：把导出文件粘进去、拿到按紧急度排好的短名单、再到真实 URL 抽查确认、最后只修真正的阻塞。每周专注 30 分钟，比每周慌张地点 2 小时强得多。
一句话总结
- 导出截至 2026 年 6 月 Search Console 里仍然存在的三份报告——Page Indexing、Core Web Vitals、HTTPS——再加上 Manual Actions 和 Security Issues 的截图。
- 把每份导出粘给 ChatGPT（GPT-5.5）、Claude（Sonnet 4.6）或 Gemini 3.1 Pro，用一个固定 prompt，忽略影响少于 10 个 URL 的问题（除非落在变现页上）。
- 动手前，每个”阻塞”都先在无痕窗口里打开真实 URL 复现。Search Console 数据滞后真实情况 2-7 天，很多被标的问题其实早就修好了。
- 分成 阻塞 / 风险 / 噪音 三桶，只修阻塞，重新 inspect，并记下修复日期。每周分流很省事；攒到每月就变成一个大项目了。
Search Console 变了哪些（为什么这很关键）
如果某篇教程让你导出 Mobile Usability（移动设备易用性）报告或 Page Experience（页面体验）报告，那它已经过时了。Google 在 2023 年 12 月 1 日下线了 Mobile Usability 报告、Mobile-Friendly Test 工具及其 API。Page Experience 这个标签页现在只是一个仪表盘，链接到 Core Web Vitals 和 HTTPS——那里没有任何单独可导出的东西。
截至 2026 年 6 月，值得分流的报告是：
| 报告 | 它标记什么 | 能导出吗？ |
|---|---|---|
| Page Indexing | URL 为何被索引/未被索引（404、noindex、已抓取未编入索引、软 404、重定向） | 能（上限 1000 行） |
| Core Web Vitals | LCP / INP / CLS 现场数据，移动端与桌面端分开 | 能 |
| HTTPS | 走 HTTP 或存在 HTTPS 问题的 URL | 能 |
| Manual Actions | Google 反垃圾团队下达的人工处罚 | 不能——直接看 |
| Security Issues | 被黑内容、恶意软件、社会工程 | 不能——直接看 |
Manual Actions 和 Security Issues 不是分流对象。只要它们里面有东西，就别看这篇了，今天就去修——这是少数几种”Search Console 红灯总是真的、总是紧急”的情况。
这篇适合谁看
管 1-5 个站的 SEO 经理、自己负责营销的独立开发者、在小公司管自然流量的内容运营，以及每周打开 Search Console 立刻不知所措的人。Google 大更新后、站点迁移后、或接手一个没有基线的新站时，尤其有用。
开始前准备
- 确认 Search Console 已正确验证、数据是当前的。验证失效 = 分流失效。
- CMS / 主机管理员权限准备好——多数修复要改配置、Header、重定向或 sitemap。
- 建一份 SEO 日志（Notion 或 Google Doc），每次修复记一行：日期、问题、修复、预期影响、实际结果。未来的你需要这份关联数据——修复日期是你能收集到的最高杠杆 SEO 数据。
- 备份好
robots.txt和sitemap.xml。AI 有时给激进建议；回滚要一条命令就能完成。
具体步骤
- 把三份还在线的报告导出为 CSV/Excel。 打开 Page Indexing、Core Web Vitals、HTTPS，点导出按钮分别存下来。截至 2026 年 6 月，界面导出上限是 1000 行。大站可以按目录过滤、分多次导出，或配置 导出到 BigQuery 的 Bulk Data Export（无行数上限）再去查询。另外把 Manual Actions 和 Security Issues 页面截图，让 AI 拿到完整画面。
- 逐份把导出粘给 AI。 用一个固定 prompt：“这是最新的 Search Console Page Indexing 导出。列出最紧急的 3 个问题，每个一句话理由。影响少于 10 个 URL 的忽略，除非落在这些变现关键路径上：[列出你的路径]。” GPT-5.5、Claude Sonnet 4.6 和 Gemini 3.1 Pro 的 100 万 token 上下文都能轻松容下一份 1000 行的导出。
- 每个”紧急”项，要的是验证步骤，不是理论： “最可能的根因是什么？我从浏览器能跑的最快检查是什么？” 你要的是测试方法，不是讲解。
- 无痕模式抽查 2-3 个示例 URL。 问题必须能在线复现。Search Console 样本滞后真实情况 2-7 天，很多问题在你看到时已经修过了。
- 把每个已确认的问题分进三个桶。
- 阻塞——现在就在掉排名：规范页 404、人工操作、sitemap 损坏、本该排名的页面上挂了
noindex。 - 风险——会变成阻塞：Core Web Vitals 从”Good”滑出去、爬取错误缓慢堆积。
- 噪音——Google 的怪癖：软 404 误报、薄长尾页上的”已抓取但当前未编入索引”、上报伪影。
- 阻塞——现在就在掉排名：规范页 404、人工操作、sitemap 损坏、本该排名的页面上挂了
- 只给阻塞起修复方案。 让 AI 给真补丁：“给我把这些路径 301 的精确 Nginx 配置改动”、“写出 schema.org 的 JSON-LD 块”、“重写这段
robots.txt，允许这些路径”。 - 应用修复后，URL Inspection → Request Indexing → 记下修复日期 和预期恢复窗口。截至 2026 年 6 月，手动 Request Indexing 上限大约是每个资源每天 10-12 个 URL，所以要排好优先级。
- 每周重复一次。 Search Console 的漂移会复利。每周分流是个 30 分钟的习惯；攒到每月分流的站，问题累积的速度会超过你修复的速度。
Core Web Vitals：AI 该拿来卡你的那几个数字
CWV 报告是唯一一处”模糊分流会害你”的地方，因为它的及格/不及格边界是精确的。Google 用 现场数据（CrUX） 在 第 75 百分位 评分——某个 URL 分组里至少 75% 的真实访问要在三项指标上都达到”Good”，该分组才算通过。截至 2026 年 6 月的阈值：
| 指标 | Good | 需改进 | Poor |
|---|---|---|---|
| LCP（最大内容绘制） | ≤ 2.5 秒 | 2.5-4.0 秒 | > 4.0 秒 |
| INP（与下一次绘制的交互） | ≤ 200 毫秒 | 200-500 毫秒 | > 500 毫秒 |
| CLS（累积布局偏移） | ≤ 0.1 | 0.1-0.25 | > 0.25 |
注意：INP 已于 2024 年 3 月取代 FID 成为 Core Web Vital，所以任何还在提 First Input Delay 的 prompt 或文档都已过时。当 AI 标出某个 CWV 为”Poor”的分组时，把这些数字交给它，问它具体是哪个指标在失败、以及单点杠杆最高的修法（一般来说：加载靠图片/LCP、INP 靠 JS 执行、CLS 靠给图片/广告预留尺寸）。动手前先在 PageSpeed Insights 里复核那个真实 URL。
第一次怎么跑
先在你熟悉的站上把整套流程跑一遍——熟悉度能帮你 sanity-check AI 的判断。计时：首次端到端通常 60-90 分钟，熟练后掉到 30 分钟。挑 AI 标出的那个最靠前的阻塞，当天就修、记日志，7-14 天后看排名和曝光。第二周改一个变量——更严的忽略阈值、换个模型，或者加入 Performance 报告——看哪个信号更好。
动手前的质量检查
- 每个”阻塞”都在真实 URL 上抽查了吗？不能复现的问题，只会浪费你的时间。
- 记修复日期了吗？没记的话，2-4 周后你没法把修复关联到排名变化。
- 子 10 URL 的问题在忽略吗（除非在变现关键页上）？Google 大量红色都是长尾页上的噪音。
- 修复后重新 inspect 了吗？只点”已提交”不重审，等于猜 Google 看没看到修复。
- 修复可回滚吗？sitemap 和
robots.txt的改动尤其要——备份留着。
容易踩的坑
- 对每个红色都反应。 多数是噪音。用忽略阈值（少于 10 URL 就忽略，除非变现关键）。
- 跳过在线抽查。 Search Console 样本滞后 2-7 天；很多”问题”已经过去了。
- 引用已下线的报告。 还在分流”Mobile Usability”，说明你用的是 2023 年的旧打法——那份报告已经不存在了。
- 不记修复日期。 之后没法把修复关联到排名变化，也就没法学到什么有用。
- 修阻塞的同时修风险。 分散注意力，拖慢真阻塞的解决。
- 不验证就信 AI 的判断。 AI 会自信地标出根本不是问题的问题。抽查不可省。
- 月度做而不是周度做。 漂移会复利；周度很省事，月度变成大项目。
FAQ
- 把 Search Console 导出粘进 ChatGPT 或 Claude 安全吗？：Page Indexing 导出里是资源 URL 加计数——没有任何终端用户数据，敏感度很低，粘给 ChatGPT、Claude 或 Gemini 都没问题。如果你的 URL 本身就保密（预发布路径、内部工具），先把它们去掉或匿名化。
- 应该多久跑一次？：活跃站每周一次，慢内容站双周一次。除非刚迁移或出了重大事故，每天跑都过度。
- AI 知道 Google 最新的报告变化吗？：不可靠——模型训练滞后好几个月，这正是本文要把”Mobile Usability 和 Page Experience 已下线”写死的原因。任何新东西都对照当前的 Google Search Central 文档核实。
- AI 能替我提交 Request Indexing 吗？：手动工具上限大约是每个资源每天 10-12 个 URL；Search Console API 每个站每天约 2000 次 inspection，但不会自动编入索引。修复后手动提交可以；批量自动提交会被限频。
- Performance 报告呢？：每月拉进来做趋势分析（按查询和页面看点击、曝光、排名）。这套分流流程聚焦技术健康；Performance 是叠在上面的策略层。
相关阅读
标签: #教程 #SEO #AI 编程 #Search Console #分流