WordPress Staging 部署 QA 检查清单：上线前必做

WordPress staging 站点不应该只是给客户看设计预览。它应该证明主题、插件、数据库变更、媒体文件、SEO 规则、表单、追踪、缓存和回滚方案都能承受真实上线。

这份清单适合 WordPress 改版、自定义主题上线、区块编辑器更新、插件维护发布，以及重视自然流量和表单线索的 B2B 网站部署。建议在内容冻结后、部署窗口前执行一次，生产环境上线后立刻再执行一次。

开始 staging QA 前，先决定哪些内容还能改、哪些内容已经冻结。博客、服务页、案例、导航、表单、SEO 元数据、重定向、可复用区块和媒体资源，都应该有负责人和冻结规则。

然后记录当前生产环境状态。导出数据库、主题文件、插件列表、WordPress 版本、PHP 版本、启用菜单、小工具区域、表单、重定向和 sitemap URL。目的不是增加文档，而是在出问题时有回滚参照。

• 导出数据库备份，并确认可以在哪里恢复。
• 记录启用主题、子主题、WordPress、PHP 和插件版本。
• 列出已冻结、仍可编辑、以及本次上线明确排除的内容。
• 修改前保存重点生产 URL、表单、重定向和 sitemap 文件。
• 指定部署窗口内谁有权批准临时内容修改。

只有当 staging 和生产环境足够接近时，staging bug 才有参考价值。如果 PHP 版本不同、插件授权缺失、缓存规则不同、数据库过旧或媒体库不完整，团队可能会花时间修不存在的问题，也可能漏掉真实上线问题。

在判断设计和功能前，先检查环境一致性。WordPress 部署常常失败在细小差异上：上传路径、图片尺寸、cron 任务、安全响应头、对象缓存、SMTP 设置、搜索索引和插件配置。

• 对照 WordPress、PHP、主题、子主题、MU 插件和普通插件版本。
• 确认媒体文件、生成图片尺寸、自定义字段、菜单、可复用区块和小工具都存在。
• 检查 staging 专用设置，例如 noindex、密码保护、邮件拦截和 analytics 抑制。
• 记录有意保留的环境差异，避免 QA 把它们误判为上线缺陷。
• 如果项目期间生产内容有变化，最终 QA 前刷新 staging 数据。

公开页面看起来正确，并不代表 WordPress 可以上线。上线后编辑人员要能安全更新页面。请用真实流程测试服务页、落地页、博客、案例、导航、可复用 pattern、表单和 SEO 字段。

测试时使用真实长度的内容和图片裁切。很多自定义主题在 demo 内容下很稳定，但遇到标题换行、翻译后 CTA 变长、或客户上传了错误比例图片时就会破版。

• 为每个关键模板创建或复制一个页面，并编辑所有自定义字段或区块 pattern。
• 测试长标题、短标题、缺失可选字段、移动端图片裁切和翻译后标签。
• 确认编辑者可以更新 SEO 标题、meta description、slug、canonical 例外和社交分享图字段。
• 检查管理员、编辑、作者以及客户自定义角色的权限。
• 确保 staging 上被拒绝的修改不会意外覆盖生产环境已批准内容。

对 B2B 和服务型网站来说，表单坏掉往往比视觉 bug 更严重。请从用户视角和内部交接视角测试所有转化路径：联系表单、询价表单、订阅表单、gated 资源、预约嵌入、站内搜索、感谢页、CRM 路由和邮件通知。

使用 staging 安全的测试数据，并确认生产环境会发生什么变化。有些团队会在 staging 屏蔽邮件，这可以接受，但生产 SMTP、CRM webhook、反垃圾规则、同意字段和 analytics 事件仍然需要上线检查。

• 在桌面和移动端提交每个表单，确认校验、成功状态、跳转和错误状态。
• 检查通知收件人、CRM 字段、隐藏来源字段、同意字段和反垃圾保护。
• 用真实查询测试站内搜索、资源筛选、案例筛选和博客分类导航。
• 确认预约、聊天、地图、嵌入和追踪脚本只在应该出现的地方启用。
• 上线前记录每条线索路径的预期负责人。

Staging 应该避免被索引，但生产环境上线后应该立刻准备好让搜索引擎抓取。这意味着 noindex、robots.txt、canonical、重定向、XML sitemap、hreflang、结构化数据、元数据、内链和图片 alt 都需要明确 QA。

最高风险的时刻是环境规则切换。网站可能带着 staging noindex 上线，canonical 还指向 staging URL，重定向缺失，或者 sitemap 暴露草稿页。把 SEO 检查当成发布阻断项，而不是上线后的优化项。

• 确认 staging 被阻止索引，但这条规则不会复制到生产环境。
• 爬取 staging，检查标题、meta description、canonical、标题层级、状态码、noindex 和断链。
• 验证旧 URL、已删除页面、slug 变化和合并内容的重定向表。
• 检查 XML sitemap、结构化数据、图片 alt、Open Graph 数据，以及多语言网站的 hreflang。
• 上线后重新爬取生产环境，证明生产 URL 而不是 staging URL 才是最终来源。

WordPress 部署经常同时涉及文件、数据库变更、媒体变更、缓存层和插件设置。Staging 页面正常，并不代表生产环境一定正常；数据库迁移可能漏掉序列化数据，媒体路径可能错误，缓存规则可能过期，优化插件也可能和主题冲突。

部署窗口前做一次小范围技术检查。目标不是追求完美分数，而是清除可避免的上线意外。重点放在核心模板、表单、搜索、移动端布局、未登录状态和后台编辑速度。

• 确认数据库迁移能处理序列化值、自定义表、options、重定向和表单记录。
• 检查媒体 URL、响应式图片 srcset、懒加载、特色图和下载文件。
• 按正确顺序清理或预热页面缓存、对象缓存、CDN 缓存和插件优化缓存。
• 在移动端和桌面端测试重点页面的布局偏移、缺失资源、console 错误和慢响应。
• 缓存和脚本优化后，确认 analytics、同意模式、cookie 提示和 tag manager 行为正常。

如果回滚路径不可见，就不要从 staging 发布。团队应该知道生产失败时可以恢复哪些文件、数据库备份、插件版本、缓存设置、DNS 或托管配置。没有测试过的回滚方案，只是希望而不是计划。

部署后，在生产环境重复关键检查。打开重点 URL，提交测试表单，验证重定向，确认 noindex 已移除，检查 sitemap 输出，监控错误日志和 analytics 事件。上线后一小时应该是运营检查，而不是单纯庆祝。

• 上线前确认备份文件、数据库恢复点、部署 commit 和托管回滚控制。
• 指定部署、QA、SEO、表单、analytics、DNS、缓存和最终批准负责人。
• 在生产环境做 smoke test：重点页面、后台登录、表单、重定向、sitemap 和搜索。
• 上线后监控服务器错误、PHP warning、404、表单提交、抓取错误和 Core Web Vitals。
• 把 staging 检查清单作为月度维护和未来主题发布的交接记录。