在讨论引用之前，GEO 先要解决一个技术条件
如果一条事实只能在 JavaScript 执行后才出现，AI Agent 可能根本收不到它。
这包括产品能力、对比结论、价格条件、文档答案、作者资料，以及你希望被 AI 引用的证据。用户在 Chrome 中能看见完整页面，并不代表爬虫、正文提取器或浏览 Agent 取得了同样的内容。
一项来自 SEO 从业者的测试把页面原始 HTML 与渲染后的页面逐模板比较。文章、教程、商店、课程、落地页和分类页中，大部分可见内容已经写入 HTML，只有少量内容依赖 JavaScript 才出现。重点不在那个具体比例，而在它提出的问题：首次返回的 HTML，是否已经包含你希望 Agent 理解的答案？
对 GEO 来说，这是资格检查。系统必须先能抓到页面的核心事实，才谈得上评估证据或决定是否引用。
不同访问路径可使用的 JavaScript 能力不同。原始抓取和正文提取通常只能依赖 HTML 响应。
Google 能渲染，不代表每个 Agent 都会渲染
“Google 能渲染 JavaScript”是事实，但它常被错误地延伸为：每个 AI 搜索产品和 Agent 都会看见最终浏览器页面。
同一个 URL 可能通过不同路径被访问：
| 访问路径 | 实际拿到的内容 | 对 JavaScript 的依赖 |
|---|---|---|
| 原始 HTTP 抓取 | 初始 HTML 响应 | 不执行 |
| 阅读器或正文提取器 | 从 HTML 选出的文本 | 通常不执行 |
| 浏览器自动化 | 渲染后的 DOM | 可能执行，但受超时和策略限制 |
| 搜索索引管道 | 抓取、排队、可能再渲染 | 取决于平台 |
| 工具调用型 Agent | 其网页抓取工具输出的文本 | 常接近原始抓取 |
Google 的渲染能力并不是可移植的承诺。其他答案引擎、企业内部检索、浏览 Agent 和网页提取工具，可能只取 HTML，也可能在客户端数据加载之前停止。把某个平台的能力当作网站架构前提，是一次没有必要的赌注。
更稳妥的原则很简单：关系到发现与引用的公开事实，应当在首次响应中就可读。
不要审计框架，要审计事实出现在哪一层
SSR 与 CSR 不是 GEO 成绩单。React、Vue 或 Next.js 网站可以对 Agent 友好；传统服务端渲染的网站也可能把关键信息藏在客户端 API 调用之后。
应审计每个重要内容块在哪一层才变得可用。
| 内容层级 | 常见示例 | GEO 风险 |
|---|---|---|
| 初始 HTML | 标题、正文、规格、FAQ、作者、日期 | 低 |
| 服务端获取后输出的 HTML | 当前价格、地区可用性 | 低到中 |
| 客户端 API 请求 | 产品卖点、对比表、文档正文 | 高 |
| 用户交互后显示 | Tab、折叠面板、筛选、无限滚动结果 | 高 |
| 登录后可见 | 仪表盘、私有知识库 | 不应期待公开引用 |
如果你希望 AI 在公开回答中复述一项事实，它不应依赖用户点击、客户端请求成功或漫长的 JavaScript 任务。交互可以保留，但解释性内容必须前移。
最常见的失败包括：只返回加载壳的产品页、在 hydration 后才显示表格的对比页、由客户端路由加载正文的文档、仅靠无限滚动的分类页，以及结论只存在于图片或 Canvas 中的视觉模块。
渲染后页面再漂亮，也可能在首次 HTML 响应中暴露了太少的语义信息。
用“双视图”检查代替主观判断
不要问网站“是不是用了 React”。请保存同一个 URL 的两个版本：
- 不执行 JavaScript 时抓到的原始 HTML。
- 在浏览器中打开页面、等待主内容出现后导出的
main文本。
基础抓取可以从下面开始：
curl -sL "https://example.com/product" -o raw.html
比较时关注语义内容，不要把页头、Cookie 横幅和页脚混进去：
- H1 和简短回答
- 第一段解释
- 产品事实与限制条件
- 对比表
- FAQ 答案
- 作者和更新时间
- 内部链接与 canonical URL
不要只用 networkidle 作为浏览器完成条件。分析脚本、客服组件和长连接会让页面一直“忙碌”。更好的条件是主内容选择器出现，或供应核心事实的特定数据源已经完成。
可以把这个对比变成发布指标：
核心内容暴露率 = 原始 HTML 中已有的关键内容块 / 页面必须具备的关键内容块
目标不是把每个像素都塞进 HTML，而是保证理解页面所需的证据不依赖客户端运行时成功。
先修内容交付路径，不必重写整个前端
多数团队不需要全站重构。应把稳定的公开信息放进首次响应，同时继续让 JavaScript 负责筛选、保存偏好、地图、动画和个性化。
| 页面情形 | 更合适的交付方式 |
|---|---|
| 稳定的文章、教程和词条页 | 静态生成或构建时预渲染 |
| 经常变化的价格、库存或地区信息 | 服务端渲染，加缓存和明确的失效策略 |
| 高交互页面但说明内容稳定 | 服务端输出说明、事实和 FAQ；客户端再水合交互 |
| 大型应用内的公开文档 | 预渲染公开路由，核心答案不依赖登录态 |
| 多个内部 API 共同供数 | 在服务端或 BFF 层聚合关键数据，供 HTML 和应用共享 |
JSON-LD 有帮助，但它不能替代可阅读的页面正文。结构化数据应描述访问者和提取器也能在文档中找到的事实。
GEO 团队的两周执行节奏
第 1-2 天：列出驱动自然发现、AI 引用、销售支持或客户支持的模板。文章、产品页、文档、对比页和分类页通常足够。
第 3-5 天：每类模板抽样 URL，保存原始 HTML 与渲染内容，标记缺失的 H1、解释、产品事实、FAQ 和内部链接。
第 6-9 天：优先修复价值最高、内容最稳定的页面。将定义、事实、对比结论和 FAQ 移入服务端或构建产物。
第 10-14 天：重复相同测试，并添加发布门禁。如果初始 HTML 缺少 H1、主答案、关键事实或 canonical 链接，模板不应发布。
这不能保证每个 AI 产品都会引用你，但它消除了一个本不该存在的失败模式：公开信息无法被潜在 Agent 稳定读取。
Auspia 的观点
GEO 通常从品牌提及、来源质量、实体清晰度和答案结构开始讨论。这些都默认系统已经获得了页面。
JavaScript 本身没有问题。把公开解释当作客户端运行时的副产品，才是问题。HTML 应承担内容责任，JavaScript 应承担体验责任。这样的分工也会改善测试、技术 SEO 与 Agent 可访问性。
FAQ
Google 能渲染 JavaScript，还需要审计原始 HTML 吗？
需要。Google 的能力不代表其他爬虫、阅读工具和 Agent 走同一条路径。原始 HTML 检查还能暴露渲染延迟和客户端请求失败，便于技术排错。
对 GEO 来说，SSR 一定比 CSR 好吗？
不一定。静态生成、服务端渲染和预渲染都可以；高交互元素仍可使用客户端渲染。判断标准是公开页面的核心事实是否已在首次 HTML 响应中可读。
页面所有部分都要避免 JavaScript 吗？
不需要。筛选、动画、地图、保存设置、个性化和登录体验都可以继续使用 JavaScript。应优先保障解释页面主题、提供可引用事实的内容。
llms.txt 能解决只靠 JavaScript 显示的内容吗？
不能。即使某系统读取 llms.txt，它也不会自动取得完整正文或客户端 API 数据。公开页面本身仍必须提供可访问的核心内容。
来源说明
本文由 Adrian Skowron 的 SSR 与 CSR 可见内容对比推文 引发。推文中的图表反映作者对自身页面模板的测量，不是行业通用 benchmark。
作者：Julian Mercer，Auspia 14 年技术 SEO 实践者。Julian 关注爬取、渲染、结构化数据，以及让搜索与 AI 系统理解内容的技术基础。
