登录 Search Console，收录页数比上周掉了 200，或者莫名其妙多了 1500。Page indexing（页面收录）报告只给整个 property 一个总数，而这个总数恰好把真正在漂的那部分藏了起来。解决办法是按目录切片：15 分钟把「好像不对」变成一个具体的 URL 模式，外加一个有名有姓的具体原因。
TL;DR
- 默认收录报告把所有 URL family 平均到一起，于是两个反向变动的目录看起来就是一条平直线。
- 用 URL 过滤器（方案 A，零配置）或单独的 URL prefix property（方案 B，可保存 + 邮件提醒）一次只隔离一个目录。
- 每个目录读三个数：已收录数 vs 预期、最大的「未收录」原因、90 天趋势形状。
- 自 Google 2025 年 11 月更新起，「Crawled - currently not indexed」会展开子原因，比如 low quality signals（低质量信号）、insufficient unique content（独特内容不足），直接告诉你这是质量问题还是配置问题。
- 把任何陡降的日期和部署日志对照；抽 3 个 URL 用 URL Inspection 验证（截至 2026 年 6 月，每个 property 每天手动请求收录约 10-12 次封顶）。
为什么默认视图在骗你
Search Console 默认的收录视图显示整个 property 的总数。对新站头一个月够用，再往后就废了。真实站点有多个 URL family：文章、分类、标签、站内搜索、商品页、语言版本。每个 family 有自己的索引节奏，问题通常也是一个 family 一个 family 出。默认视图把它们全平均掉，把信号埋了。
最大的坑是在那张全站图上做周对周比较。如果 /tags/ 在同一周被薄内容算法扫掉 400 页，而 /articles/ 刚好新收录了 400 篇，全站数字读出来就是平的，两件事你都漏掉了。按目录切片是唯一能把它们看出来的办法。
什么时候该用这招
- 收录总数环比掉 5% 以上，又没有明显部署。
- 2-4 周前上线了新分类或新内容类型，看不出它有没有进索引。
- 「Discovered - currently not indexed」或「Crawled - currently not indexed」在涨，不知道是哪个目录贡献的。
- 内容从旧目录迁到新目录，要分开追踪两边的路径。
- 出双语，想知道是哪边在掉。
设置目录级视图
两种方案。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/。URL prefix property 严格锁定这个字符串，不以它开头的 URL 一律排除。验证通常自动继承 domain property。每个 prefix 有自己独立的收录报告、Performance 报告和邮件提醒。
| 方案 A：URL 过滤 | 方案 B：URL prefix property | |
|---|---|---|
| 配置时间 | 无 | 每个目录约 2 分钟 |
| 视图可保存 | 否 | 是（独立 property） |
| 按目录邮件提醒 | 否 | 是 |
支持 query string（?type=article） | 支持（contains） | 不支持（只认路径前缀） |
| 创建时数据回填 | 继承 property 历史 | Performance 回填约 16 个月；收录数据从零开始，约 2-3 天出数 |
| 适合 | 一次性排查 | 每周都盯的目录 |
实战搭法：全站用 domain property，再给每个每周都要看的高价值目录建一个 URL prefix property。Google 官方明确说这两类 property 是互补的，不是二选一。
看目录级报告
进入一个目录，盯三个数：
- 已收录页数 —— 和这个目录实际拥有的 URL 数比。1200 篇的目录只收录 800，缺口 33%，要查。
- 未收录及原因 —— 按数量排序，第一名就是最大漏点。注意：每个原因下的示例 URL 列表最多只显示 1000 条，所以大目录里这些 URL 只是抽样，不是全集。
- 90 天趋势 —— 平滑增长才健康。陡降或台阶意味着某次部署，记下日期。
Google 的收录报告对每个未收录状态都有精确命名。对目录漂移最关键的几个：
| 状态（GSC 原文标签） | 在目录层面通常意味着 | 第一步 |
|---|---|---|
| Crawled - currently not indexed | Google 抓了但没收；2025 年 11 月更新后会展开子原因，如 low quality signals / insufficient unique content | 改页面质量，别只反复 Request indexing |
| Discovered - currently not indexed | Google 知道 URL 存在但还没抓（抓取预算或内链不足） | 加内链、提交该目录的 sitemap |
| Duplicate, Google chose different canonical than user | 你的 canonical 指一个方向，Google 选了另一个 | 检查上次部署后模板里的 canonical |
| Alternate page with proper canonical tag | hreflang/分页的备用页本就如此；只有暴涨才需担心 | 确认是有意为之，不是模板回归 |
| URL marked ‘noindex’ | 命中了 noindex 标签（经常是误带的） | grep 模板；重点查站内搜索和过滤路由 |
| Page with redirect | 目录 URL 被 301 到别处，常见于迁站后 | 把旧→新路径对照，确认重定向是有意的 |
最常见的目录级形态：
- 标签/分类目录在缩 —— 薄内容阈值终于查到。要么把页面充实，要么
noindex。 - 文章目录在缩 —— 模板改动后 canonical 或 hreflang 配错了。抽 5 个 URL 用 URL Inspection 验证。
- 搜索/过滤 URL 在「Discovered, not indexed」涨 —— 站内搜索在漏 URL。加
noindex、减少指向它们的内链。 - 一种语言比另一种小很多 —— hreflang 不匹配，或者该语言的 sitemap 缺失/过期。
15 分钟调试脚本
1. 打开 Search Console，切到覆盖嫌疑目录的 property。
2. Page indexing > URL filter > 粘贴目录路径。
3. 读已收录数。和预期比。
4. 逐个点开「未收录」原因，看示例 URL（以及子原因）。
5. 挑同一原因下 3 个 URL，逐个跑 URL Inspection。
6. 比较 live test 和 indexed 结果，找分叉点。
7. 把分叉日期和部署日志对照。这套脚本能在 15 分钟内抓到约 80% 的索引漂移。剩下 20% 要翻服务器日志、sitemap 状态或 canonical 链——但至少你已经知道是哪个目录。一个配额提醒：截至 2026 年 6 月，URL Inspection 工具里的 Request Indexing 按钮每个 property 每天约 10-12 次封顶（Google 不公布确切数字，到顶后按钮置灰），所以要有的放矢地检查，别乱按一通。
用每周基线快照追踪漂移
Search Console 里最被低估的操作，是每周导出一份目录级数据快照。在收录报告右上角 Export > Google Sheets，按日期存档。三周后你就有一张小表，漂移一眼能看出来：某个目录的数偏离正常区间，当周就能发现，不用两个月后才意识到。
独立站三列就够：日期、目录、已收录数。第四列填这一周最大的「未收录」原因。每周一花 10 分钟更新一次。提醒一个限制：Search Console 的 UI 和导出都封顶在 1000 行，所以大目录就导出计数（基线要的就是计数），万一真要完整 URL 列表，用 Search Console API 或 Search Analytics for Sheets 这类插件去拉。
和 sitemap、服务器日志交叉验证
目录视图回答的是「Google 怎么决定」。它不告诉你 Google 有没有看到过这个 URL。有两处能补上这个缺口。
sitemap 状态（Indexing > Sitemaps）显示每份 sitemap 的提交数。如果你按目录拆了 sitemap（/sitemap-articles.xml、/sitemap-tags.xml），每份 sitemap 的「发现 vs 收录」缺口就是最精确的目录报告。
服务器日志（或 CDN 的分析，比如 Cloudflare）显示 Googlebot 真实抓取的路径。如果某个目录收录在掉，而日志显示 Googlebot 根本没抓——问题在上游：robots.txt、坏掉的内链、或 sitemap 回归——不是页面质量。在采信某条日志前，先按 Google 验证爬虫的官方指南 确认那确实是真 Googlebot。
容易踩的坑
- 不切片直接看全站图做周对周比较。 两个目录反向变动会互相抵消，看到的是平直线，把两个问题都藏起来。
- 忘了报告有滞后。 收录数据不是实时的，它随 Google 重新抓取才更新，所以今天部署的，可能几天后才出现在报告里。（Performance 报告的 impressions 也滞后 2-4 天，低流量站更久。）
- 加了 URL prefix property 却忘了给它提交 sitemap。 没 sitemap 也能用，但提交了能让报告更准更快。
- 该用精确路径时用了
contains。/articles/也会匹配/draft-articles/，把数据冲大。 - 把「Crawled - currently not indexed」当 bug 读。 2025 年 11 月起子原因会说实话：如果写的是 low quality signals 或 insufficient unique content，这页需要改内容，而不是反复请求收录。
FAQ
- 要建多少个目录 property？: 每个主要 URL family 一个。多数站 5-10 个就够——articles、blog、category、tags、search，出双语再每种语言加一个。
- 加 property 会拖慢主 property 吗？: 不会。它们是同一份底层数据的独立视图，互不抢资源。
- 能按目录看 canonical 问题吗？: 能。「Duplicate, Google chose different canonical than user」在目录过滤里也能看到。canonical 相关部署后立刻用它。
- 我的目录是 query string 不是路径，怎么办？: 用方案 A。URL 过滤器支持
contains，?type=article可以。URL prefix property 只认路径前缀，做不了 query string。 - 新 URL prefix property 多久有数据？: 收录数据一般 2-3 天。Performance 数据会回填约 16 个月；收录数据从创建时从零开始。
- 2025 年 11 月那次 GSC 更新改了什么？: 收录报告加了更细的排除子原因。「Crawled - currently not indexed」现在能区分质量信号（如 insufficient unique content）和技术性排除，让「质量问题还是配置问题」的判断快得多。
相关阅读
标签: #独立开发 #SEO #Search Console #收录 #调试