旧网站改版上线前要检查哪些表单、死链和备份事项？这个问题看着像三张清单，到了真正切流量的那一晚，它们其实是一件事：新站出了问题，企业能不能及时发现，能不能保住原有的客户入口和搜索资产，还能不能退回一个可用版本。

红数科技在做上线验收判断时，不把“首页能打开”当作完成。一个更可靠的口径是：关键业务走得通，旧地址有明确去处，现场有人能用备份恢复。三项里只要有一项没有证据，就不该靠一句“应该没问题”放行。

表单要查到数据落地，不能停在提交成功

先把全站所有可能收集信息的入口找齐。除了联系表单、报价申请、预约和留言，还要留意页头页脚的小表单、产品详情页咨询、弹窗、下载资料前的登记、活动落地页、站内搜索、注册登录、找回密码、文件上传，以及嵌在页面里的第三方表单。桌面端能看到的入口，移动端未必完全一样；旧活动页和广告落地页也常常不在主导航里。

每个入口都要跑一遍完整去向：页面是否收到提交请求，服务端是否接收并校验，数据库或客户管理系统里是否生成记录，负责人员有没有收到提醒，感谢页或状态提示是否正确，分析工具有没有记下一次真实转化。只看到“提交成功”四个字不够。前端可以显示成功，后端接口仍可能超时；邮件提醒可以到达，客户资料却可能没有写进客户管理系统。

测试数据要能被认出来，比如统一使用不会混入真实业务的测试姓名和备注，并在验收后清理。建议至少覆盖这些情况：

正常填写后只生成一条记录，连续点击提交不会造成重复线索或重复扣费。
必填项为空、邮箱或手机号格式错误、内容过长、含特殊字符时，提示落在具体字段旁边，用户知道怎么改，已经填写的其他内容不会全部丢失。
上传文件时，类型、大小、数量受到限制；危险格式不能因为改了扩展名就通过。
验证码、短信或邮件验证、隐私同意、反垃圾策略确实生效，失败后也有可理解的反馈。
收集的字段确有业务需要，隐私说明链接可以打开；测试记录进入后台后，只有该处理这类信息的人能够查看和导出。
弱网、接口超时、第三方服务暂时不可用时，不把失败说成成功，也不会反复生成脏数据。
手机、电脑和网站实际支持的主流浏览器均能完成提交；键盘操作、字段标签和错误提示没有被新版样式遮住。

表单校验不能只写在浏览器里。OWASP 的输入校验说明把服务端校验作为必要措施，因为前端校验可以被绕过；对文件上传、自由文本和会进入后台的数据，还要按实际业务限制类型、长度、格式和允许范围。W3C 的 WCAG 2.2 也给出了很朴素的要求：需要输入时提供标签或说明，检测到错误后明确指出出错项，并用文字描述错误。它们不只是无障碍细节，往往也直接决定一个普通用户能不能把表单填完。

死链检查的重点，是旧地址以后怎么走

改版后的死链不能只靠人工点菜单。应该先从旧站导出可访问 URL，再合并旧版 XML 站点地图、分析工具里有访问量的页面、搜索平台已经收录的地址、外部网站带来访问的落地页，以及还在投放的广告链接。新站自身再完整抓取一遍，检查页面链接，也检查图片、脚本、样式、PDF 和下载文件。这样得到的才是接近真实流量入口的 URL 清单。

接着做一张旧地址到新地址的映射表。页面只是换了路径，应该一对一转到内容最接近的新地址，通常使用服务端永久重定向 301 或 308。不要把一批删掉的文章、产品页和地区页全部送回首页，这对访问者没有帮助，也可能被搜索引擎判断为软 404。确实没有替代内容的页面，应返回真实的 404 或 410；服务器异常、超时和 5xx 则属于必须处理的上线故障。

重定向还要看它怎么走。旧地址最好直接到最终地址，中间不要再绕两三跳，更不能形成循环。HTTP 与 HTTPS、带不带 www、结尾斜杠、大小写、参数保留规则，都要按站点实际情况统一。站内链接随后改成最终 URL，不要让每次点击都先经过一次重定向。

