Codex 读你的仓库找 SEO bug 非常强，能帮你提前发现那些半年后才会在 Search Console 里露出来的问题。前提是问得具体——不能说”帮我看看 SEO”。下面给出可直接粘贴的 prompt 和验证 Agent 输出的 shell 脚本。
问题背景
技术 SEO 是独立开发里最无聊但复利最大的一块——一个 canonical 漏了、一个 hreflang 错了，就会持续漏流量。像 Codex 这种 Agent 能几分钟扫完你的构建产物，把那些机械性问题（canonical 不一致、缺 alt、sitemap 错条目）一次性列出来，这是人工 review 容易遗漏的。但它判断不了意图——比如你的 H1 是否真的匹配搜索意图——所以分工是：Agent 抓机械问题，你处理判断题。
判断标准
- 站点超过 20 页，从来没正式 audit 过。
- Search Console 里收录数突然下滑找不到原因。
- 刚上线，想提前抓出问题免得后面复利成灾难。
- 换过技术栈或调整过路由，想确认没漏掉什么。
快速结论
本地 build，指 Agent 看 dist/，每个 SEO 关注点问窄问题，用 grep 或 curl 抽查验证，剩下当 worklist。
开始前准备
- 本地
dist/build 与生产输出一致。 - Codex / Claude Code 之类能读仓库文件。
- 装好
grep、xmllint（JSON-LD 用jq）做验证。
实操步骤
- 本地 build，让 Agent 看
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 或 > 65
- description 长度 < 80 或 > 170
- 多个页面 title 或 description 重复
输出：file,issue,title,desc_len抽查：
# 重复 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，按 schema.org Article 和 BreadcrumbList 最低必填字段校验：
Article: @context, @type, headline, datePublished, author
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 .-
抽查 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 有区别吗: 都行。关键是 Agent 能读你的仓库文件。如果只查纯 HTML，连 ChatGPT 上传文件也能一次性 review。
- 能代替 Screaming Frog 之类的爬虫吗: 不能。爬虫系统地查链接、跳转；Agent 查的是模板级 bug。两个一起用。
- Core Web Vitals 怎么办: Agent 做性能审计不行——用 PageSpeed Insights 和真实 Lighthouse。代码 review 能找出大图、阻塞脚本之类的明显问题，但替代不了运行时测量。
- 多久跑一次: 每次大改（新布局、新路由结构、schema 变更）后跑一次，否则每季度一次。
- 能让 Agent 一起出修复方案吗: 能，但要 diff 不要直接改文件，你 review 后再 apply。