文章写进数据库、页面返回 200，只能证明内容已经上线；它不等于搜索引擎已经发现、抓取、索引，更不等于生成式引擎已经检索或引用。稳定的发布系统至少需要四条互补发现链：正文和相关推荐提供主题内链，XML Sitemap 提供完整 URL 与真实更新时间，RSS 提供最近内容流，IndexNow 向支持该协议的搜索引擎发送变更通知。四条链都应该在页面真实可访问后生成，并在上线后逐项验收。
一、为什么“有 URL”还不等于“会被发现”
爬虫可以通过外部链接、站内链接、Sitemap、Feed 或主动通知发现页面。新站外链少、内容更新频率低时，如果新文章只有一个不在导航里出现的孤立 URL，发现速度和抓取路径都会更不稳定。
这并不意味着提交越多越好。把同一条未变化的 Sitemap 每小时重复提交，不会强迫搜索引擎抓取；把草稿、私有报告或带搜索参数的重复页放进 Sitemap，只会扩大无效 URL 库存。
发布工程要解决的是两个问题：一是让重要页面至少有一条真实可抓取路径；二是让“新增或显著更新”以准确、可验证的方式送达。是否索引和展示仍由搜索系统决定。
二、第一路：主题内链负责语义与长期路径
Google 的链接指南明确，标准 <a href> 是最可靠的可抓取链接形式；内部链接的锚文本应该简洁、具体、能说明目标页是什么。对技术博客而言，页脚统一放“上一篇/下一篇”只能提供路径，未必提供主题关系。
更好的“相关阅读”至少考虑两个信号：
- 内容支柱是否相同，例如方法论、平台拆解、行业方案；
- 标签是否重合，例如 Sitemap、Schema、Google AI Mode。
同分时再保留发布时间或编辑置顶顺序。这样做不是训练一个推荐模型，而是用透明规则避免“文章 A 的相关阅读永远是全站最新三篇”。
正文里的上下文链接仍然最有解释力。比如本文提到文章元数据时，链接到《TechArticle 结构化数据工程：图片、日期、作者与面包屑怎样保持同源》，读者能预期下一页会讲什么。锚文本写成“点击这里”，则丢掉了这层上下文。
三、第二路：XML Sitemap 负责完整清单与真实更新
Sitemap 适合表达站点希望被索引的规范 URL。文章系统应从“已发布”数据查询生成条目，草稿和私有页面不能混入。每篇文章至少需要：
- 绝对 URL；
- 与页面一致的 canonical；
- 来源于真实内容更新时间的
lastmod。
Google 表示 lastmod 只有在持续准确、能够与页面实际变化核对时才有用。正文、结构化数据、重要图片或内链的显著变化可以更新它；版权年份或每日构建不应更新。
Sitemap 是提示。它不保证 Google 下载，不保证抓取，更不保证收录。正确口径应该是“新 URL 已进入 Sitemap”，而不是“Google 已收录”。
四、第三路：RSS 负责最近内容流
RSS 2.0 或 Atom Feed 能表达最近发布的文章，Google 也接受它们作为只覆盖近期 URL 的 Sitemap 形式。Feed 不需要替代完整 Sitemap；它们解决的问题不同。
一条可靠 RSS item 至少保持标题、文章 URL、永久 guid、发布时间和摘要一致。XML 特殊字符必须转义。站点 <head> 还可以放 RSS 发现链接，方便阅读器和工具找到 Feed。
Feed 的优势是“最近变化”紧凑，限制也是只覆盖最近一段内容。旧文章不能因为滑出最近 50 条 Feed 就从完整 Sitemap 和站内链接消失。
五、第四路：IndexNow 负责支持平台的变更通知
IndexNow 允许站点把新增、更新或删除的 URL 通知给采用该协议的搜索引擎。协议把 HTTP 200 定义为提交成功，把 202 定义为已收到、等待密钥验证。两者都不等于页面已进入索引。
还要明确平台边界：IndexNow 不覆盖 Google，也不覆盖百度。Google 仍依赖自己的抓取、Sitemap 与 Search Console；百度使用自己的搜索资源平台链路。把 IndexNow 成功响应写成“全网搜索引擎已收录”，是把通知层和索引层混在了一起。
发布脚本的控制流也要设计好：
- 先把文章事务性写入数据库；
- 确认公开页面和发现产物能读取这条记录；
- 再调用 IndexNow；
- 通知失败要记录并允许重试，但不应回滚已经成功发布的正文。
否则外部通知接口短暂超时，可能把内容发布也一起变成失败；读者看不到文章，运维还误以为数据库没有写入。
六、四路链路怎样组成一次原子发布
“原子”不代表所有外部平台同时完成索引，而是站内状态不能互相矛盾。一次发布应按下面顺序验收：
1. 预检文章本身
解析 frontmatter，检查 slug、标题、摘要、pillar、正文长度、唯一 H1、站内交叉引用和图片路径。公开正文中内部 citation 标签匹配必须为 0。
2. 构建并测试站点代码
文章页、Sitemap、Feed、llms.txt 和导入脚本属于同一个发布系统。先通过类型检查、契约测试和生产构建，再打包。新增运维脚本 import 时，发布包必须带齐模块依赖。
3. 切换可回滚的发布版本
在临时端口用真实生产环境预检，再切换线上版本和重启服务。页面代码需要先上线，因为新文章可能依赖新图片路径、元数据逻辑或渲染能力。
4. 正式入库
导入脚本用明确发布时间发布三篇文章。批量顺序可以用秒级差异保持稳定，但不应伪造不同日期。旧文重发必须保留原始 published_at。
5. 验收四路发现链
检查文章页和图片 200、canonical、H1、TechArticle 与 BreadcrumbList；确认三条 URL 出现在 Sitemap、RSS 与 llms.txt；查看 IndexNow 返回摘要；最后验证相关文章的服务端 HTML 确实包含主题内链。
《Google 2026 生成式 AI 搜索指南：没有特殊 Schema，真正该修的是哪六层》解释了为什么这些基础 SEO 仍然是生成式搜索的上游条件，也解释了它们为什么不能被写成引用保证。
七、发布记录应该怎样写，才不会误报
可以确认的状态：
- 页面已经上线并返回 200；
- canonical、H1、代表图和 JSON-LD 已通过渲染验收；
- URL 已进入 Sitemap/RSS/llms.txt；
- IndexNow 已返回 200 或 202；
- 主题内链已在服务端 HTML 出现。
不能从这些状态直接推出的结果：
- 搜索引擎已经抓取；
- URL 已进入索引；
- 页面在目标查询中成为候选；
- AI 已吸收、引用或提及；
- 发布带来了访问、询盘或收入。
后五项需要搜索平台、服务器日志、固定查询重复采样和分析数据分别验证。发布记录越精确，后续团队越容易定位问题是在发现、抓取、索引、检索还是业务承接。
八、一份可以自动化的验收清单
[ ] 三个文章 URL 返回 200
[ ] 每页只有一个 H1，canonical 指向自身
[ ] 正文每页至少三张真实图片，图片均返回 200
[ ] Open Graph 与 TechArticle 使用正文代表图
[ ] 日期、作者和面包屑与可见页面一致
[ ] Sitemap 包含三个 URL 和真实 lastmod
[ ] RSS 包含三个最新 item，XML 可解析
[ ] llms.txt 包含标题、URL 与摘要
[ ] 主题相关阅读是服务端 a[href]
[ ] IndexNow 返回结果已记录，但没有写成“已收录”这份清单把发布完成定义为“站内事实一致、发现入口已就绪、外部通知有记录”。它没有冒充搜索引擎的最终决定。
边界声明
- Sitemap、RSS 和 IndexNow 都是发现或更新提示，不保证抓取、索引、排名或 AI 引用。
- IndexNow 当前不覆盖 Google 与百度；各平台需要独立验证。
- 主题内链算法只提高相关性与可抓取路径的可解释性，不等于搜索排名实验。
- 本文流程适用于妙蛙 GEO 当前文章系统；其他 CMS 可以采用不同实现，但应保留同样的状态边界与验收证据。
本文事实资料来自 Google Search Central Sitemap 与链接指南、IndexNow 官方协议，以及妙蛙 GEO 当前文章导入、Sitemap、RSS、llms.txt 与 IndexNow 发布链。工程建议是对这些公开规范与本站实现的综合分析。
本文由妙蛙 GEO 研究团队撰写，使用 AI 辅助进行资料整理与语言校对，文中事实、来源和结论均经人工复核。