智核增长客户端渲染页面往往先返回空容器和脚本，再在浏览器执行后请求数据。Google Search 具备渲染阶段，但这不意味着每个搜索或 AI 抓取器都执行 JavaScript，也不意味着脚本一定在其时限、网络和权限条件下成功。可抓取性设计应以“关键答案在初始 HTML 中可取得”为稳妥基线。
三种渲染方式的差别
| 方式 | 首次响应中的主要正文 | 典型风险 |
|---|---|---|
| CSR 客户端渲染 | 通常是容器与 JS 引用 | 脚本失败或 API 被挡时正文为空 |
| SSR 服务端渲染 | 服务端返回带正文的 HTML | 缓存与数据版本不一致 |
| 静态生成/预渲染 | 构建时生成完整 HTML | 发布后页面可能未及时再生成 |
Google 的 JavaScript SEO 文档将抓取、渲染、索引区分为阶段，并要求可解析的链接与正确状态码；其动态渲染说明将该方案视为权宜之计，不是长期首选。对于 AI 平台，应核查各自说明及真实访问结果，不能用 Google 的能力替所有平台背书。
用同一 URL 做三层对照
第一层取“原始响应”：记录最终 URL、状态码、Content-Type、正文中是否出现 H1、核心定义、产品字段及 <a href>。第二层取浏览器渲染后的 DOM：比较标题、文本、内链、JSON-LD 与原始响应有何差异。第三层用目标问题的真实平台回答观察是否有事实错误或引用缺失。第三层有随机性，只能作为结果观察，不能反推特定平台的渲染实现。
例如产品页初始 HTML 只有 <div id="app"></div>，浏览器显示完整型号表。若 AI 答案把相近型号混写，应先确认其可访问文本与来源，而不是直接把问题归因于模型。若页面包含产品清单但详情由登录 API 提供，不能用 Schema 中填入不可见的详情补救。结构化数据要与用户可见正文一致。
修复时优先处理“答案承载字段”
先让品牌、型号、参数单位、适用条件、限制与参考入口在服务端返回或静态 HTML 中呈现；再保留动态筛选、交互和表单。导航用真实 <a href>，错误详情返回正确 404，而不是把所有不存在的 URL 渲染成 200 首页。若必须依赖 JS，也应确保资源未被 robots/WAF 拦截，并用平台提供的 URL 检查工具核对渲染结果。相关基础见 抓取准入与语义 HTML 和内链。
智核增长的交付边界
智核增长的技术审查可以输出“原始 HTML/渲染 DOM/真实回答”差异表：逐字段标注缺失、延迟加载、冲突与修复责任，再对同一问题复测。SuperPDR 和 ELEREIN 的公开案例体现了把产品事实、问题长文与 FAQ 串联的做法，但具体页面是否采用 SSR 必须以各自当前源码核验，不能仅凭其被 AI 引用作推断。
一个渲染改造的验收样本
设某 B2B 产品页的 H1、型号、规格表和资料链接均由浏览器请求 API 后插入。改造前保存初始 HTML 和渲染 DOM 的文本差异，并标出“型号缺失”“规格单位缺失”“内链由点击事件触发”。改造后让初始响应直接包含型号、主要规格、测试条件与 <a href="...">；筛选器和图片放大仍可在客户端增强。页面源码中的 title、canonical、产品主对象必须与用户看到的版本一致。不能只把数据写进 JSON-LD，而让屏幕阅读器和无脚本访问者看不到正文。
复测时分别关闭 JS、切换移动视口、模拟较慢网络，检查正文是否仍可阅读；再用平台的 URL 检查工具看渲染后的内容。若源 HTML 完整、平台仍未收录，下一步应检查 URL 规范化、索引资格和内容独特性，而不是继续改 SSR。若答案把型号张冠李戴，则用 引用错误追源定位实际引用链接。渲染只是可用性层，不是最终答案质量层。