我进入结构化数据构成的深度越多，它似乎就越复杂和详细。甚至可以标记页面的区域，如页脚，页眉，侧边栏，单个菜单元素等。我猜一个页面很容易包含80％的模式标记和20％的内容，如果太认真。 ：）
向网站的潜在数百个实际内容页面添加多个粗略标记框架（Article或f）是否真的有用，并且不应该只有一个在专门的联系/业务信息页面上包括完整的作者信息以及营业时间，联系方式等。我担心臃肿。对于某些类型的页面，建议使用哪种标记，哪些标记可以省略，因为搜索引擎无论如何都会从网站的其他部分编译信息？
答案 0 :(得分：0)
如果您只关心大型搜索引擎服务中的用户可见搜索结果功能（例如， Bing ， Google搜索， Yahoo！Search 和 Yandex ，这一切都恰好赞助了Schema.org），答案很简单：提供要识别的搜索引擎文档。
这些用户可见的搜索结果功能是搜索引擎使用Schema.org结构化数据“做”的唯一内容吗？可能不是。他们可能会使用结构化数据来更好地理解页面内容，并且最有可能分析他们将来可以提供的其他功能。请参阅示例Dan Brickley’s (he is Google’s Schema.org representative) posting about this。但当然，所有这些通常都没有被搜索引擎记录。因此，如果您也关心这一点，那么答案就是：提供对搜索引擎有用的东西。
搜索引擎是唯一对Schema.org结构化数据感兴趣的消费者吗？不，有无数其他消费者（服务和工具）。输入Semantic Web和Linked Data的世界。如果您了解并关心消费者，那么答案很容易：提供此消费者文档支持的内容。但当然，你无法全部了解它们。因此，如果您关心所有这些（已知的和未知的，现有的并且仍然会出现）消费者，答案将是：提供对所有消费者有用的东西。或者，因为这些消费者差异很大，甚至：提供您所能提供的服务。
也就是说，有一些Schema.org类型很少提供。一个很好的例子是WebPageElement类型，正如您所提到的，它可以用于页面区域（页眉，页脚，导航，侧边栏等）。在我看来，a typical web page shouldn’t provide these types。
如果您关心文件大小，you’ll want to使用Microdata / RDFa（因为这些语法允许您注释现有内容）而不是JSON-LD（因为此语法要求您复制内容）。使用RDFa，与微数据相比，你甚至可以节省更多 但是，结构化数据通常只代表标记/内容的一小部分，即使您提供尽可能多的数据。
您可以在完全描述它的页面上使用引用：define a URI for your business (or every other thing)，而不是在每个页面上重复“背景信息”（例如，有关业务的完整数据），并使用此URI作为属性值，适用于其他页面。这可以使用@id（JSON-LD，see an example），itemid（微数据）和resource（RDFa）。不这样做的唯一原因可能是缺乏对此类引用的消费者支持（取决于消费者/用例，它们可能不会被遵循）。中间方式可能是在每个页面上提供项目（关于业务或任何其他事物），一次使用完整数据，在所有其他情况下使用有限的数据集（理想情况下页面上可见的内容，或者特定消费者需要）。 URI被用作每个项目的标识符，表明所有这些项目都是相同的。