contact_address不是HTML标准标签,浏览器不识别;应使用语义化标签标记页面或article作者/维护者的联系信息,如邮箱、电话、物理地址等,且必须作为或的直接子元素。

contact_address 标签在 HTML 中并不存在
HTML 标准里没有 contact_address、_address 或类似下划线前缀的语义标签。浏览器不会识别它,搜索引擎也不会从中提取联系信息。如果你在模板或 CMS 里看到类似写法,大概率是自定义字段名或后端变量占位符,不是前端可直接渲染的 HTML 元素。
常见错误现象: —— 浏览器会把它当未知元素忽略样式,甚至可能触发解析异常;用 CSS 选中 contact_address 也无效。
用标准语义化方式标记地址信息
应该使用 address 元素(注意:是单数,不是 addresses),它专用于表示作者/拥有者(author/owner)的联系信息,包括物理地址、邮箱、电话、网站等。关键点在于它的语义范围仅限于“本页/本节内容的作者”,不是任意地址。
-
必须嵌套在、或等上下文中,单独放在里会失去语义- 不要用它标记用户输入的收货地址、门店列表地址——那些该用
+aria-label或微数据(Microdata)- 支持内联元素:
、都可以合法出现在内<address> 联系我们:<br><a href="https://www.php.cn/link/1be7371e7797ca4a5f6f651aa9c6eb43">contact@example.com</a><br><a href="https://www.php.cn/link/08f966f051116fbae0de3356816aac80">+86 10 1234 5678</a><br> 北京市朝阳区建国路 1 号 </address>
需要结构化数据时,用 Schema.org 的 ContactPoint
如果目标是让 Google 搜索结果展示“联系电话”“营业时间”等富摘要,光靠 HTML 不够,得加结构化数据。推荐用 JSON-LD 格式嵌入
ContactPoint类型,而不是依赖 HTML 标签名。容易踩的坑:
- 把
@type写成"Contact"(错误)或"Organization"(不精准),正确应为"ContactPoint" - 漏掉必需字段:
contactType(如 "customer service")、telephone、email—— 缺一项可能导致富摘要失效 - 地址字段必须拆成
address对象,不能直接塞字符串;且需包含addressLocality、addressRegion等子字段
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "ContactPoint", "contactType": "客服", "telephone": "+861012345678", "email": "support@example.com", "address": { "@type": "PostalAddress", "streetAddress": "建国路1号", "addressLocality": "北京市", "addressRegion": "北京市", "postalCode": "100022" } } </script>CMS 或模板引擎里遇到 _address 变量怎么办
这类命名(如
{{ author._address }}、$post->contact_address)通常是后端模型字段,需在模板中显式输出到标准 HTML 元素里,不能原样照搬。实操建议:
- 确认该字段是否已做 XSS 过滤;若未过滤,必须用对应语言的安全输出函数包裹(如 PHP 的
htmlspecialchars(),Jinja2 的|safe要慎用) - 避免直接插入
:先判断字段非空,再渲染,否则可能留下空标签影响语义 - 如果字段含 HTML(比如富文本编辑器录入的地址),需额外配置白名单标签(如允许
、),不能无条件innerHTML
复杂点在于:同一个“联系信息”可能在不同场景有不同结构需求——页面底部用
,搜索优化用 JSON-LD,API 返回用扁平字段。三者要各自维护,不能指望一个_address字符串自动适配全部。 - 不要用它标记用户输入的收货地址、门店列表地址——那些该用










