让 AI 工具自动修改 WordPress 之前，先检查这 7 件事

1. 先判断谁在管理正文

Gutenberg 和 Classic Editor 通常把主要正文放在 post_content。很多页面构建器则会额外使用自己的元数据和布局结构。即使 HTML 合法，直接替换 builder 页面里的 post_content，也可能造成空白、重复或布局损坏。

所以，整页修改之前必须先检测 builder。如果自动化不了解对应的数据模型，最安全的处理是停止直接写入，只把草稿交给用户手动处理。

• Gutenberg/Classic 和主流页面构建器应视为不同写入目标。
• API 或数据库写入成功，不等于页面结构兼容。
• 修改后要检查公开页面，而不是只看接口返回成功。

2. 同时保留 WordPress Revision 和独立快照

WordPress 自带修订版本系统，并提供 wp_save_post_revision() 等核心能力。自动部署时，除了原生 revision，再保存一份应用级快照也很有价值，因为它可以包含 WordPress revision 不一定覆盖的元数据，例如 Schema 内容、部署任务 ID 等。

回滚按钮应该恢复某次具体部署对应的旧状态，而不是简单恢复“上一个 revision”，否则中间如果有人手动编辑过页面，可能回滚错版本。

3. 识别 Meta 和结构化数据到底归谁管理

如果 Yoast、Rank Math、其他 SEO 插件或主题已经管理 canonical、标题、描述和 JSON-LD，另一个工具不应该无脑再输出一套。重复 Schema 不一定立即造成处罚，但实体、canonical、Product/Article 信息互相矛盾会制造完全没必要的歧义。

安全的连接器应该允许 applied、manual、rejected 等不同状态。已有插件拥有控制权时，“manual”并不是失败。

4. 把 robots.txt 当成基础设施，而不是一段文案

服务器根目录的物理 robots.txt、WordPress 虚拟 robots、CDN 规则、安全插件都可能决定抓取行为。自动化必须知道真正权威的是哪一层，不能不理解部署环境就覆盖物理文件。

同时要区分搜索抓取和其他 AI 使用控制。Google 官方说明，Google-Extended 可以控制部分 Gemini 训练和 grounding 用途，但不会影响网站进入 Google 搜索。一个 User-Agent 规则不能代表所有 AI 产品。

5. 生成内容也必须按不可信输入处理

AI 生成结果不等于可信输入。WordPress 官方安全指导强调验证、清洗输入并按输出上下文转义。部署系统应该验证目标 URL、限制允许写入的路径、在保存结构化数据前校验 JSON，并拒绝未知文件目标。

6. 写入确认以后再清缓存

页面缓存、对象缓存、CDN 和优化插件可能让成功修改看起来像没有生效。正确顺序是先确认写入成功，再清理支持的缓存，然后重新请求公开 URL。如果公开页面仍然是旧版本，就应该报告真实状态，而不是只因为 wp_update_post 没报错就显示完成。

7. 正文修改必须经过用户确认

技术修复和内容重写的风险完全不同。窄范围、确定性的技术修复更容易安全自动化；整段正文替换应该展示草稿、说明要修改什么，并要求用户明确确认。这个审核步骤不是多余阻力，而是产品安全的一部分。