GEO-007·第 01 期·技术底座·7 / 132
你的独立站，AI 能渲染吗
AI 爬虫多数不执行 JavaScript，客户端渲染的店铺在 AI 眼里可能只是一张白壳。本文拆开从响应到 DOM 的渲染链路，指出五个常见失败点，给出三种不用写代码的测试方法，并比较 CSR、SSG、SSR 与动态渲染的取舍。
本期主线入口迁移：AI 搜索如何重排海外电商流量
周一早上，一家做宠物饮水机的出海团队在 ChatGPT 里问“出差三天，猫的饮水机选哪个”。答案里有他们的品牌，后面却跟着一句“价格与保修信息未在页面上找到”。运营打开官网，价格明明就在首屏。开发按下 Ctrl+U 看源代码，HTML 里只有一行 <div id="root"></div> 和一段脚本——用户看得见的页面，爬虫从来没有看见过。
客户端渲染不会让用户察觉任何异常，却会让 AI 爬虫只拿到一个空壳：渲染不是性能问题，而是商品在 AI 眼里存不存在的问题。
渲染链路：AI 通常只走到第二步
用户看到的页面和爬虫收到的页面，不是同一个东西。浏览器要先下载 HTML，再执行 JavaScript、拉接口、拼出 DOM，最后才是你截图里的样子。爬虫拿到的往往只是第一步的响应。
各家 AI 爬虫的公开文档主要讲 UA、用途与 robots 语义，很少承诺执行 JavaScript（截至 2026-01，以各家官方文档为准）。Google 这边不一样：Googlebot 会渲染，但渲染要排队、有预算，Google 自己的 JavaScript SEO 文档也建议关键内容别只靠脚本。另外，Google-Extended 是控制内容用途的标记，不是另一套抓取能力，真正进来抓页面的还是 Googlebot。所以“Google 能渲染”推不出“所有 AI 入口都能渲染”。四个入口的取数方式本来就不同，这一层区别在AI 搜索的四个入口里拆过，但它们的起点相同：先拿到 HTML。
失败点集中在五处：首页与 PDP 是单页应用的空壳；价格、库存、运费、保修由接口在客户端注入；折叠参数与评论要点击、滚动才发请求；地区、币种、语言靠浏览器判断后再跳转；边缘防护对人机验证较严，非浏览器请求直接拿到挑战页，连空壳都没有。放行谁、怎么验证爬虫身份，可以对照AI 爬虫地图先排一遍。
判断只有一句：真正的问题不是“能不能渲染”，而是“价格、库存、政策这些字段，在 HTML 里有没有一份”。
三种不用写代码的测试
三种测试按成本从低到高排，做完第一种就能排除大半问题。
| 测试 | 怎么做 | 看什么 | 结论怎么下 |
|---|---|---|---|
| 查看源代码 | 在 PDP 上按 Ctrl+U（不是“检查元素”），搜价格数字、SKU、保修年限 | 源码里有没有这些字 | 搜不到就是没有，别用渲染后的 DOM 说服自己 |
| 关掉 JavaScript 逛一遍 | 开发者工具 → 设置 → Debugger → 勾选 Disable JavaScript，再刷新品类页、PDP、政策页 | 正文、规格、运费、退货是否还在 | 只剩导航和页脚就是白页；加购失效可以接受，正文消失不行 |
| 取一次原始响应 | curl -sL 页面地址另存为文件；同时看 robots.txt 是否放行 AI 爬虫 | 响应字节数、正文长度、关键字段 | 字节正常但正文极短，通常是空壳；403 或挑战页说明卡在边缘 |
第一种是唯一的事实来源：源代码里有什么，爬虫才可能拿到什么。关掉 JS 是给运营看的说服工具，原始响应是给前端看的排期依据。三者都不需要写代码，一个下午能跑完十个页面。
修渲染：先静态，再服务端，最后才动态
选渲染方案的标准不是“团队熟什么”，而是“哪些字段必须出现在第一份 HTML 里”。按这个标准，五种做法有明确顺序。
| 方案 | 什么站适合 | 代价 | 判断 |
|---|---|---|---|
| 纯客户端渲染（CSR） | 登录后的工具页、后台 | AI 与部分搜索拿不到字段 | 只留在非公开页面 |
| 静态生成 / 增量静态（SSG、ISR） | SKU 有限、价格库存能容忍分钟级延迟 | 构建与失效策略要维护 | 政策页、品类页、指南页优先 |
| 服务端渲染（SSR） | SKU 多、地区定价、库存强实时 | TTFB 与缓存成本上升 | 核心 PDP 用它，不必全站 |
| 动态渲染（对机器人返回预渲染 HTML） | 老站短期过渡 | 两套 DOM 容易漂移，UA 判断会误伤 | 定一个下线日期，别长期挂着 |
| 静态壳加关键字段内联 | 所有电商站的最低要求 | 需要处理“默认值与实时值不一致” | 最实际的折中，先做这个 |
确定了顺序，落地是四步，每步都能验收：
| 步骤 | 做什么 | 谁来做 | 怎么算过 |
|---|---|---|---|
| 选页 | 10 个 URL：2 个品类页、5 个 PDP、3 个政策页 | 运营 | 覆盖主要品类与售后场景 |
| 建字段表 | 品名、价格、库存状态、规格、运费、退货、保修逐项标注“HTML 有无” | 运营加前端 | 每格是看过源码的事实，不是估计 |
| 改渲染 | 政策页与品类页先转静态；PDP 用 SSR 或内联关键字段；动态渲染只做兜底 | 前端 | 无 JS 快照能看到四类字段 |
| 建回归 | 把无 JS 抓取放进 CI 或每周巡检，字段缺失就报警 | 前端加增长 | 有脚本或清单，不靠人记 |
顺手补 Product、Offer 结构化数据是对的，但要清楚它不替代正文：结构化数据里缺价格，和正文里缺价格是同一个问题，都是AI 答案里商品的五层结构里同一层没补齐。这类活归技术底座这条线，不该由内容团队代劳。
示例：一个只有导航和页脚的 PDP
示例：某家居小家电独立站（假设场景，字段与字数仅为示意，不代表任何真实站点数据）的 PDP 由前端框架渲染。无 JS 快照里，正文只剩站点名、导航和版权声明；价格、库存、保修三项都在接口响应里。
改法不是重写前端，而是三步：服务端先输出商品标题、规格与一段 80–120 字的结论；把价格、库存状态与更新时间以内联文本或 JSON-LD 写进首份 HTML；客户端拿到实时数据后再覆盖。验收标准不是“页面看起来一样”，而是“关掉 JavaScript 后，字段还在”。如果改完仍然搜不到，问题通常已经不在渲染，而在 CDN 缓存、地区跳转或防护规则。
边界：什么情况下不用动渲染
第一，平台内卖家。亚马逊等平台的页面由平台渲染，你能改的是 listing 与 feed，不是模板，逼团队做 SSR 是错配资源。
第二，页面本来就不该被公开抓取。报价单、登录后的工具页、经销商专区，做成服务端渲染反而是信息泄露，按私有内容处理才对。
第三，建站平台已经输出服务端 HTML。先测再改，多数主题不需要动前端，问题往往出在缓存、边缘防护或地区跳转上。
第四，内容本身没有可摘的结论。渲染修好只是让 AI 更快读到一段空话，顺序应该是先有答案单元，再谈渲染。
第五，渲染不等于被引用。修好渲染只说明 AI 拿得到原料；模型先要认出你这个实体，再看有没有第三方证据，可以先跑一遍品牌实体是否存在里的自查。改前改后用同一批问题各测一次，否则涨了跌了都说不清原因。
这个月挑一件事做：挑 10 个 URL，用“查看源代码”逐页搜价格、库存状态、运费、退货四个词，把搜不到的页面列成一张表，标上页面类型和负责人，交给前端排期。这张表比一份渲染方案更有用，因为它只记录事实。