Codex 读你的仓库找 SEO bug 非常强，能帮你提前发现那些半年后才会在 Search Console 里露出来的问题。前提是问得具体——不能说”帮我看看 SEO”。下面给出可直接粘贴的 prompt，以及验证 Agent 输出的 shell 命令——因为 Agent 会在文件计数这类事上幻觉，一份验证过的 worklist 远胜一段听起来很靠谱的总结。
一句话总结
本地 build，让 Codex 看 dist/（不是源码），每个 SEO 关注点用一条窄 prompt：canonical、hreflang、title/meta、sitemap、JSON-LD。每类 finding 抽一部分用 grep、xmllint 或 jq 交叉验证。抽查 5 条——5/5 都是真问题，剩下就当 worklist 全信。按类别开一个 issue，别按文件开。
Codex 是什么，为什么适合干这活
Codex 是 OpenAI 的终端编码 Agent，截至 2026 年 6 月由 GPT-5.5 驱动。它在本地运行，读取并执行你指定目录里的代码，能连续跑上百次工具调用而不用你盯着——这正是递归遍历 dist/ 需要的。任何付费 ChatGPT 套餐都自带它：Plus（$20/月）、Pro（$100 或 $200/月，五小时用量窗口更大）、Business（$30/席位）。自 2026 年 4 月计费调整后，这些套餐里的 Codex 用量按五小时滚动窗口内的 token 消耗计量，而不再按消息条数算，所以把几千个 HTML 文件扫一遍，单个 Plus 窗口完全够用。
分工很清晰。Agent 几分钟扫完构建产物，把那些机械性、系统性的错误一次性列出来——canonical 不一致、缺 alt、sitemap 错条目——这些恰恰是人工 review 容易扫过去的。它干不了的是判断意图：你的 H1 到底匹不匹配用户真正输入的那句查询。所以流程是：Agent 抓机械问题，你来做判断题。Claude Code（跑 Claude Opus 4.7 / Sonnet 4.6）在这里用法完全一样，下面的 prompt 不挑工具。
什么时候该跑
- 站点超过 20 页，从来没做过正式的技术 SEO 审查。
- Search Console 里收录数突然下滑，找不到明显原因。
- 刚上线，想提前抓出问题，免得后面复利成灾难。
- 换过技术栈或调整过路由，想确认没漏掉什么。
开始前准备
- 本地
dist/build 与生产输出一致（npm run build）。 - Codex（或 Claude Code）能读仓库文件。
- 装好
grep、xmllint（来自libxml2）和jq用于验证。
五条 prompt
- 本地 build，让 Codex 看
dist/而不是源码：
npm run build
ls dist/ # 确认有页面
du -sh dist/ # 大小心里有数- canonical 审查。Prompt：
[CONTEXT] Astro 静态站；构建产物在 dist/。每页是 slug 目录下的 index.html。
[TASK] 递归遍历 dist/。对每个 *.html，找 <link rel="canonical">。报告：
- 文件 MISSING tag
- canonical href 与自身 URL 路径不一致
- 多个 canonical
输出 CSV: file,issue,detail
[CONSTRAINTS] 不要改任何文件。只读。grep 验证：
# 没 canonical 的页数
grep -L 'rel="canonical"' $(find dist -name '*.html') | wc -l
# canonical 不含主域名的文件
grep -ROIL '<link rel="canonical" href="https://yourdomain.com' dist | head- hreflang 审查。Prompt：
[TASK] dist/**/index.html 含 hreflang 的页面，验证：
- 该页通过 hreflang="<自身语言>" 引用自己
- 该页通过 hreflang="<另一语言>" 引用其翻译
- 另一语言的 URL 在 dist/ 里实际存在
报告不一致：file,expected_other,actual_other_or_missing- title / meta description 审查。Prompt：
[TASK] dist/**/index.html 每页提取 <title> 和 <meta name="description">。
报告：
- title 缺失或空
- description 缺失或空
- title 长度 < 25 或 > 60（Google 在约 600px / ~60 字符处截断标题）
- description 长度 < 110 或 > 158（桌面端约显示 920px / ~158 字符）
- 多个页面 title 或 description 重复
输出：file,issue,title,desc_len这些字符阈值对应 Google 2026 年中的 SERP 渲染：标题在约 600 像素（约 60 个字符）处被截断，桌面端描述渲染到约 920 像素（约 158 个字符），移动端降到约 680 像素（约 120 个字符）。字符数只是个近似——宽字符会更早被截——所以临界标题当成人工复核项，别直接判失败。
抽查：
# 重复 title
grep -hr '<title>' dist | sort | uniq -c | awk '$1 > 1' | head- sitemap diff。Prompt：
[TASK] 解析 dist/sitemap-index.xml（含引用的 sitemap）。
对比 sitemap 中 URL 与 dist/ 实际 *.html 集合。
报告：
- sitemap 中存在但文件不存在
- 文件存在但不在任何 sitemap（可能漏收录）交叉验证：
xmllint --xpath '//*[local-name()="loc"]/text()' dist/sitemap*.xml \
| sort > /tmp/sitemap-urls.txt
find dist -name 'index.html' | sed 's|dist|https://yourdomain.com|' | sed 's|/index.html|/|' \
| sort > /tmp/file-urls.txt
diff /tmp/sitemap-urls.txt /tmp/file-urls.txt- 结构化数据校验。Prompt：
[TASK] dist/**/*.html 里找所有 <script type="application/ld+json">。
解析 JSON，按 Google 生成 rich result 所需字段校验：
Article: @context, @type, headline, image, datePublished, author（含 author.name）
BreadcrumbList: @context, @type, itemListElement (array)
报告 parse 错误或缺字段。
输出: file, ld_type, problem抽查：
# 提取某页第一个 JSON-LD 块并美化
sed -n '/<script type="application\/ld+json">/,/<\/script>/p' \
dist/en/articles/some-slug/index.html \
| sed '1d;$d' | jq .Agent 能大规模抓出 parse 错误和缺字段，但它没法告诉你 Google 到底会不会给 rich result。最终在浏览器里用两个官方工具确认：Google Rich Results Test（这段标记够不够格拿 Google 的 rich result？）和 Schema Markup Validator（抛开 Google，这段标记是不是合法的 schema.org？）。对 Article，Google 的最低要求是 headline、image、datePublished 和 author.name，日期必须是 ISO 8601 格式。上线后在 Search Console 的 Enhancements 报告里盯整站的聚合状态。
-
抽查 5 条 finding。 5/5 真问题就把剩下当 worklist 全信；2/5 就把 prompt 收窄重跑。
-
按类别开 issue，不按文件。 让 cleanup 聚焦：
Issue: dist/ 有 23 篇文章缺 canonical
- 见附件 CSV
- 在 ArticleLayout.astro 里修，重新 build
- 重跑 prompt 2 验证为 0执行检查清单
- 审的是 build 产物（
dist/），不是源码。 - 每个 prompt 只问一个 SEO 关注点。
- 用
grep、xmllint或jq交叉验证。 - finding 当 issue 跟踪，不直接 inline 改。
- prompt 存档，下次大改后重跑。
上线后验证
- 修完后重跑同样 prompt 应返回空（或大幅缩短）。
- Search Console URL Inspection 抽查样本 canonical、hreflang 与预期一致。
- 至少 3 篇样本 Lighthouse SEO = 100。
容易踩的坑
- 问”我的 SEO 好不好”，得到的是个通用 checklist，根本没碰到真问题。永远问某个标签、某个文件、某个路由。
- 相信 Agent 关于搜索意图或关键词策略的建议——它看不到 Search Console 数据，会编一些听起来对其实错的建议。
- 让它看源码而不是构建产物。很多 SEO 问题只有 build 完才出现（比如 undefined frontmatter 导致 meta 标签为空）。
- 让它直接改文件。让它给 diff，你自己 review 再 apply。
- 跳过
grep/xmllint验证——Agent 会幻觉，文件计数尤其。
FAQ
- Codex 还是 Claude Code，有区别吗: 干这活没区别。Codex（GPT-5.5）和 Claude Code（Opus 4.7 / Sonnet 4.6）都能读仓库、连续跑递归遍历
dist/所需的那串工具调用，上面的 prompt 不挑工具。如果只查几页纯 HTML，连 ChatGPT 上传文件也能一次性 review。 - 会不会超出我 ChatGPT Plus 的额度: 基本不会。自 2026 年 4 月起 Codex 按五小时滚动窗口的 token 用量计量，不再按消息条数。扫几千个 HTML 文件主要是廉价的文件读取，一个 Plus（$20/月）窗口就吃得下。只有你整天并行跑好几个 Agent，Pro（$100/$200）才有意义。
- 能代替 Screaming Frog 之类的爬虫吗: 不能。爬虫顺着链接和跳转系统地爬线上站点；Agent 查的是构建产物里的模板级 bug。两者抓的是不同类型的问题，要一起用。
- Core Web Vitals 怎么办: Agent 做性能审计偏弱。用 PageSpeed Insights 和真实 Lighthouse 跑。代码 review 能标出大图、阻塞渲染的脚本之类的明显问题，但替代不了运行时测量。
- 多久跑一次: 每次结构性改动（新布局、新路由结构、schema 变更）后跑一次，否则每季度一次。把 prompt 存好，重跑就是一次粘贴。
- 能让 Agent 一起出修复方案吗: 能，但要 diff 不要让它直接改文件，你 review 后再 apply。修复通常落在一个布局组件里，而不是散在 23 个文件里。