可以在meta标签中实现微数据吗?


12

请考虑以下标记有属性的代码以提供微数据:

<!DOCTYPE html>
<html>
    <head>
        <title>Micro data test - Normal version</title>
    </head>
    <body>
        <div itemscope itemtype="http://schema.org/Product">
            <h1 itemprop="name">Product name</h1>
            <img alt="" itemprop="image" src="http://placehold.it/200x200" />
            <div itemprop="description">This is the product description.</div>
            <div itemprop="offers" itemscope itemtype="http://schema.org/Offer">
                <meta content="in_stock" itemprop="availability" />
                <span content="GBP" itemprop="priceCurrency">£</span><span itemprop="price">100.00</span>
            </div>
        </div>
    </body>
</html>

使用Google的结构化数据测试工具可得出积极的结果。

在测试示例中这很好,但是,我们希望在HTML结构差异很大的各种站点上实现微数据。要以这种方式实现属性,将需要有人分别在每个站点上手动编辑HTML标记。

最好,我们希望能够调用一个将所有微数据打包在一个位置的函数。从技术上讲,这可以通过以下方式使用元标记来实现:

<!DOCTYPE html>
<html>
    <head>
        <title>Micro data test - Meta tag version</title>
    </head>
    <body>
        <meta itemscope itemtype="http://schema.org/Product" itemref="microName microImage microDescription microOffer" />
        <meta id="microName" itemprop="name" content="Product name" />
        <link id="microImage" itemprop="image" href="http://placehold.it/200x200" />
        <meta id="microDescription" itemprop="description" content="This is the product description." />
        <meta id="microOffer" itemprop="offers" itemscope itemtype="http://schema.org/Offer" itemref="microCurrency microPrice microAvail" />
        <meta id="microAvail" itemprop="availability" content="in_stock" />
        <meta id="microCurrency" itemprop="priceCurrency" content="GBP" />
        <meta id="microPrice" itemprop="price" content="100.00" />
        <div>
            <h1>Product name</h1>
            <img alt="" src="http://placehold.it/200x200" />
            <div>This is the product description.</div>
            <div>£100.00</div>
        </div>
    </body>
</html>

使用Google的结构化数据测试工具可获得与第一次测试相同的肯定结果。

作为参考(我们永远不会在实际站点上这样做),如果您尝试传递CSS隐藏的微数据,则Google的结构化数据测试工具会返回错误。

因此,普通标记和元标记标记都会产生相同的结果,但是由于Google和Schema.org的以下声明,我有些担忧:

https://support.google.com/webmasters/answer/146750指出:

通常,Google将仅使用用户可见的标记数据。隐藏的数据将被忽略。但是,在某些情况下,同时提供内容的机器可读版本和人类可读版本都是有用的。例如,虽然文本字符串“猫王的生日”对许多人类读者都是重要的,但对搜索引擎而言,意义不如1935-01-08。同样,人类读者可以推断出$符号的含义,但是专门告诉搜索引擎您的价格是以比索还是美元为单位也很有用。

http://schema.org/docs/gs.html状态(与使用元标记有关):

应当谨慎使用此技术。仅将带有内容的元数据用于否则无法标记的信息。

http://schema.org/docs/faq.html#13指出:

通常,您只应标记访问网页的人可见的内容,而不标记隐藏的div或其他隐藏的页面元素中的内容。

我的问题是:

  1. 虽然不会返回任何错误,但我们会因使用这种方式使用元标记(即重复内容,隐藏信息等)而受到搜索引擎的惩罚吗?
  2. 如果这不合适,您能否建议从实际数据中分离微数据的任何方法,还是我们必须逐一考虑并根据具体情况在HTML中实现呢?

2
对于Google来说,这种东西相当棘手。即使今天没有问题,Google仍可以轻松更改其政策。Google通过拥有一个搜索引擎来赚钱,该搜索引擎可以比竞争对手更好地引导用户找到最合适的内容。无论如何,隐藏内容都会破坏这一点,因此标记可见内容总是更安全的。

@Alohci是的,这就是我所担心的,只有在为时已晚之前,无法告诉您!感谢您的评论,我想我们可能只需要硬着头皮按常规方式这样做。

Answers:


6

您将元数据用于微数据的计划不可行。这是Google的常见问题解答,说明了为什么它没有在搜索结果中显示您的数据

您标记的内容对用户隐藏了吗?

