网站改版上线 DNS 与 CDN 切换检查清单

网站改版上线就算通过了视觉 QA，也可能在切换阶段出问题。DNS 指到了错误主机、SSL 没覆盖根域名、CDN 缓存了测试站 robots 文件、重定向规则没有到边缘层生效，或者分析追踪在客户最需要看数据的时候重新开了一段故事。

这份清单适合网站改版、Shopify 建站、WordPress 重建、Headless Commerce 上线、B2B 网站和多语言网站，尤其适合正式域名或 CDN 配置会变化的项目。建议上线周前跑一次，切换窗口前再跑一次，上线第一天再复查一次。

先处理权限和负责人。技术方案再清楚，如果团队不能修改 DNS、批准 SSL、调整 CDN、回滚部署，或者联系不到域名注册商管理员，上线窗口就会被卡住。很多上线延期都从这里开始。

建立一张上线负责人表。包含域名注册商、DNS 服务商、主机平台、CDN、SSL 签发、邮件服务、分析负责人、Consent 工具、Tag Manager 和监控工具。每一项都写清谁能改、谁批准、凭据在哪里，以及负责人不在线时怎么办。

• 域名：根域名、www、语言子域名、旧活动子域名、预览域名和停放域名。
• DNS 记录：A、AAAA、CNAME、ALIAS、ANAME、MX、TXT、SPF、DKIM、DMARC、验证记录和第三方服务记录。
• 基础设施：生产应用、备用部署、CDN zone、图片 CDN、重定向引擎、Web Application Firewall 和缓存清理工具。
• 负责人：注册商管理员、DNS 编辑者、开发、SEO 负责人、分析负责人、客户审批人和回滚决策人。

不要等上线小时才发现某条记录 TTL 很长，或者证书还在等待签发。DNS 服务商允许时，至少提前一天把相关记录的 TTL 降低。然后确认哪些记录真的需要改，哪些记录必须保持不动。

流量切换前，就要准备好 SSL 和 CDN 层。正式域名应该已经绑定到生产环境，证书应该已签发或可快速签发，HTTPS 跳转要清楚，CDN 要知道如何处理缓存、压缩、header、重定向、图片和拦截路径。

• 把相关 Web 记录调整到较短 TTL，并记录调整时间和什么时候可以升回去。
• 检查证书是否覆盖根域名、www、语言子域名、备用域名和仍有流量的旧域名。
• 上线前确认 HTTP 到 HTTPS、根域名到 www 或 www 到根域名、尾斜杠策略和语言路由。
• 复查 CDN 缓存规则、绕过规则、安全 header、图片优化、WAF 设置，以及预览或测试路径排除规则。

切换窗口不是做最后功能开发的时候。上线窗口前冻结高风险变更，并提前定义什么算上线阻塞。目标不是避免所有小问题，而是知道哪些问题需要暂停、热修或回滚。

用普通语言写回滚规则。例如：结账被阻塞、线索表单失败、SSL 无效、首页不是 200、关键重定向失败、robots 阻挡新站，或者 CMS 无法发布关键内容时回滚。如果技术上可以回滚，但操作步骤说不清，说明计划还没完成。

• 切换窗口冻结代码、主题设置、插件更新、DNS 变更、重定向导入、CMS 迁移、应用安装和 Tag Manager 调整。
• 保存上一版 DNS 记录、上一版 CDN 规则、上一版部署 URL、上一版重定向、上一版 robots 和 sitemap 输出。
• 定义回滚负责人、决策时间、沟通频道和具体回滚步骤。
• 保留上线日志：时间、修改项、负责人、预期效果、验证结果和下一次检查时间。

DNS 修改前，先通过生产预览域名或临时域名验证新站。这里就是网站改版上线和技术 SEO 交汇的地方。重定向、canonical、hreflang、robots、sitemap、结构化数据和状态码，都应该在真实流量和爬虫进入前就正确。

不要只检查首页。样本要包含高流量 URL、收入页面、重定向表里的旧 URL、本地化页面、集合或分类页、博客、线索页面，以及至少一个有意删除的 URL。样本应该代表这次迁移的真实风险。

• 重定向：旧 URL 落到预期的新 URL，状态码正确，并且没有不必要的跳转链。
• 可索引性：生产页面可索引，测试页面被阻挡，并且测试站 noindex 不会被缓存进线上路径。
• Canonical 和 hreflang：每个页面指向预期 canonical，并输出正确语言或市场 alternate。
• Sitemap 和 robots：sitemap URL 使用最终域名，robots 引用正确 sitemap，被屏蔽路径都是有意设置。

切换时，先做最小的 DNS 修改。只更新负责 Web 流量的记录，然后从多个网络验证解析。除非上线计划明确包含，否则不要顺手修改邮件、验证或第三方服务记录。

DNS 开始解析到新架构后，先验证正式域名，再宣布上线。检查根域名和 www、HTTP 和 HTTPS、重要语言路径、关键旧 URL 和主要转化路径。如果使用 CDN，只清理必要缓存，并确认边缘层返回的是预期生产响应。

• 修改计划内的 Web 记录，并记录准确时间。
• 从多个公共解析器和至少一个真实浏览器会话检查 DNS 解析。
• 在最终域名上验证 SSL、重定向、状态码、缓存 header、canonical、robots、sitemap 和 Open Graph 输出。
• 第一次验证通过前，让支持、SEO、开发和客户负责人都留在上线频道里。

页面能打开，不代表页面背后的关键系统都正常。切换后，要测试依赖正式域名、cookie、CORS、webhook、API origin、支付回调、搜索索引、表单目的地和 Tag Manager 触发器的流程。

对电商和 B2B 网站，先测试业务路径，再处理小视觉问题。加购、结账、线索表单、预约、询价、站内搜索、下载、Consent Mode、分析事件和 CRM 路由都应该从最终域名验证。

• 电商：商品页、变体选择、购物车、结账、支付方式、订单确认和邮件通知。
• B2B：线索表单、文件上传、预约嵌入、CRM 路由、感谢页、反垃圾保护和通知邮件。
• Headless 或应用驱动网站：API origin、CORS、预览 cookie、webhook、搜索索引、图片交付和重新验证行为。
• 追踪：页面浏览、表单提交、结账步骤、购买、Consent 状态、UTM 保留，以及需要时的服务端事件。

首页能打开，不代表切换结束。DNS 传播、爬虫行为、CDN 缓存、重定向、第三方回调和分析数据，可能在上线后的几个小时或几天内暴露问题。监控应该是上线流程的一部分，而不是可选项。

为上线后 72 小时建立一份短监控计划。检查 uptime、SSL、404、重定向错误、服务器错误、可用时的 Core Web Vitals 现场数据、分析事件、sitemap 抓取、Search Console 覆盖、商品或线索转化路径，以及客户反馈。

• 第一小时：首页、关键模板、SSL、旧 URL 样本、表单或结账、分析追踪和缓存 header。
• 第一天：404 报告、漏掉的重定向、sitemap 抓取、robots 抓取、爬取异常、CDN 错误和转化追踪。
• 前 72 小时：Search Console 数据、分析异常、支持工单、客户反馈、性能指标和长尾 URL 问题。
• 稳定后：升回 TTL、清理临时权限、归档上线日志，并把漏掉的检查补进维护计划。