用 JavaScript 生成 Google 结构化数据指南

💡 核心摘要：Google 可以在渲染网页时理解 DOM 中通过 JavaScript 提供的结构化数据。你可以用 Google 跟踪代码管理器、自定义 JavaScript 或服务器端渲染生成 JSON-LD。最佳实践是尽量从页面现有内容抽取变量，避免在标签管理器中复制信息造成不一致，并用富媒体搜索结果测试的“网址测试”验证最终渲染结果。

一、为什么会用 JavaScript 生成结构化数据

现代网站大量依赖 JavaScript 渲染内容。商品价格、库存、食谱字段、作者信息、图片、页面标题、用户界面组件，都可能由前端或标签系统动态生成。

在这种架构下，结构化数据不一定只能写死在 HTML 源码中。你可以在页面运行时插入 JSON-LD，也可以在服务器渲染输出时生成 JSON-LD。

Google 官方说明，Google 搜索能够在渲染网页时理解和处理 DOM 中提供的结构化数据。关键是 Google 最终渲染页面时能看到有效、合规、与页面内容一致的结构化数据。

二、常见实现方式

Google 文档列出两种常见 JavaScript 生成方式：

Google 跟踪代码管理器
自定义 JavaScript

此外，如果你使用服务器端渲染，也可以直接在渲染输出中包含结构化数据。

三种方式都可以成立，但优先级不同。对多数网站来说，服务器端或框架层直接输出结构化数据更稳定；GTM 更适合快速实验或营销团队管理；自定义 JavaScript 适合动态数据需要从 API 或页面状态中生成的场景。

三、购物内容要特别谨慎

Google 特别提醒：如果使用的是 Product 标记，动态生成的标记可能导致购物内容抓取频率降低且不太可靠。

这对价格、库存、促销、商品状态等快速变化内容尤其重要。商品信息如果依赖客户端运行后才出现，Google 可能无法像服务器端 HTML 那样及时稳定抓取。

如果你是针对所有类型购物搜索结果进行优化的商家，还要确保服务器有足够计算资源处理来自 Google 的更多流量。

⚠️ 商品结构化数据最好优先考虑服务器端稳定输出。价格和库存这类高频变化字段，不适合完全依赖脆弱的前端注入。

四、用 Google 跟踪代码管理器生成 JSON-LD

Google 跟踪代码管理器可以在不直接修改网站代码的情况下管理标签。你可以添加自定义 HTML 标签，把支持的结构化数据 JSON-LD 放进去，然后发布容器。

基本流程是：

安装 Google 跟踪代码管理器
向容器添加新的自定义 HTML 标记
粘贴支持的结构化数据块
安装容器代码
发布容器
测试实现效果

这种方式适合没有工程发布权限、需要快速验证或少量页面改造的场景。但它也带来一致性风险。

五、GTM 中应使用变量抽取页面信息

Google 建议在 GTM 中使用变量，从网页中提取结构化数据所需信息，而不是在 GTM 中复制信息。

原因很直接：复制信息会增加网页内容和结构化数据不一致的风险。比如页面标题已经改了，但 GTM 里的 JSON-LD 仍然保留旧名称；页面作者变了，但结构化数据作者没有同步。

例如可以创建一个 recipe_name 自定义变量，动态读取页面标题：

function() { return document.title; }

然后在自定义 HTML 中使用：

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "Recipe",
  "name": "{{recipe_name}}",
  "image": ["{{recipe_image}}"],
  "author": {
    "@type": "Person",
    "name": "{{recipe_author}}"
  }
}
</script>

前提是你已经在 GTM 中定义了对应变量。

六、用自定义 JavaScript 生成结构化数据

另一种方式是使用自定义 JavaScript 生成全部结构化数据，或在服务器端已有结构化数据基础上补充更多信息。

常见做法是从 API 获取结构化数据文本，然后创建一个 script 元素插入页面：

fetch('https://api.example.com/recipes/123')
  .then(response => response.text())
  .then(structuredDataText => {
    const script = document.createElement('script');
    script.setAttribute('type', 'application/ld+json');
    script.textContent = structuredDataText;
    document.head.appendChild(script);
  });

这种方式要注意 API 稳定性、跨域限制、加载时机、错误处理和渲染结果。Google 需要在渲染页面时看到最终插入的 JSON-LD。

七、服务器端渲染通常更稳定

如果网站使用服务器端渲染，可以在渲染输出中直接包含结构化数据。很多现代框架都支持为页面生成 JSON-LD。

服务器端输出的优势是：Googlebot 抓取初始 HTML 时就能看到结构化数据，不依赖前端脚本执行、API 成功返回或标签容器加载。

对关键页面、商品页、新闻页、活动页、招聘页等结构化数据价值较高的页面，优先服务器端渲染通常更稳。

八、避免页面内容和结构化数据不一致

无论用 GTM、自定义 JS 还是服务器端渲染，结构化数据都必须和页面可见内容一致。

动态生成最常见的问题是数据源不同步：页面展示的价格来自商品服务，JSON-LD 来自旧缓存；页面作者来自 CMS，结构化数据作者来自 GTM 固定值；页面标题被前端改写，但 JSON-LD 仍是旧标题。

解决办法是尽量复用同一数据源，或者从页面实际 DOM 中抽取变量，减少重复维护。

九、测试时优先用网址测试

Google 官方建议使用富媒体搜索结果测试验证实现效果，并使用“网址测试”，而不是代码输入。

原因是代码输入测试存在 JavaScript 限制，例如 CORS 限制。它可能不能完整模拟真实页面加载、脚本执行、API 请求和 DOM 插入过程。

网址测试会抓取并渲染实际页面，更接近 Google 搜索看到的结果。

测试流程：

打开富媒体搜索结果测试
输入要测试的网址
点击测试网址
查看是否显示“网页能显示富媒体搜索结果”
检查渲染后的 HTML 是否包含结构化数据

十、测试工具不支持的类型怎么办

如果你要测试的结构化数据类型不被富媒体搜索结果测试工具支持，可以检查渲染后的 HTML。

如果渲染后的 HTML 包含对应结构化数据，Google 搜索通常能够处理该结构化数据。

但仍要注意：能处理不等于能触发富媒体结果。是否展示取决于具体功能是否支持、页面质量、政策、查询意图和 Google 系统判断。

十一、实施前的选择建议

选择实现方式时，可以按稳定性排序。

优先考虑服务器端渲染或构建时生成，尤其是关键 SEO 页面和高频变化的商品、活动、招聘内容。

如果无法改代码，可用 GTM 临时实现，但要尽量使用变量抽取页面现有信息，并安排后续迁移到模板层。

如果数据必须来自客户端状态或 API，可用自定义 JavaScript 注入，但要确保加载可靠、错误可监控、Google 渲染时能看到结果。

十二、上线前检查清单

结构化数据是否与页面可见内容一致
是否复用页面数据源，而不是在 GTM 中复制内容
JSON-LD 是否在 Google 渲染后的 DOM 中存在
API 是否稳定，是否存在 CORS 或超时问题
商品价格和库存是否足够及时
是否用网址测试而不是只用代码测试
测试工具是否支持该结构化数据类型
是否有监控机制发现注入失败

如果这些问题不能回答清楚，不建议把关键结构化数据完全依赖客户端脚本。