搜索引擎抓取日志：批量页面只有一部分被发现时怎样划分对照组
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /1f5b0fd06759.html
📄
搜索引擎抓取日志：批量页面只有一部分被发现时怎样划分对照组
先给有条件的结论：如果同一批URL中只有一部分出现在抓取日志里，不要按“已抓/未抓”直接分组，而要先按页面模板、入口层级和最后修改时间做分层，再在层内随机划分对照组。只有当未抓页面与已抓页面在模板、入口和内容类型上高度一致时，直接按抓取状态分组才成立；一旦某个模板的页面几乎全部未被抓，说明差异更可能来自模板级因素，而不是单页因素，这时直接分组会把模板差异误当成页面差异。
先确认“被发现”指哪一层，再决定分组维度
抓取日志里的“被发现”至少可能对应两种状态：一是抓取请求已经发出但未完成，二是请求已完成但响应异常。这两种状态对应的分组方式不同。若日志中未抓页面连请求记录都没有，应优先按入口来源分组，检查这些页面是否只存在于站点地图、分页列表或站内搜索入口；若日志中有请求但状态码异常，则应按响应类型和服务器行为分组。把这两种情况混在同一组里比较，后续修复动作会失去指向性。
一个可操作的动作是：先导出目标批次的URL清单，再与日志中出现的URL做交集和差集，对差集部分逐条标注入口来源。如果差集中超过一半的URL只来自站点地图而没有其他内链，下一步应优先调整内链结构，而不是先改页面内容。这个动作的结果会直接决定后续实验是围绕入口做，还是围绕页面本身做。
分层随机化比简单二分更能隔离模板差异
假设有1200个商品页，其中400个被抓取、800个未被抓取。若直接把这1200个页面按抓取状态分成两组，两组在模板版本、上架时间和分类层级上可能天然不同。更稳妥的做法是先在每个模板版本内部划分对照组：在每个模板层内，随机抽取相同数量的已抓页面和未抓页面，形成若干个小对照单元。这样比较的是同一模板下被抓与未抓的差异，而不是不同模板之间的差异。
分层时至少要记录三个变量：页面所属模板、页面到首页的最短点击距离、页面最后实质性修改的时间段。若某个模板的页面在日志中全部缺失，该模板应单独作为一层处理，不参与层内随机对照。这个判断依据是：模板级缺失往往意味着抓取预算分配、渲染方式或入口结构存在系统性问题，单页层面的对照无法解释。
什么情况下直接按抓取状态分组仍然成立
直接分组成立的条件是：未抓页面与已抓页面在模板、入口层级、内容类型和修改时间上分布接近，且差异只体现在单页属性上，例如标题长度、正文段落数或结构化数据完整度。此时可以按抓取状态二分，再在组内比较这些单页属性。若无法确认分布接近，直接分组得到的差异不能归因于单页属性。
一个反例是：某批页面中未抓部分全部来自一个刚上线的子目录，而已抓部分全部来自旧目录。即使两个目录下的页面模板相同，直接按抓取状态分组也会把“新目录缺少内链”误判为“页面内容质量不足”。这种情况下，正确做法是先按目录分组，再在目录内部比较已抓与未抓页面，否则后续修复会指向错误对象。
用一个小规模对照动作验证分组是否合理
在正式扩大实验前，可以先取一个层内对照单元做小规模验证。具体动作是：在该层内选20个未抓页面，随机分成两半，一半只增加来自同层已抓页面的内链，另一半保持不变；同时记录两半页面在后续日志中的请求出现情况。这个动作的假设是：如果入口是主要限制因素，增加内链的一半应更早出现请求记录；如果两半都没有变化，说明该层的主要限制可能不在入口，而在渲染或服务器响应环节。
无论结果如何，下一步都应回到日志中核对：新增内链后，请求是否到达、响应是否正常、是否被重定向到其他URL。只有当日志中同时出现请求记录和正常响应时，才能把该层从“未发现”转为“已发现但未完成”或“已发现且已抓取”的候选层。若只有请求记录而没有正常响应，下一步应检查服务器端行为，而不是继续调整内链。
划分对照组时需要避开的三个误判
- 把站点地图当收录保证。站点地图提交后页面仍可能不被抓取，因此站点地图中的URL不能直接当作已发现组。
- 把robots.txt限制当作移除手段。robots.txt只影响抓取行为，不等于可靠的索引移除；用它来划分“允许/禁止”组时，需明确它只回答抓取可行性，不回答索引状态。
- 把HTTPS当作抓取改善因素。HTTPS不保证安全无漏洞，也不保证排名或抓取频率提升；若分组时把协议作为变量，需先确认其他入口和模板条件一致。
当同一批页面中只有一部分被发现时，优先按模板、入口层级和修改时间做分层，再在层内随机划分对照组；只有当未抓与已抓页面在这些维度上分布接近时，直接按抓取状态二分才成立。下一步动作是先完成一层的小规模入口对照，并回到日志核对请求与响应是否同时出现，再决定是否扩大实验范围。
