我想知道Microformat 的 hRecipe和Schema.org 的 Recipe之间的主要区别是什么,以及搜索引擎如何处理它们。
除了代码的差异以及前者是开放的而后者是专有的这一事实之外,搜索引擎如何从长期的角度和 SEO 的角度看待每一个以及哪个更好实施?
我想知道Microformat 的 hRecipe和Schema.org 的 Recipe之间的主要区别是什么,以及搜索引擎如何处理它们。
除了代码的差异以及前者是开放的而后者是专有的这一事实之外,搜索引擎如何从长期的角度和 SEO 的角度看待每一个以及哪个更好实施?
hRecipe 基于类属性,而 schema 的 Recipe 基于多个属性。这些是标记的主要区别;hRecipe 向后兼容,而 Recipe 不是,因为它使用 html5 数据属性。
三大搜索引擎说他们会一视同仁,但我不相信;谷歌一直在推动他们的网络平台足够长的时间,让我认为他们会为食谱添加额外的果汁,即使我无法证明这一点。即使他们没有在 Recipe 上添加额外的 seo,您也可以确定他们会在 SERPS 中发挥作用,因此如果您使用他们的专有标记,您会得到注意……更多。以链接元素的 prefetch 和 prender 属性为例;谷歌创建了预渲染,如果您在您的网站上使用它,瞧,它会在 SERPS 中为用户预渲染。预取没有。
我不知道如何区分长期观点或 seo 观点,我看@他们是一样的;我不是说你不能,只是想解释更多。我以前从客户的角度考虑过这一点,并就微格式作为一个整体与架构问了自己这些相同的问题。这基本上是一个判断:微格式是经过尝试的,是真正的格式;使用微格式数据的站点比使用模式的站点多数百万。他们哪儿也不去。并且(如前所述)它们是向后兼容的。
也就是说,schema 得到了三巨头的支持,并且基于 html5,将来不应该有可移植性问题。前面也提到过,我相信这三个人都会在他们各自的搜索结果中奖励用户(尽管我没有证据)。不过,这里有一个警告,就是网络上的一切都在移动的速度有多快;就像 Schema 弹出一样快,它可能会被丢弃。我对此表示怀疑(尽管我希望如此),但这是一种可能性。
我不能说哪个更好实现,但是微格式肯定更容易实现,它们是基于类的,非常容易。
最好使用 schema.org 格式,因为它已被所有主要搜索引擎(Google、Yahoo 和 Bing)接受为标准。使用替代的微格式可能意味着某些搜索引擎不会识别出该数据是特殊的,并且会失去它提供的任何可能的优势。