为什么先分组，而不是先逐条查 URL
批量上线的页面通常只有少数字段不同，例如地区、型号、日期。单独打开一条看，内容完整、状态码正常、标题和描述也写了，很难看出问题。但把同模板的几十条放在一起，模板骨架几乎一样，主体信息也大量重叠，搜索引擎在索引时只能从中挑选一部分。
这时候逐条核对 URL 会非常低效：每条看起来都没错，却解释不了为什么有的被收录、有的停在已发现状态。先按模板和主体内容分组，再在组内做判断，才能看出问题出在结构上还是出在内容上。
另外要分清一件事：被爬虫抓取不等于被索引。日志里出现大量访问，只能说明抓取环节通了，是否进入索引还要看页面本身的差异度和质量判断。
近似重复的三种常见形态
模板骨架重复
标题结构、段落顺序、推荐位、页脚都一致，只有中间一小段被替换。这种页面在抽取正文时，可用的差异化文本非常有限。
主体信息重叠
不同页面描述的对象高度相似，内容互相涵盖，读者看完任意一条都能得到同样的答案。此时多出来的 URL 并没有提供新的信息。
差异字段没有搜索价值
差异只体现在内部编号、排序参数、无意义的拼接词上，这些字段没人会去搜索，也就不构成独立页面存在的理由。
分组时可以看的几个维度
- URL 结构：是否落在同一目录层级，是否带同类参数；
- 模板类型：详情页、聚合页、筛选结果页分开看；
- 去模板后的主体文本：去掉导航和公共模块，剩下多少有效内容；
- 差异字段：地区、型号、时间等，是否对应真实搜索意图；
- 内链位置：这些页面从哪些入口被链接到，是否处于同一层级。
抽样不必全站铺开，每个模板抽 5 到 10 条，覆盖不同目录深度即可。抽样的目的是判断分组是否存在，而不是给每条页面下结论。
从分组到处置的核对顺序
- 先确认这些 URL 是否属于同一组，避免把正常差异页面误分到一起；
- 判断组内是否存在真实的搜索需求差异，可以用站内搜索词、咨询记录来交叉验证；
- 查看该组当前的索引情况，是整体没有被索引，还是只有头部少数几条被索引；
- 再选择处置方式：合并成一个页面、补充真正的差异化信息、用 canonical 收敛到主版本、对无价值页面加 noindex，或者直接减少后续产出；
- 处置后留出观察窗口，再看该组的索引分布有没有变化。
顺序不要颠倒。先删再想理由，容易把本来有需求的页面一起清掉。
几个容易走偏的判断
把抓取频次当成收录信号
抓取多只能说明爬虫愿意来，收录与否取决于页面是否值得单独存在。两者混在一起，就会得出错误的优化方向。
只看总量，不看组内分布
收录量在涨，可能只是某个模板在放量，而另一组几乎没进索引。按组看分布，比看全站总数更能定位问题。
一刀切删除
近似重复里往往混着少数确实有需求的页面。删除前先确认该组是否有稳定访问和转化，再决定保留哪一部分。
判断标准可以简单一点：如果两条页面互换位置，读者几乎察觉不到区别，那它们多半不该各自占据一个索引位置。
小结
相似内容批量上线时，收录问题的根源往往在结构层面。先按模板与主体内容做近似重复分组，再在组内核对索引分布和需求差异，最后才决定合并、补强还是收敛。这样处理，比逐条检查 URL 更接近问题的实际位置。