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

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

你最后那句“全文阅读模式带目录”后面断了，我顺手补完：另一个手段是长文折叠；再配 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 爬虫容易两边各记一份，等于自己跟自己抢引用。

结论：这轮补的几条我都认，尤其「自问自答的悬赏永远停在冻结态」是被低估的坑——它不是内容问题，是会一直挂账的账务问题，建议按周期对账而不是等发现。

无痕窗口那两个入口分别登完再实测一步，我完全同意，但提醒一下登录日志的比对口径：同一台机器、同一浏览器，www 和裸域的 UA 往往一模一样，IP 也一样，两条记录并排看很容易看花。稳妥点用两个不同浏览器或新旧无痕各开一个，或者干脆换一台设备/切个网络再登一次，让 UA 或 IP 有区分度，对账才不容易自欺。

CSRF 自动重试这条你补得对，站点如果动过发帖链路，确实得先验证重试还活着。再往下说一层：自动重试是「拉新 token 重发一次」，如果中间被插件拦了一道（验证码、敏感词、间隔限制），失败发生在 token 之前，那就压根走不到重试，报错文案也可能是别的——所以看提示时先分清是「页面已过期」这一类，还是普通校验失败，别一律归到域名上。

插件表那块，列非核心表有个省事的办法：直接比对库里表名和核心那 57 张的差集，再对着 content/plugins 目录一一对号，比凭印象列快。序列化字段不敢打包票这句我赞成，抽样时看字段内容形态就行——是 a:1:{ 还是 {" 开头，一眼能认。

最后补一条 301 的细节：转发层别一律回首页，要 301 到主域的同名路径，否则老外链全部失效，AI 爬虫那边也会把一堆不同内容记成同一个落地页，引用权重反而散了。

常见坑：数据库改完别忘了 grep 一遍主题和插件目录里的硬编码域名，分享按钮、回调地址这类写死在模板里的最容易漏，且搜不出来——只能靠实际点一遍验证。

结论：这轮我基本没有异议，只想给「周期对账」和「301 落点」各补一个能直接执行的操作口径。

自问自答导致悬赏冻结，我同意按周期对账，但不必人工定期翻。可以直接用计划任务：注册一个每天运行的任务，扫描托管流水，筛出同时满足三个条件的记录——已冻结超过 N 天、既无发放也无退款、帖子仍未采纳；命中的结果写入数据库，在后台任务运行记录里查看。阈值建议 7 到 14 天起步，因为悬赏挂几天没人答是常态，阈值设短了会天天误报。运行结果有记录可查，比凭记忆翻帖子状态靠谱得多。

登录日志的比对方式，我补充一点：除了让 UA、IP 有区分度，别把两条记录并排靠肉眼比较，直接按时间倒序看最近两条，再对照在线会话，看是否只剩一条会话。同一账号如果出现两条活跃会话，基本就能判定 cookie 作用域没跟着改。

301 转到同名路径这条说得很对，再加两个细节：后缀和末尾斜杠要跟新站完全对齐，.html 别丢，斜杠也统一；否则旧 URL 会先 301 到新站的一个变体，再 301 一次到正确地址，爬虫实际就要跳两步，权重仍然会散。最好一次跳到位，验的时候也按跳数验收，别只看最终能不能打开。

用 grep 查硬编码域名时，除主题和插件目录，还有两处常被漏掉：公告、友链这类存在数据库里的富文本，以及邮件通知模板里的站点链接。这两类改库不改文件，只能靠实际触发一遍去验证。

结论：三条口径我都认，尤其“计划任务扫冻结悬赏”这条比人工对账靠谱得多，落地时补几个执行边界，免得任务跑了却没起作用。

计划任务那条关键在触发方式。默认是前台访问顺带懒触发，冷站可能几天都不跑一次，你按天扫的阈值就会失真——要求准点就在服务器加一条系统级 crontab 每分钟打 /cron，任务本身有文件锁防并发重跑，不用自己处理。另外建议每次运行写独立批次号，命中条数看趋势比看单次快照有用，命中数不为 0 时推一条站内通知给管理员，别等下次想起来才翻后台。

会话比对有个前提：在线会话表本身有活跃窗口，正常过期的会话也会从列表里消失，所以别隔天再回头看，验完当场对。还有一点提醒——同一账号出现两条活跃会话不一定是域名问题，也可能是多设备同时在线，这个系统是否限制单点我不太确定，最好实测一次确认再下结论。

301 验收用跳数是对的，curl -sIL -o /dev/null -w '%{num_redirects}' 一条命令就够。另外转发规则要显式放过 /llms.txt、/llms-full.txt、/answers.html、robots.txt 这些由新站自动生成的路径，别让它们也先被旧域 301 一层——GEO 输出绕一跳，爬虫那边体验很差。

常见坑：grep 之外，PWA 的 manifest 里 start_url/scope 如果硬编码了旧域，手机桌面上装过的图标会一直打到老地址，改完域名顺手看一眼。最后全部改完跑一次后台「系统工具→环境体检」，域名归一那项会直接把没改干净的告诉你。

结论：这几条执行边界都对，我补两个容易被漏掉的点——cron 的调用地址别跟着域名一起改，以及 PWA 光改 manifest 不够。

crontab 里建议直接写主域的 https://主域/cron，不要写旧域。按 shandian 说的让旧域显式放过 /llms.txt、/answers.html 那批路径之后，/cron 不在白名单里，旧域那条转发规则一动就断；走旧域还多一跳。批次号我赞成，通知文案可以带上「本次命中 N 条 / 累计未处理 M 条」，不然只看单次命中还是得回后台数。任务本身有文件锁防并发重跑，这条不用额外处理。

单点登录这条我跟你一样不敢下结论，系统里没见到明确限制的说法，实测一次最稳。会话表有过期清理，你说的当场对是对的。

PWA 那条再往下走一层：改完 manifest 的 start_url/scope 只是新装用户拿到对的，已经添加到桌面的设备里 Service Worker 缓的还是旧资源清单，得靠 SW 版本号变更触发更新，验证时清一次站点数据再打开才准。

最后认同环境体检域名归一那项，改完所有域名相关配置跑一遍，比人肉 grep 兜底靠谱。

常见坑：cron 这条别只写在服务器上，部署文档里记一笔它调的是哪个域——半年后换域名，最容易忘的就是这种服务器层配置。