为什么你的AI抓不到页面内容？从Vue渲染到SSR直出的一次工程实践总结

ECOSYSTEM 易科势腾

为什么你的AI抓不到页面内容？从Vue渲染到SSR直出的一次工程实践总结

2026-04-22 技术文章

在企业官网 AI 化改造过程中，我们发现一个非常典型但容易被忽略的问题：

同一篇页面内容，在不同访问方式下，返回结果可能完全不同。

浏览器访问：内容完整展示
AI 抓取请求：
- 有时可以获取正文
- 有时只返回一个几乎空的 HTML 结构

在对抓取链路进行排查（包括网络、请求频率、渲染方式等）后，最终定位到问题核心：

👉 前端渲染模式导致页面内容在 AI 侧“可见性不稳定”

这个问题在传统 SEO 体系中并不突出，但在 AI 搜索场景下，会直接影响：

👉 内容是否能够被模型理解，甚至是否“存在”

在我们推进企业官网 AI 友好化改造（易科势腾内部实践）过程中，这类问题往往是第一道技术门槛。

一、问题复现：同一页面，两种完全不同的结果

为了验证问题的稳定性，我们做了一个简单测试：

👉 将同一个产品页 URL，交给不同 AI 工具进行总结

结果非常一致：

✅ 服务端渲染页面（SSR）

能稳定获取正文内容
可完成摘要
在部分场景下可作为引用来源

⚠️ 前端渲染页面（Vue SPA）

常见返回：

页面信息不足 / 未识别到有效内容

这里有一个关键认知需要明确：

与其说 AI“抓不到内容”，不如说在前端渲染模式下，页面内容对 AI 而言是不稳定可见的

二、问题本质：AI拿到的不是你看到的页面

将页面原始 HTML 输出后，问题就非常清晰：

<div id="app"></div>
<script src="/assets/index.js"></script>

真实内容依赖前端 JS 执行：

fetch('/api/product/123').then(render)

👉 浏览器可以执行 JS，因此页面正常
👉 但大多数 AI 抓取流程：

不执行 JS
或执行能力有限
或出于成本考虑不会完整执行

👉 最终结果：

AI获取到的是“初始HTML壳”，而不是“渲染后的页面内容”

三、一个常见误区：仅靠 Schema 并不能解决问题

在优化过程中，一个常见思路是：

👉 增加结构化数据（Schema / JSON-LD）

<script type="application/ld+json">
{
  "@type": "Product",
  "name": product.name,
  "description": product.desc
}
</script>

但在前端渲染模式下，这里存在一个关键问题：

👉 Schema 本身也是通过 JS 注入的

在 AI 抓取阶段，可能出现：

👉 既拿不到正文，也拿不到结构化数据

因此真正的关键不在于“是否有结构化数据”，而在于：

👉 结构化信息是否在 HTML 返回阶段就已经存在

四、关键认知：AI不是在调接口，而是在解析HTML

在大多数实际场景中：

AI不会调用你的 /api/* 接口
它会请求页面 URL
然后直接解析 HTML

👉 因此问题可以被重新定义为：

你返回的 HTML，是否已经是“完整语义内容”

五、工程解法：SSR直出，让内容天然可见

针对这一问题，我们采用了一种更稳定的工程策略：

👉 服务端渲染（SSR）直出内容

示例（Spring Boot + 模板渲染）

Controller

@GetMapping("/product/{id}")
public String productPage(@PathVariable Long id, Model model) {

    Product product = productService.getById(id);
    model.addAttribute("product", product);

    return "product";
}

HTML 模板

<h1 th:text="${product.name}"></h1>

<p th:text="${product.description}"></p>

<h2>适用场景</h2>
<p th:text="${product.scene}"></p>

同步输出结构化数据

<script type="application/ld+json">
{
  "@type": "Product",
  "name": "[[${product.name}]]",
  "description": "[[${product.description}]]"
}
</script>

👉 改造后的效果：

HTML 即最终内容
不依赖 JS 执行
AI 可直接解析

可以总结为一句工程原则：

👉 把“运行时生成内容”，前置为“返回即存在内容”

六、从AI-CMS到GEO：一个容易被忽略的分层

在完成页面可见性改造之后，我们进一步拆解了一个关键问题：

AI-CMS = 内容生产与管理能力
GEO    = 内容被AI引用与排序能力

👉 AI-CMS解决的是：

内容有没有
能不能检索
能不能生成

👉 GEO解决的是：

AI是否会选择你的内容
是否会出现在答案中
出现的位置和权重

而“页面是否可见”，实际上是两者之间的前置条件。

七、GEO的工程化拆解（核心指标落地）

在实践过程中，我们将 GEO 拆解为五个可工程化的指标：

1️⃣ 提及率（Mention）

👉 是否存在足够多“可被引用的内容片段”

工程手段：

FAQ结构化拆分
多页面内容分布
语义自然覆盖

2️⃣ 位置（Position）

👉 信息是否出现在高权重位置

工程手段：

标题层级（H1 / H2）
首屏核心信息前置
语义结构清晰

3️⃣ 上下文权重（Context）

👉 内容是否完整、自洽

工程手段：

chunk切分策略
检索召回质量
上下文拼接优化

4️⃣ 可信度（Trust）

👉 AI是否“信任该内容来源”

工程手段：

公司信息一致性
多页面交叉验证
内容稳定输出

5️⃣ 结构化程度（Structure）

👉 AI是否容易解析内容

工程手段：

SSR输出
JSON-LD
Schema.org

👉 从工程角度来看：

GEO并不是营销问题，而是内容结构、页面结构与数据结构的组合问题

八、对后端的三个直接影响

这次实践带来的变化，其实更多发生在后端层。

1）接口设计：不再只面向前端

过去：

👉 返回 JSON 即完成职责

现在需要考虑：

是否支持HTML生成
是否适配结构化输出

2）数据结构：不再只是存储

过去：

👉 面向存储与展示

现在需要支持：

chunk切分
FAQ结构
可引用片段

3）页面输出：不仅是展示层

过去：

👉 面向用户

现在：

👉 同时面向 AI

九、实践中的一个结论（AI友好化改造视角）

在易科势腾推进 AI 友好化改造的过程中，我们逐渐形成一个共识：

👉 页面可见性，是所有AI能力的基础设施

在很多项目中：

RAG能力已经具备
知识库已经建立

但如果页面层仍然是“不可见”的：

👉 上层能力很难真正产生外部价值

像本文提到的：

SSR直出
Schema结构化
页面语义优化

本质上是在解决同一个问题：

👉 让内容稳定进入 AI 解析链路

十、边界说明（工程现实）

需要说明的是：

并不是所有 AI 系统都完全无法解析前端渲染页面。

部分具备浏览器能力的抓取流程，在特定场景下可以执行 JS。

但从工程实践来看：

成功率存在波动
抓取成本较高
不适合作为核心依赖路径

👉 更稳定的方式仍然是：

在HTML返回阶段即提供完整内容

十一、当前阶段 & 下一步

目前这套方案已经在基础场景中验证可行，但仍在持续优化：

schema自动生成
内容结构标准化
页面语义增强

下一阶段更关注的是：

👉 AI为什么会优先选择你的内容

对应更深一层问题：

内容权重分配
引用概率建模
多模型适配机制

一个工程视角的小结

在 AI 时代，很多问题不再是“能不能做”，而是：

👉 内容能不能被稳定获取
👉 信息能不能被可靠引用
👉 系统能不能被持续信任

如果你也在做 AI 知识库、RAG 或官网改造，可以交流一下你们在“前端渲染 vs AI抓取”这块的处理方式。