AI 搜索的结构化数据：哪些还有用？

结构化数据到底对 AI 助手有什么用

每当 AI 助手回答“附近最好的牙医”或“哪里能买到这个零件”这类问题时，它首先会派出一个爬虫——专门访问网页并复制内容的程序——去读取你的网站。没有标签的话，爬虫看到的只是一大段文字，得靠猜：“555-0134”是电话号码还是产品编号？结构化数据把猜测这一步省掉了，它把事实包进一小段叫 JSON-LD 的代码块里，安安静静地待在页面里，相当于明确告诉程序：这是电话号码，这是价格，这是开门时间。

OpenAI 自己的文档确认，其爬虫 GPTBot 抓取公开网页的方式，和传统搜索引擎大致相同 OpenAI，而 Google 的结构化数据指南也明确说，这些标签能帮助程序“理解页面内容” Google Search Central。这两家公司都没说过会忽略这类标记，所以实际上，你为传统搜索添加的那段 JSON-LD 代码，同样会被你顾客正在转向使用的这些 AI 助手读取。如果你从来没加过，那么今天回答关于你生意问题的 AI 助手，用的是猜测，不是事实。

真正值得花时间的四种标记类型

schema.org 列出了几百种条目类型，从食谱到电影到机场应有尽有，但对一般规模的中小企业来说，只需要其中四种，就能覆盖 AI 助手可能引用的绝大多数事实。把这四种加上，剩下的不用操心。

• Organization（组织）——把你的生意确立为一个统一命名的实体，附带徽标和官方社交账号链接，这样 AI 助手才能判断 Instagram 账号和网站说的是同一个“多洛雷斯面包店”。
• LocalBusiness（本地商家）——是 Organization 的扩展版本，专为有实体地址或服务范围的商家设计；它记录营业时间、电话号码和所在街区，正是 AI 助手回答“现在开门吗”所需要的确切信息。
• Product 和 Offer（产品与报价）——为你出售的商品标注真实的价格、货币和库存状态，这样 AI 助手引用的就是你的真实数字，而不是几个竞争对手价格的粗略平均值。
• FAQPage（常见问题页）——把一组问答按 AI 助手最爱直接摘录、原样引用给用户的格式整理好。

机器可读的身份确认，如何解决“这是同一家店吗”的问题

设想一下多洛雷斯，她在奥斯汀经营一家面包店。她有 Google 商家资料、Yelp 页面、Instagram 账号和自己的网站——网上散落着四处不同的“多洛雷斯面包店”。在 AI 助手放心推荐她之前，它得先解决一个叫“实体识别”的问题：判断这四处提及说的是不是同一家真实的店，还是其中有一个其实是另一座城市里同名的另一家面包店。

结构化数据给了 AI 助手一条捷径。schema.org 里有个叫 sameAs 的属性，能让多洛雷斯把自己的 Instagram、Facebook 和 Yelp 网址，直接列在自己网站的 Organization 标记里——这相当于她本人用机器可读的方式确认，这些账号都是她的 schema.org。这比让 AI 助手靠各个信息源里相似的名字和地址自己去猜测匹配要可靠得多；这是多洛雷斯本人为这层关联作担保，而且是一种谁都不会读错的格式。

名字的竞争越激烈，这一点就越重要。在一个只有八千人的小镇上，唯一一家“多洛雷斯面包店”很容易自我核实身份。但一家叫“河畔牙科”的诊所，如果周围还有四家名字相近的诊所，就需要靠每一个能区分身份的细节——确切地址、确切电话号码、确认过的社交账号链接——才能避免被 AI 助手和街对面的竞争对手混为一谈。

一份本周就能照抄照改的 JSON-LD 示例

这东西不需要程序员从零写起，你需要的只是照着模板填空。一段本地商家的 JSON-LD 代码块，放在一个单独的 script 标签里，类型标注为 application/ld+json，开头先声明一行，表明自己使用的词汇表是 schema.org 的上下文。在这段代码里面，类型设为 LocalBusiness，接着是一个 name 字段，填你准确的公司名称，还有一个 image 字段，指向你的徽标。

接下来是地址，它是一个独立的嵌套对象，类型为 PostalAddress，拆成 streetAddress（街道地址）、addressLocality（城市）、addressRegion（省份或地区）和 postalCode（邮编）——分成四个独立标注的字段，而不是一整行文字，因为只有这样，AI 助手回答“这家店离我近吗”的时候，才不会把邮编误认成门牌号。接着是 telephone（电话）字段，以及 priceRange（价格区间）字段（简单写个“$”表示中等价位就行）。openingHoursSpecification（营业时间）字段以结构化格式列出你的营业日期和时间，而不是一句自然语言，这样“周日不营业”就不会被误读成“周一不营业”。最后是 sameAs 字段，装一个网址数组：你的 Instagram、你的 Facebook 主页、你的 Yelp 页面，以及任何其他毫无疑问属于你的账号主页。

写好之后，这段代码只需粘贴一次，放在主页代码靠前的位置，之后就不用再管了。如果你用的是 Squarespace、Wix 或 Shopify 这类建站工具，现在大多数都提供了“自定义代码”或“结构化数据”的设置栏位，可以直接添加，不用改动网站其他部分。

哪些可以跳过

不是每种 schema.org 类型都值得花时间，追求“全都加上”只会把本该花在前面四种上的精力浪费掉。

• BreadcrumbList（面包屑导航）标记，描述的是网站的文件夹结构（首页 > 菜单 > 蛋糕），能帮传统搜索结果展示导航路径，但对 AI 助手了解你生意的事实毫无帮助——除非你之前的项目里已经加过，否则不必特意添加。
• 没有真实评价支撑的 AggregateRating（综合评分）。Google 自己的结构化数据准则明确禁止用标记伪造你实际并不具备的评分 Google Search Central，AI 助手如果照搬一个你撑不起的虚高分数，带来的是口碑风险，不是加分项。
• 在每一个页面上都嵌套或重复贴同一份标记。你的 Organization 身份信息只需要在一个地方——通常是主页——清楚声明一次；在几十个页面上不一致地重复它，只会制造出多个互相矛盾的版本，让 AI 助手无从取舍，这比只声明一次、但声明准确要糟得多。
• 太新、几乎没有平台支持的 schema.org 类型。这套词汇表本身列出了几百种为食谱、机场之类狭窄用途设计的类型 schema.org；如果某个类型不在搜索引擎和 AI 助手已被证实真正使用的那几种之列，加了这个标签，今天对你没有任何实际作用。

如何确认你的结构化数据真的起作用了

把代码加上去只完成了一半工作，确认它能被正确读取是另一半。Google 免费提供的富媒体搜索结果测试工具，可以让你粘贴一个页面网址或直接粘贴代码本身，看看它检测出了哪些类型、又缺了哪些字段 Google。每次改动之后都跑一遍这个检测，能在代码出问题、造成实际损失之前先抓出打字错误——少打一个逗号就可能悄无声息地让整段标记失效。

不过这个测试只能告诉你代码本身格式正确。它不会告诉你，ChatGPT 在回答里是不是真的用了你确认过的营业时间，也不会告诉你 Perplexity 是不是仍然先推荐了你的竞争对手。这是另一个问题，也正是 Growli 要解决的问题：我们追踪各个平台上 AI 助手实际怎么谈论一家企业，标出“代码正确”和“回答正确”之间还存在的差距。如果你想真正核实自己的结果、而不是假设标记已经生效，可以看看产品如何运作。

FAQ