入口页做到几十上百个之后，很少有人再逐个去看它们长什么样。但从外部观察者的角度，这些页面之间可能高度相似：同一套模板、同一种 URL 规律、同一台服务器、同一段页脚。相似度本身不是问题，问题在于它会把一批页面绑在一起被看待——一个表现不好，可能牵连其他。
相似度是怎么被形成的
相似不是单一维度，而是多个信号叠加的结果。常见的几类：
- 模板层：导航、侧栏、页脚、评论框、版权信息完全一致，甚至 HTML 注释里还留着同一套生成标记。
- 内容层：标题套同一句式，首段来自同一个来源，发布时间集中在同一分钟。
- 结构层：URL 是连续 ID 或同一目录下递增的 slug，层级深度一模一样。
- 网络层：同一 IP、同一 C 段、同一解析商，或者一张证书覆盖了全部域名。
- 资源层：共用同一套统计代码、同一张 CDN 图片、同一个第三方脚本域名。
单独看每一条都不致命，叠在一起就会形成很明显的批量特征。
模板相似难以避免，内容重复可以避免
入口页通常由同一套程序生成，框架相同是正常的。真正容易出问题的是内容层面的完全一致：同一段“网站简介”出现在几百个页面上，同一篇正文只换了标题，时间戳全部相同。这类重复比模板相似更容易被识别，也更容易处理。建议先把正文来源分开，让每个入口页至少有自己的一段独立文字，哪怕只有两三句。
URL 结构上的批量痕迹
连续编号、固定长度、同一层级，是最直观的批量信号。调整时不必刻意打乱到毫无规律，那样反而增加维护成本。可行的做法是：让目录层级有变化，参数和静态路径混用，编号不连续。前提是每个 URL 仍然能被正常解析，不要为了“不一样”而造出无意义的地址。
主机与网络层的关联
同一 IP 或同一 C 段下的多个域名，天然会被放在一起观察。一张证书覆盖大量域名、共用同一套 DNS 解析、甚至同一个注册邮箱，都会增加集中度。这里不需要追求完全分散，但要避免所有入口页都压在同一个出口上。可以定期检查：解析记录是否集中、证书 SAN 列表里是否有不该出现的域名、页面里是否残留同一套统计 ID。
分散的目的是让每个入口页有独立存在的理由，而不是把它伪装成别的站点。伪装带来的维护成本和不确定性，通常高于它解决的问题。
一套可执行的自查顺序
- 抽样对比标题和首段，看是否存在成批的固定句式。
- 取一段正文做文本比对，确认没有整段复用。
- 检查时间、作者、分类等字段是否全部雷同。
- 查看 HTML 源码里的注释、页脚、统计代码是否一致。
- 核对主机、解析和证书的集中程度。
- 最后才考虑模板结构的微调，因为它的收益通常最小。
常见误区
- 以为换一套模板就解决了全部问题，忽略了正文和时间的重复。
- 以为把 IP 分散开就万事大吉，内容和结构仍然一模一样。
- 追求每个入口页“完全不同”，导致维护成本失控，最后没人愿意更新。
- 一次性大规模调整，之后无法判断是哪一项改动起了作用。
怎么判断调整有没有效果
相似度是概率问题，不是开关。比较稳妥的做法是分批调整，并记录每次调整前后蜘蛛的回访次数、抓取页面数和新页面被发现的速度。如果某一批入口页在调整后回访更稳定，可以把这个做法推广到下一批。反过来，如果变化不明显，也不必把相似度当成唯一的解释——抓取表现还受链接位置、页面响应速度、内容更新频率等因素影响。
规模越大，入口页之间的“长相”就越值得定期看一眼。把它当成一项例行的巡检工作，比事后补救要省力得多。