<!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标记。
最好，我们希望能够调用一个将所有微数据打包到其中的函数一个地方;从技术上讲，可以通过以下方式使用元标记来实现此目的：
作为参考（我们永远不会在实际网站上这样做），如果您尝试传递CSS隐藏的微数据，则Google的结构化数据测试工具会返回错误。标签标记产生相同的结果，但是，由于来自Google和Schema.org的以下声明，我有些担忧：
https://support.google.com/webmasters/answer/146750状态：
通常，Google仅使用用户可见的标记数据。隐藏的数据将被忽略。但是，在某些情况下，同时提供机器可读和人类可读的内容版本可能会很有用。例如，虽然文本字符串“猫王的生日”对许多人类读者都是重要的，但对搜索引擎而言，意义不如1935-01-08。同样，人类读者可以推断$符号的含义，但是专门告诉搜索引擎您的价格是以比索还是美元为单位也很有用。 org / docs / gs.html状态（与使用元标记有关）：
应该谨慎使用此技术。仅将带有内容的元数据用于否则无法标记的信息。
http://schema.org/docs/faq.html#13状态：
作为一般规则，您应该仅标记人们可见的内容谁访问了网页但不包含在隐藏的div或其他隐藏的页面元素中。
我的问题是： ，我们是否会因使用这种标记（例如重复的内容，隐藏信息等）而受到搜索引擎的惩罚？我们必须咬紧牙关，并根据具体情况在HTML中实现它？
#1 楼
您将元数据用于微数据的计划不可行。以下是Google的常见问题解答，说明了为什么它不会在搜索结果中显示您的数据：您标记的内容对用户隐藏了吗？ ，Google将不会以丰富的摘要显示人类用户看不见的任何内容。不要使用
display:none，value-title或css之类的技术隐藏标记为丰富摘录的内容。 Google会忽略人类用户看不见的内容，因此您应该标记访问者在您的网页上看到的文字。让Google使用“您提供的微数据是将其标记在页面中对用户可见的位置。该网站。如果Google发现该网站试图以不符合准则的方式使用微数据，那么如果Google开始将其网站完全从搜索结果中排除，我不会感到惊讶。
您所标记的元数据也可以在页面的某个位置看到，Google不太可能将您的网站惩罚为恶意的。但是，它们的自动工具会检测到您何时在不可见的位置标记数据，并且它们不会在搜索结果中显示。
评论
感谢你的回答。您提出了一些有趣的观点；如果不使用数据，在meta标签中实现微数据似乎毫无意义！
–user45839
2014年11月4日，9：25
#2 楼
将meta（和link）元素用于Microdata很好。有时甚至没有明智的选择，例如，如果必须提供特定的代码，将它们显示给用户的话就毫无意义。示例：产品和软件应用程序：
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" />
所以问题是，多少太多了（是否有限制）？而且我认为可以假设没有硬性限制，这很可能取决于各种其他因素。用过的。为什么？因为它们还支持（有时甚至推荐）JSON-LD以提供Schema.org数据，并且它仅包含“隐藏”内容（即，用作数据块的隐藏
<meta itemprop="datePublished" content="2015-02-05T08:00:00+08:00"/>
元素）。这就是我对您的建议：如果您不想通过标记现有元素来添加结构化数据，请使用JSON-LD。评论
感谢您的建议。我将看一下JSON-LD。
–user45839
15年6月10日在20:17
#3 楼
我无法评论这是否适用于所有情况，但是我们以您描述的方式使用Schema.org，即产品页面上的meta“内容”。为什么？它具有更多的可移植性，并且不会破坏主题。它还允许对数据格式进行更精细的控制，并且它在<body>之后（远高于首屏）获取相关数据。想到基于钩子的平台（或什至像vQmod这样基于F＆R的平台）：没有办法将所有指令硬编码到结构中就无法将F＆R所有指令流畅地编码到结构中。任何罚款，Google仍会使用数据，仍将其放入SERP小部件中。我们仍然在页面上的某个地方保留了大多数数据，但是就大多数标记而言，它位于一个使用
content=""的单个分层元容器中，就像您的底部示例一样，只是将其包装的组织“报价”。现在不要太过分了-最好将诸如评论循环，面包屑，主要描述或规格之类的结构性内容排除在该元容器之外。尝试对它们进行硬编码。大多数人会说“不要使用
content="" metas”，但是话又说回来，其中大多数人从未尝试过。同样，类别中产品列表上的丰富标记也是如此...是的，我们也违反了该规则：)请记住，Google不是RDF池塘中唯一的鱼。在这种情况下，G所说的并不是“以失败告终”的方式，使用标准问题的数据格式以使其他池塘完全可以接受。也许是因为G本身在将来改变主意。它需要高于/高于所有的数据，但它却使您可以将代码编码到下方/下方的数据中，而meta属性则以机器可访问的语言将其放在顶部和中间。评论
Flaggellum笔记，OpenGraph（OG）等以类似的方式工作：作为或中内容的metas。 Pinterest喜欢Schema中的数据优先。 Twitter卡的工作原理类似。而且不要害怕将数据词汇用于面包屑和评论循环的一部分，这是有效的。
– dhaupin
2014年11月3日23:40
感谢您的回答，很有趣的是，成功地实现了meta标签方法，而没有受到任何明显的惩罚。
–user45839
2014年11月4日在9:23
评论
对于Google来说，这种东西相当棘手。即使今天没有问题，Google仍可以轻松更改其政策。 Google通过拥有一个搜索引擎来赚钱，该搜索引擎可以比竞争对手更好地引导用户找到最合适的内容。无论如何，隐藏内容都会破坏这一点，因此标记可见内容总是更安全。@Alohci是的，这就是我所担心的，直到太迟之前，都无法告诉！感谢您的评论，我想我们可能只需要硬着头皮按常规方式操作即可。