SSR / SSG（服务端渲染/静态生成） Server-Side Rendering / Static Site Generation

SSR（Server-Side Rendering，服务端渲染）与 SSG（Static Site Generation，静态生成）是两种“让内容先于浏览器存在”的渲染方式：前者由服务器在每次请求时生成完整 HTML，后者在构建期就把全部页面产出为静态文件。它们与 GEO 的关系可以用一句话说尽——主流 AI 爬虫普遍不执行 JavaScript，页面内容必须出现在抓取器拿到的那份原始 HTML 里，否则对 AI 引擎近乎不可见。渲染方式在传统 SEO 里是性能与工程取舍题，到了 GEO 语境里，它升级为内容能否进入 AI 检索库的准入题。

三种渲染路径：内容在哪个环节变成 HTML

把前端常见的渲染路径放到一条时间轴上看，差别只在“内容成形”发生在哪一刻。CSR（Client-Side Rendering，客户端渲染）把页面组装放进浏览器：服务器先交出一个近乎空白的 HTML 壳和一批 JavaScript 脚本，浏览器下载并执行脚本之后，内容才被画出来，单页应用（SPA）是典型形态。SSR 把这一步挪回服务器：每次请求进来，服务器现场渲染出包含全部内容的 HTML，浏览器拿到的第一份响应就是完整页面，脚本只负责其后的交互。SSG 再往前挪一步：在站点构建时把每个页面生成静态 HTML 文件，部署后直接分发，内容生成与用户访问彻底解耦。

一个常见误会要先澄清：SSR 与 SSG 不等于“没有 JavaScript”。SSR 页面通常仍附带脚本做水合（hydration），接管按钮、表单这类交互；真正的差别在于核心内容不依赖脚本执行——爬虫不跑 JS 也能拿到全文。判断标准从来不是“用没用 JS”，而是“关掉 JS 之后正文还在不在”。

从业者的常见问题“SSR 和 SSG 哪个对 GEO 更好”，答案是对爬虫完全等价：两种路径下抓取器拿到的都是含正文的 HTML，引擎不关心这份 HTML 是请求时现生成的还是构建期备好的。差别全在工程与运营侧——SSR 每次请求都要付出渲染成本，适合内容随用户或参数变化的产品页与详情页；SSG 把成本前置到构建期，适合成批更新、访问量大的内容页。两者也常混用：内容区做静态生成、搜索与个人化接口做服务端输出，再用 CDN 把动态渲染的结果缓存成事实上的静态，是内容站最常见的组合。

AI 爬虫为什么普遍不执行 JavaScript

这条结论的一手来源是 Vercel 对其托管网络的实测：GPTBot、ClaudeBot、PerplexityBot 等主流 AI 爬虫都不执行 JavaScript，唯一的例外是 Gemini——它借 Googlebot 的渲染管线，等于用了别人家的浏览器（研究档案见 Vercel：AI 爬虫崛起报告）。

机制层面并不费解。执行 JavaScript 意味着爬虫方要为每次抓取启动一个完整的浏览器环境，等待脚本运行、等待脚本再去拉数据，资源与时间开销远超取回一份现成 HTML。搜索引擎愿意为渲染付这笔钱，因为渲染后的页面质量直接服务于自家的搜索结果；而训练与检索用途的 AI 爬虫要的是大规模、低成本地搬运语料，渲染这道工序既非必要也难以负担（爬虫按用途分层的逻辑见 训练·检索·用户触发爬虫（三型），整体图景见 AI 爬虫（AI Crawlers / Bots））。

抓取量级可以佐证这个判断的分量：据 Vercel 2024-12 的单月口径，GPTBot、Claude、Applebot、PerplexityBot 四家 AI 爬虫的月请求合计约为 Googlebot 的 28%——在这样的规模上给每家爬虫都配浏览器渲染，成本会先于收益失控。同一份报告还带出一条与渲染同层的教训：ChatGPT 有 34.8% 的抓取浪费在 404 页面，Googlebot 仅 8.2%——在 AI 爬虫只看第一份响应的世界里，死链与空壳页的代价同样被放大（对照详见 四大 AI 爬虫月请求合计约为 Googlebot 的 28%）。

