address标签仅语义标记作者联系信息，schema.org地址结构化须通过json-ld实现；二者分工明确：前者供人读，后者供机器解析，需配合使用并用工具验证。

address 标签本身不直接包含 Schema.org 结构化数据，它只提供语义层面的“作者/拥有者联系信息”标记；真正的 Schema.org 地址结构化需通过独立的 JSON-LD 脚本实现。

address 标签的语义边界很明确

它仅用于标识当前页面的作者、网站运营方或内容责任主体的联系方式。比如个人博客页脚的住址、邮箱、电话——这些才是合法使用场景。它不是地址容器，不能用来包裹客户地址、门店位置或第三方服务点。

• 内部可含 <a href="mailto:..."></a>、<a href="tel:..."></a>、纯文本地址行
• 不可嵌套 <h3></h3> 或语义无关的元素（如地图 iframe、营业时间、社交图标）
• 浏览器默认渲染为斜体，这是语义提示，不应靠 CSS 强行取消来“伪装”成普通区块

Schema.org 地址结构化必须另起 JSON-LD

要让搜索引擎和 AI 理解地址的精确含义（如街道、城市、经纬度），必须用 <script type="application/ld+json"></script> 声明，类型通常选 PostalAddress 或嵌套在 LocalBusiness、Organization 中。

• 地址字段要分层写：streetAddress、addressLocality、addressRegion、postalCode
• 地理位置建议补充 geo 字段：@type 为 GeoCoordinates，含 latitude 和 longitude
• 整个 JSON 必须是合法格式：双引号、无注释、无尾逗号、时间/URL 用完整 HTTPS

两者配合才完整：人读 + 机读分离

address 是给人和辅助技术看的清晰联系入口；JSON-LD 是给机器解析的精准数据源。它们职责不同，不能互相替代，也不应混用。

• 例如页脚有 <address>杭州市西湖区文三路123号</address> → 这是人类可读的作者地址
• 同时页面 或 顶部加一段 JSON-LD，描述同一地址的结构化字段 → 这是机器可读的 PostalAddress
• 若该地址属于合作方而非本站作者，则 address 标签根本不该出现，只用 JSON-LD 标记即可

验证是否生效的关键动作

别只看页面显示效果，得用工具确认机器是否真正“读懂”了。

• 复制 JSON-LD 内容到 Google 的 Rich Results Test
• 上线后用 URL Inspection Tool 抓取，展开“富媒体搜索结果”查看识别状态
• 在浏览器 DevTools 的 Network 面板中搜索 ld+json，确认响应里确实返回了未被截断的原始 JSON