这几年 AI 爆发，我一边做 SEO 顾问，一边看着越来越多团队把 SEO 做成了一个很简单的动作：生产内容。
今天研究 100 个关键词，明天让 AI 写 100 篇文章，后天再做 100 个页面。只要发布数量还在涨，团队就觉得 SEO 还在往前走。
这个逻辑对不对？
也不能说完全不对。一个刚上线的新网站，连能被 Google 看见的页面都没几个，当然需要先把基础内容补起来。问题是，很多网站已经跑了两三年，已经有几百甚至几千个页面，团队依然只会用同一套办法解决所有问题。
排名掉了，再写一篇。
流量跌了，再写十篇。
老页面过时了，假装没看见，继续发新的。
说实话，这已经不是执行效率的问题了，而是大家对 SEO 的理解根本不在一个层次上。
正如我上一篇文章里提到的，站内 SEO 做的从来不只是内容生产，更重要的是内容资产的管理。既然是资产，就不可能只负责买入，不负责盘点；只负责新增，不负责维护；只看今年增加了多少页面，不看去年那些页面还剩多少价值。
真正有内容优化意识的团队，和只顾着发布新内容的团队，最后在 SEO 上拉开的差距，往往比写作能力本身大得多。
你看得到竞品有很多文章，看不到它怎么管理这些文章
为什么很多团队会陷进“继续发新文章”这条路？
因为这是 SEO 小白做竞品研究时，最容易看到的东西。
假设我刚开始做 SEO。我去查一个竞争对手，发现它自然搜索流量很高。再往下看，哦，原来它有几千篇博客，其中很多页面都在带流量。
那我最直接的策略是什么？
我也去做博客。
这个结论特别自然，甚至很难说它错。竞争对手有博客，博客带来了流量，于是我也建立内容团队、关键词库和发布计划。很多公司的 SEO 内容体系，就是这么起步的。
但问题也在这里。
你能从 Semrush、Ahrefs 或公开 URL 里看到竞争对手发布了多少页面，哪些页面有流量，覆盖了哪些关键词。你看不到的是，它内部怎样维护这批内容资产。
你不知道它多久做一次内容审计。
你不知道它如何判断一个页面该保留、更新、合并还是删除。
你不知道它是否会保护已经带来点击的标题、内链、Schema 和页面结构。
你也不知道它有没有一套监控机制，在 CTR 刚刚下滑、排名从第 4 名漂到第 8 名的时候就把页面捞出来，而不是等流量掉光以后再开追悼会。
这就是表面模仿最容易漏掉的一层。
你模仿了对手的内容产量，没有模仿到对手的内容资产管理能力。
而对一个进入成熟期的网站来说，后面这套能力往往更值钱。
新页面是从零开始，老页面是带着家产上手术台
新页面其实很好处理。
它没有排名，没有历史点击，没有外链，没有内部链接，没有积累下来的搜索意图，也没有一条正在赚钱的转化路径。你怎么改都行，反正起点就是零。
更新老页面完全不是一回事。
一个已经有排名的页面，可能已经拥有一批稳定查询，已经被几十个站内页面指向，已经积累了外链，已经有 Schema，已经被 Google 反复抓取和理解，也可能每天还在带来询盘、注册和订单。
你面对的不是一张白纸。
你是在给一项仍然产生现金流的资产做手术。
这也是很多所谓“AI 内容更新”最危险的地方。团队一看页面流量掉了，就让模型从头重写一遍。句子更顺了，小标题更多了，字数也从 2000 字变成了 5000 字，读起来好像很努力。
然后原来排名的查询没了，标题 CTR 掉了，内链锚文本对不上了，结构化数据被覆盖了，Google 重新理解整张页面，最后连原来那点流量也被刷新没了。
这不叫内容更新。
这是给自己做了一次 SEO 降权，只不过包装得比较像勤奋。
我这次参考的 Search Engine Land 案例，讲的是一个机场接送网站如何更新安塔利亚机场页面。作者先锁定 56 天基线，再检查查询、页面意图、人物需求、当地信息、图片、Schema 和内部链接，只改真正需要变化的部分。
案例里的页面在更新前，56 天获得了 148,537 次展示，平均排名 14.89，CTR 只有 1.49%。更新后，日均点击从 39.55 增加到 49，平均排名从 14.89 提升到 10.87，CTR 提升到 1.79%。
作者还披露，他们一共完成了 59 次测试，归一到可比较的 56 天窗口以后，额外获得了 2,284 次自然点击；自然购买相对基线增加 24.9%，自然收入增加 20.1%。
这组数据不是我的项目数据，也不能直接外推到所有网站。季节性、品牌、页面类型和测试方法都会影响结果。但它至少证明了一件事：对于已经拥有搜索资产的成熟网站，针对性更新有可能比盲目增加页面更接近商业结果。
真正有价值的动作，不是把整页重新写得更像 AI。
是找到那一小块正在漏血的地方，然后把它修好，同时别把原来还能工作的部分拆了。
原文用 Claude Code，我更想把它改造成 Codex 工作流
原文最有价值的地方，不是它用了 Claude Code，也不是它拆出了 14 个步骤。
真正值钱的是一句很容易被忽略的话：判断没有交给机器，机器负责执行和约束已经形成的判断。
这一点我非常认同。
很多人使用 AI 的方式，依然是把它当成一个更便宜的写手。给一个关键词，扔一篇旧文章，让它“结合最新趋势重写并扩充”，然后期待模型自己理解哪些排名要保护、哪些事实已经过期、哪些段落承担转化、哪些内链不能动。
AI 知道个锤子。
它没有你的 GSC 数据，不知道页面靠哪些查询活着；没有 GA4 转化数据，不知道哪部分流量真正值钱；没有内容资产图谱，不知道改掉这一段会不会和另一张页面发生 cannibalization；没有品牌约束，也不知道你哪些承诺可以说，哪些价格、政策和产品能力不能乱写。
所以 Codex 版本的核心，不应该是“让 Codex 帮我刷新一篇文章”。
而是把 SEO 团队已经验证过的管理纪律，做成 Codex 每次都必须遵守的工作流。
OpenAI 当前给 Codex 的官方最佳实践，正好提供了几块适合做这件事的基础设施：
- 用
AGENTS.md保存项目里长期有效的规则和禁止项； - 用 Skills 把重复工作包装成可复用流程；
- 用 MCP 或脚本连接仓库之外的实时数据；
- 用 Scheduled Tasks 定期运行已经稳定的监控和分析；
- 用 Git diff、测试、检查和 review 验证每一次真实改动。
所以，这不是简单地把原文里的 Claude Code 名字替换成 Codex。
Codex 版应该更像一套内容资产操作系统。
第一层，用 AGENTS.md 守住不能乱动的东西
Codex 官方把 AGENTS.md 定义成面向 Agent 的项目说明文件。它会在工作开始前自动读取，而且可以从全局、仓库到子目录逐层覆盖。
放到 SEO 内容更新里，这个文件最适合保存什么？
不是“文章要写得专业、自然、有深度”这种谁看了都不知道怎么验收的废话。
它应该保存真正会影响资产安全的规则：
## Content update invariants
- 没有锁定更新前基线，不允许修改页面。
- 默认保留 URL slug。
- 标记为 Keep 的段落不得重写，只允许事实校正。
- 已经带来点击的主要查询必须进入保护清单。
- Meta title 有稳定 CTR 时，默认不改。
- Schema 只能扩展或修复，不得无理由整体替换。
- 修改前必须备份原文件，修改后必须输出 section-level diff。
- 没有通过构建、链接、Schema 与页面渲染检查，不得进入 CMS。
- Codex 只允许生成草稿或 staging 版本，不得直接公开发布。这些规则看起来很土。
但 SEO 真正容易出事故的地方，本来就不是什么高深玄学。大多数时候，是某个人兴致勃勃地“优化”了一遍，然后把 URL、标题、内链、结构、事实和页面意图一起改了。
AGENTS.md 的作用，就是让这些边界不用每次重新提醒。Codex 进入这个项目，就先知道这是一项资产维护工作，不是一场自由创作比赛。
第二层，把判断流程拆成一组小而明确的 Skills
官方文档对 Skills 的定位也很清楚：如果一个提示词不断重复，一个流程不断被纠正，就应该把它做成 Skill。
SEO 内容更新非常适合。
但不要一上来做一个“全自动 SEO 大师 Skill”。这种东西听起来很厉害，最后一般会变成一个五千行提示词垃圾桶，什么都能做，什么都做不稳。
我的 Codex 版会把它拆成几个边界清楚的工作单元：
content-decay-radar
读取页面级 GSC、GA4 或内部收入数据，比较固定窗口，找出点击下降、CTR 变差、排名漂移、查询覆盖收缩或转化下降的页面。它只负责生成候选队列，不负责改内容。
content-asset-audit
读取候选页面和查询数据，把现有段落标成 Keep、Fix、Remove、Add。每个标签必须附理由和证据。没有数据支撑时，只能标记为“待人工判断”，不能为了凑结果硬分。
serp-and-intent-gap
检查当前 SERP、竞争页面、搜索意图和可能的 cannibalization。它要回答的是哪里缺了、哪里错位了、哪里已经被另一张页面覆盖，而不是抄一份竞品目录回来。
delta-brief
只写变化说明，不为整张页面重新做一份大而全的内容 Brief。它像工程变更单：哪段保留，哪段修复，哪段删除，新增什么，为什么改，改完如何验收。
content-delta-editor
只修改 Fix 和 Add 部分。它必须读原文语气、品牌资料、产品事实和保护查询，不能把保留段落统一洗成同一种 AI 腔。
fact-and-freshness-checker
新写的内容要查，保留内容也要查。价格、产品功能、地点、政策、年份、截图、统计口径，只要可能过期，就不能因为它被标成 Keep 而跳过验证。
seo-preservation-auditor
检查 slug、title、description、canonical、Schema、入链、出链、anchor、图片规格和页面渲染。它的任务不是让文章更漂亮，而是确认这次更新没有误伤已有权益。
publish-auditor
只负责生成 staging、diff 和最终审核报告。任何硬门槛失败，流程就停。人工确认以后，才进入真实发布动作。
这些 Skill 不是 OpenAI 开箱即送的 SEO 套餐，而是团队根据自己的网站、数据和业务规则创建的业务工作流。
Skill 负责方法，数据仍然要从真实系统来。
第三层，用 MCP 和脚本把 Codex 接到事实，而不是接到想象
Codex 官方建议在信息位于仓库之外、变化频繁、需要重复读取时使用 MCP。
SEO 基本就是为这句话量身定制的。
查询和索引表现可能在 Google Search Console；会话与转化在 GA4；关键词和外链数据可能来自 Ahrefs、Semrush 或内部数据库；页面源文件在 Git；产品事实可能在 Notion、数据库或商品系统；最终内容还要进 WordPress、Strapi 或自建 CMS。
如果这些数据没有接进来，Codex 看到的只是一篇孤零零的 Markdown。
让它根据一篇孤零零的 Markdown 决定整张页面怎么改，和让一个没看病历的医生直接动手术，区别也没有很大。
所以我的建议是，先别急着把所有工具都接进来。官方文档也不建议一开始就配置一大堆 MCP。先找出最频繁、最痛的人工循环。
通常可以从三条链路开始：
- GSC 页面与查询数据；
- 站点内容源文件和内容资产清单；
- CMS 的草稿或 staging 接口。
如果团队习惯把内容资产放在 SQLite 里，也可以让脚本先把页面、目标关键词、更新时间、查询基线、内链关系、转化类型和审核状态写进数据库。Codex 每次运行都从同一个事实源读取，而不是今天看表格、明天翻聊天记录、后天凭印象猜这个页面以前为什么写。
对内容资产来说，事实源越多，自动化越容易变成精神分裂。
一套 Codex 内容更新流程，应该怎样真正跑起来
我会把整个过程压成六个阶段。
flowchart LR
A[Decay Radar<br/>发现衰退] --> B[Baseline & Snapshot<br/>锁定基线与备份]
B --> C[Audit & Research<br/>分段审计与意图研究]
C --> D[Delta Brief<br/>只定义变化]
D --> E[Edit & Verify<br/>修改并验证]
E --> F[Staging & Measure<br/>人工批准后上线和复盘]阶段一，先找对页面，不要看到日期旧就更新
内容衰退不等于发布日期比较早。
有些三年前的页面仍然稳定排名，事实也没过期，用户需求没有明显变化。你去改它，纯属手痒。
真正值得进入队列的，是那些已经出现业务信号的页面：
- 点击与排名持续下降；
- 展示稳定但 CTR 变差；
- 原来有排名的核心查询逐步掉出前十；
- 新查询出现，但页面没有真正回答；
- 转化率、询盘或收入开始走弱；
- 竞争页面获得了新的信息优势；
- 页面事实、产品能力或当地信息已经变化。
Codex 可以按固定周期读取这些数据，生成候选队列。但最终优先级不能只看流量跌幅。
一个每天少 100 次访问但完全不转化的博客，未必比一个每天只少 10 次访问、却直接承接订单的商业页更优先。
成熟团队应该先看商业价值，再看衰退程度。收入决定先看谁，诊断决定怎么修。
阶段二，锁定基线，给原页面拍一张完整的遗照
不好意思，“遗照”这个词有点晦气，但意思就是这个意思。
在 Codex 动任何一个字之前，先保存原文件、页面 HTML、查询基线、标题、Schema、内链、截图和关键转化数据。窗口用 28 天、56 天还是同比周期，要根据站点季节性和数据量决定，不要迷信原文的 56 天。
原文使用 56 天，是因为它配合 SEOTesting 的八周测试周期，也适合那个具体旅游业务。你的 SaaS、工具站、电商站或新闻站，可能需要完全不同的窗口。
真正不能省的是“先锁定，再修改”。
没有基线，更新以后流量涨了，你不知道是不是季节、算法、品牌活动或运气；流量跌了，你也不知道哪一步破坏了原来的价值。
阶段三，给每一个段落贴标签
Keep、Fix、Remove、Add，这四个标签几乎可以保留原文的设计。
Keep 不是“永远正确”，只是当前仍然有效并且承担价值。
Fix 是方向没错，但事实、表达、结构或意图覆盖已经落后。
Remove 必须最谨慎，因为删掉的内容可能正在承接一个你没有注意到的长尾查询。
Add 也不能因为竞争对手有一个 H2，你就跟着加一个 H2。新增内容应该来自查询缺口、用户任务、产品变化或证据缺口。
Codex 在这一阶段最适合做的是把证据与段落对应起来。哪一个查询对应哪一段，哪一段缺少答案，哪一处事实过时，哪一段和另一张页面重复。
只要这个映射做对了，后面的写作反而是最便宜的部分。
阶段四，先写 Delta Brief，不直接写正文
这是整套方法里我最想保留的东西。
很多内容 Brief 其实是为了新页面设计的。目标关键词、文章结构、H2、FAQ、参考竞品全部重来一遍。拿这种 Brief 更新老页面，天然会鼓励重写。
Delta Brief 不一样。
它只描述变化：
- 哪一段保持不动；
- 哪一个事实需要重查；
- 哪一段应该重写，原因是什么；
- 要补哪个查询意图；
- 哪个模块需要增加；
- 哪些 SEO 权益必须保护；
- 改完以后用什么证据判断成功。
这份 Brief 越像工程 change request 越好，别追求文学性。
文章是给用户看的，变更单是给执行系统看的。两种东西混在一起，最后谁都看不明白。
阶段五，只写 Delta，然后像审代码一样审内容
进入编辑阶段以后，Codex 只允许改 Fix 和 Add。
改完不是“读起来挺顺”就结束。要看 section-level diff：究竟删了什么，新增了什么，哪些数字变了，哪些链接变了，标题、Schema 和页面结构有没有被碰。
如果页面在代码仓库里，这一点正好是 Codex 的优势。它可以直接修改 Markdown、MDX、JSON、前端组件和 Schema 文件，运行 lint、构建、链接检查和页面 smoke test，再把 diff 交给人审。
如果 Brief 需要一个比较表、选择器、计算器或 FAQ 组件，Codex 也可以在同一个仓库里完成 UI 实现和验证，而不是让内容团队写完文案，再去排两周开发期。
但这里一定要保留一条边界：能生成组件，不等于可以跳过产品和 SEO 判断。
一个漂亮的交互模块，如果没有解决真实任务，只是在页面上增加了 JavaScript 和维护成本。Vibe Coding 很快，垃圾也会生成得很快。
阶段六，先 staging，再发布，再用同一口径复盘
Codex 可以通过 MCP 或 CMS API 把内容推到 staging，也可以生成待审核草稿，但公开发布最好保留成人工动作，尤其是商业页面。
发布前至少要过：
- 原页面与新页面的分段 diff；
- 内链与 anchor 检查；
- canonical、robots、Schema 校验；
- 页面构建与渲染；
- 关键 CTA 和转化事件；
- 移动端与性能风险；
- 事实来源与更新时间；
- 人工最终判断。
任何硬检查失败，流程就停。
上线以后，仍然使用更新前锁定的指标口径复盘。排名、点击、CTR、查询覆盖当然要看，但商业页面最后还要看注册、询盘、购买和收入。
只看排名，不看商业结果，很容易把一次 SEO 更新做成自我感动。
Scheduled Tasks 才是这套系统真正开始复利的地方
当单页流程跑通以后，Codex 版还有一个很关键的下一步：Scheduled Tasks。
官方对它的定位很准确，Skill 定义方法，Scheduled Task 定义时间。
你可以让 Codex 每周读取一次内容资产数据，生成衰退候选；每天检查刚更新页面的构建、索引和链接状态；每月汇总更新实验的结果；当某个页面达到阈值时，自动创建一份审计任务。
注意，我说的是自动创建任务和分析报告，不是自动冲进 CMS 把线上页面改了。
真正成熟的自动化，不是“什么都不用管”。
是低风险、重复、可验证的动作自动跑，高风险、不可逆、需要业务判断的动作在门口等人。
这个区别很重要。很多团队追求全自动，只是因为看起来先进。最后 Agent 每天很忙，文章每天在发，数据库每天在写，真正的搜索流量和收入却没人知道发生了什么。
这种系统不是自动化，是电子宠物。
可以并行研究，不要让多个 Agent 同时改同一张高价值页面
Codex 支持多 Agent 和并行任务，这对内容审计当然有帮助。
你可以让不同 Agent 分别读取 GSC、分析 SERP、检查事实、扫描内链和审计图片，然后由主任务汇总。
但一张已经有排名、转化和历史资产的页面，不适合让几个 Agent 同时抢着改。
官方的多 Agent 建议也更偏向把并行用在探索、测试、日志分析和总结这类读操作上；同一批文件的写操作，需要更谨慎，必要时用 Git worktree 隔离。
我的建议很简单：
研究可以并行，决策要收口，写入要串行，发布要审批。
别为了追求面板上同时跑着六个 Agent，就把内容质量和资产安全一起献祭了。工具看起来忙，不等于项目真的快。
Codex 也不会自动解决内容资产管理
写到这里，可能有人会觉得，只要把上面这些 Skill、MCP、Scheduled Tasks 和 AGENTS.md 配好，网站就可以自己生长了。
NO NO NO。
Codex 解决的是执行与约束的规模问题，不会自动替你拥有业务判断。
它不知道你今年为什么要重点推某条产品线，除非真实数据和策略告诉它。
它不知道一张页面虽然流量不高，却是销售团队每次发给客户的信任材料。
它不知道某个看起来重复的页面，实际服务两个国家、两种法规和完全不同的购买人群。
它更不知道你愿意为了短期点击牺牲多少品牌表达，或者为了品牌长期价值放弃多少容易获得的流量。
这些都不是模型自己应该决定的东西。
所以我更愿意把 Codex 看成一个内容资产运营团队的执行系统。它能记住规则，读取数据，运行审计，生成 Delta Brief，修改文件，做验证，留下 diff，定期监控。
至于做什么、为什么做、什么结果值得接受，最后还是人的判断。
AI 不应该替你假装懂业务。
它应该把你已经形成的业务判断，稳定地执行一千次。
真正的差距，不是有没有用 AI，而是有没有管理资产
回到最开始那个 SEO 小白的竞品研究。
你看到竞争对手有几千篇文章，于是你也准备写几千篇。
但也许对手真正厉害的地方，不是它每个月还能发多少新内容，而是它知道哪一张页面正在衰退，哪一张页面值得抢救，哪一段不能碰，哪一个查询只差半步，哪一个旧页面更新以后比十张新页面更接近收入。
这些东西不会直接出现在 Ahrefs 的 URL 列表里。
它藏在团队的数据纪律、内容审计、更新队列、版本记录、测试方法和发布边界里。
也就是藏在内容资产管理能力里。
AI 让写作变便宜以后，这个差距只会越来越明显。因为所有人都能生产，生产本身就不再稀缺。真正稀缺的是，谁知道什么不该生产，什么值得维护，什么必须保护，什么应该被删除，以及每一次变化最后有没有变成流量、转化和刀乐。
所以，如果你已经有一个相对成熟的网站，手里有几百上千个页面，我真不建议下一步还只是让 Codex 再写 100 篇文章。
先把内容资产清单建起来。
先找出那些正在缓慢失血、但还有排名、有查询、有链接、有转化基础的页面。
再把你的判断做成 AGENTS.md，把重复方法做成 Skills，把实时数据接进 MCP，把硬检查放在发布之前，把稳定流程交给 Scheduled Tasks。
这个过程没有“一键生成 100 篇文章”那么爽。
甚至有点脏，有点麻烦，还要反复看数据、做 diff、查事实、守边界。
但真正有商业价值的 SEO 工作，很多时候就是这些不好截图发朋友圈的苦活。
别再只让 AI 帮你生产内容了。
让它开始帮你管理内容资产。
写作只是其中最便宜的那一步。