自查清单：你的核心内容在「裸 HTML」里吗

对 GEO 从业者，这条实证的直接动作是一套三步自查。第一步看源码：在浏览器里查看网页源代码，搜一段只有正文里才有的文字，搜得到说明内容在原始 HTML 里，搜不到多半是 CSR 壳。第二步禁用 JavaScript 后重载页面：内容仍在，则对不执行脚本的爬虫安全；页面变空白或只剩导航，问题确诊。第三步查服务端日志：按 User-Agent 过滤出 AI 爬虫的请求，确认它们拿到的是 200 且含正文的响应，而不是壳页、跳转链或 404。

日志排查时，认爬虫靠 User-Agent 字符串加行为特征：GPTBot、ClaudeBot、PerplexityBot 各有公示的 UA 与抓取档案，其中 Perplexity 一类的自建索引爬虫对内容方尤其关键——它是进入对方引用池的入场券，抓取节奏直接反映你在其索引里的存在感（识别与排查顺序见 PerplexityBot）。同时要留意 UA 可以伪造：日志里核对请求来源与行为是否符合官方档案，再决定放行或封禁，别把伪装成爬虫的采集流量当成引擎的到访。

自查里最容易误判的是“Google 收录正常，AI 应该也没问题”。Google 有渲染队列，能对 JS 页面二次渲染后再入库；多数 AI 爬虫没有这道工序，Gemini 的例外恰恰因为借道 Googlebot。所以搜索表现良好推不出 AI 可见，两个口径要分开验。另一个盲区是“看得见却进不来”的内容：正文藏在登录视图之后、由前端异步拼装、或被 robots 规则与反爬策略挡在门外——每一类都要在自查清单里单独过一遍。

动态渲染兜底：能用，但要离 cloaking 远一点

对存量单页应用改造成本高的站点，行业里的传统解法是动态渲染：识别到爬虫 UA 时返回预渲染的 HTML，普通用户仍走 JS 应用。它在功能上能解决“被读到”，我们的口径仍把它定位为兜底而非架构——两套输出长期并行，内容漂移几乎不可避免：预渲染版本停在旧数据、用户版本持续更新，爬虫与用户看到的差异越积越大，排查成本也随之上涨。

更要紧的是合规边界。给爬虫与用户返回不同内容，在搜索引擎的规则里本来就是敏感区：两套输出若只是同一内容的不同呈现，通常被当作技术实现细节；若差异演变成爬虫看到一版、用户看到另一版，就滑向 cloaking（内容门禁欺骗）的红线，而这类手法在 GEO 语境里被各平台明令禁止（边界与判定见 Cloaking（内容门禁欺骗））。务实做法是把动态渲染当迁移期的过渡：用它争取时间，同时把站点逐步迁到 SSR 或 SSG，让同一份 HTML 对所有访问者成立。

迁移的次序也有讲究。先把最值钱的内容页——定义型、指南型这类被引用潜力最高的资产——静态化或服务端化，让核心内容先恢复可见；再处理列表与详情模板；纯交互页最后处理或维持现状。每迁一批，就回到三步自查复验一次，用日志确认 AI 爬虫真的拿到了正文。迁移的验收标准不是“改完了”，而是“爬虫视角下内容回来了”。

本站为什么选纯静态

GEO研究自身就是这条实证的直接应用：站点用 Astro 做纯静态生成，每一页都是构建期产出的完整 HTML，正文零 JavaScript 依赖，全站唯一的脚本是明暗主题切换。选这条路线的理由与本卡主题一一对应——不赌任何爬虫的渲染意愿，不维护两套输出，构建期就保证每一页都先于访问者存在，没有渲染失败的窗口期。

静态路线的附带收益也与 GEO 的目标同向：静态文件可全量铺到 CDN，响应快而稳；构建期生成意味着内容一经发布即是最终形态，AI 爬虫无论何时到访，取到的都是同一份完整页面。以内容为资产的站点，这是渲染决策里风险最低的一档；交互重、个性化强的产品页面，SSR 加受控的渐进增强是比 CSR 稳妥的折中。无论选哪条路线，验收标准不变：裸 HTML 里必须有正文。