Google 下线了 FAQ SERP，FAQ schema 还需要写吗？JSON-LD 呢？（附模板）

2026 年 5 月 7 日，FAQ 富媒体结果从 Google 搜索里全面消失。不是限缩，是消失。连之前还保留资格的政府和卫生机构站点也一起收回。

如果你还在往页面里堆 FAQPage，为的是搜索结果里那个下拉问答框，那这个目的从今年 5 月起就已经不成立了。

但 JSON-LD 还是要做。只是做它的理由，和大多数人以为的不一样。

一、2026 年，哪些已经失效

这一波清理不是突然发生的，是一条时间线。

2023 年 8 月到 9 月：HowTo 退役。 移动端 8 月先收回，桌面端 9 月跟上。现在任何设备上都没有 HowTo 富媒体结果了，Google Search Central 里的文档也一并移除。

2026 年 1 月：7 个类型退役。 Course Info、Claim Review、Estimated Salary、Learning Video、Special Announcement、Vehicle Listing、Practice Problems。

2026 年 5 月 7 日：FAQ 富媒体结果全面下线。

后续还有两步：2026 年 6 月，Search Console 里的 FAQ 报表、搜索外观筛选器，以及 Rich Results Test 对 FAQ 的检测支持全部下架；2026 年 8 月，Search Console API 里的相关数据也会移除。

要分清楚一件事：类型被废，和类型还在但没效果，是两码事。

FAQPage 和 HowTo 作为 Schema.org 的类型本身都还在，放着不会产生页面错误，Google 也明确说过未被使用的结构化数据不会造成问题。所以已有的标记不用急着删，等下次维护时顺手清掉就行，优先清高流量页。

真正该改的是预期：别再为一个已经不存在的版位写标记。

还有个容易踩的坑：FAQPage 和 QAPage 不是同一个东西。

QAPage 仍然完全支持，但它只适用于社区问答页，就是用户提问、其他用户提交多个答案那种（Stack Overflow、Quora、支持论坛）。如果你把 QAPage 当成 FAQPage 的替代品用在自己的问答页上，会被当垃圾过滤掉。

判断标准很简单：答案是谁写的。 你自己写的单一权威答案用 FAQPage，用户互相回答的用 QAPage。

二、为什么被砍的偏偏是这些

Google 官方给的理由是低质量和普遍滥用。发布者在没有真实问答内容的页面上加 FAQ schema，占掉了一个内容本身没挣到的版位。

但把 2026 年砍掉的 8 类放在一起看，规律很清楚：

被砍的都是"只有发布者自己说了算"的。 你怎么写都行，Google 没有独立来源核对。

保留并且在扩张的，是"有独立事实源可核对"的。 MemberProgram（2025 年末推出，用来描述会员和忠诚计划）、商家列表新增的忠诚定价和配送权益子属性，这两类都在往 AI Mode 和 Gemini 结果里延伸。

所以有一条判断标准可以记下来：

结构化数据的权重，等于它能被第三方验证的程度。

Product 的价格有 Merchant Center feed 可以核对，Organization 的身份有 Wikidata 和 LinkedIn 可以核对，这两类就安全。FAQ 和 HowTo 只有你自己说，就被砍。

这条标准后面还会用到。

三、AI 搜索到底读不读 JSON-LD

这是 GEO 圈争议最大的一块，我直接上有对照的数据。

先说反面的证据，这部分数据更硬。

Ahrefs 在 2026 年 5 月做过一个受控实验：找出 1,885 个在 2025 年 8 月到 2026 年 3 月之间加了 JSON-LD 的页面，配 4,000 个加之前的引用率相近的控制页，对比前后各 30 天。

结果是：Google AI Overviews 引用率下降 4.6%，统计显著。AI Mode 上升 2.4%，ChatGPT 上升 2.2%，两个都不显著，等于没变化。

另一项 2026 年 2 月的研究更狠。730 个 AI 引用的样本里，完全没有 schema 的页面，表现比"有通用但不完整的 schema"的页面好 18 个百分点。

研究者的解释值得记住：AI 系统把"写了但没填满"的 schema 当成负面信号，等于告诉它这个站点试过但没维护好。空的 url 字段、占位符作者、答案直接复制标题的 FAQPage，都比干脆没有更糟。

再说机制。

有受控实验发现，LLM 把 JSON-LD 块当成普通文本切词，发布者以为自己提供的语义结构在摄入阶段就散了。更关键的是：当 AI 系统直接抓取单个 URL 来生成答案时，主流系统只提取可见的 HTML 内容。JSON-LD、隐藏的 Microdata、隐藏的 RDFa，全部被忽略。

