网站改版很少只改一件事：换模板、换域名、调整栏目、重写 URL 规则，常常在同一周内一起发生。风险也来自这里——单看每一项都有人负责，合在一起就没人确认。上线后才发现 robots.txt 挡住了新目录、canonical 还指向测试域名、模板页脚挂着旧链接，这类事故在站点运营里反复出现。把检查项提前写成清单，比临场凭记忆靠谱。
第一步：把改动范围写清楚
清单的前提是知道改了什么。切换前用一页文档列出：
- 域名、协议、WWW 前缀是否变化；
- URL 规则是否变化，哪些栏目受影响；
- 模板层面改了哪些公共区块，比如导航、面包屑、页脚、结构化数据；
- 内容层面是否存在批量迁移、下线或合并；
- 涉及的外部依赖：CDN、统计代码、第三方接口、站长平台的验证文件。
范围写清楚之后，每一类改动对应一组检查项，责任到人，避免“以为别人会看”。
第二步：切换前的抓取与索引检查
被挡住与被排除
- robots.txt 是否放开了新模板需要的目录与静态资源路径；
- 页面头部是否残留测试期使用的 noindex、nofollow 标记；
- canonical 是否仍指向测试域名或旧地址；
- 响应头里是否还有用于预发布环境拦截蜘蛛的规则未清除。
地址映射
如果 URL 有变化，需要一份旧地址到新地址的映射表，并坚持一对一。旧地址直接跳到新地址，不要出现 A 跳到 B、B 再跳到 C 的链路。映射表里查不到对应关系的历史链接，统一落到最相关的栏目页或首页，而不是全部甩给首页。
页面级细节
- 面包屑、导航、正文内链是否还指向旧地址；
- 站点地图是否按新结构重新生成，是否还包含已下线的地址；
- 404 页面是否给出搜索入口和主要栏目入口；
- 移动端与桌面端能否拿到同样的正文内容。
第三步：切换当天的动作顺序
- 提前把域名 TTL 调低，避免切换后解析长时间摇摆；
- 确认旧版本可随时恢复，回滚路径不依赖临时搭建；
- 选择访问低峰期执行，并留下明确的开始与结束时间；
- 切换后立刻抽样访问：首页、一级栏目页、详情页、分页第二页、404 页、站内搜索结果页；
- 用事先准备好的地址列表跑一遍状态码扫描，看清 200、301、404 与 5xx 的分布。
抽样检查只能证明页面“能打开”，状态码扫描才能证明没有大面积指向错误。两者都要做，顺序不要颠倒。
第四步：上线后的观察窗口
切换完成不代表结束。接下来两到四周是问题集中暴露的时期：
- 访问日志里 404 与 5xx 是否出现异常峰值，来源集中在哪些目录；
- 蜘蛛对旧地址的访问量是否逐步下降，是否还在抓取已经下线的页面；
- 站长平台里的抓取与索引统计是否出现异常波动，用来定位问题而不是追数字；
- 站内搜索与关键转化路径的埋点是否正常上报。
这个窗口期内不要连续做大改动。一个问题还没定位清楚就叠加第二版模板，日志和数据的因果关系会变得难以判断。
第五步：回滚预案要写下来
回滚不是失败，而是清单的一部分。提前写清楚触发条件（例如 5xx 比例、核心页面不可用时长、关键转化断崖）、执行人、执行步骤和预计耗时。只保留旧程序备份、却没写恢复步骤，等于没有预案。
可复用清单
- 改动范围文档已完成，责任人与时间点明确；
- robots.txt、页面头部标记、响应头规则均按正式环境配置；
- canonical 与站点地图统一指向正式域名；
- 旧地址映射表完整，无链式跳转，兜底地址合理；
- 模板内旧链接已清理，面包屑与导航指向正确；
- 状态码扫描通过，404 页与首页均无异常；
- 观察窗口与回滚预案已确认，并指定跟进人。