Google收录批次监测：按发布日判断抓取与索引效率

直接答案：本文教你以发布日期为队列主键、页面类型为次级分组，建立一份可复核的 Google 收录监测台账，把已提交、已发现、已抓取、已索引、产生展现、有排名六个状态分开记录，用 URL 检查、页面索引报告与站点地图报告交叉核对，并在 D+3、D+7、D+14、D+28 四个窗口判断样本是否成熟，最后按状态选择止损动作。

六个状态的定义与判定依据

发布一批页面之后，最常见的误判是把提交动作当成结果。站点地图提交成功、URL 检查里点过“请求编入索引”，很多人就在心里给这批页面打了勾。但 Google 官方在说明重新抓取方法时明确写过，提交或请求重新抓取并不保证页面会被索引（[Ask Google to Recrawl URLs](https://developers.google.com/search/docs/crawling-indexing/ask-google-to-recrawl)）。抓取与索引 FAQ 也说明，发现、抓取、索引之间存在时间上的不确定性，官方不给出具体天数承诺。

这意味着“这批页面收录得怎么样”这个问题，本身无法用一个是非答案回答。它至少包含六个不同状态：已提交、已发现、已抓取、已索引、产生展现、有排名。每个状态的证据来源不同，判定入口不同，能采取的动作也不同。把它们混在一起，就会出现两种典型错误：一是把已发现当成已索引，过早判定失败并反复干预；二是把已索引当成有展现，去改内容却改错了方向。

本文要解决的问题是：发布一批页面后，如何按发布日判断 Google 的抓取与索引效率，并决定何时干预。核心主张是：只有把六个状态分开记录，按发布日分队列等待样本成熟，才能判断效率并设定止损。下面按“先定义状态、再建队列、再建台账、再用三个报告核对、最后按窗口止损”的顺序展开。

按发布日与页面类型建立队列

判定顺序必须固定，否则台账里会出现同一 URL 被标成两个状态的情况。建议按下面的顺序逐级判定：先看提交，再看发现，再看抓取，再看索引，最后才看展现与排名。前一级不成立时，不要跳到后一级下结论。

这张表的关键在于每一行都对应一个独立的证据来源。页面索引报告区分已索引与未索引状态，并提供验证入口，但它本身是属性级聚合，不提供单页最终判定；URL 检查可以查看已索引版本、抓取细节与实时可索引性，但单页结果不代表整个队列。抓取统计提供抓取请求历史与响应码，属于抓取证据，不等于索引证据。

因此判定规则可以写成一句话：**一个 URL 的“当前状态”取它已经满足的最高一级，且必须有对应报告的证据支撑。**没有证据支撑的级别一律不填。这条规则是后面所有队列比较和止损判断的基础。

批次台账字段与记录节奏

状态定义统一之后，下一步是分组。分组的目的不是分类好看，而是让同一组内的 URL 具备可比性。如果拿 20 个产品页和 5 个帮助文档混在一起算“收录率”，得到的比例既不能反映产品页的效率，也不能反映帮助文档的效率，任何基于它的止损决定都是错的。

分组规则建议如下：

1. **队列主键是发布日期。**同一天发布的 URL 归入同一队列，队列名用发布日期加序号，例如“2026-09-01 批次”。 2. **次级分组是页面类型。**同一队列内再按页面类型拆分，例如产品页、帮助文档、分类页、文章页。 3. **同组内模板与内容结构应一致。**如果同一天发布的产品页里，一部分有独立正文、一部分只有参数拼装，它们不应放在同一组比较。 4. **跨队列不合并计算比例。**不同发布日的队列各自记录各自的分布，不把两周的数据加总成一个“总体收录率”。

站点地图的构建与提交方式本身就适合按 URL 队列维护：官方说明站点地图用于帮助发现 URL，提交后可在站点地图报告中查看处理情况与已发现数量。把站点地图按队列组织，能让“已提交”和“已发现”这两个状态直接对应到具体批次，而不是全站一个笼统数字。

分组完成后，每个 URL 应当只属于一个队列和一个页面类型。如果某个 URL 无法归类，说明它的发布信息或模板归属本身不清楚，应先补全信息再纳入监测，而不是先塞进某个队列凑数。

用 URL 检查确认单页状态

队列建好之后，需要一份能追溯状态变化的台账。台账的核心要求是“只追加、不覆盖”：每次检查新增一行记录，而不是把上一次的状态改掉。因为判断效率靠的是状态随时间的变化，如果历史被覆盖，就只剩下一个当前快照，无法回答“这个队列在 D+7 到 D+14 之间有没有推进”。

记录节奏建议与观察窗口对齐：发布当天记录一次初始状态（通常只能到“已提交”或“已发现”），之后在 D+3、D+7、D+14、D+28 各记录一次。每次记录时，先写检查来源，再写状态，最后写是否采取了动作。这样一条记录就能自证：状态是从哪个报告读出来的，读的时候有没有做过干预。

台账不需要复杂工具，一张表格即可。真正决定它有没有用的是两条纪律：状态必须有来源，历史必须保留。

用页面索引报告核对属性级分布

台账里最容易出错的是单页状态。属性级报告给出的是分布，单页的最终判定要靠 URL 检查。官方说明 URL 检查可以查看某个 URL 的已索引版本、抓取细节与实时可索引性，也可以对单个 URL 请求重新抓取。

使用时有三个边界必须记住：

**实时可索引性不等于已索引。**检查结果显示“网址可编入索引”，只说明当前没有阻断抓取或索引的技术障碍，不代表 Google 已经收录了这个页面。
**请求重新抓取不保证被索引。**官方在重新抓取说明中明确保留了这一边界，也不提供生效时间承诺。因此台账里“是否请求重新抓取”是一个动作字段，不是状态字段。
**单页结论不外推到队列。**一个 URL 被索引，不能推断同队列其他 URL 也会被索引；一个 URL 未索引，也不能推断整批失败。

操作上建议这样用：当台账中某个 URL 的状态在连续两个窗口没有变化时，用 URL 检查确认它当前的真实状态与抓取细节，把结果作为新的一行记录写回台账，并在“检查来源”里注明是 URL 检查。如果确认存在技术性阻断，先修问题再谈等待；如果确认没有阻断，就回到队列层面继续观察，不要因为单页结果就改动整批页面。

用站点地图报告核对提交与发现

单页确认解决个体问题，队列整体分布要靠页面索引报告。官方说明该报告区分已索引与未索引状态，并提供验证入口。它的用途是回答“这个队列里有多少 URL 处于已索引状态、未索引的分别落在哪些原因下”，而不是回答“某个 URL 到底收没收录”。

使用时注意四点：

1. **报告是属性级聚合。**它反映的是整个属性范围内的状态分布，不能直接读出某个队列的数字，需要结合站点地图或 URL 列表做对应。 2. **未索引状态需要分类查看。**不同原因对应的处理动作不同，把“未索引”当成一个整体会掩盖真正的差异。 3. **报告存在数据延迟。**官方文档说明报告数据并非实时，因此台账中记录报告结论时，应同时记录读取日期，避免把延迟当成停滞。 4. **聚合结论需要单页复核。**当报告显示某队列出现异常分布时，用 URL 检查抽验若干 URL，确认是普遍现象还是个别现象。

把这一步的产出写进台账时，建议在队列层面单独记一行“队列分布”，写明读取日期、已索引数量与未索引的主要分类。这样 D+7 与 D+14 的对比才有依据，而不是凭印象说“好像没怎么动”。

按 D+3、D+7、D+14、D+28 观察成熟度

站点地图报告负责最前面两个状态。官方说明该报告用于监测已提交站点地图的处理情况与已发现 URL 数量。它回答的是“这批 URL 有没有被提交、有没有被发现”，不回答“有没有被抓取或索引”。

这里要严格区分两个概念：

**提交是动作，不是结果。**站点地图提交成功只说明 Google 收到了这份文件，不保证其中的 URL 会被抓取，更不保证被索引。
**已发现是中间状态。**报告显示已发现数量，说明 Google 知道了这些 URL 的存在，但尚未抓取。已发现长期不推进，才需要考虑检查可抓取性与内链。

站点地图应按队列维护，而不是全站一份长期不变的文件。按队列维护的好处是：当某个批次在 D+7 仍停留在“已发现”时，你能直接定位到对应的站点地图，核对提交时间与已发现数量，而不是在一个包含全部历史 URL 的大文件里猜测。

记录时，把站点地图报告的读取日期、已提交状态与已发现数量写入队列行。如果发现数量明显低于提交数量，先核对站点地图本身是否包含全部 URL、格式是否被正确处理，再考虑其他原因。

止损规则与干预动作

四个窗口的作用不是“到点必须收录”，而是给队列的状态变化留出观察节奏。官方在抓取与索引 FAQ 中说明发现、抓取、索引存在时间不确定性，因此任何窗口都只能用来观察趋势，不能用来承诺结果。

判断样本是否成熟，用一条可操作的标准：**队列内多数 URL 的状态在相邻两个窗口之间不再变化。**例如 D+14 与 D+28 之间，大部分 URL 的状态没有推进也没有回退，这个队列就可以视为成熟，可以进入止损判断。反之，如果状态仍在明显推进，即使比例不理想，也应继续等待，而不是提前干预。

还有两条纪律：窗口之间只比较同一队列，不拿本批次和上一批次直接比高低，因为模板、内容结构、发布时间都可能不同；未成熟前不判定失败，也不因为焦虑而反复请求重新抓取，因为重复请求本身不改变索引结果，只会污染台账里的动作记录。

样本成熟之后，才轮到止损。止损不是“没收录就重发”，而是按当前状态选择对应动作。下面按状态给出判定与动作。

执行止损时有三条规则：

1. **先排除技术可抓取问题，再谈内容。**如果 URL 检查显示存在阻断，先修阻断；在阻断存在的情况下讨论内容质量没有意义。 2. **干预后重新计时。**任何一次修改或重新抓取请求，都应在台账中新增一行，记录动作与时间，并把下次检查窗口重新设为动作后的 D+3 或 D+7。 3. **不承诺干预必然生效。**官方明确说明提交与重新抓取不保证被索引，因此干预后的预期只能是“重新观察”，不是“必然收录”。

止损的终点也不是“全部收录”。一个队列在成熟后仍有部分 URL 未索引，属于正常范围；真正需要处理的是那些有明确技术原因、且原因可修复的 URL。把止损范围限定在可修复问题上，台账才不会变成一份永远清不完的清单。

把台账用起来

回到最初的问题：发布一批页面后，如何判断 Google 的抓取与索引效率。答案不是看一个总数，而是看同一队列在四个窗口里的状态推进：D+3 看提交与发现是否对齐，D+7 看是否出现抓取证据，D+14 看已索引比例是否推进，D+28 看状态是否稳定。稳定之后，再按状态选择动作。

这套方法的价值在于把“收录了没有”拆成六个可验证的状态，把“这批页面行不行”拆成按发布日分组的队列比较，把“要不要干预”拆成有前提的止损规则。它不承诺任何页面一定会被索引，也不承诺干预一定生效；它只保证你的每一个判断都有来源、每一次动作都有记录、每一个队列都有明确的下一步。

现在就可以开始：为最近一批已发布 URL 建立台账，补记 D+3 状态，然后在 D+7 复核队列分布，再决定是否执行止损动作。

下一步

用本文的台账字段为下一批发布 URL 建立记录，先补记 D+3 状态，再在 D+7 复核队列分布后决定是否执行止损动作。