OG：为非文章的单个网页键入文章与网站答案

【问题标题】：OG:type article vs website for Individual Web Pages That Are Not ArticlesOG：为非文章的单个网页键入文章与网站
【发布时间】：2013-01-02 17:23:51
【问题描述】：

我正在寻求澄清有关使用 og:type 文章与网站的单个网页在技术上不是“文章”但也不代表整个网站。

文档似乎自相矛盾：

来自https://developers.facebook.com/docs/opengraphprotocol/#types

Use article for any URL that represents transient content - such as a
news article, blog post, photo, video, etc. Do not use website for this
purpose. website and blog are designed to represent an entire site, an 
og:type tag with types website or blog should usually only appear on the 
root of a domain.

在这种情况下，文章应仅用于“瞬态”内容。 “短暂”的定义是“只持续很短的时间”。这句话还含蓄地说“网站和博客旨在代表整个网站......（并且）通常应该只出现在域的根目录上。”

编辑：有趣的是，描述类型的同一页面还说：

If your URL is a video, you should set og:type to video.

这本身就与上面关于视频的引用相矛盾。

回到主题，但是，在上面，同一页还说：

If your URL is a piece of content — such as a news article, photo, or 
similar — you should set og:type to article (see below).

这似乎与第一句话一致。

此外，以下页面 (https://developers.facebook.com/docs/technical-guides/opengraph/built-in-objects/#article) 显示将 og:type = article 与 Publish Time、Expiration Time 和 Author 结合使用，这支持应该将其用于包含“文章”的页面的想法.在同一页面上，网站示例支持指示整个网站是正在定义的对象的用法。

但是，来自 Open Graph 协议网站：

http://ogp.me/#types

Any non-marked up webpage should be treated as og:type website.

这句话似乎表明了一种最佳做法，即我认为“网页”是指可能存在于具有许多页面的网站的上下文中的单个网页，应被视为 og:type 网站。这似乎与上述说法相矛盾。

为了让事情变得更复杂，两者都没有解决常见的现实世界场景，即网站内单个网页的内容不是文章、博客条目或类似的“过时”或“临时”内容，而是相当长期的内容，也不是由任何其他 og:type 直接表示的。

例如，网站上的常见问题解答页面。它是什么类型的？一个介绍公司提供的服务的页面怎么样？还是描述公司使命宣言和经商方法的页面？或者描述产品或服务的好处但实际上并不直接代表产品或服务的营销页面，这留给产品详细信息页面。

尽管 Open Graph 协议网站有声明，但似乎如果我们希望这些页面每个都有唯一的 LIKE 按钮，“网站”不是正确的 og:type。

但是，这些页面上的内容通常不会被描述为“暂时性/临时性”，并且没有过时或与特定作者相关联，因此“文章”似乎也不是正确的 og:type。

但是，这似乎是我们仅有的两个选择。奇怪的是，我在任何地方都找不到关于这个非常灰色的话题的讨论。没有澄清。没有最佳实践。提及 og:type 的文章很少提及，并且大多数都将读者推荐给“开放图对象类型列表”以了解更多信息。

似乎使类型正确也很关键，因为错误可能会导致后果。

那么，有人知道 Facebook 希望这些类型的单个页面对象是什么类型吗？有没有人看到任何关于这个的讨论？其他人都在做什么？

谢谢！弗里茨

【问题讨论】：

有人对此有什么建议吗？
所以，NOBODY 知道在不是主页（网站）、不是现实世界对象（电影、视频、歌曲等）、不是产品（产品），而不是博客或新闻文章（文章）？
仅供参考 - 我在向 Facebook 提交的错误报告中报告了这些文档差异和缺陷，他们已确认并标记为已知问题，并附注以继续关注即将推出的更新。 link
这是一篇精彩的帖子（尽管根据 SO 规则不是一个有效的问题），您可能会遇到更多 Facebook 服务的类似冲突。这让我想，如果他们不能正确定义自己的服务，他们可能会误导性地使用我们的数据。最终，我们会受到无关紧要的结果的惩罚。我只能感谢您的详细阅读和发现，并希望来自 FB 的人关心，阅读此内容。
惊呆了，仍然没有明确的答案！事实上，“网站”甚至没有在 the opengraph reference.. 中列出，因为“开发人员的简单性是开放图形协议的一个关键目标” - Source；他们真的把球放在了文档上。

标签： facebook facebook-like facebook-opengraph

【解决方案1】：

根据我的经验，“文章”和“网站”之间的区别与 Facebook 使用“赞”的方式有关。具有网站类型的页面的“喜欢”将出现在用户个人资料的列出他们喜欢的部分中； “喜欢”类型为文章的页面不会。用户对“文章”对象的喜欢更有可能在他们的新闻源中显示给朋友（尽管到目前为止，即使是没有评论的文章也不太可能成为新闻源项目，除非有强大的原因——共同感兴趣的话题，用户之间非常频繁的交互——使项目在 Facebook 算法中浮出水面）。

【讨论】：

【解决方案2】：

facebook 中的网站和博客将代表根域或子域，根非少。

据我了解，这最初是为类似按钮的社交插件设计的，它是一种为网站设置层次结构的方法。 “这是 Facebook 特有的功能”。

type = social_plugin 是我用来代表我的社交插件的东西，我在我的应用程序的开放图形设置中设置了它。如果不存在代表您的页面类型的类型，则创建一个。

anotherfeed.com - website
  |
  |
  |
  /widgets/index.php - social_plugin
  /?cat=world_news - article

【讨论】：