结论先给出:当批量页面只有一部分被发现时,不要按“已发现/未发现”直接分组,而应按一个与发现机制相关的、页面自身的属性来划分对照组。例如,把同一批页面按“是否在上线后立即被站内链接指向”分成两组,而不是按结果分组。这样做的理由是,按结果分组会把原因和结果混在一起,无法判断某个因素是否真的影响了发现。但有一个反例会让这个结论失效:如果两组页面在内容质量、模板、服务器响应等维度上同时存在系统性差异,那么即使你按某个属性分组,也无法把发现差异归因于该属性。
按结果分组是最直觉的做法,但它有一个根本问题:你比较的是“已经发生的发现”和“尚未发生的发现”,而这两组之间的差异可能来自任何原因。比如,已发现的页面可能恰好是较早提交站点地图的那一批,未发现的页面可能是后来才加入的。这样你观察到的差异可能只是提交时间的差异,而不是页面本身的问题。
更麻烦的是,如果百度对同一批页面的抓取是分批进行的,那么“未发现”可能只是时间未到,而不是页面有什么缺陷。此时按结果分组,你会把暂时未被抓取的页面误判为有问题,进而去修改本来正常的页面。
合理的对照组应该按一个在发现发生之前就已经确定的属性来划分。这个属性不能是“是否被发现”,而应该是可能影响发现的页面特征或外部条件。常见的可用维度包括:
选择维度的原则是:这个属性在页面被发现之前就已经存在,并且你有理由怀疑它可能影响发现。如果你找不到这样的属性,那么更稳妥的做法是先不做分组,而是直接检查站点地图提交记录和服务器日志,确认百度是否已经请求过这些页面。
假设你上线了 200 个新页面,其中 100 个从栏目页有直接链接,另外 100 个只放在站点地图里。两周后,有链接的 100 个中有 60 个被百度发现,无链接的 100 个中只有 10 个被发现。这个对比说明站内链接与发现之间存在关联,但不能直接证明因果,因为两组页面可能在其他方面也不同。
此时下一步动作是:从无链接的那 100 个页面中,随机选 20 个,给它们加上来自栏目页的链接,然后观察这 20 个在接下来两周内的发现情况。如果这 20 个的发现比例明显上升,而剩下的 80 个仍然很低,那么站内链接这个因素就更值得进一步验证。如果这 20 个也没有变化,那么站内链接可能不是主要因素,需要转向检查其他维度,比如页面内容是否与已有页面高度重复。
最典型的失效场景是:两组页面在多个维度上同时存在差异,而你只按其中一个维度分组。例如,有站内链接的那 100 个页面恰好也是用手工撰写的标题和描述,而无链接的那 100 个页面是用模板批量生成的。此时即使你观察到发现比例差异,也无法判断是链接的作用还是内容质量的作用。
另一个失效场景是:百度对这批页面的抓取本身就不稳定,比如服务器在某个时间段返回了较多 5xx 错误。这种情况下,发现差异可能只是服务器可用性的差异,而不是页面属性导致的。你需要先排除服务器响应层面的问题,再考虑分组比较。
还有一个边界需要注意:站点地图提交不保证收录,robots.txt 的抓取限制也不等于可靠的索引移除。如果你在分组时把“已提交站点地图”当作一个分组维度,要明白它只是一个提交动作,不能直接推断发现结果。
在划分对照组之前,先做一件事:用百度搜索资源平台提供的抓取诊断或站点地图状态,确认“未发现”的页面是否真的没有被请求过。如果日志显示百度已经请求过这些页面但未索引,那么问题可能不在“发现”阶段,而在“索引”阶段,此时分组比较的维度应该转向页面内容质量、重复度和可索引性,而不是站内链接或提交方式。
如果确认是发现阶段的问题,那么按一个页面自身属性分组,设置一个可观察的后续动作,比如给其中一组增加站内链接,然后比较两组在相同时间窗口内的发现比例变化。这个动作的结果会直接告诉你:如果增加链接的那一组发现比例上升,下一步可以扩大链接覆盖范围;如果没有上升,下一步应该检查页面内容是否与已有页面高度相似,或者服务器是否对百度抓取返回了异常状态码。无论哪种结果,都比按“已发现/未发现”直接分组更能帮你找到可操作的改进方向。