页面加载速度测试：批量页面只有一部分被发现时怎样划分对照组
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /61243872b4cb.html
📄
页面加载速度测试：批量页面只有一部分被发现时怎样划分对照组
先给有条件的结论：如果“被发现”指的是页面已经进入过抓取或索引流程，那么对照组应按发现渠道划分，而不是按URL数量平均分配；如果只有一部分页面出现在站点地图、内链或日志里，先把它们按来源拆成几组，再让每组内部同时包含“被发现”和“未被发现”的页面。这样做的原因是，发现渠道的差异会直接影响下一步该修什么。但如果所有未发现页面都集中在同一个模板或同一批发布时间，按渠道分组就会失效，此时应优先按模板和上线批次划分。
先确认“被发现”到底指什么，否则分组没有意义
很多团队把“服务器日志里出现过一次请求”和“搜索结果里能查到”混为一谈。这两种状态对应的处理动作不同：前者可能只是抓取，后者才涉及索引。划分对照组之前，先统一口径，例如以“最近一次完整抓取周期内是否产生过请求”为准，还是以“是否出现在站内搜索或索引查询结果中”为准。口径不同，同一批URL会被分到不同组，后续对比就没有可比性。
一个可操作的动作是：把待测URL按“站点地图提交”“站内链接可达”“外部链接指向”“仅靠历史提交”四种来源打标，然后统计每种来源里被发现和未被发现的比例。如果某一种来源的未发现比例明显偏高，下一步就应针对该来源做小范围验证，而不是全站重提站点地图。需要说明的是，站点地图提交本身不保证收录，它只是发现渠道之一；robots.txt 里的抓取限制也不等于可靠的索引移除，两者不能互相替代。
对照组要按发现渠道分，而不是按URL数量对半切
把1000个页面简单分成500对500，看起来公平，实际上会把不同模板、不同上线时间、不同内链深度的页面混在一起，最后无法判断差异来自哪里。更合理的做法是先分层，再在层内配对：
- 同一模板的页面放进同一层，层内再区分“有站内链接指向”和“没有站内链接指向”。
- 同一批上线的页面放进同一层，层内再区分“提交过站点地图”和“未提交过”。
- 同一目录深度或同一栏目下的页面放进同一层，层内再区分“有外部链接”和“无外部链接”。
这样分完之后，如果只有“无站内链接且未提交站点地图”这一组持续未被发现，而其他组正常，那么问题更可能出在发现路径上，而不是页面质量或服务器响应。反过来，如果各组都有一部分未发现，且未发现页面集中在某个模板，那就要回到模板层面排查。
什么情况下按渠道分组会失效
反例很具体：假设某次改版后新上线的页面全部使用了同一个新模板，而这些页面又恰好都没有进入站内链接，那么“发现渠道”和“模板”这两个变量完全重合，无论怎么分组都无法区分是渠道问题还是模板问题。此时按渠道划分对照组只会得到看似一致的结果，却无法指导下一步。遇到这种重合，正确做法是暂停分组对比，先人为制造差异：从这批页面里挑一小部分加上站内链接，另一小部分保持原样，观察一个抓取周期后再比较。这个动作本身不承诺任何收录结果，但它能把两个变量拆开。
另一个会让分组失效的情况是：未发现页面数量太少，比如总共只有三五个。此时任何比例对比都没有意义，更实际的动作是逐个检查这几个URL的返回状态、规范标签和站内可达性，而不是强行做对照组。
分组之后，下一步动作取决于差异出现在哪一层
如果差异出现在“有无站内链接”这一层，下一步应优先补内链，并只对补过内链的那部分页面做跟踪，而不是全站铺链接。如果差异出现在“是否提交站点地图”这一层，下一步应检查站点地图本身是否可访问、是否包含这些URL、是否被正确引用，而不是反复重新提交。如果差异出现在模板层，下一步应对比两个模板输出的HTML结构差异，尤其是首屏内容和链接部分。
跟踪时建议记录每个对照组的抓取请求次数和索引状态变化，但要注意：请求量归零或某项统计下降，不能单独证明之前的处理正确，也可能是抓取预算转移、站点整体流量变化或外部因素导致。判断处理是否有效，需要同时看对照组和参照组的变化方向，而不是只看一组数字。
最后给一个可执行的下一步：先固定“被发现”的判定口径，再按来源给现有URL打标，然后只选一组差异最明显的做小范围干预，观察一个完整抓取周期后再决定是否扩大范围。这样做的目的是让每一次页面加载速度测试之外的分组动作，都能对应到一个明确的排查方向，而不是停留在统计层面。
