【问题标题】:Best JSON-LD practices: using multiple <script> elements?最佳 JSON-LD 实践:使用多个 <script> 元素?
【发布时间】:2015-08-23 18:26:56
【问题描述】:

我很好奇将 JSON-LD 应用到 schema.org 网站的最佳实践。

如果我有一个带有Article 的页面,并且我还想在我的页面上定义WebSite,我会这样:

<script type="application/ld+json">
{
    "@context": "http://schema.org",
    "@type": "WebSite",
    "url": "http://www.example.com/",
    "potentialAction": {
      "@type": "SearchAction",
      "target": "http://www.example.com/search?&q={query}",
      "query-input": "required"
    }
}
</script>

<!- … -->

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "Article",
  "author": "John Doe",
  "interactionCount": [
    "UserTweets:1203",
    "UserComments:78"
  ],
  "name": "How to Tie a Reef Knot"
}
</script>

这是对还是错?将这些合并到同一个脚本或项目数组中是否有任何好处或需要?

【问题讨论】:

标签: html seo schema.org json-ld


【解决方案1】:

拥有单个或多个数据块没有任何好处,除了限制您在网站中存储和管理架构数据的方式。

例如,如果您网站中的不同组件负责独立生成每个数据块,您可能需要将它们分开。或者,如果您的网站能够在一个地方管理一个页面的所有架构,则管理单个数据块并将其呈现为单个 script 元素可能会更简单。

您可以通过将每个架构列为这样的数组来将它们组合成一个脚本:

<script type="application/ld+json">
[
  {
    "@context": "http://schema.org",
    "@type": "WebSite",
    "url": "http://www.example.com/",
    "potentialAction": {
      "@type": "SearchAction",
      "target": "http://www.example.com/search?&q={query}",
      "query-input": "required"
    }
  },
  {
    "@context": "http://schema.org",
    "@type": "Article",
    "author": "John Doe",
    "interactionCount": [
      "UserTweets:1203",
      "UserComments:78"
    ],
    "name": "How to Tie a Reef Knot"
  }
]
</script>

【讨论】:

【解决方案2】:

有效。您可以拥有任意数量的数据块(= script 元素)。

只使用一个script 元素的一个可能的好处是:它允许使多个项目之间的关系更容易(例如,如果您决定使用hasPartmainEntity),因为您只需要嵌套这些项目。
但是,当使用单独的数据块时,当然也可以建立这些关系,方法是使用 @id (thanks, @ Gregg Kellogg) 引用项目的 URI。

(作为参考,adding two or more top-level items in a single script 可以与@graph 一起使用。)

【讨论】:

  • 您还可以使用 @id 将 JSON-LD 脚本块中的节点绑定在一起。从模型的角度来看,它们都被视为公共图中的三元组。但是,搜索引擎可能会“优化”而不是您所期望的。使用 JSON-LD 算法可能没有充分的理由使用单独的脚本块;只需将它们合并为一个公共对象,甚至是一个对象数组。
  • @GreggKellogg 和 unor - 感谢您的回答!我主要担心的是 CMS 的局限性,因为我会在全局级别指定网站,而在页面级别指定文章。我不太确定在这种情况下会发生什么。谷歌的结构化数据工具给了它一个好的结果,但我总是有点怀疑:)
  • @GreggKellogg 所以现在是 2017 年,现在推荐的是@graph 还是对象数组?相关讨论是在2012年完成的(github.com/json-ld/json-ld.org/issues/96),我的阅读共识是@graph对于多个顶级对象。提前致谢。
  • @AmirR 通常您将使用@graph(或@graph 的别名)来允许使用具有共享上下文的单个顶级对象。然而,两者都是相当合法的。请注意,另一种模式是使用具有用作顶级对象的公共对象值的反向属性,链接到引用它的所有资源。见Reverse Properties
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2010-09-15
  • 2011-11-29
  • 2018-09-15
  • 1970-01-01
  • 1970-01-01
  • 2018-03-31
  • 2015-07-08
相关资源
最近更新 更多