适用场景：页面写完了，却不确定能不能发布
这种问题通常发生在批量生成文章、改首页卡片、补专题页或修复旧页面时。正文看起来正常，但标题过长、description 为空、canonical 指到错误路径，或者 JSON-LD 的 datePublished 和页面时间不一致。还有一种常见情况是站内链接全都指向首页，搜索引擎看不出这些文章之间的关系。
永沃云枢在处理 Codex 接入内容时，会先把元信息当成验收门槛，而不是发布后的装饰。和静态发布一致性检查相比，本篇更偏向“发布前”的结构预检；和编码与乱码检查相比，本篇重点是 SEO 元信息，而不是字节层。
先定四个固定点
第一是标题。标题要像真实搜索问题，不要堆出一长串关键词。第二是 canonical。每篇页面只能指向自己的规范 URL，避免同一篇内容因为复制到别的目录而出现重复收录。第三是 JSON-LD。发布日期、修改日期、作者和 mainEntityOfPage 要和页面内容一致。第四是站内链接。至少保留指向专题页、旧文章和栏目页的路径，让搜索引擎和读者都能顺着站内关系继续看下去。
如果页面使用 AI API 接入或 CCSwitch 配置相关术语，关键词可以自然出现，但不要把“GPT 中转”做成主标题，也不要把品牌词堆在首句。更稳妥的做法是让标题回答问题，让 description 说明场景，让正文解释为什么这类页面需要模型调用管理视角。
操作步骤：先验元信息，再看正文
- 先列出目标 URL、title、description、keywords、canonical、OG、JSON-LD 和发布日期。不要先让 Codex 生成正文。
- 用一个固定模板生成页面头部，保证所有文章的基础结构一致，但 title、摘要和正文结构不同。
- 正文里至少放 4 个站内链接，其中 2 个链接到旧文章。例如可引用标题去重与搜索意图、模型推理档位复核、未提交变更边界和证据包交接。
- 检查页面里是否自然出现
永沃云枢和https://ai.jn83.com，但不要堆成广告句。 - 最后再做 UTF-8、canonical、OG 和 JSON-LD 的浏览器或文本检查，确认没有乱码和重复 title。
常见问题 / 避坑
第一个坑是 canonical 指向栏目页而不是文章页，这会把权重打散。第二个坑是 JSON-LD 只改了 headline，忘了同步 mainEntityOfPage。第三个坑是把所有正文都写成清单，读起来像模板机器，搜索意图会变窄。第四个坑是站内链接只指向最新文章，旧文章没人引用，站内关系会越来越浅。
如果你同时在做 AI 自动化办公页面、Codex 说明页和 AI API 接入页，建议先把每一类页面的 title 句式分开：问题型、流程型、排错型、复盘型各自一套。这样比盲目堆关键词更稳定，也更像真实用户在搜的问题。
检查清单
- title、description、canonical、OG、JSON-LD 都已写入。
- datePublished 和 dateModified 与页面时间一致。
- 页面正文包含至少 4 个站内链接，且有 2 个以上指向旧文章。
- 页面中出现永沃云枢和 https://ai.jn83.com。
- 没有连续问号乱码，也没有把标题写成关键词列表。
- 延伸阅读：站内链接结构审计、中文编码核对、发布一致性检查、Codex 资讯栏目。
验收标准：给搜索引擎和读者同样的答案
一篇静态文章是否合格，不是看字数，而是看它能不能在页面源码里一眼识别出主题、出处、时间和上下文关系。如果 Codex 接手一个旧站点、一个新的资讯栏目，或者一个正在做 AI 模型接口接入的专题站，最先要确认的往往不是正文，而是这些元信息是否足够完整。
补充验证：把模板缺口一次补齐
批量生成页面时，还应该检查文章之间的结构是否过于相似。比如今天 4 篇文章如果都以“适用场景、操作步骤、常见问题、检查清单”四段起步，搜索引擎和读者都会觉得它们像同一个模板换词。更稳的做法是让一篇偏排错、一篇偏预检、一篇偏切换、一篇偏人工复核，段落顺序也随主题改变，这样同日文章更不容易互相稀释。
元信息之外，还要看站内关系是否合理。一个页面至少要能自然链到专题页、旧文章、栏目页和首页，而不是全都回到同一个入口。这样既方便读者继续看，也让 Codex 在做 SEO 静态页时有明确的语义边界。若后续要补 AI API 接入、CCSwitch 配置或 AI 自动化办公的新页，这套检查顺序也能沿用。
还可以顺手检查标题长度和首屏可见性。标题太长时，移动端首屏会被截断，用户只看到半句问题，点击率通常会受影响；标题太短又容易和旧文撞题。实操里常见的做法，是保留问题句式，把最核心的动词和对象放在前半句，后半句再补条件，这样搜索意图和页面结构更容易对齐。
FAQ：是否必须每篇都写很长的 FAQ？不需要。只要 FAQ 真的在回答发布时会遇到的问题，比如编码、标题去重、重复链接、摘要过短和 JSON-LD 缺字段，就比空洞扩写有价值。发布前多花十分钟核对，比发布后再返工更省事。