AI AI 工具指南
独立开发 / 建站指南

GSC 覆盖率按目录排查索引漂移

收录页数动了又说不清原因？把 Search Console 按目录切片，15 分钟把模糊问题变成可调查的具体路径。

发布于: 作者: AI Productivity Guide Team 🌐 查看英文版本

登录 Search Console 发现收录页数比上周掉了 200，或者无原因多了 1500。Pages 报告只显示总数，根本看不出是站的哪一部分在漂。解决办法是按目录切片——15 分钟把「好像不对」变成具体 URL 模式加具体原因。

问题背景

Search Console 默认 Pages 视图显示整个 property 的总数。这对新站头一个月够用，再往后就废了。真实站点会有多个 URL family——文章、分类、标签、搜索、商品页、语言版本。每个 family 有自己的索引节奏，问题也是一个 family 一个 family 出。默认视图把它们平均掉，把信号藏起来。URL prefix property（或者 domain property 上的目录过滤）能让你每次只看一个 family。

判断标准

  • 收录总数环比掉 5% 以上，又没有明显部署。
  • 2-4 周前加了新分类或新内容类型，看不出它有没有进索引。
  • 「Discovered — currently not indexed」或「Crawled — currently not indexed」在涨，不知道是哪个目录。
  • 内容从旧目录迁到新目录，要分开追踪两边的状态。
  • 出双语，想知道是哪边在掉。

快速结论

对站点每个主要 URL family（/articles/、/en/、/zh/、/tags/、/category/），要么单独建一个 URL prefix property，要么用现有 property 的 URL 过滤器。逐目录读一遍 Pages 报告。变动最大的目录是嫌疑，目录内变动最大的状态就是诊断结论。

设置目录级视图

两种方案。A 更快，B 更强。

方案 A：在现有 domain property 里用 URL 过滤。 Pages > Filter > URL contains > /zh/articles/。Apply 后只读这个目录的图表和已收录/未收录拆分。逐目录重复。零配置，但视图存不下来，也没法按目录订阅邮件提醒。

方案 B：每个目录建 URL prefix property。 Settings > Add property > URL prefix > 粘贴 https://yoursite.com/zh/articles/。验证（通常自动继承 domain property 的验证）。每个 prefix 有自己的 Pages、performance 报告和邮件提醒。配置稍多，长期监控强很多。

看目录级 Pages 报告

进入一个目录，盯三个数：

  1. 已收录页数——和这个目录实际拥有的 URL 数比。1200 篇的目录只收录 800，缺口 33%，要查。
  2. 未收录及原因——按数量排序。第一名就是最大漏点。
  3. 90 天趋势——平滑增长才健康。陡降或台阶意味着某次部署，记下日期。

按目录最常见的发现及典型原因：

  • 标签/分类目录在缩：薄内容算法终于查到。要么把页面充实，要么 noindex。
  • 文章目录在缩：模板改动后 canonical 或 hreflang 配错了。抽 5 个 URL 用 URL Inspection 验证。
  • 搜索/过滤 URL 在「Discovered, not indexed」涨：站内搜索在漏 URL。加 noindex、减少内链。
  • 一种语言比另一种小很多：hreflang 不匹配，或者该语言 sitemap 没提交。

15 分钟调试脚本

1. 打开 Search Console，切到覆盖嫌疑目录的 property。
2. Pages > URL filter > 粘贴目录路径。
3. 读已收录数。和预期比。
4. 逐个点开「未收录」原因——看示例 URL。
5. 挑同一原因下 3 个 URL，逐个跑 URL Inspection。
6. 比较 live test 和 indexed 结果，找分叉点。
7. 把分叉日期和部署日志对照。

这套脚本能在 15 分钟内抓到 80% 的索引漂移。剩下 20% 要翻服务器日志、sitemap 状态或 canonical 链——至少你已经知道是哪个目录。

用快照基线追踪变化

Search Console 里最被低估的操作是每周导出一份目录级数据。Pages 报告 > 右上 Export > Google Sheets。按日期保存。三周后你就有一张小表，漂移一眼能看出——某个目录的数偏离正常区间，当周就能发现，不用两个月后才意识到。

独立站三列就够：日期、目录、已收录数。第四列填这一周最大的「未收录」原因。每周一花 10 分钟更新一次。第一次某个数突变时，你手上已经有历史对照。

和 sitemap、服务器日志交叉验证

Search Console 的目录视图回答的是「Google 怎么决定」。它不告诉你 Google 有没有看到过这个 URL。这要看另外两处。

sitemap 状态（Indexing > Sitemaps）显示每份 sitemap 的提交数。如果你按目录拆了 sitemap（/sitemap-articles.xml、/sitemap-tags.xml），每份 sitemap 的「发现 vs 收录」缺口就是最精确的目录报告。

服务器日志（或 Cloudflare analytics）显示 Googlebot 真实抓取的路径。如果某个目录收录在掉，而日志显示 Googlebot 根本没抓——问题在上游：robots.txt、坏掉的内链、sitemap 回归——不是页面质量。

容易踩的坑

  • 不切片直接看全站 Pages 图周对周比较。两个目录反向变动会互相抵消，看到的是平直线，把两个问题都藏起来。
  • 忘了 Pages 报告滞后 2-3 天。今天部署的，周三才在报告里出现。
  • 加了 URL prefix property 但忘了给它提交 sitemap。没 sitemap 也能用，提交了报告的准确度更高。
  • 该用 exact match 时用了 contains。/articles/ 也会匹配 /draft-articles/，把数据冲大。
  • 把「Crawled — not indexed」当 bug 读。有时只是「Google 暂时觉得这页还不值得收录」。改内容质量，别反复 Request indexing。

FAQ

  • 要建多少 folder property？: 每个主要 URL family 一个。多数站 5-10 个就够：articles、blog、category、tags、search，加双语再翻倍。
  • 加 property 会拖慢主 property 吗？: 不会。它们是同一份数据的独立视图。
  • 能按目录看 canonical 问题吗？: 能。「Duplicate, Google chose different canonical」在目录过滤里也能看到。canonical 相关部署后用这个。
  • 目录不是 URL 而是 query string 怎么办？: URL filter 支持 contains，?type=article 可以。URL prefix property 不支持。query string 用方案 A。
  • 新 URL prefix property 多久有数据？: 一般 2-3 天。performance 数据会回填 16 个月，Pages 数据从零开始。

相关阅读

标签: #独立开发 #SEO #Search Console #收录 #调试

相关文章