次のSEOのコア？！【構造化データに関する一般的なガイドライン③】ユーザーエクスペリエンスの高い「リッチリザルト」体験に向けて

こんにちは、ペンギン男です🐧

前回の記事では↓、ガイドライン中、品質に関する内容に触れました。

今回は、品質に関するガイドラインの続きですが、構造化データに必ずしも特化しない一般性の高い内容もありました。しかし、今回は、再び、構造化データ「固有」のトピックに戻ります。

Googleのドキュメントも念のため↓

————————————————————————

【目次】

————————————————————————

品質に関するガイドライン（承前）

完全性

推奨プロパティ

リッチリザルトタイプの、Googleから必須とされたプロパティは全て指定のこと。レシピの例で言えば、次のようなもの「img」「name」などのアイテム。

• img→完成した料理の画像
• name→レシピの名称
• author→レシピの作者
• cookTime→調理時間 

など。

推奨プロパティと検索結果の質

指定する推奨プロパティが多いほど、表示される検索結果の質は高くなります。たとえば、求人情報については、給与の明示がないより、あった方が好まれます。

場所

構造化データを実装する場所は

• 内容を記述するページか、
• 概要ページに実装し、詳細ページにリンクさせる

ことで対応できます。

もっとも、カルーセル形式（遊園地の回転木馬みたいに、次々と横にスライドできる形式↓）だと例外があるようですが、ここでは割愛。

具体性

• Schema.orgでマークアップ用に定義されている、もっとも具体的なタイプとプロパティ名を利用すること 
• 再度、あらゆるガイドラインへ遵守の必要性が明言されています。（なお、このパラグラフに構造化データ実装を通したリッチリザルトに関するドキュメントへの言及あります。アンカーテキストも用意され、そこから遷移する仕組み。ただし、遷移先の名称<検索ギャラリーを使ってみる>が、本件の性格と整合性高くないので、混乱をさけるため、割愛。）

なお、最初の項目に関し、ボキャブラリーについては、とにかくGoogleのドキュメントを使えとの指示あったのですが、私では、ここらあたりの指示に関し、整合性あるのかどうか分かりません💦

画像

• 構造化データのプロパティとして画像を指定する場合には、画像がそのタイプのインスタンスに実際に属している必要性（ここでいう「インスタンス」とは「実態」くらいの意味でしょうか。要は、指定プロパティ名が表す内容と、画像の内容が、一致している必要あるということと理解しています）
• 全ての画像URLは、クロールやインデックス登録に対応できる必要性。

ページ上の複数の要素

ユーザーに表示されるページコンテンツが、記述されている構造化データオブジェクトであれば、一つのページに構造化データオブジェクトを含めることができます（ただし、オプジェクトが複数あり、その中の一つのアイテムだけマークアップすることは出来ず、一つやるのなら、全部のアイテムをマークアップする必要あります）

最後に

かなり充実したガイドラインやマークアップ事例も準備された構造化データ。しかし、一般化したとは、まだ言えない状況（だと理解しています）。

しかしながら、一旦、広まれば、逆にデフォルトのような扱いになる可能性もあります。SEOにバシバシ効く！なんて影響力がある人が推せばすぐか、と。

ただし、実装の手間は結構かかるので、たとえば、はてなブログさんだと、別途APIを開発せざるを得なくなるかもしれませんね😊

また、次回。

#構造化データに関する一般的なガイドライン

#技術に関するガイドライン

#品質に関するガイドライン