address标签仅语义标记作者联系信息，Schema.org地址结构化须通过JSON-LD实现；二者分工明确：前者供人读，后者供机器解析，需配合使用并用工具验证。
address 标签本身不直接包含 Schema.org 结构化数据，它只提供语义层面的“作者/拥有者联系信息”标记；真正的 Schema.org 地址结构化需通过独立的 JSON-LD 脚本实现。
address 标签的语义边界很明确
它仅用于标识当前页面的作者、网站运营方或内容责任主体的联系方式。比如个人博客页脚的住址、邮箱、电话——这些才是合法使用场景。它不是地址容器，不能用来包裹客户地址、门店位置或第三方服务点。
- 内部可含
<a href="mailto:...">、<a href="tel:...">、纯文本地址行 - 不可嵌套
<h3>或语义无关的元素（如地图 iframe、营业时间、社交图标） - 浏览器默认渲染为斜体，这是语义提示，不应靠 CSS 强行取消来“伪装”成普通区块
Schema.org 地址结构化必须另起 JSON-LD
要让搜索引擎和 AI 理解地址的精确含义（如街道、城市、经纬度），必须用 <script type="application/ld+json"> 声明，类型通常选 PostalAddress 或嵌套在 LocalBusiness、Organization 中。
- 地址字段要分层写：streetAddress、addressLocality、addressRegion、postalCode
- 地理位置建议补充 geo 字段：@type 为 GeoCoordinates，含 latitude 和 longitude
- 整个 JSON 必须是合法格式：双引号、无注释、无尾逗号、时间/URL 用完整 HTTPS
两者配合才完整：人读 + 机读分离
address 是给人和辅助技术看的清晰联系入口；JSON-LD 是给机器解析的精准数据源。它们职责不同，不能互相替代，也不应混用。
- 例如页脚有
<address>杭州市西湖区文三路123号</address>→ 这是人类可读的作者地址 - 同时页面
<head>或<body>顶部加一段 JSON-LD，描述同一地址的结构化字段 → 这是机器可读的 PostalAddress - 若该地址属于合作方而非本站作者，则 address 标签根本不该出现，只用 JSON-LD 标记即可
验证是否生效的关键动作
别只看页面显示效果，得用工具确认机器是否真正“读懂”了。
- 复制 JSON-LD 内容到 Google 的 Rich Results Test
- 上线后用 URL Inspection Tool 抓取，展开“富媒体搜索结果”查看识别状态
- 在浏览器 DevTools 的 Network 面板中搜索
ld+json，确认响应里确实返回了未被截断的原始 JSON