Google Search Central 对网站迁移的建议很明确：提前建立旧 URL 与新 URL 的对应关系，使用永久服务端重定向，避免重定向链；迁移后更新站内链接、规范网址和站点地图，并持续监测。其文档建议重定向通常至少保留一年，让搜索信号有足够时间转移。若旧地址仍有用户访问或外部链接，保留更久往往更稳妥。

到这里还没结束。上线包里要确认正式域名的 robots.txt 没有误封重要目录，预发布环境使用的 noindex 或访问限制已经从正式页面移除；规范网址指向正式新地址，XML 站点地图只放可索引的最终 URL。链接本身也要是可抓取的真实地址。按钮靠脚本跳转、标签没有有效 href，人能点开，不等于搜索引擎一定能稳定发现。

备份文件存在，不等于网站能恢复

上线前的备份不能只是一份网站压缩包。一个能支撑回滚的备份，至少要说清楚这些东西在哪里：

需要留存的内容	验收时要看到什么
数据库	与切换时间对应的完整备份，版本、时间和校验结果可核对
用户上传与媒体文件	图片、附件、下载文件完整，和数据库记录处于可接受的一致时间点
程序与构建产物	上线前旧版、待发布新版及对应版本号都能找到
配置	Web 服务器、任务计划、缓存、重定向、CDN、WAF、DNS 等关键配置有可恢复副本
第三方集成	邮件、短信、支付、客户管理、统计等依赖项有配置清单；密钥按安全方式保管，不把明文混进普通压缩包
操作记录	谁在什么时间备份、由谁保管、如何恢复、恢复后检查哪些页面和业务

备份至少要与生产环境隔离，限制访问权限并加密。条件允许时，保留一份离线或不可变副本，不要让生产账号被攻破后还能顺手删除所有备份。CISA 的勒索软件防护指南同样强调：关键数据应保留离线、加密备份，并定期在灾难恢复场景中检查备份的可用性和完整性。

发布单上还应写下两个具体时间。一个是最多能接受丢失多长时间的数据，另一个是故障后必须在多久内恢复核心网站。前者决定数据库和上传文件备份要做到多密，后者会反过来检验现有人员、带宽和恢复步骤是否够用。只写“每天备份一次”，回答不了这两个问题。

真正有分量的验收动作是恢复。找一个隔离环境，把数据库、媒体文件、程序和配置从备份中还原，打开关键页面，再提交一条测试表单。记录恢复用了多久、缺了什么权限、哪些步骤依赖某个人脑中的记忆。文件能解压，只能证明压缩包没坏；恢复后的站点能登录、能显示内容、能完成核心业务，才证明这份备份可用。

回滚方案还要提前约定触发条件。比如关键表单无法落库、支付或登录大面积失败、主要页面持续返回 5xx、数据迁移出现不可接受的错位，达到哪一种程度就停止排查并回退。谁下决定、谁执行、DNS 或 CDN 怎么切、数据库结构能不能向后兼容，都写进同一张发布单。新版如果已经写入了旧版不认识的数据，单纯换回旧代码未必能恢复业务，这一点最容易在紧急时刻暴露。

上线前最后一次放行，至少要拿到这些证据

把口头确认换成可以复查的记录，发布会会短很多。红数科技建议在最终放行单里保留以下内容：

全部表单入口清单，以及每个入口从页面提交到后台接收的测试结果。
旧 URL 到新 URL 的映射表，死链扫描结果，重定向链和循环检查结果。
正式环境的 ‎robots.txt、规范网址、XML 站点地图和状态码抽查记录。
备份文件位置、生成时间、校验结果、保管权限和最近一次恢复演练记录。
回滚触发条件、执行人、决定人、预计恢复时间，以及上线后的观察人。

发布后最初几小时，盯住 4xx、5xx、表单成功率、核心接口和服务器资源；第二天核对实际线索是否进入业务系统，再看搜索平台的抓取异常和索引变化。改版规模较大时，接下来一到两周仍要持续看旧地址访问、重定向命中、软 404、主要页面收录和自然搜索流量。网站迁移本来就可能带来短期波动，但真实错误不能被“改版都会波动”这句话盖过去。