Search Console 索引问题怎么查?Page Indexing、URL Inspection 与 Crawl Stats 分工
Search Console 索引排错流程:用 Page Indexing 看整体原因,用 URL Inspection 查单页,用 Crawl Stats 核对主机与抓取趋势。
先说结论:Page Indexing 回答“全站哪些类型没有进入索引”,URL Inspection 回答“这一条 URL 发生了什么”,Crawl Stats 回答“Google 抓取主机时是否稳定”。 三份报告的数据范围和刷新节奏不同,不能拿一个页面的实时测试去否定全站历史报告。
三个工具分别解决什么
| 工具 | 适合回答 | 不适合回答 |
|---|---|---|
| Page Indexing | 已知 URL 的索引状态分布和未索引原因 | 单条 URL 当前实时可抓取性 |
| URL Inspection | 指定 URL 的发现、抓取、canonical 与索引详情 | 全站覆盖趋势和完整 URL 清单 |
| Crawl Stats | 主机状态、请求量、响应码、下载量和平均响应时间 | 某条页面为什么没有被选入索引 |
Google 官方说明,Page Indexing 展示 Google 已知 URL 的整体索引状态;URL Inspection 用于定位单个页面;Crawl Stats 面向高级用户,主要用来检查抓取历史和主机可用性。
先从 Page Indexing 选问题簇
不要把“未索引”总数直接当故障。robots 阻止、noindex、重定向或重复页可能是预期结果。先筛出重要 canonical 页面,再按原因分组,例如“已抓取但未编入索引”“重复页”“服务器错误”或“被 noindex 排除”。
如果报告中的 URL 总量明显少于实际重要页面,先检查 Sitemap 和内部链接发现;如果只是样例列表不完整,要注意 Google 的样例并不等于全部数据。
再用 URL Inspection 查代表页
每个问题簇抽 2 至 5 条代表 URL,核对最后抓取时间、抓取允许、索引允许、页面提取和 Google 选择的 canonical。实时测试只表示“现在能否抓取”,不会自动证明页面已经进入索引,也不能覆盖历史抓取结果。
页面刚修复时,先运行实时测试;重要页面通过后再请求抓取。多页面发现应依靠 Sitemap 和内链,不要把逐条请求索引当作长期工作流。Sitemap 的配置方法可参考结构化数据工具分工文章中的发布后验证思路。
遇到 5xx 再看 Crawl Stats
如果 Page Indexing 出现服务器错误,或 URL Inspection 的抓取失败无法稳定复现,再进入 Crawl Stats 查看 Host status、响应码分布和平均响应时间。连续的 5xx、DNS 或连接问题才指向主机层;单条偶发错误应结合服务器日志和具体时间核对。
速度诊断不要只看抓取报告,可结合站内的PageSpeed Insights 与 Search Console 诊断闭环区分真实用户体验与抓取稳定性。
建议固定一张排错记录
记录问题簇、代表 URL、报告日期、最后抓取时间、用户声明 canonical、Google canonical、实时测试结果、服务器日志证据、修复动作和复查日期。这样可以分清“报告尚未刷新”和“问题仍然存在”。
常见问题
URL Inspection 显示可编入索引,为什么还搜不到?
可编入索引只是资格判断,不是收录保证。还要看 Google 是否已抓取、是否选择该 canonical,以及内容质量和发现信号。
Page Indexing 与 URL Inspection 结果不一致怎么办?
先比较各自的抓取和更新时间。URL Inspection 的实时测试是当前状态,索引数据和 Page Indexing 可能来自更早的处理批次,应在修复后留出复查窗口。
小网站需要每天看 Crawl Stats 吗?
通常不需要。Google 官方说明该报告主要面向较大站点和高级排错;小站应优先保证重要页面可访问、可内链、Sitemap 正确和内容有价值。
核验来源
- Google Search Console:Page indexing report
- Google Search Console:URL Inspection
- Google Search Console:Crawl Stats report
- Google Search Console:Sitemaps report
本文是工具排错流程,不代表 Google 对具体页面的索引承诺。