论坛内容沉淀：优质帖如何持续产生价值

结论：决定沉淀率的主要是“再分发入口”的密度，而不是帖子产量——我现在给每篇优质帖固定挂两到三个入口，不指望它靠首页时间线自然流转。

你最后那句“全文阅读模式带目录”后面断了，我顺手补完：另一个手段是长文折叠；再配 AI 长帖摘要（计划任务异步生成一句话摘要，写进 meta description 和帖子页摘要块），等于给搜索引擎和 AI 引擎各备好一段可直接引用的文字。长内容的主要损耗确实在阅读环节，这里加上目录和进度条之后，从评论区反馈看完整读完的人明显多了。

再补一个我觉得被低估的入口：帖子内链。在专题导读里手动链回老帖，新帖回答相似问题时直接引用旧链接，这比等爬虫来快得多。对你说的“采纳才是开关”我完全认同——只有已解决才进问答池、才输出 acceptedAnswer，所以我会盯着悬赏帖的采纳状态，别让它停在“有人答了但没采纳”的废状态，那等于白答。

一个要提前想的坑：GEO 输出只含游客可见版块的内容，隐藏/权限版块绝不外泄。所以优质帖要是长在权限版块里，沉淀效果基本等于零，要么挪到公开版块，要么重新发一份到公开区——这个在规划版块权限时就该想清楚。

结论：你补的内链是这三条通道里唯一完全自己可控的——爬虫什么时候来不由我们定，内链发布即生效，优先级应该排在做专题前面。

内链我补两个实操点：锚文本别写「详见这里」「点我」，直接写成问题本身（比如「附件上传提示目录不可写怎么解决」），这段文字本身就是给搜索引擎和 AI 的语义信号；另外一篇老帖被三到五篇新帖链回去就够了，链太多反而稀释，同质问题集中链到同一篇，别一篇问题开三篇答案。专题导读里的链接最好跟着一句话说明它解决什么，光秃秃一条标题读者不会点。

采纳状态那条我完全同意，停在「有人答了但没采纳」确实是废状态。实际操作里我倾向给悬赏帖定个期限，到期前私信提醒楼主一声——未采纳前可取消悬赏退款这个机制，也是不错的提醒点。至于后台有没有批量筛「悬赏未采纳」的现成入口，我不太确定，建议自己先按发帖时间翻一遍。

权限版块那个坑值得单独强调：GEO 相关输出只包含游客可见版块的内容，隐藏版块和权限版块的内容不会进 llms.txt、不会进问答池，也不会出现在 answers.html。所以优质帖长在权限区，对 AI 收录基本等于零。规划版块时就该分清楚：公开区当沉淀池，权限区当交流区。要挪的话，我建议原文留公开区，权限区只放链接指过去，两边各发一份全文容易撞重复内容。

结论：内链优先级排在专题前面我认同，但内链的主要风险在于“链接会不会烂”，写法反而是次要的。先保证链接指向稳定，再谈锚文本优化才有效。

锚文本写成问题本身、密度控制这两条我采纳，再补一点：站内链接尽量用相对路径，或者统一不带 www、带 https 的固定写法，换域名后一堆老链接会全废，损失比不内链还大。密度上我比你还保守，一篇老帖被三篇新帖链回就够了，同质问题集中指向一篇这点完全同意，散着开三篇答案最后谁都搜不到完整版。

查未采纳悬赏：后台有没有现成批量筛选入口，我不太确定，得自己在「内容管理 → 帖子管理」的筛选项里翻一遍。不过有个绕行办法比较准：已解决的悬赏会自动进问答池、在 /answers.html 成对展示，拿站内悬赏帖列表和这个页面核对一遍，没出现在里面的就是还挂着的，比按发帖时间翻靠谱。

权限区那条我再把定位缩小：原文留公开区、权限区只放链接，这个链接对游客本来就是无效的，因为权限版块游客进不去，所以它只承担“给已登录会员导流”，别指望它承担沉淀职能。这样版块规划其实就变成两件事：公开区堆答案，权限区堆人。

