WordPress 主题交付检查清单：网站改版后怎么接手

WordPress 改版不是生产环境看起来正确就结束。真正结束，是营销团队可以更新服务页、发布文章、替换图片、调整导航、检查 SEO 字段，同时不会破坏这次改版本来要保护的布局和组件。

这份交付清单适合自定义 WordPress 主题、区块主题、混合主题，以及使用 Advanced Custom Fields、自定义内容类型、可复用区块或多语言内容的服务型网站。建议在上线 QA 之后、网站 owner 正式签收前使用。

交付的第一步，是把可编辑内容和结构性主题决策分开。编辑要知道哪些字段是安全的，哪些字段会影响全局布局，哪些改动需要开发支持。如果边界不清楚，团队很容易复制页面、粘贴行内样式，或安装插件去解决主题本来已经处理好的问题。

做一份简短的内容 ownership map，列出每个主要模板由谁负责，以及它在哪个编辑界面维护。至少包括页面、文章、服务页、案例、落地页、菜单、页脚内容、表单、SEO metadata、脚本、重定向和主题设置。

• 把每个模板标记为编辑负责、开发负责，或双方共同负责。
• 记录全局内容在哪里编辑，例如顶部导航、页脚链接、公告条和可复用 CTA。
• 列出不应随意修改的字段，例如 schema 设置、canonical URL、追踪脚本和表单目标。

好的 WordPress 主题给编辑的是可复用模式，而不是一个空白画布。请记录团队在常见营销任务中应该使用哪些区块、section 和页面模式。这样新页面才会延续改版后的设计系统，而不是几周后变成一堆一次性布局。

文档不需要很长。真正有用的交付包会说明每个区块适合什么场景、应该出现在哪里、哪些字段必填、推荐图片比例、字符长度限制，以及可选字段为空时页面会怎样显示。

• 为服务页、落地页、博客、案例、FAQ 和活动页记录页面模式。
• 写清楚实际限制，例如 hero 标题长度、卡片标题长度、图片比例和按钮数量。
• 截图只在能解释字段行为时使用；真正的参考仍然应该是实时编辑体验。
• 如果旧页面迁移到新模板，请配合 CMS 内容迁移 QA 清单一起检查。

WordPress 交付经常漏掉 SEO 控制项，因为它们可能在插件、自定义字段组或部署设置里。网站改版后这很危险。团队需要知道 title tag、meta description、社交分享图、canonical、noindex、XML sitemap、重定向和 schema 字段分别在哪里维护。

测试要用真实页面。编辑一个标题标签，修改摘要，替换社交分享图，更新一条重定向，并预览前端。然后确认渲染后的 HTML、sitemap 和 Search Console 工作流仍然符合上线计划。

• 确认每种内容类型的 metadata 是由哪个 SEO 插件或自定义字段负责。
• 在 staging 页面、感谢页、筛选归档页和重复落地页上测试 noindex 与 canonical 控制。
• 记录重定向流程，包括谁可以新增重定向，以及发布前由谁复查。
• 如果填错会造成结构化数据不准确，请限制 schema 字段的编辑权限。

不要只用管理员账号交付网站。请为编辑、作者、SEO 复查、翻译和开发验证真实角色。营销编辑应该能完成日常工作，但不应该拥有安装插件、编辑主题、管理用户或修改生产配置的权限。

同时要确认发布流程和恢复路径。团队在活动期间出问题之前，就应该知道草稿、修订、审批、备份、恢复点、插件更新和部署回滚如何运作。

• 用真实编辑角色测试前 10 个高频编辑任务，而不是管理员账号。
• 确认重要内容类型启用了修订历史，并且没有被自定义字段流程阻断。
• 记录备份频率、恢复负责人、预计恢复时间和备份存储位置。
• 禁用或限制高风险能力，例如安装插件、编辑主题文件和注入任意脚本。

WordPress 编辑交付必须覆盖上线后编辑会触碰的系统。表单、媒体、翻译、嵌入内容和可复用内容，常常因为夹在主题代码、插件和外部服务之间而静默失败。

让团队完成一次真实更新：发布一篇文章，替换 hero 图片，更新服务页，编辑表单确认信息，新增翻译页面，并刷新一个可复用 CTA。这个练习通常能暴露字段不清楚、权限缺失、图片问题和翻译漂移。

• 检查表单目标、通知、防垃圾设置、隐藏归因字段和成功消息。
• 记录图片尺寸、命名规则、alt 文本要求、压缩方式，以及什么时候使用 SVG、PNG、JPG 或 WebP。
• 多语言网站要确认译者可以编辑本地化 slug、metadata、菜单、按钮和可复用区块。
• 在真实页面布局中测试嵌入和第三方脚本，尤其是 Cookie 横幅、预约日历、地图和视频播放器。

交付包要小到团队真的会使用。目标是一份实用运营手册，而不是完整技术规格。最好的版本会合并页面清单、编辑流程说明、插件 ownership、维护责任和升级路径。

把它放在团队日常使用的工具里。Notion 页面、共享文档或项目 Wiki，通常比很快过期的 PDF 更有用。里面应包含后台 URL、staging URL、分析仪表盘、托管后台、表单收件箱、备份位置和 issue tracker。

• 包括模板清单、区块清单、插件清单和定期维护日历。
• 列出托管、域名、DNS、邮件、表单、分析、Search Console 和付费插件的账号负责人。
• 记录请求新 section、模板改动、插件新增和紧急修复的最安全流程。
• 加入一套已验证的 smoke test，方便团队在更新或内容发布后快速复查。

操作视频有用，但它不能证明交付真的成功。请安排一次现场 session，让营销团队执行真实任务，开发团队在旁边观察。目标是在支持工单堆积前，发现字段名不清楚、权限缺失、预览状态含糊和文档缺口。

任务要贴合网站业务。B2B 服务型网站可以更新服务页、发布洞察文章、添加案例引用、调整表单接收人并复查 SEO metadata。活动型网站可以复制一个落地页模式并修改 offer，而不编辑结构代码。

• 请编辑先说出他们预期字段在哪里，再决定是否帮助他们。
• 如果问题模式很明显，马上修正字段标签和帮助说明。
• 把未解决问题记录为上线 follow-up，附上负责人和截止日期。
• 重大模板变更或新增插件工作流后，再重复一次演练。