生成式引擎优化（GEO）不是堆关键词，而是一场关于“可核验性”的竞赛。GitHub 的 robots.txt 里曾经有一段针对 GPTBot 的禁止指令，后来又被移除。这个动作本身成了一场公开讨论：SaaS 软件的帮助页、更新日志到底该不该让 AI 爬？

无效动作长什么样

很多 SaaS 团队把产品更新写成营销软文，堆满“行业领先”“极致体验”这类词。页面看起来热闹，但生成式引擎根本不引用。因为它们要的不是形容词，而是能直接回答问题的数据、版本号、变更日期。GitHub 的 Changelog 页面不同，它用事实说话：每个版本对应哪些改动，哪些 API 被弃用，哪些问题被修复。这种写法不需要 AI 去猜，直接就能成为答案的一部分。

还有一种无效动作是只改首页 Banner。团队以为把“支持 AI 搜索”放在首页就能被引用，但首页往往没有具体信息，模型无法提取出可核验的答案片段。GitHub 没有靠 Banner，它靠的是每个更新条目里的具体链接和编号。

他们何时发现白做

2023 年，OpenAI 发布 GPTBot 抓取规范后，不少网站开始用 robots.txt 禁止 GPTBot。GitHub 也在名单里。但很快，团队发现这种做法没有带来任何可见度提升，反而让自家文档从生成式引擎的候选来源里消失了。用户问“GitHub 最近更新了什么”，AI 答不出，只能引用第三方博客的二手信息。那些博客往往过时或带有偏见。

于是 GitHub 调整了策略：重新允许 GPTBot 抓取公开的 Changelog 和文档页。这不是妥协，而是认识到生成式引擎已经成为开发者获取信息的重要入口。与其挡住，不如把页面做得更结构化、更可核验。

转向后的页面

GitHub Changelog 保持了一贯的格式：每个条目有标题、日期、标签（如“API”“Actions”“Enterprise”）。这种结构让模型能轻松提取“什么功能在什么时候变了”。页面没有华丽的交互，但每条更新都链接到对应的文档或 issue。模型引用时，能给出清晰的段落，而不是从一堆营销话术里拼凑。

另一个关键点是，GitHub 没有把 Changelog 藏在登录墙后面。公开访问让 GPTBot 和用户都能直接看到。SaaS 团队常犯的错误是把更新日志放在需要登录的后台，AI 爬不到，自然无法引用。

现在能核对什么

你可以直接查看 GitHub 的 robots.txt，确认 GPTBot 是否被允许。也可以搜索“GitHub Changelog”加上一个具体功能名，看生成式引擎的答案是否引用了官方页面。更重要的是，检查你自己的 SaaS 网站：robots.txt 有没有误伤 GPTBot？更新日志是不是公开的？页面里有没有具体的日期和版本号？这些都能用工具核验。

避免重蹈的步骤

第一，别再用软文写产品更新。每个条目至少包含一个可核验的事实：日期、版本、具体改动。第二，检查 robots.txt，确保 GPTBot 没有被禁止。第三，把更新日志从后台移到公开页面，并保持稳定的 URL。第四，在页面里加入结构化数据，如 schema.org 的 Article 或 SoftwareApplication。第五，定期用生成式引擎测试自己的品牌词加 “更新”，看是否被正确引用。

还容易问的

很多人问，robots.txt 禁止 GPTBot 会不会影响传统 SEO？答案是：不直接影响传统搜索排名，但会减少生成式引擎的引用机会。还有人问，是不是所有页面都应该允许 AI 爬？不是，涉及用户隐私或内部数据的页面仍应禁止。只把公开的帮助文档、更新日志、API 参考开放给 GPTBot 即可。

GitHub 的案例说明，SaaS 软件要进入“最佳工具”类生成式答案，先得让模型能找到并读懂你的页面。这与GEO 的核心一致：可核验、结构化、公开访问。如果你还不清楚 GEO 和传统 SEO 的区别，可以看这篇对比。