结构化数据怎么加：哪几种还活着，哪两种已经下线

结构化数据怎么加才有用，理由比多数教程说的窄得多：它把「谁发布的、什么时候、讲的是什么」用一种不需要猜的格式写清楚。而最常被推荐的两种类型——HowTo 和 FAQPage——在 Google 已经完全不再产生富结果了。知道哪几种还活着，能省下给没人读的东西打标记的功夫。

读这篇之前

等内容确实取得到、读得到了再加标记。结构化数据是描述一个页面，不是抢救一个页面。爬虫拿到的是空壳的话，先看AI 爬虫会执行 JavaScript 吗——用脚本注入的 JSON-LD，和别的用脚本注入的东西问题完全一样。

结构化数据怎么加：先看 Google 现在还支持哪几种

Google 当前的富结果清单列了 25 种，包括 Article、Breadcrumb、Dataset、Organization、Product、Profile page、Q&A、Video、Review snippet。有两种被长期推荐的类型，不在这份清单上。

网上大部分讲 schema 的文章，写的时候这两种还没被撤掉。动手之前先去看那份清单。

图注：这张图标签较多，中英文页共用同一张（英文标注）。左列绿色是仍受支持的四种，右列红色是已下线的两种，与上面的中文表格一一对应。

加了它，被引用的概率会变吗

我们不知道，那些给你一个百分比的人也不知道。没有引擎公布过自己怎么给结构化数据加权，我们也没在自有站上跑过对照实验。站得住的说法更弱、但仍然值得做：标记消除了作者、日期、实体身份上的歧义，而这恰恰是引擎归因一条主张时需要的事实。

所以老实的理由不是「加了 schema 就被引用」，而是「万一真有东西读它，这件事花你一个小时，而且不会被读错」。

四段可以直接粘的代码

每段放进 <script type="application/ld+json"> 标签里，写在页面 head 中。把值替换掉，别留占位文字。

一篇文章或博客：

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "页面上可见的那个标题，一字不差",
  "datePublished": "2026-08-15",
  "dateModified": "2026-08-15",
  "author": { "@type": "Person", "name": "作者名" },
  "publisher": {
    "@type": "Organization",
    "name": "你的公司",
    "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }
  },
  "mainEntityOfPage": "https://example.com/the-page"
}

你是谁，放首页或关于页：

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "你的公司",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "description": "一句话说清你做什么。",
  "sameAs": [
    "https://github.com/yourcompany",
    "https://www.linkedin.com/company/yourcompany"
  ]
}

面包屑，把层级说明白：

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "手册",
      "item": "https://example.com/handbook" },
    { "@type": "ListItem", "position": 2, "name": "本章",
      "item": "https://example.com/handbook/this-chapter" }
  ]
}

一个发布数据的页面——这种更少见，所以更值钱：

{
  "@context": "https://schema.org",
  "@type": "Dataset",
  "name": "我们测了什么",
  "description": "一句话写清样本、方法和时间窗。",
  "creator": { "@type": "Organization", "name": "你的公司" },
  "dateModified": "2026-08-15",
  "distribution": {
    "@type": "DataDownload",
    "encodingFormat": "application/json",
    "contentUrl": "https://example.com/data/results.json"
  }
}

会被处罚的那一条规矩

Google 的结构化数据政策很短，要紧的那句毫不含糊："your structured data must be a true representation of the page content"（必须是页面内容的真实表示），以及 "Don't mark up content that is not visible to readers of the page."（不要给读者看不到的内容打标记。）

违反 "can result in a manual action"（可能招致人工处罚），后果写得很具体：该页面 "loses eligibility for appearance as a rich result; it doesn't affect how the page ranks in Google web search"（失去富结果资格，但不影响它在网页搜索里的排名）。所以代价是丢掉你本来想赢的那个功能，不是排名崩塌——但它由人来核查，而且会报在 Search Console 的人工处罚报告里。

落到操作上：JSON-LD 里任何一个值，如果在页面上读者看不到，就把它删掉。

