AI 爬虫抓不到正文里的答案，脚本渲染的页面怎么让它读到

AI 爬虫抓不到正文里的答案，多数不是被拦在门外，而是它取回的那份 HTML 里本来就没有文字：靠脚本渲染内容的站点，在不做脚本执行的抓取方面前等于空壳。让模型读到内容的第一步，是确认答案段落出现在初始响应里，而不是等浏览器跑完脚本之后才拼出来。可行的三条路是服务端渲染、构建期静态输出，以及把关键问答段落直接写进正文，站点说明文件解决的是导航，替不了渲染这一环。

抓取层看到的是什么

判断这个问题有个很直接的动作：用不带脚本执行的方式请求一次自己的页面，看返回的 HTML 里正文在不在。如果响应体里只有容器节点和脚本引用，文字要等浏览器运行脚本之后才出现，那么在只做”取回—解析”的抓取方眼里，这一页确实没有内容。这不是解析器出错，而是抽取以响应 HTML 为准，很多 AI 爬虫不会为你的页面专门跑一遍浏览器。

第三方 GEO 实践指南把这条列为常见失效原因，说法是零 JavaScript 执行：靠客户端脚本渲染内容的站点，AI 爬虫看到的是空壳。同一份指南还给出另一个前提：被引用的最小单位是段落而不是整页。两句话合起来的含义是，页面必须在初始响应里就给出成段的、可整段摘出的文字。

为什么脚本渲染读不到

浏览器渲染和响应渲染是两件事。前端框架把数据接口返回的字段填进模板，人看到的是组合后的结果；抓取方只取了组合前的那份 HTML。异步加载的正文、翻页后才出现的内容、点击展开的问答，都属同一类。判定标准可以简单到一句话：这段文字是不是在第一次响应里以可读文本存在。凡是”要点一下、等一会才有”的内容，抽取层都当不存在。

三条可行解法

第一条是服务端渲染：请求到达时在服务器上组装好正文再返回，成本是服务器压力与改造工作量。第二条是构建期静态输出：内容发布或更新时生成静态页，伪静态规则把地址维持成正常路径形态，抓取层拿到的就是完整正文，成本主要在生成时机与缓存刷新，对小流量站点最划算。第三条是保底冗余：把每条答案的关键段落写进正文节点，交互组件只负责增强阅读，不承担内容交付。三条的取舍看流量结构与更新频率，不看技术时髦度。页面加载速度在这里也有额外收益，静态输出的响应通常更短。

站点说明文件放在哪一步

llms.txt 解决的是另一件事：给大语言模型一份站点内容的导航说明，让它知道有哪些板块、去哪里读。它不能把空壳页面变成有内容的页面——如果正文本身取不到，说明文件只会把一个读不懂的地址清单交给模型。合理顺序是先确认响应里有正文，再生成 llms.txt，把精选入口交代清楚；它和负责链接发现的站点地图不冲突，一个交代内容结构，一个交代地址清单。

怎么验证改动生效

验证要落到能重复的动作：同一地址分别用带脚本执行和不带脚本执行的方式取一次，比对正文长度；抽查一批核心答案页，看首段是否完整出现在响应中；再看 AI 抓取来源的访问日志与 referral 分布，是否在改动后出现引用。内容结构层面，自定义内容模型可以让答案字段独立成块，避免把结论埋在大段样式标签里，抽取更稳定。

常见问题

问：只把正文放进 meta 描述里行不行？ 不够。描述字段用于摘要展示，长度受限，模型要引用的是成段结论，需要在正文节点里。

问：翻页后的内容抓不到怎么办？ 给每页独立的完整地址并在响应内输出该页正文，别让翻页只靠脚本请求接口。

问：llms.txt 写了就能被引用吗？ 它只负责交代内容结构。能不能被引用取决于页面是否给出可读、可整段摘出的答案。

问：怎么知道哪些页面是空壳？ 按模板批量拉一次初始响应，统计正文文本量，低于阈值的基本都依赖脚本注入。