在台湾部署了 LocalBusiness Schema，却始终没有被 AI 引擎提及？问题很可能不在代码，而在数据没有对齐。当用户向 Perplexity 或 ChatGPT 提问“台北市信义区有哪些值得推荐的牙医？”时，AI 会先把你官网上的名称、地址和电话号码，与 Google 商家资料、地图及行业目录进行交叉核对。只要这些渠道出现三个版本，它通常宁可不提及你，也不会替你猜哪个才正确。因此，真正影响信息能否被引用的，是 NAP（名称、地址、电话）一致性。Schema 语法只是把这些事实封装成机器可读的格式。本文将按实施顺序说明：选择类型、填写地址、设置营业时间，最后统一各个平台的 NAP。
为什么 AI 引擎对 LocalBusiness 信息格外敏感
AI 引擎回答本地问题时，需要能够被清晰提取的事实：门店在哪里、现在是否营业、电话号码是什么。中文地址对机器并不友好。“台北市信义路5段7号”和“台北市信义区信义路5段7号”在人看来是同一个地点，但提取模型可能将它们识别为两个实体。LocalBusiness Schema 通过固定字段拆分并标记这些信息，相当于把答案直接交给引擎，减少其猜测和比对的成本。引擎需要猜测的部分越少，就越有把握把你写进答案。
第 1 步：选择正确的 @type，不要一律填写 LocalBusiness
schema.org 在 LocalBusiness 之下提供了数十种子类型。类型越具体，引擎越容易理解你的业务。例如，会计师事务所标记为通用的 LocalBusiness，与标记为 AccountingService，会直接影响 AI 判断“这是不是用户正在寻找的专业服务”。应先选择与业务最接近的子类型；确实找不到时，再退回上一级使用通用类型。
- 餐厅与咖啡店：Restaurant、CafeOrCoffeeShop
- 牙医与诊所：Dentist、MedicalClinic
- 律师与土地代理服务：Attorney、LegalService
- 会计与记账事务所：AccountingService
- 零售门店：Store，还可细分为 ClothingStore、HardwareStore 等
- 美容院与美发店：BeautySalon、HairSalon
- 只有确实找不到对应类型时，才使用通用的 LocalBusiness。
地址字段：将台湾行政区划映射到 PostalAddress
地址是最容易填错的部分。PostalAddress 有固定字段，台湾的行政区划层级需要逐项对应。不要把从县市到门牌号的完整地址全部塞进 streetAddress，否则引擎将无法准确提取县市和行政区。
- addressCountry：填写国家或地区代码“TW”，不要填写英文或中文名称
- addressRegion：填写直辖市或县，例如“台北市”“新北市”
- addressLocality：填写区、乡或镇，例如“信义区”
- streetAddress：填写道路、段、巷和门牌号，例如“信义路5段7号”
- postalCode：填写 3+3 邮政编码，例如“110011”
- geo：填写经纬度，坐标必须与 Google 地图上的图钉位置一致
营业时间：openingHoursSpecification 怎样填写才不出错
营业时间使用 openingHoursSpecification，dayOfWeek 标记对应日期，opens 和 closes 则以 24 小时制的 HH:MM 格式填写。门店如果午间休息，不要直接写成 09:00 至 21:00，而应拆成两个时段，例如 11:00–14:00 和 17:00–21:00，否则 AI 可能告诉用户下午 3 点仍在营业。法定节假日不营业，就不要列入常规营业时间。若全天 24 小时营业，opens 和 closes 都填写 00:00。春节或法定节假日等临时调整，应使用 specialOpeningHoursSpecification 并注明适用日期，比直接修改常规时间更稳妥。修改后还要同步更新 Google 商家资料中的节假日营业时间，确保两边表述一致。
NAP 一致性：Schema 只是其中一个数据节点
Schema 写得再规范，只要其他渠道的信息对不上，前面的工作就会大打折扣。各个平台上的名称、地址和电话号码应逐字一致，包括标点和格式。电话号码尤其容易混乱：官网写“02-1234-5678”，Google 商家页面写“(02)12345678”，Schema 又写“+886-2-1234-5678”。人能理解它们是同一个号码，机器却可能将其视为三条不同信息。建议结构化数据统一采用 E.164 格式“+886212345678”。面向用户展示的号码可以另行排版，但 Schema 中只保留一种格式。
- Google Business Profile
- 官网的 Schema、页脚和联系页面
- Facebook、Instagram 商家页面
- Apple 地图及各类导航平台
- 行业目录与本地黄页
我们为客户审查本地企业官网时，最常见的问题并不是缺少 Schema，而是同一个电话号码在四个平台上出现四种写法。对 AI 引擎来说，这可能不是同一家门店，而是四家看起来十分相似的门店。— Tenten GEO audit notes
上线前验证清单
- 使用 Google Rich Results Test，确认 Schema 能被正常解析且没有错误
- 使用 Schema Markup Validator 检查各字段的语法
- 把 Schema 中的 NAP 原样粘贴到 Google 商家资料旁逐项比对，找出所有不一致之处
- 直接向 AI 引擎提出本地问题，检查其回答中的地址和营业时间是否正确
- 上线后定期复查；地址或电话号码一旦变更，立即同步更新所有平台
实施 LocalBusiness Schema 的难点，从来不是那段 JSON-LD，而是长期维护散落在十多个平台上的事实，让它们始终保持一致。如果你不确定 AI 引擎会把你的 NAP 和结构化数据识别成几家门店，Tenten GEO 的 30 天 GEO 审查可以一次找出这些缺口。如果想先快速明确方向，也可以预约 30 分钟 GEO 诊断，我们会使用你的真实网站地址进行本地查询。
