canonical：批量页面只有一部分被发现时怎样划分对照组
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b8fa58a23b5d.html
📄
canonical：批量页面只有一部分被发现时怎样划分对照组
先给有条件的结论：如果一批页面共享同一模板、同一批 canonical 规则，而只有一部分被实际抓取或进入候选索引，不要按“已发现/未发现”直接分组。更稳的做法是先把这批页面拆成“规则完全相同”的若干层，再在每层内部做发现状态对照，否则你比较的可能是模板差异、参数差异或链接位置差异，而不是 canonical 本身的效果。
先确认这批页面是否真的共享同一条 canonical 规则
批量页面“只有一部分被发现”，常见原因不是 canonical 写错，而是这批页面本来就不属于同一实验单元。判断时先做三件事：
- 看 canonical 的目标值是否按模板统一生成，还是混入了分页、筛选参数、地区或语言变量。
- 看这些页面是否都出现在同一类入口里，例如同一列表页、同一站点地图或同一内部搜索路径。
- 看未发现的那部分是否集中在某个参数组合、某个目录层级或某个发布批次。
如果这三项里有一项不成立，就不要把它们放进同一个对照组。此时“被发现”与“未发现”的差异，可能来自入口数量、链接深度或参数组合，而不是 canonical 声明。一个实际动作是：先按模板和参数把页面清单打上标签，只保留标签完全一致的部分作为候选池，再进入下一步。这个动作会直接决定后面能不能把差异归因到 canonical，而不是归因到抓取预算分配。
对照组要按“同一规则层”划分，而不是按发现结果划分
在候选池内部，划分对照组的原则是：让两组在 canonical 规则上一致，只在发现状态上不同。可以这样操作：
- 把候选池按 canonical 目标类型分组，例如自指、指向主版本、指向另一条路径。
- 在每组内部，再按页面是否已被抓取或已进入候选索引分成两列。
- 检查两列在内部链接数量、站点地图收录情况、发布时间上是否接近；如果差距过大，这一组不能直接比较。
这里要说明一个容易忽略的事实：站点地图不保证收录，robots.txt 的抓取限制也不等于可靠的索引移除。因此“未发现”可能只是入口不足或抓取延迟，不能单独证明 canonical 处理正确或错误。把发现状态当作结果变量之前，先确认两组的入口条件是否可比。
一个反例：当未发现页面集中在同一入口缺失时，对照失效
假设一批页面都声明了自指 canonical，其中一部分已发现、一部分未发现。如果你直接比较两组，可能得出“canonical 自指导致未发现”的结论。但更合理的解释是：未发现的那部分只存在于一个未被提交的站点地图分片里，或者只被一个低权重列表页链接。此时差异来自入口，而不是 canonical。
这个反例说明：只要未发现页面在入口来源上高度集中，对照组就不能成立。你需要先把入口来源作为分层变量，而不是把它当作噪音。否则后续无论怎么调整 canonical，都可能看不到预期变化。
下一步动作：先做入口补齐，再决定是否改 canonical
如果分层后发现两组入口条件接近，而 canonical 规则不同，才值得把 canonical 当作候选原因继续排查。如果入口条件本身不接近，先做入口补齐：把未发现页面加入可抓取路径，或确认它们是否被 robots.txt 误挡。补齐后观察发现状态是否变化。这个动作的结果会决定下一步：如果发现状态改善，说明问题主要在入口；如果发现状态不变，才需要回到 canonical 规则本身，检查是否存在目标值冲突或跨域指向。
整个过程里，不要用“请求量归零”或“抓取量下降”单独证明某项处理正确，因为这些现象也可能来自发布节奏、入口调整或抓取延迟。把分歧转成可核对的项目，关键就是让每一组在规则和入口上都可比，再比较发现状态。
