B2B 网站 CMS 发布流程 QA 检查清单

CMS 交接不是编辑器可以改标题就结束。真正的交接，是客户团队可以独立发布页面，同时不破坏 SEO、转化追踪、导航、复用组件、翻译、无障碍和客服流程。

这份清单适合 B2B 市场团队、WordPress 网站负责人、改版项目团队和维护伙伴，用来发布服务页、案例页、资源页、落地页和产品内容。它也适用于 WordPress、Headless CMS、Shopify 内容区块和定制 CMS。

目标不是让编辑变慢，而是建立一个轻量发布流程：普通更新足够快，高风险更新有人复核，每一次上线修改都能追踪和回滚。

先按页面类型分配负责人。一个 B2B 网站通常会有首页模块、服务页、行业页、案例页、资源文章、落地页、价格页、法律页和活动页。每一种页面的 SEO、合规、销售和设计风险都不一样。

CMS 权限应该匹配风险。作者可以起草资源文章，但不应该在没有复核的情况下修改价格页、导航标签、schema 模板、重定向规则或全站复用推荐语模块。市场同事可以安排落地页发布时间，但追踪和索引设置可能需要开发或 SEO 负责人确认。

把谁能创建、编辑、审批、定时发布、上线、下线、恢复和删除每种页面写清楚。如果 CMS 支持角色，就用角色控制；如果不支持，就把审批规则写进交接文档。

• 把页面类型对应到负责人、复核人、发布审批人、回滚负责人和支持联系人。
• 区分低风险文案修改，以及模板、URL、表单、导航、schema、追踪相关的高风险修改。
• 删除、下线、重定向和全站组件权限，只开放给完成培训的用户。
• 把权限规则放进维护文档，避免新成员拿到不清楚的权限。

发布流程不应该只有一个草稿按钮。编辑需要知道保存、预览、提交复核、定时发布、正式发布、下线、恢复和回滚时分别会发生什么。交接前，每一个状态都要测试。

预览尤其重要。预览链接应该能看到正确模板、当前复用模块、草稿图片、内部链接、表单状态和本地化版本，同时不能把未公开内容暴露给搜索引擎。如果网站使用静态生成或 headless 前端，预览和缓存刷新也要单独 QA。

定时发布也要有清楚规则。确认时区、发布时间、状态变化、缓存清理、sitemap 更新和通知收件人。一次定时发布时区错误，造成的问题不比部署失败小。

• 测试保存、预览、提交复核、审批、定时发布、上线、下线、恢复和回滚流程。
• 确认预览链接既足够私密，又足够接近最终页面，能用于上线前检查。
• 检查定时发布的时区、缓存行为、sitemap 更新和通知收件人。
• 写清楚页面卡在复核或定时状态时，编辑应该找谁处理。

CMS 发布 QA 应该在高价值页面修改时包含基础技术 SEO 检查。新增一个段落可能风险很低，但修改 URL、标题、首屏、资源中心页面、案例页或落地页，会影响搜索能见度和转化表现。

在流程里加入一个简短 SEO 字段检查。确认 title tag、meta description、H1、URL slug、canonical URL、索引状态、Open Graph 图片、图片 alt、schema、内部链接和 sitemap 收录。如果 CMS 有默认值，也要让编辑知道什么时候可以用默认值，什么时候必须手动填写。

对 WordPress 和 headless CMS 来说，还要测试字段为空时会发生什么。空 SEO 字段应该有合理 fallback，而不是重复标题、空描述、缺失 canonical 或坏掉的社交分享预览。

• 检查 title tag、meta description、H1、URL slug、canonical、索引状态、Open Graph 图片和 schema。
• 确认首图、文章封面、案例图和图表的 alt text 与文件命名规则。
• 检查导航、相关文章、服务页和页脚模块中的内部链接。
• 测试空字段 fallback，避免编辑发布空白或重复的 SEO 元数据。

大多数 CMS 事故不是一个错别字造成的，而是 URL 被改、页面被删、复用组件被误改、表单被隐藏、图片失效，或一个全站内容块影响了比编辑预期更多的页面。

