批量替换链接之后，已经生成的静态页面要不要重建

用后台的全站替换改掉链接之后，已经生成的静态页面要不要重建？判断依据只有一条：这个站点有没有把页面落成静态文件。纯动态渲染的站点每次请求都从数据库取内容，替换完刷新即可见；开了静态化的站点，前台访问的是先前生成的文件，数据层改了也不会自动同步，必须重建才会生效。

全站替换改的是哪一层

AnQiCMS 的全站替换支持关键词与链接两类批量改写，作用范围是数据库里的正文、标题等字段，导航设置和单页面管理里的内容同样在替换范围内。也就是说，它改的是”数据”，不是”已经写出去的文件”。这一步容易理解错：有人以为替换完成前台就变了，实际上从数据到可见之间还隔着静态化与缓存两段。

如果替换的是导航里的菜单文字，而导航是通过模板在渲染时读取的，那么前台立刻就是新文案；但如果这套导航被一并静态化进页面文件，旧文字仍会留在文件里，直到重建才会消失。

为什么改完前台还看得到旧链接

常见有三种情况，处置方式不同。

第一种是页面本身被静态化。地址形式由伪静态规则决定，规则匹配到某个路径时，服务器可以直接返回先前生成的静态文件，此时浏览器和爬虫拿到的都是旧内容。这种情况要重建，不是清缓存。

第二种是缓存层在中间挡着。整页缓存或对象缓存命中时，即便数据层已经更新，返回的仍是缓存里的旧结果。这种清缓存就会好，不需要整站重建。

第三种是替换没有覆盖到。批量替换按匹配串工作，写法不同的链接（少一个斜杠、带了域名前缀、写在模板里而非正文里）会漏掉。改完抽样二十到三十个页面核对，比改完后凭印象翻几页要可靠。

静态页重建要不要挑时段

重建是逐个页面重新生成的过程，对整站批量执行时会持续占用服务器资源。合理的做法是：

先在小范围验证替换结果，确认新地址都能正常打开，再触发整站重建；把重建安排在访问低谷，避开业务时段，减少与正常访问争抢资源；重建完成后抽查列表页、详情页、分类页三类地址，列表页的翻页地址最容易被漏掉。

重建之前先做一次备份。重建失败或替换串写错时，备份与恢复是回到改动前状态的退路，这一步比事后手工逐页改回来省事得多。

换地址时配套要做的两件事

如果替换的不只是文字，而是把文章地址整段换掉，旧地址会直接失效。这时要配套两步。

一是给旧地址设置 301 跳转，把先前进过外链、被搜索引擎收录过的旧路径指向新地址，避免流量在切换当天断掉。跳转规则要按批量对应关系写，一条一条手工补容易漏。

二是把站内引用改干净。正文、导航、单页面里残留的旧链接如果没被替换覆盖，重建之后仍会指向失效地址，形成站内死链。改完再从站点地图入口抽查一轮，确认提交给搜索引擎的地址是新的。

常见问题

只改关键词文字，不改地址，也要重建吗？ 纯动态渲染不用；开了静态化就要重建，否则文件里仍是旧文字。不确定时先清缓存看是否变化，变了是缓存层，没变就是静态文件。

重建会影响正在访问的用户吗？ 重建期间服务器负载上升，建议放在低峰执行。重建前完成备份，出现问题可以恢复。

替换错了能撤回吗？ 批量替换本身没有逐步撤销的入口，撤回要靠替换前的备份恢复，这也是重建前先备份的原因。

改完地址要不要通知搜索引擎？ 旧地址保留 301 跳转的站点，让爬虫顺着跳转找到新地址即可；同时把站内引用和提交给搜索引擎的地址一并更新，避免新旧两套地址长期并存。