有个验证方法很能说明问题：给 ChatGPT 和 Perplexity 一个逻辑上自相矛盾、明显无效的 schema，它们照样能生成答案。因为它们根本没把它当 schema 读，只是当成页面上又一段文字。

那"加 schema 引用率涨 3.4 倍"这类数据是怎么来的？

我查到的几个来源，基本都出自卖结构化数据工具或 GEO 监测服务的厂商。它们的样本、控制组和统计口径没有公开到能复核的程度。

按第八篇那把尺子量一下：谁承诺读了？没有一家 AI 厂商公开确认会读 JSON-LD。读了改什么行为？受控实验显示没有。这就是自嗨那一类。

唯一有一致正相关的，是实体消歧。

多个平台研究里，Organization schema 用 sameAs 把品牌链接到 Wikidata、LinkedIn、Crunchbase 这类外部权威标识，与 AI 引用率有一致的正相关。

机制也说得通。AI 模型训练时遇到的实体有多个名称，没有消歧的话，你的品牌可能被当成一个含义不明的指代。一旦 Organization 里明确连上了 Wikidata 实体 ID，模型就能把它锚定到自己已有的知识上，在相关语境里引用时更有把握。

四、所以现在做 JSON-LD 是为了什么

三个还站得住的理由，按重要性排。

第一，实体消歧。 让 AI 和 Google 搞清楚你是谁，不会把你和同名竞品搞混。这是唯一有数据支持的一条。

第二，还有富媒体效果的类型。 Product、Article、BreadcrumbList、VideoObject、Organization、Person 这几类仍完全支持，能影响商品结果、Top Stories、Discover 和面包屑展示。

第三，降低提取成本。 前提是 schema 准确完整，且内容在 HTML 里可见。写得烂不如不写。

一句话总结：JSON-LD 是描述层，不是排名层，也不是引用保证。

它的作用是让机器准确理解你是什么、是谁、什么时候写的。至于要不要展示、要不要引用，取决于内容本身值不值。

五、六类博客的模板

下面这些可以直接改了用。所有日期用 ISO 8601 带时区，图片给绝对地址。

1. 全站：Organization（放首页，或全站模板）

这是最高优先级的一份，也是唯一明确对抗 AI 引用下滑的一份。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "站点名称",
  "url": "https://example.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/logo.png"
  },
  "sameAs": [
    "https://www.wikidata.org/wiki/Q000000",
    "https://www.linkedin.com/company/yourcompany",
    "https://www.crunchbase.com/organization/yourcompany"
  ],
  "knowsAbout": [
    "主题一",
    "主题二",
    "主题三"
  ]
}

sameAs 里挑真实存在的填，没有 Wikidata 条目的话，花二十分钟建一个，值得。

2. 常规博客文章：BlogPosting

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/post-slug#article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/post-slug"
  },
  "headline": "文章标题，控制在 110 字符以内",
  "description": "一句话摘要，跟页面 meta description 保持一致",
  "image": [
    "https://example.com/img-16x9.jpg",
    "https://example.com/img-4x3.jpg",
    "https://example.com/img-1x1.jpg"
  ],
  "datePublished": "2026-10-26T09:00:00+08:00",
  "dateModified": "2026-10-26T09:00:00+08:00",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/about#person",
    "name": "作者名",
    "url": "https://example.com/about",
    "sameAs": [
      "https://www.linkedin.com/in/author"
    ]
  },
  "publisher": {
    "@id": "https://example.com/#organization"
  },
  "inLanguage": "zh-CN"
}

三个细节：

Article 类型现在有 0 个必需字段。 Google 在 2025 年 12 月更新的文档里写得很明确，没有必需属性。上面这些全是推荐字段，但都填上效果最好。

author 要连到真实的 Person 实体，用 @id 指向作者页，不要写个字符串了事。YMYL 类内容尤其重要。

image 给三种宽高比（16:9、4:3、1:1），这是推荐做法，不是必需。

3. 教程类：别用 HowTo，改用这个

HowTo 已经没有任何富媒体效果了。替代方案不是换个 schema，而是把 HTML 结构写清楚。

用 BlogPosting 作为外层，步骤部分在正文里用 h2 加有序列表：

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "如何做某件事",
  "author": {
    "@type": "Person",
    "name": "作者名"
  },
  "datePublished": "2026-10-26T09:00:00+08:00",
  "dateModified": "2026-10-26T09:00:00+08:00",
  "articleSection": "教程",
  "timeRequired": "PT15M"
}

关键是正文的 HTML：

<h2>第一步：做这件事</h2>
<ol>
  <li>具体动作，一句话说完</li>
</ol>

