本地企业在互联网上往往依赖地图、搜索或生活服务平台获得曝光，但如果官网没有提供结构化数据，搜索引擎只能从页面文字里猜测地址、电话和营业时间，一旦页面排版复杂，猜测结果就容易出错。结构化数据的作用，就是把这些关键信息用统一的语法明确告诉搜索引擎，比如告诉它这是一家餐厅，位置在哪个街道，电话是多少，周一到周五几点开门几点关门。这样一来，搜索结果就有机会直接展示这些字段，用户不用进入网站就能判断是否要前往。对于有线下门店的企业，这种标记的转化价值非常直接。
结构化数据标记解决什么问题
很多本地企业网站会在页脚或者联系我们页面展示地址和电话，但搜索引擎抓取页面后并不一定能准确关联到具体门店。比如同一个页面出现多个电话号码，或者地址里包含楼层、房间号，机器很难判断哪个是主要电话。结构化数据把字段明确分开，name、address、telephone、openingHours这些属性有固定的含义，搜索引擎可以直接解析。
在Schema.org的体系里，本地企业类型统称为LocalBusiness，下面还可以细分为Restaurant、Store、MedicalClinic、LodgingBusiness等。使用更具体的类型，搜索引擎能够理解企业的行业属性，在相关搜索中给予更准确的展示。地址使用PostalAddress类型，电话使用telephone字段，营业时间使用openingHours或者openingHoursSpecification字段。这些字段不是随便命名的，是Schema.org定义的规范，搜索引擎都认可。
地址和电话怎么标记才准确
地址标记需要拆分成多个子字段，而不是把完整地址写在一个字符串里。streetAddress用来写街道门牌号，addressLocality写城市或区，addressRegion写省或州，postalCode写邮政编码，addressCountry写国家代码，比如CN代表中国。拆分得越细，搜索引擎越容易把门店定位到地图上，也越容易和本地搜索结果匹配。对于地址中的楼层、房间号，可以放在streetAddress里，但不要省略街道名。
| 字段 | 作用 | 填写示例 |
|---|---|---|
| streetAddress | 街道门牌号 | 中关村大街1号 |
| addressLocality | 城市或区 | 北京市海淀区 |
| addressRegion | 省或州 | 北京市 |
| postalCode | 邮政编码 | 100080 |
| addressCountry | 国家代码 | CN |
电话标记推荐使用国际通用格式，也就是加号和国家的电话区号。例如中国的座机可以写成 +86-10-12345678，手机可以写成 +86-138-0000-0000。加号告诉搜索引擎这是国际格式，能够避免本地号码无法识别。如果企业有多个联系电话，比如前台、售后、加盟热线，可以把主电话放在telephone字段，其他号码放在contactPoint里，并注明类型。不要把所有电话都堆在同一个字段，那样会降低准确性。
有多个门店时，每个门店应该是一个独立的LocalBusiness节点，分别标记各自的地址、电话和营业时间。不要只放总部地址而让所有分店都指向同一个位置。如果是连锁品牌，还可以用parentOrganization字段关联到总品牌，但具体门店信息必须是独立的。
营业时间标记的两种常见写法
营业时间字段可以使用简洁的文本格式，也可以使用结构化的对象格式。简洁格式是openingHours字段，写法类似 Mo-Fr 09:00-18:00，表示周一到周五上午九点到下午六点。这种写法对搜索引擎友好，也方便人工阅读，但缺点是无法精确表达节假日、午休时间或者一周内不同时段。比如某门店周三下午休息，只用openingHours就很难写清楚。
更灵活的方式是使用openingHoursSpecification字段，它是一个数组，每一组都包含dayOfWeek、opens、closes三个属性。dayOfWeek可以写Monday到Sunday，opens和closes使用24小时制的HH:MM格式。如果同一天有分段营业，比如上午10点到14点，下午17点到22点，可以写成两组相同的dayOfWeek但不同的opens和closes。如果24小时营业，opens写00:00，closes写23:59，不过不同搜索引擎对24小时营业的识别有差异，建议同时在页面上用文字说明。
节假日特殊营业时间可以用specialOpeningHoursSpecification字段，但要额外标明日期范围。多数本地企业先做好常规营业时间标记就足够了，节假日信息如果变动频繁，可以考虑用插件或管理工具自动更新。
JSON-LD标记示例与放置位置
目前搜索引擎普遍推荐使用JSON-LD格式来嵌入结构化数据。它是一段独立的JavaScript对象，用script标签的application/ld+json类型包裹，放在网页的head或者body里都可以。和微数据、RDFa相比，JSON-LD不要求把标记写进HTML元素的属性里，维护起来更简单，也不容易破坏页面结构。下面是一个本地餐厅的简化示例。
<code><script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Restaurant",
"name": "示例餐厅",
"address": {
"@type": "PostalAddress",
"streetAddress": "中关村大街1号",
"addressLocality": "北京市海淀区",
"addressRegion": "北京市",
"postalCode": "100080",
"addressCountry": "CN"
},
"telephone": "+86-10-12345678",
"openingHoursSpecification": [{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "09:00",
"closes": "18:00"
}]
}
</script></code>这段数据需要与页面上的可见信息保持一致。如果页面写的是上午九点到下午五点半，结构化数据里却写18:00，搜索引擎会认为数据矛盾，可能放弃展示丰富摘要。所以改营业时间时，要同时更新页面文字和JSON-LD。多个门店的JSON-LD可以写成数组，也可以分别放在各门店页面中，但每个页面最好标记当前页面所对应的门店。
标记后如何检查和避免常见错误
标记完成后不能只管上线，还要用官方工具验证。可以打开Google Rich Results Test，输入网页地址或者粘贴代码，它会显示能触发哪些搜索功能，也会指出字段错误。Schema.org的Schema Markup Validator也能检查JSON-LD语法是否正确。验证通过并不等于一定会展示丰富摘要，展示与否还取决于网站质量、搜索需求和Google的算法，但至少保证了数据可读。
- 只写openingHours而不写星期，导致搜索引擎无法判断具体日期。
- 电话使用本地格式，缺少国家代码，或者使用分隔符混乱。
- 地址没有拆分字段，全部塞进streetAddress。
- 页面可见信息与标记内容不一致。
- 多个门店共用一个地址或电话。
- JSON-LD脚本没有正确闭合，或者使用了普通script标签导致不解析。
如果企业的营业时间变化频繁，比如临时闭店或节假日调整，建议在页面上提前用文字公告，同时更新结构化数据。Google Search Console里的增强效果报告可以查看本地商家展示情况，发现覆盖或错误后及时修正。对于大多数本地企业来说，把这套标记做好，是成本很低但收益直接的优化动作，尤其是地址电话营业时间这三类用户最常看的信息。