一个类目挂不下的条目：目录站多分类归属时，主分类、面包屑和 URL 该怎么选

收录到三百条以后，几乎每个目录站都会撞上同一个问题：一个站同时像两个类目的成员。做在线协作白板的，既是设计工具也是办公效率；二手房平台既是房产又是交易。把它放进一个类目，另一个类目的用户找不到；放进两个，又怕出问题。

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

分类可以多，详情 URL 只能有一个

先把这条放在最前面，因为它是整个问题的地基。一个条目在目录站里应该有且只有一个详情页 URL。它可以出现在多个分类页的列表里，可以被多个标签挂住，但点开的那个地址必须始终是同一个。

很多站为了方便，给同一个条目按分类生成两套地址：/design/figma/ 和 /productivity/figma/，内容几乎一样，然后用一个 canonical 把后者指回前者。技术上不算错，但每多一个类目就多一个近似 URL，几百个条目乘以平均两三个类目，索引里就多出上千个需要去重判断的地址。这些地址不一定收录，但每次抓取都要读一遍 canonical 才能确认，属于白花的抓取预算。

更干净的做法：数据库里保存多对多的归属关系，渲染分类页时正常列出条目，链接一律指向那个唯一的详情地址。

主分类怎么挑：三个信号，够用

信号	看什么	怎么落地
搜索需求	类目词本身的月搜索量和竞争度	哪个类目词更常被搜，就挂哪个
站点定位	这个类目在你的站里是主干还是附庸	主干类目优先，它决定了用户对站的认知
层级深度	从首页到该类的点击层数	链路短的优先，深层类目担当副分类

三条冲突时按这个顺序取：搜索需求 > 站点定位 > 层级深度。理由也简单——主分类决定了这个条目最可能承接哪部分搜索流量，而流量是目录站唯一的正事。定位次之，因为改定位是件大工程，不该由单个条目触发。层级最次要，深度问题可以用横向内链补。

实际做的时候别手工一个个挑。写一条规则，让系统按「类目月搜索量 × 该类目条目稀缺度」给每个候选类目打分，取最高分当主分类。稀缺度这一项很关键：一个只有 8 个条目的小类目，比一个已经有 240 个条目的大类更需要这个条目，把它塞进大类里基本等于淹没。

面包屑只能有一条路

面包屑的作用是把当前页在整站层级里的位置讲清楚，它是给人和爬虫看的一条路径，不是一堆可选父级。谷歌的 BreadcrumbList 结构化数据里，itemListElement 是有顺序的列表，从首页一路排到当前页——它天生就假设只存在一条路径。

所以，哪怕一个条目挂在三个类目下，面包屑也只展示主分类那一条：

首页 › 设计工具 › 在线白板 › 某工具

至于另外两个身份，放在条目页内部的「同时收录于」模块里呈现。这个模块承担的是分流，不是结构。这么处理还有一个附带好处：面包屑路径和 URL 路径保持一致，用户从 URL 就能猜出自己在哪，这部分是不少目录站漏掉的可读性收益。

结构化数据和站点地图各自该写什么

详情页上的 BreadcrumbList 按主分类那一条生成，不要按三个类目生成三个。JSON-LD 里出现两条互相矛盾的层级，爬虫理解起来就含糊。

站点地图只列主 URL，一个条目一行。副分类产生的组合不单独出现在站点地图里——它们本来也不是独立地址。lastmod 用详情内容真正发生变化的时间，不是每天跑一遍脚本刷新的时间戳。这一条前面几篇文章里提过，这里再啰嗦一句是因为<｜hy_placeholderno813｜>在多分类结构里特别常见：改了一个条目的副分类，脚本就把主 URL 的 lastmod 全刷一遍，等于告诉爬虫几百个页面都更新了。

副分类页上的展示要不要区别对待

要，但只改表面那层。同一个条目出现在副分类页时，标题和描述可以针对该类目做一行微调，卡片上的锚文本可以突出跟这个类目相关的那部分功能。这不会制造重复内容，因为详情仍是同一个 URL。

别做的是给副分类单独写一份长描述，然后放在详情页里做成 Tab——这种 Tab 内容与按类目切换的依赖 JS，爬行时能读到的往往只有第一个 Tab。想要类目专属说明，就让它在副分类页的列表摘要里存在，别塞进详情页。

什么时候该给一个条目单独新类目

多分类用得多了，自然会想：既然它横跨两个方向，是不是该新建一个交叉类目。判断标准只有一条：这个类目下的条目能不能凑到 15 个以上，并且用户真的会按这个交叉条件来找。凑不满 15 个的新类目是纯负担，它带来的层级复杂度比容纳的条目价值还高。

凑得满的情况也有：麦克风类目下有 8 个播客专用款，用户需求明确，那就该建。建完之后把原类目下这 8 个的主分类改过去，限期一次性做完，用批量脚本一次跑完，再补一轮内链。主分类的迁移是一次性工程，分次做反而让面包屑和统计口径长期处于中间状态。