什么是微数据？
无抓取的通用抓取API检索网页以进行结构化数据提取工作流，包括那些可见内容由JavaScript渲染的页面。
简而言之
- 微数据为现有HTML添加可机读的意义。 它给普通元素添加属性，而不是将结构化数据保存在单独的文档中。
- 一个微数据项有一个类型和命名属性。 核心属性定义范围、词汇、身份、属性名称以及对非后代元素的引用。
- Schema.org和微数据是不同的层次。 Schema.org提供词汇；微数据提供一种将该词汇附加到HTML的语法。
- 微数据有用，但与页面标记紧密耦合。 模板的变化可以破坏注释或提取规则，即使可见页面仍然看起来正确。
- 对于搜索标记，JSON-LD通常更容易维护。 当语义应保持附加到可见元素时，微数据仍然有效，可能更适合。
微数据是一种内置于HTML的结构化数据语法。它允许发布者识别页面上描述的事物，例如产品、事件、人员、食谱或文章，并标记与该事物相关的属性。浏览器仍然呈现相同的标题、链接、图像和文本。额外的属性为解析器、爬虫、搜索系统、可访问性工具和数据提取软件创建了额外的可机读层。
该 WHATWG微数据HTML标准部分 定义了处理模型。这个标准背景很重要，因为微数据不是一个可视组件或搜索引擎插件。它是文档本身的一部分，其含义遵循有关项目范围、属性值、URL和嵌套项的规则。
微数据如何表示实体
微数据将实体表示为具有零个或多个属性的项目。一个项目始于一个携带 itemscope 属性的HTML元素。可选的 itemtype 属性提供一个或多个定义项目所代表的实体类型的词汇URL。携带 itemprop 的后代元素为该项目贡献命名值。
值并不总是来自可见文本。链接贡献其URL，图像贡献其源URL，时间元素可以贡献一个可机读的日期时间值，元元素可以携带一个不需要作为普通散文出现的值。因此，解析器遵循微数据的值规则，而不是去掉标签并读取剩余的任何文本。
两个附加属性涵盖简单嵌套无法表达的关系。 itemid 如果词汇支持，它会给一个类型项提供一个全局标识符。 itemref 指向同一文档中其他元素，这些元素的属性应该包含在该项中。这些特点帮助处理真实模板，但它们也意味着提取器必须实现完整模型，而不是扫描孤立的 itemprop 字符串。
微数据属性一目了然
| 属性 | 角色 | 常见错误 |
|---|---|---|
| itemscope | 创建一个新项。 | 在没有清晰拥有项的情况下添加属性。 |
| itemtype | 将项链接到词汇类型。 | 在期望绝对词汇URL的地方使用标签。 |
| itemprop | 命名当前项的一个属性。 | 假设可见文本始终是提取的值。 |
| itemid | 在允许时全球识别一个类型项。 | 将其视为任意数据库键。 |
| itemref | 包含引用元素的属性。 | 在提取过程中忽略引用节点。 |
Schema.org的适用位置
Schema.org 是一个共享的词汇，而 Microdata 是一种序列化语法。 Schema.org 入门材料 文档类型如产品和事件以及属性如名称、图像和开始日期。发布者可以使用 Microdata、RDFa 或 JSON-LD 表达许多相同的术语。更改语法并不会自动更改词汇或预期的实体模型。
这种区分可以防止常见的规划错误。团队可能会说它“使用 Schema”，但实际的问题是分开的：哪种词汇类型正确描述商业实体？哪种格式适合呈现堆栈？哪个消费者支持所选组合？哪些验证规则适用于特定搜索特性？独立回答这些问题可以产生更干净的标记和更可靠的提取。
解析器如何提取 Microdata
一个符合规范的提取器从顶层项目开始，确定每个项目的类型和标识符，然后从后代和任何引用的节点解析属性值。嵌套项仍然保持结构化值，而不是被压缩成无关的文本。带有 URL 值的属性是根据文档基础 URL 解析的，因此最终值可能与源 HTML 中找到的字面属性不同。
生产提取增加了另一个问题：应该解析哪个文档？服务器 HTML 可能已经包含 Microdata，或者客户端应用程序可能会在 JavaScript 执行后添加属性。因此，原始 HTTP 响应和渲染的 DOM 可能会暴露不同的结构化数据。获取阶段应与输出一起记录，以便下游用户知道数据集反映的是源 HTML 还是浏览器渲染状态。
Microdata、JSON-LD和RDFa
Microdata 将属性直接放置在 HTML 元素上。JSON-LD 通常在脚本块中保留一个 JSON 对象，与可见内容分开。RDFa 也对标记进行注释，但它来自 RDF 数据模型，并支持超出典型 Schema.org 发布工作流程的链接数据模式。这三者都可以表达结构化数据，但它们创造了不同的维护和提取权衡。
Google Search Central 的结构化数据指导 在网站设置支持时建议使用 JSON-LD，因为与呈现的分离使嵌套数据更易于维护。该推荐并不使 Microdata 无效。当模板已经将每个语义属性绑定到可见元素时，Microdata 是合理的，组织希望注释与该元素一起移动。
| 问题 | Microdata | JSON-LD | RDFa |
|---|---|---|---|
| 值的位置 | 在 HTML 元素上 | 在 JSON-LD 块中 | 在 HTML 元素上 |
| 呈现耦合 | 高 | 较低 | 高 |
| 典型强度 | 可见内容对齐 | 模板维护 | 链接数据表达 |
| 提取需求 | HTML 友好的项目解析 | JSON 解析加图形处理 | RDFa 友好的解析 |
常见的 Microdata 失败模式
破坏的范围是最基本的失败。属性可能放置在拥有相关项目的元素之外，导致解析器将其附加到其他地方或忽略它。嵌套实体也可能被错误建模：地址通常应该是一个具有自己属性的项目，而不是从附近的任何文本拼凑而成的字符串。
词汇漂移会导致更微妙的缺陷。属性名称对于一种类型可能有效，但对于另一种类型可能无效，或者搜索特性可能需要一般词汇认为是可选的字段。因此，验证应在两个层面上进行：语法和数据模型正确性，然后是特定消费者的合格检查。通过一个测试并不能保证丰富的结果或任何特定呈现。
重复真相是另一个风险。一个网站可能在 JSON-LD 旁边携带 Microdata，并在每个地方暴露不同的价格、日期或规范 URL。提取器应保留来源，并选择权威表示或报告冲突。出版者应从一个数据源生成所有结构化格式，而不是独立编辑它们。
搜索外观之外的实际用途
实体提取
爬虫可以将产品、事件、组织或文章属性映射到类型记录，而无需从周围的散文推断每个字段。
质量保证
监控工作可以将可见值与机器可读值进行比较，标记过时的价格、缺失的标识符或无效的嵌套。
内容迁移
迁移管道可以在内容系统之间移动页面时保留实体元数据，前提是词汇映射经过审查。
数据集丰富
Microdata 可以提供明确的名称、日期和关系，以补充文本提取，尽管这些值仍需验证。
如何选择和维护 Microdata
选择 Microdata 当语义注释自然地属于稳定的服务器渲染元素并且开发团队适合将标记作为模板的一部分进行测试时。在实体图复杂、多个可见元素贡献于一个记录或内容和展示在不同时间表上发生变化时，优先选择 JSON-LD。当链接数据要求使其图模型更加适合时，优先选择 RDFa。
维护应包括模板级测试、代表性渲染页面、词汇验证和特定于消费者的检查。跟踪页面 URL、捕获方法、提取时间戳、项目类型、原始属性值、规范化值和验证结果。当重新设计移动属性或客户端脚本延迟插入时，这些字段使得变更可以被解释。
对于网络规模的集合，获取和解析应保持分开。 Scrapeless 通用抓取 API 可以将页面内容提供给提取阶段，同时解析器应用 Microdata 规则并将结果映射到稳定的下游模式中。审查 Scrapeless 定价 在估算计划页面量的获取成本时。
结论
Microdata 是 HTML 原生的结构化数据：项目定义实体，属性定义值，词汇提供共享含义。当语义注释与稳定的可见元素保持一致时，它工作得很好。可靠的使用依赖于解析完整的项目模型、捕获正确的页面表示、验证词汇规则和跟踪来源，当多个结构化格式共存时。
准备建立结构化数据工作流吗？
使用 Scrapeless 获取公共网页，然后验证并将 Microdata 映射到您的管道可以信任的记录中。
开始免费 →常见问题
Microdata 与 Schema.org 是一样的吗？
不是。Microdata 是用于表达项目和属性的 HTML 语法，而 Schema.org 是定义许多常用类型和属性名称的词汇。Schema.org 术语也可以用 JSON-LD 或 RDFa 表达。
Microdata 会提升搜索排名吗？
Microdata 帮助支持的消费者理解符合条件的结构化信息，但添加它并不保证排名提高或特定搜索功能。可见页面、内容质量、技术资格和消费者政策仍然适用。
页面可以同时使用 Microdata 和 JSON-LD 吗？
是的，页面可以包含这两种格式，但重复的实体应一致。冲突的价格、日期、标识符或规范 URL 为验证者和提取管道带来了歧义。
提取器应该读取源 HTML 还是渲染的 DOM？
提取器应该读取包含权威标记的表示。服务器渲染的 Microdata 时，源 HTML 更快；当 JavaScript 添加或更改属性时，渲染的 DOM 是必要的。
Microdata 数据集应保留什么？
一个有用的数据集应保留页面 URL、捕获方法、项目类型、项目标识符（如存在）、原始属性值、规范化值和验证结果。来源使后续纠正和审计成为可能。