一次发 5 篇、20 篇或改主题前，最该先确认的是备份能不能恢复。数据库、uploads、插件版本、特色图像和缓存都要进 SOP。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
一次发 5 篇、20 篇或改主题前，最该先确认的是备份能不能恢复。数据库、uploads、插件版本、特色图像和缓存都要进 SOP，否则发布失败时只会留下半截文章和破图。
更新日期与来源依据
更新日期：2026-06-27。WordPress 官方备份文档强调，完整恢复通常需要数据库和文件两部分；WP-CLI 的 `db export` 可导出数据库，`media import` 可导入媒体并设置特色图像。公开来源限制为三条：WordPress backups handbook、WP-CLI db export、WP-CLI media import。
这篇 SOP 面向内容站和自动化发布，不替代主机级备份策略。真正上线前，还要按自己的主机、对象存储、缓存插件和部署方式做一次恢复演练。
适用场景
- 你每天或每周批量公开发布文章，文章包含特色图像、分类、标签、内链和来源链接。
- 你准备升级主题、插件、WordPress 版本或缓存规则，担心发布后页面破版。
- 你使用 WP-CLI、SSH、自动化脚本或远程发布工具创建文章。
- 你需要向团队证明“发布失败可以回滚”，而不是只依赖主机商的整机备份。
不适用场景
- 站点没有写权限，或者只是在本地草稿里编辑文章；此时先做内容校对即可。
- 站点涉及电商订单、会员付款、论坛发帖等高频写入数据；回滚前必须考虑用户数据差异，不能简单恢复旧数据库。
- 主机商已提供事务级备份和可验证恢复，但你无法访问数据库或文件；这种情况应走主机商恢复流程。
准备材料
- 数据库备份命令或主机后台导出入口，确认能导出 `.sql` 或压缩文件。
- `wp-content/uploads` 的文件备份方式，至少覆盖当天即将上传的封面和正文图片。
- 插件与主题版本表：插件名、版本、最近更新时间、是否影响发布、是否影响缓存。
- 待发布文章清单：标题、slug、分类、标签、特色图像路径、来源数量、状态。
- 回滚记录表：备份路径、发布前文章数、发布后文章 ID、媒体 ID、缓存清理结果、撤回命令。
操作步骤
- 第一步，冻结发布窗口。告诉团队从备份开始到验收结束，不要手动改文章、插件、菜单或主题设置，避免备份与现场状态错位。
- 第二步，导出数据库。使用主机后台或 `wp db export`，文件名包含站点、日期、操作类型，例如 `wolftalkshow-2026-06-27-before-bulk-publish.sql`。
- 第三步，备份 uploads 增量。至少复制当天将上传的封面目录和最近修改的媒体文件。若站点很大，先备份 `wp-content/uploads/YYYY/MM/` 当月目录。
- 第四步，记录插件和主题版本。运行插件列表或后台截图，标注缓存、SEO、图片优化、编辑器、表单等会影响发布展示的插件。
- 第五步，做发布前 dry-run。检查文章 HTML、来源上限、特色图像路径、slug、分类标签和合规 gate，确认没有模板残留。
- 第六步，执行批量发布。每篇文章保留 post ID、media ID、URL、分类标签和发布时间。失败时不要继续补写远端数据，先判断是否局部修复或回滚。
- 第七步，清缓存并验收。检查首页、分类页、sitemap、5 个文章 URL、特色图像、移动端横向溢出和破图。
验收清单
- 数据库备份文件存在，大小合理，文件名能看出站点和日期。
- uploads 备份覆盖本次新增或替换的图片，图片可在本地打开。
- 每篇文章都有 post ID、URL、publish 状态、特色图像和分类标签。
- 首页、分类页、sitemap 可访问，缓存已清理，页面无明显破图。
- 回滚表写明何时回滚、回滚到哪个备份、会丢失哪些发布后的编辑。
可复制 SOP 模板
批量发布前备份与回滚 SOP
站点：
日期：
操作者：
发布批次：
发布前：
- 数据库备份路径：
- uploads 备份路径：
- 插件/主题版本记录：
- 待发布文章数量：
- dry-run 报告：
发布中：
- post ID 列表：
- media ID 列表：
- 失败文章：
- 临时修复：
发布后：
- 首页状态：
- sitemap 状态：
- 分类页状态：
- 缓存清理：
- 移动端抽检：
回滚触发：
- 数据库恢复命令：
- 文件恢复命令：
- 回滚后验证 URL：
- 不回滚的理由：
常见坑与排错路径
- 坑一：只备份文件，不备份数据库。文章、分类、标签、媒体关联大多在数据库里，只有文件无法完整恢复。
- 坑二：只备份数据库，不备份 uploads。恢复后文章存在，但特色图像和正文图片可能变成 404。
- 坑三：发布失败后继续手动补救，没有记录 post ID 和媒体 ID。排错时先列出本批次新增对象，再决定删除、改状态或回滚。
- 坑四：缓存没有清，前台仍显示旧页面。先清 WordPress 对象缓存，再清 LiteSpeed 或 CDN，再用无痕窗口和 `curl` 复查。
排错顺序：先确认 WordPress 后台状态，再确认媒体附件，再看前台 URL，再看缓存层。不要因为浏览器看到旧页面就立刻恢复数据库；也不要因为后台有文章就忽略前台破图。
判断规则与后续维护
- 如果只是新增 1 篇低风险文章，可以依赖自动备份加文章级回滚；如果批量发布或改主题，必须做手动可见备份。
- 如果站点有用户订单、评论或会员数据，恢复数据库前要评估备份时间之后新增的数据，必要时做表级或文章级修复。
- 如果连续两次发布后出现破图，应把图片上传和特色图像设置加入硬 gate，而不是发布后再人工修。
- 每月做一次恢复演练：把数据库导出、uploads 备份、文章 ID 记录和缓存清理跑完整，不一定真的恢复线上。