本文约 2,863 字，预计阅读 8 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：索引报告里那一堆状态，到底先看哪个
一个改版后的 WordPress 站，GSC 里显示“已编入索引”的页面有 1200 个，“已排除”有 3400 个。站长第一反应是“三千多个页面出问题了”，逐个点开看，发现排除原因里有一半是「已抓取但未编入索引」，还有一批是「替代网页（已正确规范化的网页）」——后者其实是正常状态。
索引报告的价值不在于告诉你“有多少页面”，而在于按原因分组，把技术问题、内容问题和正常的规范化结果区分开。看不懂状态含义，就会把正常状态当成故障去修，或者反过来把真故障当成正常忽略掉。
原理分析：状态其实是三类信号
第一类成功信号：已编入索引（正常参与搜索）、已编入索引（但被 noindex 标记阻止？不存在）。注意 Google 的状态名会随版本微调，界面上还可能看到“网页已编入索引，但被 robots.txt 阻止”——这是一种半成功状态：Google 没抓到页面内容就收录了 URL，SERP 上会出现“由于此网站的 robots.txt 无法抓取本页”的提示，这必须修。
第二类警告信号：已抓取，当前未编入索引、已发现，当前未编入索引。前者说明 Google 抓了但认为不值得索引，后者说明连抓都没抓。这两者是内容与技术问题的主战场。
第三类排除信号（多数是正常的）：替代网页（已正确规范化的网页）（canonical 指向别的页面，符合预期）、已按 noindex 标记排除（你主动标注的）、被 robots.txt 屏蔽（你主动屏蔽的）、重复内容，Google 选择的规范网址与用户不同（需要检查）、软 404、已重定向、抓取时出错、服务器错误 (5xx)。
| 状态分类 | 典型状态 | 是否需要处理 |
|---|---|---|
| 成功 | 已编入索引 | 否，监控即可 |
| 半成功 | 已编入索引但被 robots.txt 阻止 | 是，放开抓取 |
| 警告 | 已抓取未索引 / 已发现未索引 | 是，见专项排查 |
| 正常排除 | noindex 排除 / 规范化替代 | 否 |
| 异常排除 | 软 404 / 5xx / 重定向异常 | 是 |
| 异常排除 | 重复且规范选择不符预期 | 是，修正 canonical |
保姆级实操
步骤 1：先按「排除原因」倒序排列看数量分布。 打开 GSC → 索引 → 网页，滚到「未编入索引的原因」区域。不要点开单个页面，先看哪个原因占大头。
步骤 2：确认「已编入索引但被 robots.txt 阻止」必须优先修。 这类页面在 SERP 上展现极差（没有摘要）。修法是放开 robots 对该路径的抓取，然后用 URL 检查工具请求重新抓取。
步骤 3：导出问题清单。 报告支持导出列表（CSV/表格），导出后按 URL 模式归类——通常问题集中在某一类路径（比如全部的 /tag/、/author/、某个参数目录），归类后一次性处理。
步骤 4：用 URL Inspection API 做批量核实。 界面上的 URL 检查工具一次只能查一条，做抽样核实时用接口更实际。接口地址与字段如下：
# URL Inspection API：批量抽样核实页面的索引状态
ACCESS_TOKEN="YA29.a0AfH6SMBx..."
inspect () {
curl -s -X POST \
-H "Authorization: Bearer ${ACCESS_TOKEN}" \
-H "Content-Type: application/json" \
-d "{\"inspectionUrl\":\"$1\",\"siteUrl\":\"https://www.example.com/\"}" \
"https://searchconsole.googleapis.com/v1/urlInspection/index:inspect" \
| python -c "import sys,json;d=json.load(sys.stdin)['inspectionResult'];\
print('$1', d['indexStatusResult']['verdict'], '|', d['indexStatusResult'].get('coverageState',''))"
}
inspect "https://www.example.com/blog/seo-guide/"
inspect "https://www.example.com/tag/wordpress/"
inspect "https://www.example.com/?p=123"
步骤 5：处理后用「验证修复」跟踪。 每一个排除原因分组里都有「验证修复」按钮，点击后 Google 会在一段时间内重新抓取该组页面。这不是即时生效，通常要等一到数周才能看到状态更新。
步骤 6：建立基线。 每月记录一次各状态的页面数量。索引报告没有历史对比功能，不自己留存就无法判断趋势。
常见踩坑
- 把「替代网页（已正确规范化）」当成问题。 canonical 生效的正常结果，不需要处理。
- 忽略「已编入索引但被 robots.txt 阻止」。 这是最容易被漏掉却影响最大的状态。
- 导出后逐个处理而不归类。 同类 URL 应该一次性用规则或模板解决。
- 点了「验证修复」就期待秒生效。 Google 的重新抓取有配额，大规模站点会持续很久。
- 只关注排除数，不看「已编入索引」的构成。 索引里混着大量无价值页面同样是问题。
- 跨资源看数据。 网址前缀资源看不到子域，会被误判为“页面消失了”。
- 案例： 一个站点报告里 1800 个页面显示「已抓取，当前未编入索引」，团队排查两个月无果。最后按 URL 模式归类发现，其中 1700 个都是
/product/?color=xx&size=xx这类筛选组合页，正文内容几乎完全相同。把筛选页改为 canonical 指向父级 + 少数有真实内容的组合放开索引后，剩下的 100 个才是真正的内容问题。先归类再排查，能省掉 90% 的工作量。
总结
索引报告的使用顺序是：看排除原因的分组 → 优先处理「已编入索引但被 robots.txt 阻止」→ 按 URL 模式归类后再排查 → 修正后用「验证修复」跟踪 → 每月留存基线。判断标准也清晰：排除原因里属于规范化、noindex、robots 主动屏蔽的，是设计内的正常结果；属于软 404、5xx、抓取异常、以及大量「已抓取未索引」的，才是真正需要投入的故障。这套顺序能让你避免在正常状态上耗时间。
