什么是 LocalBusiness 结构化数据——它该包含哪些内容，以及它换不回什么

同一个说法有两种写法：白话说的是 local business schema，词汇表自己的拼法是 LocalBusiness。它们指的是同一件事——LocalBusiness 是 schema.org 里的那个类型，而 local business schema 就是使用它的那段结构化数据：网站发布的 JSON-LD，让机器把你的事实当数据取走，而不是从文案里猜。

Schema.org LocalBusiness 是一种国际通用的结构化数据语义规范。实体商家通过在网页 HTML 源码中嵌入标准化 JSON-LD 代码，向搜索引擎明确声明自身的企业名称、实体地址、服务范围、营业时间与联系方式。

普通人类访客通过肉眼阅读网页中的图文排版，而搜索引擎爬虫则直接解析 JSON-LD 数据图谱，以获取确定性的客观事实。

该声明哪个类型

LocalBusiness 是通用类型，对大多数本地行业来说它就是正确答案。但它不是可用的最具体的一个，而更具体的那个能说明更多事。

Dentist、LegalService、PlumbingContractor、AccountingService、GeneralContractor、Restaurant、BeautySalon——这些都是 LocalBusiness 的子类型。机器读到它们时，既知道这是哪门生意，也知道它在哪里：通用类型说的是「一家在这条街上的企业」，子类型说的是「这条街上的一个水管工」。

前提是这个类型得是页面撑得住的。一个既没有地址、也没有电话、也没有营业时间的站点，根本撑不起 LocalBusiness——它身上没有任何「本地」的成分——硬写上去就是一段自己兑现不了的声明。有这些事实、但没有更细行业类型的站点，得到的是 LocalBusiness；设定了业务类型的站点，得到的就是那个类型。如何核验你的 LocalBusiness 结构化数据写的是这条规则在渲染器里怎么跑。

LocalBusiness 数据能做什么，不能做什么

当潜在客户在手机上发起高意向搜索（如「附近的牙医」或「西雅图水暖抢修」）时，真正给出答案的地图结果来自谷歌商家资料（Google Business Profile），而不是这个网页。商家资料才是那份名录；你网站上的 schema 只是对同一组事实的声明。

这个区分决定了这段标记值多少钱。谷歌的本地排名会权衡三件事：

1. 相关性（Relevance）：企业提供的专业服务与用户的搜索意图是否精确契合？
2. 权威度（Prominence）：该商户是否具备正规备案、营业资质与良好口碑？
3. 地理距离（Distance）：该商家的实际坐诊或服务半径是否处于用户所在区域内？

LocalBusiness 结构化数据提供的是其中两项赖以计算事实的部分——你的类目、地址与坐标——这样谷歌不必从文案里猜测，名录与网站也不会在无人察觉的情况下互相矛盾。但它对第二项毫无贡献：权威度来自评价、外部引用与历史，标记无法凭空断言。它也不会创建、预留或填充任何一个地图结果。它做的是让你的站点对机器可读，并让它与你本就在维护的那份商家资料保持一致。

一个完整的本地商业数据图谱必须包含的关键属性

合规的 LocalBusiness JSON-LD 代码应当包含以下核心字段：

• @type 细分行业类型：优先使用精准行业子类型（如 Dentist、LegalService、PlumbingContractor、Restaurant、BeautySalon），而非泛化的 Organization。
• name 与 url：官方经过工商核验的企业商号与标准化主域名。
• telephone 电话：符合国际 E.164 标准的联系电话，支持移动端一键拨号。
• address 物理地址：拆分为街道、城市、省份、邮编的标准地址结构。
• geo 经纬度坐标：高精度的 GPS 经纬度数值。
• openingHoursSpecification 营业时段：周一至周日各天的精确开门与闭门时间段。
• priceRange 价格梯次：公开的消费区间标注（如 "$$"、"$$$"）。
• areaServed 服务范围：你覆盖的地点，以地点实体的形式声明。
• hasOfferCatalog 服务目录：你提供的服务项目，以 Service 实体组成的服务目录声明。
• hasCredential 资质认证：你持有的执照、资质认证或保险，带一个 credentialCategory。
• amenityFeature 实体设施：客户会筛选的实体设施——停车位、淋浴、等候区。
• servesCuisine 菜系：你供应的菜系，只对做餐饮的生意有意义。

同一份清单，作为一个文档——这就是标记实际的样子：

json
{
  "@type": "Dentist",
  "@id": "https://yourbrand.com/#organization",
  "name": "Your Brand Dental",
  "url": "https://yourbrand.com/",
  "telephone": "+1-555-0100",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "18 Example Street",
    "addressLocality": "Portland",
    "addressRegion": "OR",
    "postalCode": "97204",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 45.5152,
    "longitude": -122.6784
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Monday",
      "opens": "09:00",
      "closes": "17:00"
    }
  ]
}

上面每一个属性都是渲染器会输出的属性，也每一个都是你自己设置的：@type 用的是细分类型而不是 Organization，@id 则是页面其余结构化数据所引用的那个实体。

机器读到的那份文档

关于这段标记，有两件事值得分开讲，因为它们是结构化数据里最常被混为一谈的两件事。

那张图谱。 @id 不是装饰。它是页面其余结构化数据所引用的那个实体的标识符——服务目录、资质认证、营业时间全都挂在它下面；读得懂图谱的消费者才能顺着线走过去。站点结构，以及你的文案放在哪里讲的是这段标记写在哪一层。

那份重复。 上面每一个字段，都是页面别处已经显示过的事实：页脚上的地址、联系页上的营业时间、价格页上的服务项目。这也是这段标记是「派生」而不是「手写」的原因。手写的那份，是你迟早会改动的事实的第二份拷贝，而两份拷贝一定会漂移——那正是这段标记要避免的分歧。

怎么检查你真正发布出去的那一份

结构化数据是站点上唯一可以彻底检查的部分，因为它就是一份你能读懂的文档。流程的简版是这样：

1. 取已发布的页面，不是预览页——两者可能不同，而只在其中一个里是对的 schema，并不算对。
2. 在源码里找到 <script type="application/ld+json"> 那一块，当文档来读，而不是当字符串读。
3. 查类型：是 LocalBusiness、Organization，还是你设定的子类型？如果你以为会是 LocalBusiness 而拿到的是 Organization，原因几乎总是三个字段之一——没有地址、没有电话、没有营业时间。
4. 查地址完整：只有城市和省份、没有街道地址，地图上落不下针。
5. 查营业时间与页面一致。与页面矛盾的营业时间，比没有营业时间更糟。
6. 然后拿线上地址去跑谷歌的 Rich Results Test。它会告诉你这段标记能不能解析、会抱怨什么；它不会告诉你这家生意是不是真的，而后者才是决定本地结果的那部分。

如何核验你的 LocalBusiness 结构化数据是完整流程，包括决定类型的那些字段。

Zeso 的全自动数据图谱引擎

在 Zeso 上，商家无需手工编写复杂的 JSON-LD 代码。只要在后台完善营业时间、实体地址与服务类目，平台便会在静态编译时自动嵌入 Schema.org 结构化数据——它取自页面上早已展示的同一批事实，因此两者不会各说各话。类型也是同一套规则：资料里设了业务类型，就给你那个子类型；地址、电话与营业时间三者齐备，实体才是 LocalBusiness，而不是泛泛的 Organization。