一个步骤一个 h2，步骤内用有序列表，每步一句话。AI 系统读的是这段可见 HTML，不是 schema。

4. 问答页：FAQPage（只在一种情况下用）

如果你的页面确实有问答内容，而且你想让 AI 更容易读到，可以用。但要守两条规矩。

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "这里写完整的问题原文",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "这里写完整的答案原文，不要截断，不要写“见上文”"
      }
    }
  ]
}

规矩一：问题和答案必须完整。 不能省略，不能指向别处。

规矩二：问答必须在页面 HTML 里直接可见。 如果它们藏在需要点击才展开的手风琴组件里，而且关闭 JavaScript 后就消失了，那 AI 引擎同样读不到。这一条是这类页面最高性价比的修法，改完立刻生效。

社区问答用 QAPage，结构是用户提交多个答案：

{
  "@context": "https://schema.org",
  "@type": "QAPage",
  "mainEntity": {
    "@type": "Question",
    "name": "用户提出的问题",
    "answerCount": 3,
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "被采纳的答案",
      "upvoteCount": 42,
      "author": { "@type": "Person", "name": "回答者" }
    },
    "suggestedAnswer": [
      {
        "@type": "Answer",
        "text": "另一个用户的答案",
        "upvoteCount": 12,
        "author": { "@type": "Person", "name": "另一个回答者" }
      }
    ]
  }
}

5. 评测与产品：Product + Review

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "产品名称",
  "image": ["https://example.com/product.jpg"],
  "description": "产品描述，跟页面可见内容一致",
  "brand": {
    "@type": "Brand",
    "name": "品牌名"
  },
  "offers": {
    "@type": "Offer",
    "price": "299.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/product"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "reviewCount": "128"
  }
}

商家列表的必需字段只有 3 个：name、image、offers（含 price 或 priceSpecification.price 加 priceCurrency）。aggregateRating、brand、gtin、sku、description 全是推荐，不是必需。

但 aggregateRating 有个硬前提：必须有页面上真实存在的评价支撑。编造评分是明确违反指南的，也是 Google 砍掉一批类型的直接原因之一。

价格和库存必须跟页面可见内容、Merchant Center feed 三方一致。

6. 榜单与清单：ItemList

{
  "@context": "https://schema.org",
  "@type": "ItemList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "第一名",
      "url": "https://example.com/item-1"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "第二名",
      "url": "https://example.com/item-2"
    }
  ]
}

position 必须从 1 开始连续递增，每条要有 name。

7. 面包屑：每个 URL 都加

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "首页",
      "item": "https://example.com"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "分类",
      "item": "https://example.com/category"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "当前页"
    }
  ]
}

最后一层的 item 可以省略。这条建议加到全站每个 URL 上，不只是产品页。

组合写法：用 @graph 串起来

一个页面上放多个独立 script 标签，机器看到的是一堆互不相干的碎片。用 @graph 加 @id 互相引用，才是完整的一张图。

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "站点名称",
      "url": "https://example.com"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/about#person",
      "name": "作者名",
      "url": "https://example.com/about"
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/post-slug",
      "isPartOf": { "@id": "https://example.com/#website" },
      "breadcrumb": { "@id": "https://example.com/post-slug#breadcrumb" }
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://example.com/post-slug#breadcrumb",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "首页", "item": "https://example.com" }
      ]
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/post-slug#article",
      "mainEntityOfPage": { "@id": "https://example.com/post-slug" },
      "headline": "文章标题",
      "author": { "@id": "https://example.com/about#person" },
      "publisher": { "@id": "https://example.com/#organization" },
      "datePublished": "2026-10-26T09:00:00+08:00",
      "dateModified": "2026-10-26T09:00:00+08:00"
    }
  ]
}

六、五个最常见的错误

第一，半填充。 这份研究结论再说一遍：不完整的 schema 比没有 schema 差 18 个百分点。插件自动生成的残缺 markup 是重灾区，宁可删掉。

第二，用 JavaScript 动态注入。 检索型 AI 爬虫（GPTBot、ClaudeBot、OAI-SearchBot、PerplexityBot、Google-Extended）走 HTTP 不执行 JavaScript，它们读的是第一份响应的 HTML。schema 必须服务端渲染。

第三，内容藏在交互组件里。 手风琴、选项卡、点击展开，关掉 JavaScript 就消失的内容，AI 引擎大概率也读不到。

第四，schema 和页面内容不一致。 Google 反复强调结构化数据必须与可见内容匹配。标的价格和页面价格对不上，是最典型的违规。

第五，author 是占位符。 写 "admin"、"author"、站点名当作者，等于告诉机器这个字段没人维护。