一句话：如果你的内容只在 hydration 之后才存在，Google 通常仍会收录它，而多数 AI 检索代理看到的是一个空壳——所以「Search Console 很干净」不能证明答案引擎读得到你的站。
为什么这是最少被诊断出来的故障
你用来检查站点的一切都执行 JavaScript。浏览器会，预览工具会，排名追踪工具多半也会。所以一个客户端渲染的页面从你日常所处的每一个视角看都完全正常，而这里唯一重要的那个消费者——取原始 HTML 的检索代理——恰好是你从不模拟的那个。
关掉 JavaScript 打开自己的页面。你看到的就是模型看到的全部。
它的几种形态
| 形态 | 代理拿到的是 |
|---|---|
| 客户端路由的 SPA | 只有外壳——而且常常每个 URL 都是同一个外壳 |
挂载后在 useEffect 里取内容 | 标题和版式，没有实质 |
| 价格或参数在交互时才从 API 加载 | 这张页面看起来根本没有价格 |
| FAQ 由组件渲染 | FAQPage 结构化数据描述的内容不在 HTML 里 |
| 无限滚动或「加载更多」 | 永远只有第一批 |
怎么办，按优先级
- 把实质内容服务端渲染。想被引用的东西用静态生成或 SSR。这是真正的修复，其余都是缓解。
- 做不到的话，把关键事实提到初始 HTML 里。价格、定义、每个标题下那段答案——哪怕是以纯标记的形式和交互版本并存。
- 永远不要把答案藏在交互后面。折叠块和标签页作为视觉形态没问题，前提是内容在 HTML 里、只是用 CSS 收起来了。
- 别指望用结构化数据补偿。给页面从不渲染的内容加 FAQPage 标记，描述的是一张不存在的页面；而一个把标记和渲染内容对照的系统，有理由两个都不信。
怎么正确验证
关掉 JS 取一次，读 body 的文本——不是开发者工具里的 DOM，那显示的是 hydration 之后的状态。然后用每个点名的 AI 代理身份各做一次，因为有些源站会按 User-Agent 返回不同的 HTML，偶尔是无意的。把原始 HTML 的字数与读者看到的对比，差距大本身就是结论。
一条诚实的补充
有些代理确实会执行 JavaScript，而且厂商行为会变。但把方案建立在「它们会」这个假设上，是一个你无法验证也不必去下的赌注——因为修复方式（把重要内容放进 HTML）对你站点的任何一类消费者都没有坏处，包括网速慢的真人。