如何校验你的 LocalBusiness 结构化数据

结构化数据是站点里唯一可以彻底自查的部分，因为它是一份你能读懂的文档。下面是流程：看什么、去哪里看，以及每个结果意味着什么。

渲染器会输出什么，以及它何时是 LocalBusiness

每个站点的 JSON-LD 里都有一个组织实体。它的类型并不总是同一个，而规则是首先要理解的部分：

• 如果你自行指定了经营类型，实体就以那个类型输出——Dentist、PlumbingContractor、LegalService。具体的类型比通用类型说明得更多，也是更有用的断言。
• 如果站点的机构信息里带有邮政地址、电话号码或营业时间中的任意一项（且没有显式指定类型），该实体会以 LocalBusiness 输出。
• 否则以 Organization 输出。

这是刻意为之。在一个既没有地址也没有营业时间的站点上声明「LocalBusiness」，是一项页面自己无法支撑的断言，而一项无法支撑的断言，比没有这项断言更糟。

真正起作用的字段

• name——商家名称，取自品牌名，可覆盖。
• legalName——注册名称，当它与品牌名不同时使用。
• address——一个 PostalAddress，包含 streetAddress、addressLocality、addressRegion、postalCode 与 addressCountry。每个字段只在被设置时才输出，因此地址不完整就是真的不完整——而缺的往往正是本地搜索包需要的部分。
• telephone——客户真的会拨打的号码。
• openingHoursSpecification——营业时间，也是让类型切换为 LocalBusiness 的字段之一。
• priceRange——价格区间，在你想声明时使用。
• sameAs——社交主页，从页脚与机构自身配置中收集而来。
• logo 与 image——品牌标识，在设置时输出。
• url——规范来源地址，而不是某个页面地址。
• areaServed——你覆盖的地点，以地点实体的形式声明。只在你明确设置时才输出：覆盖某个城市的商家会说出来，什么都不覆盖的商家则什么都不声明。
• hasOfferCatalog——你提供的服务项目，以 Service 实体组成的服务目录。这是整段实体里平台无法推断的一部分：水暖工的目录不等于沙龙的目录。
• hasCredential——你持有的执照、资质认证或保险，带一个 credentialCategory。执照编号应当写在该资质的 name 里，因为读者找的就是那里。
• amenityFeature——客户会筛选的实体设施：停车位、淋浴、等候区。它们是场所的属性而不是商家的属性，所以不写成一句文案。
• servesCuisine——你供应的菜系，只对做餐饮的生意有意义。

这段结构化数据长什么样

渲染器输出的组织实体，所有字段都已填写：

json
{
  "@type": "LocalBusiness",
  "@id": "https://yourbrand.com/#organization",
  "name": "Your Brand",
  "url": "https://yourbrand.com/",
  "telephone": "+1-555-0100",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "18 Example Street",
    "addressLocality": "Portland",
    "addressRegion": "OR",
    "postalCode": "97204",
    "addressCountry": "US"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Monday",
      "opens": "09:00",
      "closes": "17:00"
    }
  ],
  "areaServed": [
    {
      "@type": "City",
      "name": "Portland"
    }
  ],
  "hasOfferCatalog": {
    "@type": "OfferCatalog",
    "name": "Services",
    "itemListElement": [
      {
        "@type": "Offer",
        "itemOffered": { "@type": "Service", "name": "Emergency appointments" }
      }
    ]
  },
  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "license",
      "name": "Your licence number"
    }
  ]
}

把它当文档读。里面每一个字段都是渲染器会输出的字段，而你能看到的每一个字段都是你自己设置的。

校验流程

1. 抓取已发布的页面，而不是预览。预览与线上可能不一致，而只在其中一个版本里正确的结构化数据，不能算正确。
2. 找到 JSON-LD。 它是页面源码里一个 <script type="application/ld+json"> 块。把它当文档读，而不是当字符串。
3. 核对实体类型。 是 LocalBusiness、Organization，还是你自行指定的那个类型？如果你预期是 LocalBusiness，实际却是 Organization，原因几乎总是三个字段之一：没有地址、没有电话、没有营业时间。如果你指定了业务类型，输出却仍然是 Organization，那说明这个类型没有传到渲染器。
4. 核对地址是否完整。 一个只有城市与省份、没有街道地址的邮政地址，落不下图钉。
5. 核对营业时间与站点是否一致。 与页面内容相矛盾的营业时间，比没有营业时间更糟。
6. 然后再跑谷歌的富媒体结果测试，针对线上 URL。它会告诉你这个块能不能被解析、它抱怨什么；但它不会告诉你这家生意是否真实存在，而后者才是真正决定本地搜索结果的部分。
7. 确认爬虫拿到的也是同一个页面。 只对登录用户可见、或者只出现在预览里的结构化数据，不等于爬虫拿到了结构化数据。