通常,Google不会以人类用户不可见的丰富摘录显示任何内容。不要隐藏你标记了使用类似技术丰富网页摘要内容display:nonevalue-title或CSS。Google会忽略人类用户看不到的内容,因此您应该标记访问者在您的网页上看到的文本。

让谷歌使用的微观数据,您提供的唯一方法是将其标记它奠定页面,对用户可见。

在这一点上,Google不会因为尝试滥用丰富网页摘要而受到惩罚,而不仅仅是关闭该网站的丰富网页摘要。当Google发现某个网站试图以不符合指南的方式使用微数据时,如果Google开始将其网站从搜索结果中完全排除,这不会令我感到惊讶。

只要您标记的元数据在页面上的某处也可见,Google就不会将您的网站视为恶意网站。但是,它们的自动工具会检测到您何时在不可见的位置标记数据,并且它们不会在搜索结果中显示。


感谢您的回答。您提出了一些有趣的观点;如果不使用数据,在meta标签中实现微数据似乎毫无意义!

4

对Microdata 使用meta(和link)元素很好。有时甚至没有明智的选择,例如,如果必须提供特定代码,那么向用户显示这些代码毫无意义。

Google甚至meta在其丰富摘录示例中使用了以下示例:

  • 产品软件应用程序

    <meta itemprop="priceCurrency" content="USD" />
  • 评论

    <meta itemprop="datePublished" content="2006-05-04">
    <meta itemprop="bestRating" content="10"/>
    <meta itemprop="worstRating" content="1"/>
    
  • 影片

    <meta itemprop="uploadDate" content="2015-02-05T08:00:00+08:00"/>
    <meta itemprop="duration" content="PT1M33S" />
    <meta itemprop="interactionCount" content="2347" />
    
  • 文章

    <meta itemprop="datePublished" content="2015-02-05T08:00:00+08:00"/>

因此,问题是,多少太多(如果有限制)?我认为可以假设没有硬性限制,这很可能取决于各种其他因素。

但是,如果仅使用/,则Google 不要关闭微数据标记是有意义的。为什么?因为它们还支持(有时甚至推荐)JSON-LD以提供Schema.org数据,并且它包含“隐藏”内容(即,用作数据块的隐藏元素)。metalinkscript

这就是我针对您的建议:如果您不想通过标记现有元素来添加结构化数据,请使用JSON-LD


感谢您的建议。我将看一下JSON-LD。

1

我无法评论这是否适用于所有情况,但是我们以您描述的方式使用Schema.org,即产品页面上的meta“内容”。为什么?它具有更多的可移植性,并且不会破坏主题。它还允许对格式数据进行更精细的控制,并且紧接之后<body>(远高于首屏)获取相关数据。想到基于钩子的平台(或什至像vQmod之类的基于F&R的平台):如果不将所有指令硬编码到视图中,就无法将F&R所有指令流畅地转换为结构。

我们尚未发现任何处罚,Google仍在使用数据,仍将其放入SERP小部件中。我们仍然在页面上的某个地方保留大多数数据,但是就大多数标记而言,它位于一个单独的分层元容器中,content=""就像您的底部示例一样,仅将其包装的组织作为“提供要约”。现在不要太过分了-最好将评论循环,面包屑,主要描述或规格之类的结构性内容排除在该元容器之外。尝试将它们硬编码为可见的。

大多数人会说“不要使用content=""metas”,但是话又说回来,其中大多数人从未尝试过。同样,类别中产品列表上的丰富标记也是如此...是的,我们也违反了该规则:)请记住,Google不是RDF池塘中唯一的鱼。在这种情况下,G所说的并不是“以失败告终”的方式使用标准问题的数据格式,这对于池塘的其余部分完全可以接受。也许甚至是因为G本身在将来改变主意。它需要高于/高于所有的数据,但它使您可以将代码编码到下方/下方的数据中,而meta属性则以机器可访问的语言将其放在顶部和中央。


Flaggellum笔记,OpenGraph(OG)和其他工具也以类似的方式工作:作为具有<head>或内容的元数据<body>。Pinterest喜欢Schema中的数据优先。Twitter卡的工作原理类似。并且不要害怕将数据词汇用于面包屑和评论循环的一部分,这是有效的。
dhaupin 2014年

感谢您的回答,很有趣的是,成功地实现了meta标签方法,并且没有任何明显的损失。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.