17370845950

微数据是否被识别，关键看 itemscope 和 itemtype 是否成对出现；浏览器和搜索引擎仅当元素同时具备有效的 itemscope 和可访问的 itemtype URL（如 https://schema.org/Person）时才识别，单独 itemprop 无效，且 itemtype 不可缩写或省略协议。

微数据是否被识别，关键看 itemscope 和 itemtype 是否成对出现

浏览器和搜索引擎只在元素同时具备 itemscope（声明一个微数据项）和有效的 itemtype（指向一个已知的词汇表 URL）时，才将其视为可识别的微数据结构。单独写 itemprop 没有意义——它必须嵌套在有 itemscope 的祖先元素内。

• itemtype 必须是完整、可访问的 HTTP/HTTPS URL，例如 https://schema.org/Person；http://schema.org/Person 也行，但不推荐用短协议（//schema.org/Person）——部分解析器会忽略
• 常见误写：itemtype="Person" 或 itemtype="schema:Person" —— 这些不会被任何解析器识别
• 验证工具（如 Google Rich Results Test）会直接忽略无 itemscope 的 itemprop，控制台也不会报错，容易误以为“写对了”

怎么快速判断页面里有没有被识别的微数据

最直接的方式是用浏览器开发者工具检查 document.getItems()（仅 Chromium 内核支持），或更通用的方法：提取所有带 itemscope 的元素并检查其 itemType 属性值。

const items = document.querySelectorAll('[itemscope]');
items.forEach(el => {
  console.log('Scope:', el, 'Type:', el.itemType); // 注意是 itemType（驼峰），不是 itemtype（小写）
});

• el.itemType 返回的是一个 DOMSettableTokenList，如果为空或无效 URL，其 .length 为 0 或内容不可解析
• Safari 和 Firefox 不支持 getItems()，也不暴露 itemType 属性，所以靠 JS 检测有兼容性盲区；此时只能依赖外部验证工具
• 不要依赖 getAttribute('itemtype') 判断有效性——它只是返回字符串，不管 URL 是否合法或能否被解析

常见 schema.org 类型识别失败的三个硬伤

即使语法全对，itemtype 指向 schema.org 也常因细节失效：

• 用了重定向 URL：比如 https://schema.org/Organization 是 301 跳转到 https://schema.org/Thing 的别名页，但某些旧爬虫只认最终目标 URL，建议直接用规范地址（查 schema.org 全量列表确认）
• itemprop 值类型不匹配：例如给 price 传字符串 "$29.99"，而 schema.org 要求 Number 或带 content 属性的数值，应写作
• 嵌套层级断裂：比如 itemtype="https://schema.org/Restaurant" 下写了 itemprop="address"，但没在该元素内再加 itemscope itemtype="https://schema.org/PostalAddress" —— 地址对象不会被结构化识别

用 itemref 关联跨区域属性时最容易漏掉的检查点

当 itemprop 所在元素不在 itemscope 容器内部时，需用 itemref 引用其 id。但这个机制非常脆弱：

立即学习“前端免费学习笔记（深入）”；

• itemref 只能引用**同级或父级文档流中已存在的元素**，不能跨 、不能引用 display: none 元素（部分解析器会跳过）
• 多个 itemref 值必须用空格分隔，写成逗号或换行会被当成单个无效 ID
• 被引用元素本身**不能有 itemscope**，否则它会被当作独立项处理，导致属性归属错乱

The Hobbit
J.R.R. Tolkien

微数据识别不是“写了就生效”，而是“写了 + 符合 schema 约束 + 层级闭合 + URL 可解析 + 工具能抓取”五个条件同时满足。其中 itemtype 的 URL 有效性和嵌套结构完整性，是线上排查时最常卡住的地方。