内容发到多个平台后，产品里很自然会多出一个功能：在文章底部列出“本文也发布在 X、小红书、知乎、B 站”，旁边再加上各自的外链。

从运营视角看，这像是在提供更多入口；从系统视角看，它又像是在展示分发完整度。

我最后把这些公开入口全删了。文章详情页不再显示平台卡片，内容列表不再显示“N 次分发”，公开 API 和 SSR 数据也不再下发平台外链。后台的分发台账、分片、指标和历史链接全部保留。

不是分发不做，而是分发记录不应该自动变成读者的导航。

一、每一条外链都在把注意力送出主站

独立站本来就不依赖这些反链获得流量。读者已经在原文页面里，继续读下去才是主站的默认目标。此时再给出六七个平台入口，等于在每一篇文章底部主动制造一次分流。

读者点走一次，可能就进入另一个账号页、另一个推荐流、另一套登录和通知。主站并不会因为这个动作直接报错，但会损失真正稀缺的东西：读者的下一步注意力。

这并不意味着内容不应该分发。分发是触达新读者，原文页是把已经被触达的读者留下来。两件事的目标不同，不能因为后台都叫“publication”，就在前台共用一套展示。

二、多平台列表会削弱主站的主体性

“本文也发布在……”很诚实地记录了复制关系，但在读者眼里，它也可能产生另一种印象：这篇文章是聚合页，真正内容散落在别处。

尤其当标题不同、封面不同、平台版本也经过改写时，列出一排入口并不能帮助读者理解哪个是完整版本。相反，它会让原文看起来只是其中一个副本。

主站需要的身份是：这里是 canonical original，是长文、完整结构、可检索的源页面；平台版本是传播形态，不是并列目录。

平台版本身然可以直达，例如 /p/<slug>/x 或 /p/<slug>/xiaohongshu，但公开详情页不再主动列出它们。需要平台账号的人，可以从 /about 找到 active 渠道；搜索引擎仍能通过结构化数据建立账号关联。

三、外链会腐烂，记录不会

历史 publication 里已经出现过失效链接、裸链接和被平台重新包装的 URL。每在公开页多挂一个入口，就多一个需要永久维护的承诺。

但分发台账的用途完全不同：它需要保留历史，哪怕链接失效、平台改版、账号迁移。它是审计材料，不是营销组件。

这两种需求放在同一个接口里，就会互相污染：

需求应该去哪里
读者看这篇的原文独立站详情页
找到创作者的其他账号/about 的 active channels
查看这篇文章发过哪些平台后台分发台账
统计每个平台的指标后台 publication 与 metrics
直达某个平台版明确的平台路径，不从详情页主动导流

数据存在，不等于数据要公开；保存历史，不等于要在每一页重复展示历史。

四、公开接口也应该跟着收敛

只把前端组件删掉还不够。如果公开 API 和 SSR 数据仍然返回 publication_links、latest_external_url、external_url 和 external_id，任何客户端都能重新拼出一个跨平台列表，公开边界就不完整。

所以我同时改了投影层：

  • 公开文章详情不再返回分发外链；
  • 公开列表不再返回 N 次分发 所需的链接；
  • SSR 数据不再把这些字段带到浏览器；
  • 后台管理接口继续保留完整台账；
  • 平台页面仍可直达，但顶部提供回原文的入口。

这不是删除数据，而是把“可公开字段”和“可管理字段”分成两份投影。数据库是事实来源，前台只是事实的一种视图。

五、这是一个有代价的决定

删掉跨平台入口不是没有损失：

  • 失去了最直接的站外关注转化；
  • 不会再用外链给其他平台导流；
  • 一部分读者确实要通过 /about 多点一步；
  • 对历史页面来说，这是一次公开行为的改变。

但我认为这个代价值得。新的规则更清楚：

  1. 原文只指向自己。 读者读完就在主站继续找相关内容；
  2. 账号入口只集中在资料页。 不在每篇文章底部重复导流；
  3. 平台版只做直达。 有链接的人可以看，不主动抢原文读者；
  4. 分发记录只服务运营。 后台完整，公开不展示；
  5. 外部链接不进入公开 API。 不让“隐藏”只停留在 CSS。

六、真正要防止的是“记录系统变成展示系统”

内容系统很容易因为字段齐全，就顺手把所有字段都渲染出来：有平台名就做卡片，有外链就做按钮，有分布次数就做徽章。

但记录系统的目标是可追溯，展示系统的目标是帮助当前读者完成任务。两个目标不一样。

我现在更愿意把分发台账当成内部资产：它告诉我这篇文章到过哪里、效果如何、以后是否值得继续发，但它不应该要求读者也看见全套操作后台。

对读者来说，最重要的信息是：这是一篇完整原文，标题、摘要、标签和正文都属于同一个页面。

分发是幕后工作，不是正文的一部分。