放在哪儿，一个页面有多种类型怎么办

一段一个 <script type="application/ld+json">、都放 head，是最简单也最好维持真实的排法。也可以把多种类型放进一个数组里，有些框架偏好这样；两种都能被正常解析。

更重要的是先判断这一页主要是什么。一篇同时列了产品的文章，它仍然是一篇文章；两种都标，只会让两段随着页面变化各自漂移。挑那个描述主内容的类型，再加上 BreadcrumbList（因为它描述的是位置不是内容），然后就停——除非第二种类型真的承重。

做全站基线的话，覆盖面最好的排法是：首页放 Organization、每篇文章放 Article、任何有层级的地方放 BreadcrumbList。这是三个模板的事，不是一页一页的活。

怎么验证

三步，按这个顺序。第一步能抓住大部分错误，而且只要几秒。

1. 用爬虫的身份取页面，确认 JSON-LD 在交付的 HTML 里。框架如果是在客户端注入的，那对任何不渲染的东西来说它就不存在。
2. 跑一遍 Google 的富媒体搜索结果测试，确认语法能解析、类型能被识别。
3. 把每个值对着可见页面重读一遍。这一步让你不踩上面那条政策，而且没有任何工具会替你做。

curl -s -A "Mozilla/5.0 (compatible; OAI-SearchBot/1.4; +https://openai.com/searchbot)" \
  https://example.com/your-page | grep -o 'application/ld+json' | wc -l

返回 0 就说明标记没被交付出去，不管你的后台预览显示成什么样。

怎么让那些值别漂掉

结构化数据的腐坏方式和正文不一样。一个错的 dateModified、一个两年前就离职的作者，没有人会发现，因为它们都不在页面上显示——这正是它会漂的原因，也正是那条政策靠人工核查而不是靠校验器执行的原因。

最便宜的防护，是让这些值和可见页面用的是同一个数据源，而不是手写进模板。屏幕上的署名和 JSON-LD 里的 author 来自同一个字段，它们就不可能不一致。做不到的地方，就在每次动模板时把这段重读一遍。

实际有多少站在做

2026 年 8 月 15 日我们取了 15 个知名网站的首页，多数在交付的 HTML 里根本没有 JSON-LD，少数几个带了一到三段。样本很小也很糙——只测首页、只看有没有不看对不对——但它足以纠正一个印象：并不是别人都已经把这件事做好了。

三种常见的做错

前两种浪费力气，第三种制造风险。

1. 因为某篇教程说了就去实现 HowTo 或 FAQPage。两种都不再产生富结果了。你要基于「说不定某个引擎会读」还是加 FAQPage，那也行，但要清楚那是一个赌注，不是有据可查的收益。
2. 用 JavaScript 注入 JSON-LD。和其他前端渲染内容一样的失效方式：对不渲染的客户端，它不存在。
3. 给页面上没有的值打标记。没人留过的评分、不是他写的作者、对不上的日期。这正是那条政策点名的东西。

常见问题

我已经加了 HowTo，要删掉吗

没有记录在案的处罚，Google 的公告也没要求谁去删。它只是在 Google 搜索里不起作用了。下次动这个模板的时候顺手删掉就行，不用专门立个项目。

Google 撤了 FAQPage，为了 AI 引擎还值得加吗

有可能值得，而且我们两边都拿不出证据。我们不会做的是把它说成一个 SEO 收益，因为在 Google 那边它已经不是了。

只加一种的话先加哪个

首页的 Organization，并在 sameAs 里指向你其他已验证的主页。这是声明「你是谁」的那一段，而实体身份正是引擎最需要被钉死的东西。

标记越多结果越好吗

不是。每多一种类型，就多一组必须随页面变化保持为真的值。两段准确的，胜过六段已经漂掉的。

下一步

机器可读的那部分事实就位之后，这一部分剩下的功夫在正文本身——把段落写成可被摘取的样子，那件事没有任何标记能替你做。

加这几段要一个小时。随着页面变化让它们保持为真、并在变化时推送收录，才是会卡住的部分。