条目页的「相关推荐」模块：算法、编排和内链权重的边界

条目详情页本身能承载的内链很有限：面包屑往上指分类，正文里的出链指向对方站点。真正能把用户往站内其他条目导的，就是底部那块"相关推荐"。

这块地方看着简单，实际要决定的事不少：放几条、按什么算相关、要不要跨分类、能不能自动轮播、链接该怎么写。每一条都有对错，而且做错了不会立刻有反馈。

图片来源：网络，版权归原作者所有，侵权请联系删除

数量：少了没用，多了稀释

六到十二条是合理区间。低于六条，用户扫一眼没有可选项，模块等于摆设；高于十二条，用户不会往下看，而且页面上的链接数量被成倍放大，每个链接分到的注意力都变小了。

从内链的角度想这个问题更清楚：一个条目页上如果有三十个推荐链接，加上导航、分类、标签、页脚，整页出链上百个。这种情况下每个链接传递的信号都被摊薄，还不如只留十条精准的。

移动端减到四到六条。手机屏幕上十二条要滚很久，实际被看到的还是前几条。

算法：没有数据的时候先用规则

新站或者新条目没有点击数据，协同过滤那套用不上。这时候用规则排序，按重要性排：

• 同分类，且标签重合度高的排前面
• 同分类，收录时间接近的次之
• 跨分类但标签高度重合的，放最后几位

有点击数据之后，改用共现：同一个会话里被先后点过的条目对，出现次数越多越相关。这个数据积累一个月就能用了，比拍脑袋的规则准。

两种方法混着用更稳：共现数据覆盖的条目用共现结果，没覆盖的（长尾条目）回落到规则。纯共现会让热门条目越来越热，冷门条目永远没有曝光，长此以往站内流量全集中在头部几十个条目上。

编排规则要写死在代码里

有几条排除规则不是优化项，是必须项：

排除当前条目自己。听起来像废话，但确实有站在推荐位上推自己。

排除已下架和已失效的条目。推荐位上出现一个点进去 404 的站点，用户会认为整个推荐不可信。这一条要连着死链巡检一起做，下架操作必须能立刻反映到推荐结果里。

排除当前分类里已经在这个页面上大量出现的条目。如果条目页上方本来就有同分类列表，底部的推荐再推同分类，等于重复。

跨分类要留比例。全推同分类，用户在一个小圈子里打转；全部跨分类，推荐就不"相关"了。八比二或者七比三都行，关键是固定下来，别每次刷新都变。

技术细节上最容易做错的三处

用 JS 动态渲染。推荐位如果靠点击后才去接口取数据、用 JS 插进 DOM，那这些链接在抓取时可能不在页面里。要用服务端渲染输出成真实的 <a href>，JS 那套留给"换一批"的交互。

锚文本堆关键词。推荐的条目链接文字就写站点名，不要写成"设计素材网站下载_免费设计素材导航"这种。内链锚文本的自然分布比堆砌有用得多，堆砌还有过度优化的风险。

无限滚动或自动轮播。自动轮播的推荐位会让页面 DOM 一直增长，也会让抓取时看到的内容和不同用户看到的不一样。固定十条，不要动。

还有一条性能上的：推荐结果要缓存。每个条目页都实时算一遍相似度，流量上来之后数据库撑不住。按条目缓存，缓存时间几小时到一天，配合定时任务预先算好。

同质推荐会把自己的词打散

推荐位上如果全是高度相似的条目（同一个细分领域、描述雷同），这些条目本来就在争同一批词，你再用内链把它们捆得更紧，等于告诉搜索引擎"这几个页面说的是同一件事"。

编排时加一条约束：同一批推荐里，描述相似度超过某个阈值的条目最多出现一个。实现上很简单，算一下标题和标签的重合率就行。

怎么判断做得好不好

看三个数：推荐位的点击率（曝光到点击）、推荐点击之后的二跳率、以及推荐位带来的条目页浏览量占总条目页浏览量的比例。

点击率低于百分之几，说明推荐不相关或者位置太靠下没人看到；二跳率很低，说明点进去的条目不符合预期；第三个数如果长期低于一成，说明这个模块对站内流转基本没贡献，值得重做。

别只看点击量。热门条目的推荐位点击量天然高，那不代表推荐做得好，只代表位置好。要看的是推荐位带来的增量，比如同一条目页在有推荐和没推荐时的人均浏览页数差异。

---

相关推荐是站内少数几个你能完全控制的内链位置。控制得住就别浪费，宁可少放几条精准的，也不要铺一屏凑数的。