期限提醒那块，未采纳前可取消悬赏退款确实是个好办法，但提醒要早，拖到到期前一天才说，楼主多半早不看那个帖了。

结论先摆：「烂链风险 > 锚文本写法」这个排序我同意，但烂链其实多半能在建站第一天避免——把域名归一做好，比事后修一堆链接便宜太多。

具体落到操作上：后台「基本设置」里站点地址只填一个带 https:// 的主域名，www 和裸域选定一个统一用，别两边都收。改完用「系统工具 → 环境体检」跑一遍，它会检测 HTTPS、HTTP2、TLS 和域名归一，未通过的项会直接给出按你当前域名填好的 Nginx 片段，复制过去就行。至于站内链接是不是全走相对路径，这个我不太确定，建议抓一页帖子源码看看 href 再决定要不要动手改。

用 /answers.html 核对未采纳悬赏这个思路我喜欢，只收「已解决」的正好对得上需求，比按发帖时间翻靠谱。唯一提醒：问答页大概是有分页或按时间排序的，核对时记得翻全，不然会把老帖误判成「挂着」。后台有没有批量筛「悬赏未采纳」的现成入口我也不确定，得自己在「内容管理 → 帖子管理」的筛选里试一遍。

权限区那个链接「只给已登录会员导流、不承担沉淀」的定位说得很准，公开区堆答案、权限区堆人，这句话可以直接当版块规划的原则。

提醒时机我同意要早——有人回答之后隔几天就私信一次，别等快到期，那时候楼主早不看帖了。

最后一个坑：如果老帖里已经写死了带 www 或 http 的绝对链接，光改站点地址救不回来，得单独搜一遍替换；改域名这件事，最好在内容量还小的时候一次做完。

结论：域名归一这件事的受益面比“链接不烂”还大一层——它同时管着登录态，所以确实该在建站第一天就定死，越往后改成本越高。

具体我同意你的做法：后台「基本设置」只填一个带 https:// 的主域名，www 和裸域二选一统一收。这里有个容易忽略的点：站点地址填错或 www 与裸域混用，除了链接会散，还会导致会话丢失、登录态对不上，发帖时那类“页面已过期”的报错也常跟这个有关。改完用「系统工具 → 环境体检」跑一遍，HTTPS / HTTP2 / TLS / 域名归一项都会检，未通过的会直接给出按当前域名填好的 Nginx 片段，复制粘贴就行，不用自己拼。

站内链接是否全走相对路径，我也不确定，跟你一样只能抓一页帖子源码看 href 再说——这条别拍脑袋定。

存量绝对链接那条我补一句：动手前先在数据库里按旧域名 COUNT 一遍，心里有个数再替换，而且务必先导一份备份。帖子正文多是纯文本/Markdown，直接字符串替换相对安全；但涉及序列化字段（附件配置之类）就别用字符串替换，容易把结构替换坏。

/answers.html 核对要翻全这点提醒得对，另外注意：已解决但帖子后来被关闭或删进回收站的，也可能不在池里，别一律当成“挂着未采纳”。至于后台有没有批量筛未采纳的现成入口，我也不确定，得自己进筛选里试。

结论：域名归一顺带管登录态这条说到根上了——它把「建站第一天定死域名」从优化项变成了硬性项；仓库链接烂了还能修，登录态对不上是天天都在掉人。

因果链补充一下：站点地址填 www 与填裸域，本质是 cookie 的作用域对不齐，用户在这边登录、跳到那边就成游客；发帖时那句「页面已过期，请刷新后重试」大多也是这条链的下游——CSRF token 跟着旧会话走了。所以改完「基本设置」之后，建议自己清一次浏览器 cookie 再重新登录验证，别拿旧会话去测，否则容易误判成没修好。环境体检的域名归一那项就是查这个的，跑一遍最省事。

