一句话总结
多数 SEO 审计扔给你 300 条发现，其中 250 条只影响两个页面，结果你什么都没改。这套流程在自己仓库里用 Claude Code：开 plan 模式（只读）按”影响页数”给发现打分，只修 top 3 并 review diff，用你自己的审计脚本加一次 build 验证，再一条修复一个 commit。预算两小时。结尾你拿到三个上线的修复、可测量的问题数下降，全程不离开终端。
你需要准备什么
这是一篇教程，所以先把它假设的环境讲清楚（截至 2026 年 6 月）：
- 装好并登录 Claude Code。它只跑 Anthropic 自家模型——Opus 4.7（深度推理）和 Sonnet 4.6（快速主力）。它已经包含在 Claude Pro 套餐里，每月 20 美元（年付折合每月 17 美元），所以这套流程不需要单独的 API key。见 Claude 定价。
- 一个用 Astro、Next.js 或 Hugo 的内容站，仓库根目录有
CLAUDE.md。 - 一个能跑的内容校验脚本，比如
npm run audit:content，外加npm run build。 - 开始前先把 git 工作树清干净。
为什么用 Claude Code 而不是把页面贴进聊天窗口：agent 读的是你真实的文件，能引用真实路径和行号，并把修复以 diff 形式给你批准。聊天窗口只看得到你贴进去的内容，所以它会编造出无法核实的结构。
plan 模式是安全护栏
这里最重要的设置就是 plan 模式。plan 模式是一个只读权限状态：Claude Code 能读文件、能跑 shell 命令探索，但在你退出该模式之前一个源文件都改不了。这正是审计那半场想要的。
三种进入方式：
- 启动时就只读：
claude --permission-mode plan - session 中途按 Shift+Tab，在
default → acceptEdits → plan之间循环 - 在 prompt 里打
/plan
整个审计都在 plan 模式里跑。只有当你选好 top 3 修复后，才退出 plan 模式，一条一条地 apply。
先把 agent 指向你的数据注册表
最大的质量杠杆是”接地”。在任何审计 prompt 之前，先确保 agent 读了描述你站结构的文件——内容数据注册表。在这类 Astro 站上，就是 src/data/categories.ts 和 src/data/hubs.ts 这种文件。agent 读了它们，发现就会引用真实的类目和 hub 字段，而不是猜。
CLAUDE.md 保持在 200 行以内（这是 Anthropic 自己的建议：文件越长消耗的 context 越多，Claude 遵守指令的可靠度也越低）。这套流程的高信噪比 CLAUDE.md 只需三样东西：目录布局、审计命令的确切写法、以及一行”审计一律用 plan 模式”的规则。跑一次 /init 从代码库生成起始文件，再删减。
审计 prompt
在 plan 模式里跑。它本身就是只读结构，但 plan 模式把这个保证从”客气的请求”变成”硬约束”：
在 plan 模式下跑 SEO 审计。读 src/data/categories.ts、src/data/hubs.ts，
以及每个类目 5 篇样本文章。报四个桶：
1. metadata 问题（缺标题/标题过短、描述过短或重复）
2. 薄内容候选（正文低于你的字数下限）
3. 内链缺口（孤儿页、入链少于 2 条的页面）
4. hreflang 问题（缺 return 标签、en 与 en-us 不匹配）
每条发现给出：文件路径、确切问题、影响多少页。
什么都别改。“影响多少页”这一句是全局关键，它把一张平铺的清单变成一个 triage 队列。
打分与分流
把每条发现按页数排序、分桶。单页问题不值得开 agent session——那些以后手动修。用这个粗略的分界线：
| 影响页数 | 处理方式 | 原因 |
|---|---|---|
| 50+ | 本场就修 | 模板级或注册表级 bug，一个修复带动很多页 |
| 10–49 | 进了 top 3 就修 | 值得开一个 agent diff |
| 2–9 | 攒到以后手动批量过 | 太小，不值得 review 的开销 |
| 1 | 手动改 | 不是 agent 该做的事 |
按页数挑 top 3。其余全部进审计日志，留到下季度。
一次只修一条
现在退出 plan 模式（Shift+Tab 回到 default，或者你信得过范围就用 /accept-edits）。对三条问题里的每一条：
只在列出的文件里修问题 1。apply 前先给我看 diff。别碰任何其他文件。- 读 diff。范围限定在”metadata”的修复绝不该改正文——改了就说明 prompt 太松。
- 批准，然后跑
npm run audit:content和npm run build。两个都得过。 - 确认
audit:content的问题数真的降了。没降说明是表面修复——撤掉它。 - commit。一条问题一个 commit，事后发现回归时回滚很精确。
session 结尾让 agent 总结：修了什么、推后了什么、注意到什么新模式。贴进审计日志。
实战示例：hreflang return 标签修复
双语站最常见的发现是 hreflang “no return tags”——这是 Google 最高频的 hreflang 错误。意思是 A 页指向了它的对应页 B，但 B 没指回来，于是 Google 可能给用户推错语言版本，或者干脆忽略你的 hreflang。在双语 EN/ZH 站上，这通常追溯到同一个根因：translationKey 不匹配，或者 alternates 列表里 en 与 en-us 取值不一致。因为它是注册表级的，改对一个 helper 就能一次修好几百个页面——正好是上表里 50+ 那一行。让 agent 找到生成 alternates 的那段代码、在源头修值，而不是一页一页改。
第一次实操怎么跑
第一天别拿它对着整站跑。
- 选一个有 30–50 篇文章的类目——比整库小、又够代表性。
- 只在那个类目跑审计 prompt。把发现存进一个 Markdown 文件。
- 端到端只修一条发现。记下 agent 哪里不清楚、哪里追问了两次。
- 把领悟更新进
CLAUDE.md：它懂的术语、反复漏读的文件。
让它可复用
- 把审计 prompt 存成项目 slash command，路径
.claude/commands/seo-audit.md。之后打/seo-audit就能跑整段 prompt，不用重打。（.claude/commands/是按项目的位置；~/.claude/commands/则让它在你所有仓库里都能用。） - 用一张小表追踪问题数随时间的变化——季度、总发现、top 类目。趋势比单次审计更重要。
- 每半年重测这套流程本身。Astro 默认、Google 的 SEO 指南、Claude Code 自己的行为都会变。
FAQ
- 需要单独的 API key 吗？: 不需要。Claude Code 包含在 Claude Pro 套餐里，每月 20 美元（年付每月 17 美元），用的是你正常订阅的 token 额度。只有做无人值守的自动化时才需要独立的 API key。
- Claude 能看懂我的站结构吗？: 把它指向数据注册表（
categories.ts、hubs.ts）、再保持一个 200 行以内、点名这些文件的CLAUDE.md，效果会好很多。没有接地，发现就会变得很笼统。 - 修复会伤 SEO 吗？: 会。最常见的翻车是标题里过度堆关键词。plan 模式加上逐条 diff review，能在上线前抓住它。
- 小修复能跳过人工 review 吗？: 第一次审计不行。审过三次都干净之后，单行 metadata 这类琐碎改动可以批量审。
- 该花多久？: 含修复两小时。超过四小时，说明范围太宽——缩到一个类目。
- 想更深地处理 hreflang 怎么办？: 这次审计抓的是显眼的 return 标签和取值不匹配；想做一次专门的处理，见 AI hreflang 检查教程。
容易踩的坑
- 一个 prompt 让 Claude Code 修所有——你会拿到一个没法 review 的大 diff。
- 不开 plan 模式跑审计，结果一句随口的”顺便修一下”就把审计变成失控的编辑。
- 跳过发现的人工复核——再好的审计也有 10–20% 噪声。
- 每修一次不跑
audit:content加一次 build 验证——静默回归就溜过去了。 - 让 agent 自创约定而不是跟注册表——把它钉死在
categories.ts和hubs.ts。 - 把审计输出当终稿——它是 triage 清单，不是修复清单。
相关阅读
- SEO 审计 Prompt
- AI 审 Astro 站
- AI 检查你的 hreflang 配置（双语 / 多 locale）
- 用 AI 批量生成 Meta Description（小心）
- 怎么用 AI 分流 Search Console 问题
标签: #教程 #SEO #AI 编程 #Claude Code #SEO 审计