CMS 内容迁移 QA 检查清单：网站改版上线前必做

网站改版经常在内容迁移阶段悄悄出问题。新设计可能看起来正确，CMS 也能编辑，launch checklist 也像是完成了，但只要标题被缩短、旧 PDF 消失、产品文案进错字段，或本地化页面失去对应关系，流量和转化仍然会受影响。

这份清单适合正在做网站改版、WordPress 主题重做、Shopify 内容整理、Headless CMS 迁移、多语言上线或技术 SEO 迁移的团队。建议在新 CMS 模型接近定稿后、完整内容迁移被视为可上线前使用。

先建立一份源内容清单，并把它当作迁移期间的临时事实来源。导出所有线上 URL、标题、模板、状态、canonical URL、语言、负责人、流量级别、转化角色和最后更新时间。如果网站有 staging 页面、活动页、PDF、资料下载或主导航之外的落地页，也要纳入。

清单里要区分哪些内容会迁移、合并、重写、重定向、归档或按新模板重建。如果没有这个决策字段，团队会在上线周反复重新发现同一批页面。

• 抓取线上站点，并与 CMS 导出、analytics 落地页、XML sitemap 和付费落地页列表对比。
• 标记收入关键、SEO 关键、法律、支持、活动和历史遗留页面。
• 为每个页面类型指定一个内容负责人和一个技术负责人，而不只是按部门分配。
• 批量迁移开始前冻结一个清单版本，之后每个已批准变化都要记录。

CMS 迁移不是复制粘贴。旧页面可能只有一个 body 字段，而新模板拆成 hero 文案、intro 文案、对比行、FAQ、相关服务、schema 输入和可复用 CTA 模块。QA 需要一份字段映射表，说明每个旧值应该进入哪里。

每种页面类型都要记录必填字段、选填字段、fallback 行为、允许格式、字数限制、图片比例、负责人备注，以及不应该迁移的字段。这样可以避免内容为了满足导入器而被塞进最接近但并不合适的字段。

• 为首页、服务页、案例页、博客、产品、collection、落地页和法律页面创建字段映射。
• 确认字段类型是纯文本、富文本、markdown、引用、数字、日期、布尔值、文件还是选项。
• 测试长标题、空选填字段、翻译文案、特殊字符和可复用模块。
• 保留清晰的例外列表，标明哪些页面导入后需要人工编辑。

元数据经常丢失，因为它在设计审查里不可见。请把 title tag、meta description、canonical URL、robots 设置、Open Graph 字段、结构化数据输入、图片 alt、面包屑和发布日期都当作迁移内容处理。它们需要和正文一样有负责人和 QA。

除非这是明确决策，否则不要让新系统自动生成所有内容。自动元数据可以用于低风险页面，但关键服务页、产品页、collection 页面、案例页和文章应该在上线前人工检查。

• 上线前对每个 SEO 关键页面比较新旧 title tag。
• 检查 meta description 是否被截断、重复、缺少价值点或语言错误。
• 确认 canonical URL 和 noindex 规则没有继承 staging 或草稿内容。
• 导入后验证图片 alt、Open Graph 图片、面包屑和 schema 字段。

URL QA 应该和内容 QA 绑定在一起。当内容被合并、改名、本地化，或移动到新的 CMS collection 时，即使页面本身导入正确，内链和重定向也可能出错。把 URL 决策放在内容清单旁边审查，才能看清每个重定向的原因。

重定向表应该是工作中的 QA 文档，而不是项目最后才出现的文件。每个删除或变化的 URL 都应该有目标地址、状态、负责人和测试结果。内链尽量直接指向新目标页，而不是依赖重定向。

• 抽测高流量页面和长尾页面，从旧 URL 到新 URL 的重定向是否正确。
• 替换仍然指向 staging、临时 slug、旧域名或已重定向 URL 的内链。
• 检查导航、页脚链接、面包屑、相关文章、相关服务、XML sitemap 和 hreflang alternate。
• 确认 canonical tag 使用最终生产 URL 格式，包括尾部斜杠和语言规则。

图片和文件很容易被忽略，因为页面可能看起来差不多正确。QA 应该确认图片裁切、响应式资源、文件名、alt、caption、压缩、授权和文件目标都保留下来。损坏的 PDF、过大的 hero 图片和缺失的案例素材，都会影响信任和性能。

嵌入内容需要单独检查。表单、视频、日历、地图、计算器、对比表、产品 feed 和第三方组件经常依赖脚本或 ID，跨 CMS 平台迁移时不一定能干净保留。

• 至少在移动端和桌面端检查 20 个高价值页面的图片裁切和缺失资源。
• 从线上页面打开迁移后的 PDF、下载资料、门槛内容和媒体链接，而不只是从 CMS 查看。
• 部署后确认 lazy loading、图片尺寸、压缩和响应式版本。
• 在 Cookie 横幅、广告拦截、严格隐私设置和慢网速下测试嵌入内容。

可复用模块让 CMS 更好维护，但也会放大迁移错误。一个错误的客户证言、价格说明、服务卡片、产品标签或合规声明，可能出现在几十个页面上。QA 应该同时检查模块源内容，以及它出现的关键页面。

还要注意页面级例外。历史页面经常包含特殊免责声明、手工表格、活动文案、自定义 CTA 或地区说明，这些内容在批量导出里不一定明显。最终导入通过前，它们需要人工审查。

• 列出可复用模块，并确认负责人、用途、源内容和出现页面。
• 在服务页、案例页、博客、产品页和落地页中检查模块上下文。
• 记录需要人工迁移、重写或开发支持的例外情况。
• 除非这个例外有明确业务价值且未来会重复出现，否则避免创建一次性 CMS 字段。

多语言迁移会增加一层风险。英文页面可能已经准备好，但中文、德文或地区版本仍然有旧截图、缺失元数据、错误内链或不同转化路径。QA 应该比较页面配对，而不只是检查语言文件夹。

每个翻译页面都要确认 locale、slug、标题、meta description、hreflang 引用、canonical URL、导航标签、表单语言、货币、法律文案和负责人。如果某个页面刻意不翻译，也要记录 fallback 行为和重定向决策。

• 把每个迁移页面匹配到它已有的翻译或区域版本。
• 检查翻译后的元数据、图片 alt、按钮文案、表单、感谢状态和下载资料。
• 内容发布后再验证 hreflang 和 canonical 规则，而不只是看 CMS 预览。
• 保留只先上线一个语言版本的页面列表，避免利益相关方误以为是迁移 bug。

不要等完整迁移后才发现 CMS 模型缺字段。先迁移一个样本集：一个首页或 hub 页面、两个服务页、两个案例页、五篇博客、五个产品或 collection 页面、一个法律页面、一个低流量归档页，以及至少一个翻译页面。

在 CMS、staging、搜索预览和 crawl 结果中审查这个样本。样本应该暴露字段映射问题、页面速度问题、缺失媒体、损坏内链、编辑者困惑，以及全量迁移前需要预算的人工工作。

• 样本至少覆盖 20 到 30 个页面，或网站的 10%，选择覆盖面更好的那个。
• 包含简单页面、高价值页面、长页面、历史页面和带特殊模块的页面。
• 让内容、SEO、设计、开发和运营审查同一组样本并签字确认。
• 更新字段映射和迁移流程后，再导入剩余内容。