上线前先制定 URL 规则。编辑需要知道什么时候可以改 slug、谁审批、如何创建重定向，以及如何检查旧链接。如果 CMS 允许自由修改 slug，就在清单里加入旧 URL、新 URL、canonical、sitemap 和重定向目标的对照步骤。

复用模块也需要同样的纪律。Logo 墙、CTA、客户推荐语、价格表、FAQ 或资源卡片可能出现在几十个页面。修改前，编辑应该看到它被哪些页面使用，并至少检查一个受影响页面的桌面和移动端效果。

• slug 修改、页面合并、页面删除和活动页替换，都需要重定向复核。
• 发布前对照旧 URL、新 URL、canonical URL、sitemap 条目和重定向目标。
• 编辑推荐语、CTA、价格表、FAQ 和资源卡片前，先列出它们出现在哪些页面。
• 修改共享组件或重媒体模块后，检查移动端和桌面端布局。

页面看起来正常，不代表收入流程正常。B2B 网站通常会连接表单、预约、下载、CRM 分配、营销自动化、Cookie 同意、分析事件、站内搜索和线索评分规则。这些系统应该进入发布 QA。

为每个转化页面定义一条测试线索路径。提交表单、检查确认状态、验证 CRM 字段、确认邮件通知、查看分析事件，并确认同意管理规则仍然正确触发。模板修改后要测，移动表单、CTA、下载或嵌入组件后的重大内容修改也要测。

QA 记录里应该包含测试邮箱、时间戳、页面 URL、预期 CRM 负责人、预期事件名称和通过或失败结果。这样当销售团队反馈表单失效时，维护团队能更快定位。

• 测试表单提交、成功状态、CRM 分配、邮件通知和垃圾线索处理。
• 确认表单提交、CTA 点击、下载、预约打开和合格线索转化等分析事件。
• 嵌入脚本或表单移动后，检查 Cookie 同意和营销自动化触发规则。
• 把测试线索 ID 和时间戳记录在发布 QA 表里。

编辑需要足够自由来更新网站，但 CMS 也应该保护布局质量。QA 要发现过大的图片、缺失 alt、弱对比度、标题层级跳跃、拥挤卡片、失效嵌入、移动端表格问题，以及超出容器的内容。

按内容类型制定媒体规则。首图、博客封面、案例截图、团队照片、图表和产品图，都应该有推荐尺寸、比例、压缩目标、alt text 规则和替换步骤。

无障碍检查不需要复杂。测试交互模块键盘焦点、链接文字清晰度、图片 alt、标题顺序、表单标签、对比度和移动端间距。如果编辑可以添加富文本，就要有标题、列表、按钮、表格和嵌入内容的规则。

• 发布前检查图片尺寸、压缩、alt text、裁切和响应式表现。
• 复核标题顺序、链接文字、表单标签、对比度、键盘焦点和移动端间距。
• 在移动端测试表格、嵌入、折叠面板、资源卡片和长标题。
• 给编辑页面类型媒体规范，不要让他们凭经验猜尺寸。

如果网站支持多语言或地区页面，发布 QA 需要包含本地化规则。翻译正文不够，还要检查元数据、URL、hreflang、本地化 slug、图片、法律文案、表单、CRM 分配、货币或地区表达，以及内部链接。

尽量使用 translation key 或内容关系字段。这样更容易找到对应语言版本，也能避免某个语言在改版或维护更新后悄悄漂移。

当只有一个语言版本更新时，要决定其他语言版本是继续上线、显示 fallback，还是进入翻译队列。这个决定应该在 CMS 里可见，避免市场、SEO 和支持团队做出冲突更新。

• 检查翻译后的 title tag、meta description、slug、hreflang、canonical、Open Graph 图片和 alt text。
• 验证本地化表单、CRM 分配、法律说明、地区表达和内部链接。
• 使用 translation key 或关系字段连接对应语言版本。
• 写清楚一个语言先更新、另一个语言还没准备好时，页面应该如何处理。