AI平台文档在浏览器里能看，为什么抓取后只剩导航？

公开文档在开发者电脑上显示完整，另一套工具取回页面却只有导航、页脚和“加载中”。这不一定是工具不会理解内容，可能是正文要等脚本请求接口后才出现。先检查文字在哪一层交付，再判断需要调整渲染还是修复访问条件。

挑一条关键事实，追踪它出现的位置

不要只找品牌名。选择一个能代表正文的具体片段，例如某版本支持的输入格式、接口限制或错误处理说明。记录准确URL和版本，然后依次检查：

1. 服务器最初返回的HTML是否包含这条事实。
2. 它是在可见正文元素里，还是只在脚本中的序列化数据里。
3. 浏览器执行脚本之后，正文是否实际出现，是否仍对应同一个版本。

源码中搜索到一个词，只能证明这些字节存在。若它藏在配置对象、脚本字符串或未展示的模板中，还要检查读者能够看到的正文。反过来，初始HTML没有这句话，也不能直接得出所有搜索系统都读不到它。

把“加载后出现”与“只有登录后出现”分开

用未登录的新浏览器上下文访问同一地址。如果只有开发者自己的登录状态能看到说明，应先确认这份资料本来是否允许公开。客户专属配置、访问令牌与内部接口文档，不应为了可检索性开放。

对于确实公开的文档，再看关键请求是否成功、资源是否被访问策略拒绝，以及接口返回的版本是否正确。页面返回200可能只是外壳成功，并不表示正文请求成功。故障记录应写清“外壳正常、正文依赖失败”，不要笼统写成“网站没问题”。

Google的处理能力不能推成所有AI工具的能力

Google的JavaScript SEO说明区分抓取、渲染与索引，并解释应用外壳可能需要执行脚本才能取得正文；文档同时提醒，不是所有机器人都能运行JavaScript。这支持对照初始响应与渲染内容，不能证明某个AI产品已读取当前页面。

光算的页面渲染与抓取内容核对指南也以“关键事实在哪个版本里”为排查起点。把公开的版本说明、输入限制和基本使用条件直接交付在HTML正文中，可以减少对特定客户端能力的依赖，但不构成收录或引用保证。

修复方案要照顾更新一致性

稳定文档可以考虑构建时生成完整内容，经常变动的内容可评估服务端交付；交互式示例仍可在客户端运行。选择取决于系统结构和更新流程，不必为了一个缺失段落重写整个站点。

真正容易漏掉的是双版本：初始HTML写旧限制，脚本启动后替换成新限制。验收应同时核初始正文与最终正文，确认缓存更新和版本路由一致。不能把旧内容留给不执行脚本的访问者，只给普通浏览器展示新说明。

给工程任务附一条可复测的要求：“在未登录情况下直接访问指定版本URL，初始正文包含已确认的限制说明；脚本运行后仍显示同一事实，示例交互可以单独失败而不掩盖文档。”这比“让AI看见我们”更容易实施和验证。

完成后分别记录内容可读、访问正常与平台实际收录的证据。前两项可以自己核查；第三项需要相应平台的真实反馈，不能拿本地请求成功代替。