合法的 itemtype 值必须同时满足:协议为 HTTPS、URL 可返回 HTTP 200 状态码、且精确指向 schema.org 官方定义的类型(如 https://schema.org/Product),大小写敏感、末尾无斜杠,不可用缩写、拼写变体或已弃用地址。

itemtype 必须是完整、可访问的 HTTPS URL,且必须来自 schema.org 或其他被 Google 明确认可的词汇表;写成 Person、http://schema.org/Person 或相对路径,结构化数据就直接失效。
怎么判断 itemtype 值是否合法
合法的 itemtype 值要同时满足三个硬性条件:协议必须是 HTTPS、URL 必须能返回 HTTP 200 状态码、内容必须指向 schema.org 官方定义的类型(如 https://schema.org/Product)。Google Structured Data Testing Tool 和 Rich Results Test 都会严格校验这三点,任一不满足就整个 itemscope 块被忽略。
- 用浏览器直接打开你写的
itemtypeURL,看是否能正常加载 HTML 页面(哪怕只是文档首页) - 不要用本地路径、缩写、或拼写变体:
https://schema.org/product(小写 p)和https://schema.org/Person/(末尾斜杠)都非法 - 避免使用已弃用的旧版 URL,比如
http://data-vocabulary.org/—— 自 2020 年起 Google 已停止支持
常见类型与对应 URL 怎么查
别猜,直接去 https://schema.org 搜索你需要的实体类型。搜索结果页顶部显示的 URL 就是唯一合法值。例如搜 “Article”,页面 URL 是 https://schema.org/Article,那就复制这个完整地址;搜 “LocalBusiness”,对应 URL 是 https://schema.org/LocalBusiness,不是 https://schema.org/business 或 https://schema.org/localbusiness。
- 所有标准类型都区分大小写,
https://schema.org/Offer≠https://schema.org/offer - 嵌套常用类型(如
author、review)必须各自有独立的itemtype,不能复用父级的值 - 如果页面同时描述多个不同实体(比如一篇食谱 + 作者 + 食材),每个都要配自己的
itemscope+itemtype,不能混在一个容器里
为什么用 schema.org 而不是自定义词汇表
Google、Bing、Yandex 等主流搜索引擎只认 https://schema.org/ 下的类型。你写一个看起来很规范的 https://yourdomain.com/vocab/Recipe,即使它返回 200,解析器也完全无视——因为没在白名单里。WHATWG 微数据规范允许自定义词汇表,但实际生态中只有 schema.org 被广泛实现和支持。
- 第三方词汇表(如
https://www.productontology.org/)仅作扩展用途,必须以 schema.org 类型为基类,不能单独使用 - 某些 CMS 或建站工具生成的
itemtype带有随机哈希或内部 ID(如https://www.php.cn/link/2ad908ea29b45df4bf8b2a3136690429),这类链接通常不可公开访问或已过期,务必替换为官方地址 - 移动端或 AMP 页面对
itemtype校验更严,错一个字符就导致富媒体结果(如星级、价格)无法展示
最常被忽略的一点:就算 URL 正确,如果服务器配置了严格 CSP 或重定向到非 HTTPS 页面,也会导致校验失败——itemtype 不只是“写对”,还要“能通”。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











