网站上线检查清单

本地处理

打赏支持
分享链接
反馈建议

上线当天出问题的，几乎都不是代码写错，而是这类清单里的某一条被跳过了：HTTPS 跳转没做全、robots.txt 顺手写了个 Disallow: /、sitemap 里混进了测试 URL、favicon 404。勾一遍清单，十分钟省掉三天救火。

为什么是「清单」而不是「经验」

网站上线这件事，复杂度不在技术难度，而在项目数量。一个人凭记忆能想到 HTTPS、能想到 301、能想到 sitemap，但很难同时想到「服务器时区是否与日志一致」「HSTS 该先用短 max-age 试跑」「换域名时旧路径的 301 映射有没有逐条测过」。经验是模糊的，清单是确定的。

这份清单把 54 个检查项分成 6 组，按上线风险权重分配分值（性能体验 22 分、HTTPS 与安全 18 分、抓取与索引 18 分、运维 18 分、内容合规 14 分、域名可达性 10 分），满分 100。打分不是为了好看，而是为了暴露短板集中在哪里。

带「必做」标记的项是阻断项

清单里有 8 项标了「必做」。这些是漏掉就一定会出事的：HTTPS 跳转、证书链完整、全站无混合内容、服务器时间正确、robots.txt 未误拦全站、LCP 达标、无占位文案、备份可恢复。只要有一项没勾，工具会直接给出「不建议上线」的结论——哪怕总分 95。

几个最容易翻车的细节

细节	翻车方式	正确做法
HSTS	直接上 max-age 一年 + preload，某个子域证书不全会导致该子域几个月无法访问	先 300 秒试跑一周，再逐步加到 31536000
robots.txt	测试环境写的 Disallow: / 随部署一起上线，站点从索引里消失	把 robots.txt 纳入上线检查，或按环境动态输出
sitemap	包含 404、重定向、noindex 的 URL，浪费抓取预算	只放 200 且 canonical 自指的规范 URL
缓存	HTML 也被设成一年 immutable，改版后用户看不到新内容	只给带内容哈希的静态资源设长效缓存
表单	上线后才发现 action 指向测试接口	上线前对所有表单做一次真实提交测试

看 Core Web Vitals 时记住 Google 的阈值：LCP 好 ≤ 2.5 秒、需要改进 2.5–4.0 秒、差 > 4.0 秒；INP 好 ≤ 200 毫秒、需要改进 200–500 毫秒；CLS 好 ≤ 0.1、需要改进 0.1–0.25。这三个指标按真实用户数据的 75 分位计算，不是实验室跑一次就算数。

你可能还想问

上线前最该检查什么？

域名解析与证书、核心页面可访问、表单与支付等关键链路、站点地图与抓取规则、监控与回滚方案；漏一项都可能影响上线。

为什么要准备回滚方案？

上线常伴随意外，出现严重问题时能快速恢复到上一个稳定版本，把影响面控制到最小；没有回滚等于只能硬扛。

上线后要立刻做什么？

观察监控与错误日志、检查关键指标是否正常、验证搜索引擎能正常抓取；发现异常立即处置，别等到第二天。