网站上线检查清单：上线前、发布当天与第一周怎么验收

网站上线检查清单的作用，是确认一个陌生用户能打开正式网站、看懂你提供什么、完成关键操作，并得到承诺的结果。它还要回答另一个问题：发布出错时，你能不能及时发现，知道该恢复哪个版本。

下面按上线前、上线当天和第一周安排检查，每项都有操作与通过标准。示例是一款虚构的小型 SaaS：公开文章、邮件登录、保存项目、付费订阅。作品集可以把付款换成询盘，电商则需要补库存、运费和订单履约。文中的检查是建议执行的验收方法，不是已经完成的真实上线测试。

1. 先定清楚：什么问题必须拦住上线

先写一条完整用户路径，再打开测试工具。例如：“用户从定价页进入，注册账号，创建项目，完成付款，获得对应权限。”如果网站用于接单，路径就是看案例、提交需求、收到确认、负责人收到线索。

不要让清单上的所有问题看起来一样重要。登录恢复失效、表单提交后丢失、别人的私有内容可以打开、扣款成功却不交付，都应该阻止发布。非必要动画、某张配图不够精致，可以安排后续处理。搜索排名和真实用户性能数据则需要上线后观察，不能当作上线当天必须兑现的承诺。

即使整个网站只有你一个人做，也要保留证据：检查地址、版本、设备或浏览器、结果和时间。没有测试就写“未测试”，不能因为页面看起来正常便打勾。不适用的项目写明原因，以免下次复用时误删必要步骤。

如果你还没确定各页面承担什么任务，先做一次内容映射。上线检查能发现功能缺陷，却不能替你解决“每个页面都在讲同一件事”的问题。

2. 上线前：正式域名、安全与环境边界

预览地址能打开，不代表正式环境已就绪。域名解析、跳转、登录回调、邮件链接和支付通知，都可能在切换域名后出问题。用退出登录的浏览器测试正式站点，并直接打开一条深层页面。

预览环境中的秘密不能靠 robots.txt 保护。对公开但不希望进入搜索的页面，noindex 是另一种用途；如果禁止 Google 抓取，它也可能读不到这条指令。Google 的 noindex 说明解释了两者的关系。

不要为了开放首页，一次性移除全站访问保护。应分别检查公开营销页、账户页和预览环境的边界。公开页面配置正确后，如果仍然停在“已发现但未编入索引”，再用专门的排查流程继续定位。

3. 上线前：用新账号走完核心操作

开发时常用的账号通常已经有数据、有权限，反而容易漏掉新用户遇到的问题。要用空账号走正常路径、失败路径和恢复路径。注册成功但确认邮件跳回本地地址，整个流程依然没有通过。

把可访问性放进这条路径里：只用键盘能否完成操作？焦点是否可见？输入框是否有标签？校验提示是否说清楚改哪里？对话框打开后是否能退出？这些都比单独问“有没有做无障碍”更容易验收。

手机上需要检查导航、长标题、输入框和提交按钮，不能只看首页缩小后的样子。再用长名字、空状态和远多于演示数量的记录走一次流程，确认操作入口没有被内容挤掉。

若网站卖产品，还要把定价页承诺与用户实际获得的权限逐项对应。页面写着可使用的功能，不能在付款后才发现没有开通。

4. 上线前：让重要页面具备进入搜索的条件

先挑重要页面：首页、核心服务页、定价或联系页，以及少量有实际用途的文章。私有账户页、重复排序地址和结账回跳页，不需要为了“全部收录”塞进搜索。

Google 的技术要求给出了搜索资格的最低条件，满足条件也不保证收录。

Sitemap 是发现辅助，不是收录保证。lastmod 应反映页面有意义的修改，不要每次部署都把所有地址改成当天。Google 的 Sitemap 文档可作为配置依据。

上线前也适合检查一次关键词映射，避免几个页面争同一组搜索意图。如果后续发现某页还没抓取，转到已发现未收录排查指南，不要把重新提交全站 Sitemap 当成每天的维护动作。

5. 上线前：付款要验交付，统计要验含义

支付按钮能跳转，只证明入口存在。要用服务商支持的测试环境覆盖成功、失败、放弃，以及适用的订阅场景。确认外部订单映射到正确账号，通知重复到达时不会重复交付，并检查测试与正式环境的密钥、商品、价格和回调是否有意分开。

Stripe 测试文档提供模拟场景；其履约文档解释了为什么不能只依赖用户返回成功页来交付。使用其他平台时按对应官方流程验收。测试环境通过也不等于正式付款已经验证，生产交易演练需由负责人明确安排。

不要把“点击付款按钮”当作收款金额。测试订单也不应该混入业务收入。检查分析工具与错误日志收到哪些个人信息，并把适用的同意行为纳入真实流程验收，而非只确认页面上有个横幅。

平台还没定，可以先看SaaS 收款方案选型；付费状态与权限处理用订阅计费指南提前定义。上线当天应该验证既定规则，而不是临时决定退款是否等于停止访问。

6. 上线当天：小范围验收，保留恢复路径

记录本次版本、上一个可用版本和发布负责人。尤其要知道“回滚”能恢复什么：代码恢复并不自动撤销数据库迁移，也不会撤回已经发生的外部交易。涉及数据结构调整时，提前确认兼容性和恢复方式。

发布后马上走一条最小完整路径：首页、深层地址、登录、关键操作、保存、交付。用受控测试信号确认监控确实收到事件，且没有泄露私人数据。打开支持收件箱，明确由谁处理反馈。

关键路径损坏时先停止推广，按预先准备的方式恢复。保留失败步骤和对应版本，再做修改。连续改多个生产配置却不记录，会让下一轮排查更难。

性能也要分阶段看：流量到来之前，用实验室测试找明显问题；有足够数据后，再看真实用户表现。Web Vitals 文档区分了这两类测量。新站没有足够现场数据很正常，不能用一次评分代替真实体验。测试时要覆盖访客真正进入的页面，以及同意后加载的第三方脚本。

把重点页面与内容映射表对应起来，发生故障时就知道哪些落地页要优先恢复。

7. 可直接复制的网站上线检查清单模板

把下面的表复制到文档或表格里，按每个 URL、每条用户旅程增加行。状态建议用“未测试、通过、阻塞、不适用”，比一个勾选框更能说明问题。这是一份可复制的文字清单，不是 PDF 下载文件，也不是另行提供的画布模板。

对示例中的 SaaS 来说，项目丢失、付费权限发错账号都阻止上线；搜索抓取暂时延迟则进入后续调查。不要把所有结果混成“网站没上线成功”，具体搜索问题按发现与抓取排查流程处理。

8. 第一周：围绕用户损失安排修复

每天关注的是失败注册、未回复询盘、关键操作流失、保存错误和交付失败，而不是清单打了多少个勾。一笔付费订单丢失，往往比几处视觉小问题更急。拿少量真实支持案例与统计事件对应，确认报表里“成功”真的代表用户完成了任务。

搜索方面，记录重要页面的状态和检查时间。重复页、私有页不收录可能符合预期；重点是用户需要的规范页面是否可访问、可发现。不要追求所有生成出来的 URL 都进入搜索。

保留简短变更记录。如果同一天改导航、重新提交 Sitemap，又重写几十篇文章，后续状态变化很难解释。对等待抓取的页面，按逐 URL 排查方法推进；开始获得用户后，再用订阅生命周期检查确认第一次付款之后的体验同样可靠。