Microdataを提供する属性でマークアップされた次のコードを検討してください。
<!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構造が大きく異なるさまざまなサイトにmicrodataを実装する必要があります。この方法で属性を実装するには、各サイトのHTMLマークアップを個別に手動で編集する必要があります。
できれば、すべてのmicrodataを1か所にパッケージ化する単一の関数を呼び出すことができます。技術的には、これは次の方法でメタタグを使用することで可能です。
<!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の構造化データテストツールを使用すると、最初のテストと同じ肯定的な結果が得られます。
参考のため(実際のサイトではこれを行いません)Googleの構造化データテストツール CSSによって隠されたmicrodataを渡そうとするとエラーが返されます。
したがって、通常のタグマークアップとメタタグマークアップの両方で同じ結果が生成されますが、GoogleとSchema.orgからの次のステートメントに懸念があります。
https://support.google.com/webmasters/answer/14675 状態:
通常、Googleはユーザーに表示されるマークアップデータのみを使用します。非表示のデータは無視されます。ただし、いくつかの状況では、コンテンツの機械可読バージョンと人間可読バージョンの両方を提供すると便利な場合があります。たとえば、「エルビスの誕生日」というテキスト文字列は多くの人間にとって重要ですが、検索エンジンにとっては1935-01-08ほど意味がありません。同様に、人間の読者は$記号の意味を推測できますが、価格がペソなのかドルなのかを検索エンジンに明確に伝えると便利です。
http://schema.org/docs/gs.html 状態(メタタグの使用に関連して):
この手法は慎重に使用する必要があります。他の方法ではマークアップできない情報のコンテンツにのみメタを使用します。
http://schema.org/docs/faq.html#1 states:
一般的なルールとして、非表示のdivまたはその他の非表示のページ要素のコンテンツではなく、Webページにアクセスするユーザーに表示されるコンテンツのみをマークアップする必要があります。
私の質問は:
Microdataにメタデータを使用する計画は実行不可能です。 GoogleのFAQが検索結果にデータを表示しない理由について :
マークアップしたコンテンツはユーザーから隠されていますか?
一般的に、Googleは、人間のユーザーには見えないリッチスニペットのコンテンツを表示しません。
display:none
、value-title
、cssなどの手法を使用して、リッチスニペット用にマークアップしたコンテンツを非表示にしないでください。 Googleは、人間のユーザーに表示されないコンテンツを無視するため、訪問者がWebページに表示するテキストをマークアップする必要があります。
Googleが提供するmicrodataを使用できるようにする唯一の方法は、それをマークアップすることですそれが置かれる場所、ユーザーに表示されます。
この時点で、Googleは、そのサイトのリッチスニペットをオフにするだけでなく、リッチスニペットを悪用しようとしても罰せられません。 Googleがガイドラインに準拠していない方法でmicrodataを使用しようとしているサイトを見つけたときに、Googleが検索結果からサイトを完全に除外し始めても驚かないでしょう。
マークアップしているメタデータがページのどこかに表示されている限り、Googleはサイトを悪意のあるものとして罰することはほとんどありません。ただし、それらの自動ツールは、非表示の場所でデータをマークアップしていることを検出し、検索結果に表示しません。
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がmeta
/link
のみが使用されている場合、Microdataマークアップを無視するnotは意味があります。どうして?また、Schema.orgデータを提供するためのJSON-LDをサポート(および 場合によっては推奨 )し、これはonlyの「非表示」コンテンツ(つまり、非表示のscript
要素が使用されました データブロックとして )。
そして、これは私があなたの場合に提案するものです:既存の要素をマークアップして構造化データを追加したくない場合は、JSON-LD。
これがすべての状況で機能するかどうかについてコメントすることはできませんが、製品ページのメタ「コンテンツ」として、あなたが説明する方法でSchema.orgを使用します。どうして?移植性が非常に高く、テーマを破壊しません。また、データのフォーマットをより細かく制御でき、<body>
(フォールドのはるか上)の直後に関連データを取得します。フックベース(またはvQmodのようなF&Rベース)のプラットフォームが思い浮かびます。すべてのディレクティブをハードコーディングせずに、すべてのディレクティブを構造内に流動的にF&Rする方法はありません。
ペナルティはありません。Googleは引き続きデータを使用し、SERPウィジェットに入れます。ページのほとんどのデータはまだどこかにありますが、ほとんどのマークアップに関する限り、content=""
を使用する1つの単一の階層メタコンテナにあります。 「。これを取りすぎないでください。レビューループ、ブレッドクラム、メインの説明、または仕様などの構造的なものは、このメタコンテナから除外するのが最適です。ビューにハードコーディングするようにしてください。
ほとんどの人は「content=""
メタを使用しないでください」と言うでしょうが、それでも、それらのほとんどの人はそれを試したことはありません。同じことが、カテゴリの製品リストのリッチマークアップなどにも当てはまります...ええ、私たちもそのルールを破っています:) RDF池の魚はGoogleだけではないことを覚えておいてください。 Gが言うことは、池の残りの部分に完全に受け入れられる方法で標準的な問題のデータ形式を使用するこの状況では、「作ったり壊したり」することではありません。おそらく、G自体が将来その心を変えるからです。すべての上/上にデータが必要ですが、下/下のデータでコードを作成できますが、メタ属性はマシンアクセス可能な言語でその中心に配置します。