一句话总结
让 Codex CLI 同时读你的 sitemap 源（src/pages/sitemap-*.ts、next-sitemap.config.js 或 CMS 配置）和构建出来的 dist/sitemap-index.xml，然后跑一条聚焦的审计 prompt。Codex 会查：混进来的 draft 页、断掉的尾斜杠一致性、过期的 lastmod、缺失的 hreflang 对，并为每条问题标出确切的源文件和行号。在源上修、重构建、再跑一遍，最后重新提交到 Search Console。一个一年没扫过的站点，首跑通常会冒出 10-30 条异常。这篇给出确切的 prompt 和 Codex 该执行的协议上限。
sitemap 为什么会漂移（人为什么看不出来）
任何有意义的站点变更——URL 重构、加语言、内容迁移——sitemap 都会悄悄和现实脱节。draft 页混进来、lastmod 不再反映真实改动、不同小节的尾斜杠约定分裂，一周后 Search Console 弹出”已提交的网址标注了 noindex”或”已提交的网址未找到（404）“——而那时 Google 已经白白消耗了抓取预算。
这种问题为什么躲过人工 review：sitemap 是生成的，所以没人去读它。你读的是生成它的源，然后默认产物没错。Codex 正好补上这个缺口——它同时读构建产物和源，然后告诉你两边在哪里对不上。
这篇适合谁看
任何有生成式 sitemap.xml 的站长：Astro、Next.js、Hugo、带 sitemap 插件的 WordPress，或自定义生成器。它在双语 / 多语言站点上最值钱——hreflang 注解和分语言 sitemap 把失败模式翻倍。（在本站，每篇英文文章都通过共享的 translationKey 和一篇中文孪生文配对，所以缺一个配对是真实的排名 bug，不是表面问题。）
Codex 在这里到底是什么
Codex 是 OpenAI 的终端编码 agent。截至 2026 年 6 月，它默认跑 GPT-5.5（可用 /model 切到 GPT-5.4 或 GPT-5.3-Codex），能在指定目录里读和运行代码，内置网页搜索。有两个特性让它特别适合做 sitemap 审计：
/review用一个独立的 review agent 扫你的工作区——在 Codex 提出源级修复后很有用。codex exec以非交互方式跑一条 prompt，于是同一套审计可以放进 CI。
Codex 不是爬虫。它对你的文件做推理，并不去抓你的线上 URL。在这里这反而是优点——你要它检查的是生成逻辑，不是服务器的 HTTP 响应。
Codex 该执行的协议上限
下面这些数字来自 sitemaps.org 协议 和 Google 的 sitemap 文档，截至 2026 年 6 月仍然稳定。把它们写进 prompt，让 Codex 直接标违规，而不是靠猜：
| 规则 | 上限 / 要求 | Codex 该标什么 |
|---|---|---|
| 单文件 URL 数 | 最多 50,000 | 单文件超限、需要拆分 |
| 解压后文件大小 | 最多 50 MB（52,428,800 字节） | 接近字节上限的文件 |
| 索引文件内的 sitemap 数 | 最多 50,000 | 需要嵌套的索引 |
lastmod 格式 | W3C 日期时间（YYYY-MM-DD 或完整 ISO 8601） | 格式错误或编造的日期 |
lastmod 准确性 | 仅在主体内容真改动时更新 | 所有 URL 同一个日期，或到处写”今天” |
hreflang 簇 | canonical 必须在自己的替代簇内 | 翻译对缺了一边 |
| 尾斜杠 | 全站统一一种约定 | /page 与 /page/ 混用 |
其中两条值得强调。Google 的 John Mueller 已确认：通过 hreflang 声明的替代语言 URL 不单独计入那 50,000 条上限。另外 Google 说过：如果你每天给每个页面都把 lastmod 设成今天，它会判定这个字段没意义，从此不再信它——改个页脚版权年份不算内容改动。
具体步骤
- 在仓库根目录打开 Codex。先重新 build（本站是
npm run build），让dist/sitemap-index.xml反映当前源。Codex 必须读产物，不能只读源。 - 发下面这条审计 prompt。注意它写明了确切文件、协议上限，以及一条硬规则——每条问题都要引源位置：
读 src/pages/sitemap-*.ts 与 dist/sitemap-index.xml（build 之后）。
核验并报告 findings：
- 每个分类页、每个语言都收录了。
- 每个文章 URL 都带尾斜杠（项目约定）。
- 不出现 draft URL（draft 页的 frontmatter 是 draft: true）。
- lastmod 用 YYYY-MM-DD，且不是所有 URL 都一模一样。
- 共享 translationKey 的 en/zh 条目之间存在 hreflang 对。
- 没有文件超过 50,000 个 URL 或解压后 50 MB。
- 随机抽 10 个 URL，确认每个都有对应的源文件存在。
每条 finding 引源文件 + 行号，绝不引 dist/ 路径。
建议在源上改，不要建议改 dist。- Codex 返回异常列表。每条都读；当某页是有意做成单语言时，
hreflang启发式会产生少量误报。 - 在源上修——生成逻辑、frontmatter，或你的内容审计脚本——绝不碰
dist/。改dist/下次构建就被覆盖。 - 重新构建，再用同一条 prompt 跑一次。findings 应当降到 0，或一组有文档记录的有意例外。
- 源改动用清晰的 message 提交，例如
fix(sitemap): drop drafts, normalize trailing slashes。 - 到 Google Search Console 重新提交 sitemap。Google 不会按你的节奏重新抓。
全量扫之前先试跑
不要相信一份你还没核对过的 30 条报告。先把 prompt 限定到两个你了如指掌的 URL——首页加一个你最熟的小节——确认 Codex 正确读懂了你的源结构。然后跑全量 prompt，数 finding 数，先修影响最大的前三条（draft 和 404 优先于表面的日期漂移），再跑一遍。看数字下降，说明修复是真的有效；数字不动，说明 Codex 读的是重构建之前的旧 dist/。
怎么确认 Codex 做对了
- 每条 finding 都引了源文件、不是
distURL 吗？没有，就说明 Codex 没理解构建链路——把源路径写明白后重新发一遍。 - 建议的修法幂等吗？对一个本来就正确的文件套用，应当什么都不改。如果某个修法会破坏正确文件，就重新精修它。
- 在浏览器里随机打开 5 个 sitemap URL。404、重定向、语言不对，都是 Codex 静态读取可能漏掉的红旗。
- 下次抓取后，去 Search Console 看 hreflang 报告。Codex 抓结构问题，Search Console 验证搜索引擎的实际行为。
做成常态化检查
把 prompt 存成片段，项目相关路径用占位符，然后每季度、每次 URL 变更、每次内容清理后都跑一遍。再把便宜的那部分用 codex exec 放进 CI——它把 prompt 跑成 headless，并能在回归时让构建失败：
codex exec "读 dist/sitemap-index.xml。如果任一 URL 缺尾斜杠、出现任一 draft URL，或所有条目 lastmod 完全相同，则失败。打印一行 PASS，否则打印不合规的 URL。"再维护一份 sitemap-conventions.md，记录尾斜杠规则、draft 政策和 hreflang 配置也有帮助——Codex 会读它，从此不再反复标你有意为之的选择。Astro / Next.js / CMS 大版本升级后重测，因为不同版本之间 sitemap 生成逻辑经常变。
容易踩的坑
- 直接改
dist/sitemap.xml。 下次构建覆盖你的修复。永远改源。 - 不声明尾斜杠约定。 Codex 会报混用，但在你说清楚之前，它分不清哪边是正版。
- 放行 draft 或
noindex页。 搜索引擎抓了，再发现 404 或带noindex，就开始抱怨。 - 每个 URL 的
lastmod都一样。 Google 不再信这个字段。确切修法见 sitemap lastmod 总是今天。 - 翻译内容缺
hreflang对。 Search Console 会很晚才标；Codex 在构建期就能抓到。 - 修完忘了重新提交。 如果页面还是不出现，见 sitemap 已提交但未被索引。
FAQ
- 几万个 URL 怎么办？: 抽样。让 Codex 在随机 100 个 URL 上验证规则，报模式而不是逐条。如果单个文件逼近 50,000 个 URL 或 50 MB 上限，就拆成 sitemap 索引——Codex 能在源上帮你搭好这个拆分。
- Codex 能直接修，不只是报告吗？: 能。让它改源生成器，再用
/review扫一遍 diff，然后开一个 PR，像任何 PR 一样审。 - Codex 也查 robots.txt 和 meta noindex 吗？: 那是相邻议题。单独开一条 prompt；一个正确地从 sitemap 排除掉的
noindex页其实没问题，把两个审计混在一起只会让结论变浑。见 robots meta 与 sitemap 冲突。 - 我的 sitemap 来自 CMS 插件，Codex 还能用吗？: 能。它审生成的产物和插件配置。源修在配置里，绝不在生成的 XML 里。
- 该用哪个 Codex 模型？: GPT-5.5（2026 年 6 月的默认）就够了。这个任务是对文本文件做推理，不是重型代码生成，所以调低 reasoning 等级能更快。