网站上线后检查工具 是做什么的？
监控工具。在DNS切换后立即运行，然后每天运行一次，持续三十天。它只报告；从不阻止、从不修复、也从不发布任何公告。
唯一规则
阻止项优先读取，最后宣布。 上线过程中的任何内容在报告确认无误前不得宣布——不发送邮件、不发布帖子、不联系客户。公告是上线流程中唯一无法撤回的步骤，而这里的两个阻止项正是上线尚未真正发生的两种状态：访问者无法通过的证书，以及告诉搜索引擎遗忘网站的noindex标签。这两种情况在您已登录的浏览器中都看起来正常。
如果有人要求您在阻止项存在时宣布，请直截了当地说明阻止项是什么及其代价，不要粉饰。
只读
该技能是只读的。它会获取线上站点、暂存主机、旧主机以及重定向映射中的URL，并向四个公共DNS解析器查询域名指向何处。它只写入两样东西，且都是操作者自己的记录：报告包以及其中的watch.json文件。它从不编辑站点、提交表单、切换设置、调用提供商API或修改DNS。
以下三条规则在您报告时必须重述：
- 每个发现都要有证据。 一个URL、一个状态码、一个响应头、一条DNS应答、一行CSV数据。
- 跳过不等于通过。 您未提供的每个输入都会在未覆盖中生成一行命名条目。
未覆盖永远不能当作通过。 您需逐字向用户重复该部分。
两种模式
| 模式 | 何时使用 | 回答什么问题 |
|---|---|---|
--mode cutover | DNS切换后以及每次修复后 | 上线是否真的发生了 |
--mode watch | 每天一次，第1-30天 | 今天有什么待办事项，是否有变化 |
先运行cutover，修复发现的问题，再次运行直到无阻塞项，然后宣布。当天启动监控。
1. 收集输入
您遗漏的每个输入都会导致一项检查无法运行。请逐个询问，不要猜测。
- 生产URL。 必填。
baseline.json— 来自pre-launch包，或来自切换前针对暂存环境的launch-audit运行。这是衡量“是否有任何变化”的基准。没有它，四项检查将无比较对象，第五项将回退到--expect-analytics。所有这些都会明确说明。redirects.csv— 来自使用--old-url构建的launch-audit包。每一行都会在其写入时的URL处重新请求。- 旧站点的URL，如果有站点被替换。
- 暂存URL，以便运行确认暂存副本现已封存。
- 分析工具测量ID，用于没有基线时。
- 预期DNS记录，格式为
apex=<ip>,www=<host>。
如果您没有基线或重定向映射，请在运行前说明，而非之后：它们来自前两个阶段，且在切换后无法重新生成。
2. 运行切换检查
运行脚本；永远不要阅读其源代码，也不要重新实现其功能。
node scripts/post-launch.mjs --mode cutover --url <production url> \
--baseline <path to baseline.json> --redirects <path to redirects.csv> \
--old-url <old site url> --staging-url <staging url> \
--expect-analytics <measurement id> --expect-dns apex=<ip>,www=<host> --out <dir>
路径相对于该技能自身的目录——从该目录运行命令。包写入当前工作目录：如果不使用--out，则输出到./website-launch/<host>-post-launch-<date>/，结合上述命令意味着该技能自身目录内。使用--out将包写入工作所在任意目录。
其他标志：--dev-host <host>（可重复）、--browser auto|on|off、--out <dir>、--config <path>、--json、--help。
退出码： 无论切换如何糟糕，始终返回0。2表示使用错误或IO故障。退出码0绝不意味着“上线正常”——它只报告，不阻止。请阅读报告。
3. 按此顺序阅读报告
references/reading-the-report.md包含包布局。references/cutover-day.md解释了当天的运行顺序——在您开始乱序修复问题前请先阅读。
- 阻止项。 以粗体打印，无论它们来自哪一步。在其他问题之前修复它们，且在告知任何人站点已上线之前。
- 高风险发现。 重定向漂移、缺失页面、死表单端点、仍活跃的暂存副本、仍在服务的旧主机——这些都是当前导致流量或咨询损失的问题。它们是今天的工作，而非下周的。
- 基线差异。
references/baseline-diff.md说明了哪些字段在上线时预期会变化，哪些从不应该变化。不要将整个差异报告为损害；只报告未请求的部分。 - 中风险和通知。 阅读它们。说明内容。今天不修复。
- 未覆盖，逐字。 每一行，未经编辑，包括爬虫无法看到的两项内容。
然后重新运行，并持续重新运行，直到阻止项消失。
4. 处理六项人工任务
它们会在每次运行结束时打印，且不可省略：
提交站点地图（Search Console和Bing） · 请求索引顶部页面
确认新的Search Console属性 · 实时验证分析工具
保持旧主机运行并重定向 · 仅在此项确认无误后宣布
切勿代他人勾选项。“端点返回200”不是“某人收到了测试提交”，“HTML中有标签”也不是“实时出现了数据”。
5. 每日运行监控
node scripts/post-launch.mjs --mode watch --url <production url> --day <n>
它会打印逾期项目、今天到期的项目以及未来七天即将到期的项目，然后重新运行自动化部分并记录运行。references/thirty-day-watch.md包含完整的日程安排、每天在Search Console和分析工具中检查的内容，以及“正常”状态的定义，以免将正常的发布后流量下降报告为灾难。
省略--day，它会从第一次运行开始计数。未运行监控的天数，自动化任务的逾期状态会持续到覆盖运行完成；人工任务的逾期状态会持续到人工确认，因为脚本无法证明某人打开了Search Console。
6. 第30天
两项任务，均非自动化：
- 回顾总结。 哪些地方出现了回退，重定向映射遗漏了什么，以及应在
pre-launch关卡中添加什么以避免下次上线重复出现。记录下来。 - 旧主机决策。 只有当Search Console显示不再爬取旧URL且重定向已生效至少30天时，才能停用旧主机。两个条件都满足之前，请继续为其付费。过早关闭会丢弃旧站点获得的所有链接。
7. 呈现结果
以结论而非计数开头。
- 判决。 “切换存在一个阻止项”或“切换无错误。”一句话。
- 阻止项是什么，并指出修复方法。
- 什么问题正在造成损失，按原因分组：高风险发现，用通俗语言说明。
- 与基线相比哪些变化并非请求的。
- 未覆盖，逐字。
- 人工任务，说明哪些已完成，哪些未完成。
- 是否可以宣布上线。 明确说明是或否。
两项永远不运行的检查
- 文案与源文档对比。 无法将线上页面文字与已审批文案进行比较。需要人工阅读两者。
- 页面与商定范围对比。 无法知道哪些页面本应存在。从未构建的页面在此处不可见。
参考文档
| 文件 | 涵盖内容 |
|---|---|
references/cutover-day.md | 有序的当天脚本，以及每一步如此安排的原因 |
references/thirty-day-watch.md | 日程安排、Search Console和分析工具中需检查的内容、正常状态的定义、旧主机规则 |
references/baseline-diff.md | 每个差异字段，哪些变化在上线时预期出现，哪些不预期 |
references/reading-the-report.md | 包结构、严重性级别、ID、如何分类 |
与其他工具的关系
pre-launch在部署前把关仓库并阻止问题。launch-audit爬取暂存或生产URL并报告。post-launch即本工具：切换验证及上线后三十天监控。按此顺序运行——本工具所需的基线和重定向映射只能由前两个工具生成，且必须在旧站点仍在线时进行。