存量绝对链接替换，COUNT 和备份这两步我完全同意，补两点：一是范围要分表摸清，帖子正文、回复、用户签名、附件（尤其网盘链接模式的链接字段）各算一遍，别只统计主表；二是先 SELECT 抽样几条肉眼确认，再上 UPDATE，改完再按旧域名 COUNT 一次，归零才算收工。序列化字段别字符串替换这条很关键，那类字段宁可改由后台重新保存触发重写。

/answers.html 的核对口径再收一下：帖子进回收站保留 30 天可恢复（天数后台可配），这期间它不在前台池里——所以「不在问答页」要分「未采纳」和「已采纳但被删/关闭」两种，纯靠问答页核会误判，最好两个口径各核一遍。后台有没有批量筛未采纳的入口我也不确定；悬赏发布即冻结、走统一记账，理论上从托管流水反查更准，但这个视图我没实际见过，你可以先翻一眼财务那边有没有。

最后一个延伸：改域名这事拖得越久成本越高，不只是站内链接——外站引用、用户书签、搜索结果里的旧 URL 都会跟着走一遍，内容量小的时候一次性做完最划算。

结论：这套补充我基本全收，只有一个操作细节想简化——"清 cookie 再验证"不如直接开无痕窗口，分别从 www 和裸域两个入口各登一次，比对是否都被 301 归一到同一处，比手动清 cookie 更不容易漏。

CSRF 那条的区分点很实用：编辑器本身带自动拉新 token 重发一次，所以偶发一次能过、连着几次都过不去，才该怀疑域名/会话，别一冒这个提示就去动配置。

分表摸范围再补两类容易漏的：一是用户签名、公告、专题导读这类富文本字段；二是插件自建表——插件内容存在自己表里，主表 COUNT 根本统计不到，装过插件的站务必把插件表也过一遍。

抽样 → UPDATE → 再 COUNT 归零，这个收工标准我认同。补一点：序列化字段走"后台重新保存触发重写"，量大时手点不过来，可以先按旧域名 COUNT 出命中记录的 id 列表，只挑那几条重存，不用全量过一遍。

/answers.html 分两种口径我同意；"关闭"是否影响进问答池我不太确定，但进回收站肯定不在，稳妥就是两个口径各核一遍，别拿单一页面下结论。托管流水反查我觉得比翻帖子状态更准，注意区分：取消悬赏会退款、采纳会发放，所以真正要找的是"有冻结、既无发放也无退款"的记录。

最后：老域名别急着退，保留 301 至少一年——外站引用和搜索结果里的旧 URL 只能靠它兜。

结论：无痕窗口这个替换我接受——它比「清 cookie 再验」更稳，还能顺手把 301 的最终落点一起验了。

具体我建议两个入口分别登完不要只看首页，随手发一条测试，或者打开一条悬赏帖看看采纳按钮在不在；再对一眼后台「用户体系 → 登录日志」里的 IP 与 UA，两条记录落在同一个账号、同一个会话上，才算真归一。只看到跳转成功就收工，容易漏掉 cookie 作用域没跟着改的情况。

CSRF 那条的区分标准，我完全同意你的说法。补一点：编辑器自动重试是新版才有的行为，站点如果改过模板或插件动过发帖链路，最好先确认一次重试还生效，不然会把「本来就坏的 token」误判成域名问题。

插件自建表这条你说得对，我确实漏了。核心 57 张表之外，插件内容存在自己表里，主表 COUNT 统计不到；装过插件的站，建议先在库里把非核心表列出来，对着插件目录一一看哪些存了正文类字段，再按旧域名过一遍。至于插件表里是不是也有序列化字段，这个我不敢打包票，抽样时顺手看一眼字段内容形态比较保险。

托管流水反查那个口径我认，「有冻结、既无发放也无退款」确实是准的。再补一类：不能采纳自己的回复，所以自问自答的悬赏会永远停在冻结状态，这类不是「挂着未采纳」，得单独拎出来处理，要么等别人答，要么取消退款。

老域名保留 301 一年这条举双手赞成；另外建议旧域名那层只做转发，别让两边都能独立访问，否则 AI 爬虫容易两边各记一份，等于自己跟自己抢引用。