構造化データの概要とSEO 〜リッチリザルト, マークアップ方法, SEO施策まで〜
レベル：上級
こんにちは、SEO野郎です。
今回のテーマは構造化データとSEOです。
構造化データとは本来セマンティックウェブの思想に立脚し、ソースコードの羅列であるウェブページに意味を持たせようという考えがベースとなっている仕組みです。
HTML上で構造化データのマークアップを行うことで、そのテキストが人名を指すのか、場所なのか、イベントなのかという意味を付け加えることができます。
今回はその構造化データという仕組みそのもの概要を、検索エンジンにおける存在意義、さらにはSEO施策の観点から解説していきたいと思います。
SEO施策として構造化データのマークアップを検討しているウェブサイト運営者の方の参考になれば幸いです。
1. 構造化データの技術的仕組み
構造化データは技術的には主にボキャブラリーとシンタックスの2要素から成り立ちます。
ボキャブラリーはインターネットにおける辞書のようなもので、シンタックスはその辞書をウェブサイトのソースコードの中に引用する言語のようなものです。
1-1. ボキャブラリー
Googleは schema.org と data-vocabulary.org をサポートしており、一般的なウェブサイトにおいてはschema.orgを採用するのが無難です。
① schema.org
・Google、Yahoo!、Microsoftの2社で策定したボキャブラリーの規格
・schema.org でマークアップする場合にはタイプ（型）とプロパティ（属性）を指定する
② data-vocabulary.org については本記事では割愛します
1-2. シンタックス
シンタックスとは、構造化データがどのようなタイプについて記述されていて、各プロパティがどのような値を取っているかの論理構造を示すものです。
Googleは microdata、RDFa、JSON-LD のシンタックスをサポートしています。
① microdata
・HTML5に独立した仕様で、HTML5のみで使用できる
・テキストを直接マークアップする
・HTMLが煩雑になる
・今後の使用は非推奨
② RDFa
・HTML5、XHTML等でも使用できる
・W3Cの推奨
③ JSON-LD
・表示されるテキストとマークアップを別に記述する
・構造化データマークアップが別の場所にあるため、HTMLを汚さずに済む
マークアップを一箇所にまとめることができる
・Googleが最も推奨するシンタックスである
・一定数ファイルサイズが大きくなる
・cf. BlogPosting（ブログ投稿）でマークアップする場合、articleBody（記事本文）プロパティにHTMLで記述した記事本文を再度記述することになる
表示されるテキストと別の場所に記述するため、意図せず両者の内容が異なってくる可能性がある
→ 悪質だとスパムと認識される場合もある
2. 構造化データ基礎
2-1. 構造化データとリッチリザルト
構造化データのマークアップはリッチスニペットが表示されるための必要条件でしかありません。
構造化データのマークアップを行ってもリッチスニペットが表示されない場合、以下のような要因が考えられます。
・コンテンツと構造化データが正しく対応していない場合
・構造化データが正しくない場合
・マークアップしたデータがユーザーには隠されている場合
・一般的な品質ガイドラインに違反している場合
2-2. 構造化データをマークアップする利点と欠点
① 構造化データの利点
・リッチスニペットが表示される可能性がある → CTRの向上が期待できる
・ナレッジグラフ、アンサーボックスに表示される可能性がある
② 構造化データの欠点
・ソースコードのサイズが大きくなるためページ読み込み速度が遅くなる（そこまで大きなファイルではないので、相当大規模に実装しない限り無視して良いレベル）
・検索エンジンのアルゴリズムやサポートの更新などによって随時メンテナンスが必要
3. JSON-LDによる構造化データのマークアップ
今後しばらく主流のシンタックスとして採用されていくのがJSON-LDです。
本記事ではJSON-LDによる構造化データのマークアップ方法を解説します。
3-1. JSON-LDのコードの位置
・JSON-LDは実際に表示される文字列とは別の場所に記述する
・<head>、<body>の任意の場所にコードを設置して良い
・cf. 構造化データの記述を<body>から<head>に移動したところリッチリザルトが表示されるようになったというウェブサイトもあるため、ソースコード上での配置には検証が必要
3-2. JSON-LDの記述方法
① JSON-LD基本
（1）基本
・<script>タグの中に記述（JavaScriptが実行されるわけではない）
・1つの schema.org のタイプに1つのJSONオブジェクトが相当する（JSONオブジェクト：JSON-LDでマークアップした塊）
・“key”: “value” を対応させながら記述する
・最初に@context でボキャブラリー、@type でタイプを宣言する：”@context”: “http://schema.org”, “@type”: “Example”
・schema.org のプロパティが key となることが多い
・宣言の後はプロパティとその値を記述する
（2）会社情報の構造化データマークアップの例
<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "Corporation",
"name": "SEO Yarou Inc.",
"adress": "東京都渋谷区SEO28-4 SEOビル 1800階",
"telephone": "+811234567",
"employee": "SEO野郎",
"URL": "http://example.co.jp/“
}
</script>② embed
（1）embed 基礎
・特定のプロパティは子要素を持つことができる
・プロパティの子要素は embed という方法で記述する
・embed する場合、JSONオブジェクトをvalueとして指定する
（2）addressプロパティのembed例
"adress": {
"@type": "PostalAdress",
"postalCode": "123-4567"
"addressRegion": "東京都",
"addressLocality": "渋谷区",
"streetAddress": "SEO28-4 SEOビル 1800階"
}③ array
（1）array 基礎
・array：同じ key を複数回登場させる際に使用（JSON-LDでは同じ key を複数回記述すると正しく認識されない）
・employee key の場合：”employee”: [“SEO野郎”, “SEO太郎”],
・array で記述するkeyプロパティが子要素を持つ場合 array の中にJSONオブジェクトを記述できる
（2） employeeプロパティでPersonタイプを子要素に持たせる場合のarray
“employee”: [
{
“@type”: “Person”,
“name”: “SEO野郎”,
“email”: “seoyarou@example.co.jp”,
},
{
“@type”: “Person”,
“name”: “SEO太郎”,
“email”: “seotaro@example.co.jp”
}
],5. 構造化データとSEO
5-1. MFI
PCページとスマホページのコンテンツが異なる場合、構造化データはスマホページに合わせてマークアップを行います。
5-2. パンくずリストの構造化データ
① 必須プロパティ
リッチリザルトとして表示するためにはコンテンツに以下3つの必須プロパティを含める必要があります。
（1）item（Thing）：パンくずを表すページのURL
（2）name（Text）：ユーザーに表示されるパンくずのタイトル（パンくずのアンカーテキスト）
（3）position（Integer）：パンくずリスト内のパンくずの位置、そのパンくずが何階層目かを数字で記述する
② JSON-LDによるパンくずリストのマークアップ例
想定パンくずリスト：トップページ > カテゴリA > 子カテゴリA > example article
<script type=“application/ld+json”>
{
“@context”: “http://schema.org”,
“@type”: “BreadcrumbList”,
“itemListElement”:
[
{
“@type”: “ListItem”,
“position”: 1,
“item”:
{
“@id”: “https://example.com/categoryA”,
“name”: “カテゴリA”
}
},
{
“@type”: “ListItem”,
“position”: 2,
“item”:
{
“@id”: “helps://example.com/categoryA/subcategoryA”
“name”: “子カテゴリA”
}
},
{
“@type”: “ListItem”,
“position”: 3,
“item”:
{
“@id”: “https://example.com/categoryA/subcategoryA/examplearticle”
“name”: “example article”
}
}
]
}
</script>5-3. 記事の構造化データ
記事の公開日と更新日の両方をマークアップすることをGoogleは推奨しています。
5-4. レビューの構造化データ
① レビューの構造化データマークアップ
・構造化データでレビューをマークアップしたページでの実際のレビューの表示のさせ方：規約上はそのページ内でオリジナルのレビューが全て閲覧可能である必要がある
・レビューの数が膨大な場合（ページネーション、Ajax等で「さらに読み込む」スタイルなど）
→ アグリゲートレーティング：全てのレビューを統合したレビューをマークアップする（レビューのテキスト全てをマークアップする必要はない）
・他サイトのレビューを引用し、リッチスニペットのためのマークアップを行ってもポリシー違反ではない
② レビューのリッチリザルト
・TripAdvisorのウィジェットにはマークアップが組み込まれており、それを設置したページはリッチリザルトを表示できる（ガイドライン違反ではない）
5-5. 比較コンテンツの構造化データ
① 比較コンテンツの構造化データ
・比較コンテンツ用の構造化データ自体は存在しない
・車をCarボキャブラリでマークアップするとエンティティの理解には役立つ（Carボキャブラリに関連するリッチリザルトは存在しない）
② 販売していない商品のマークアップ
・アフィリエイトサイトのように、比較ページが販売ではなく比較のために存在する場合（サイト内で商品を購入できず、他サイトの商品の紹介を行っている場合）
→ Product、Offer のマークアップを行っても検索エンジン視点からは全く問題ない（実際の購入ができないためユーザーが不満を持つ可能性はある）
・Product：商品, 製品用の構造化データ
・Offer：販売情報用の構造化データ
SEOには構造化データの選択肢を持っておきたい
構造化データのSEO観点からの価値とは、検索エンジンのエンティティの理解を促し、リッチリザルトによってCTRを大きく改善させるポテンシャルがあることです。
検索エンジンからの発見面の支配戦略においてその価値は言うに及ばないでしょう。
日本のSEO従事者、特にベンチャー企業においては施策に構造化データを持つ担当者はまだ少ないように感じます。
また、アメリカに比べて日本のウェブサイトは構造化データを実装している割合がまだまだ小さいです。
故に構造化データに関連した施策は上手くいけば大きな優位性になり得ます。
もちろんその費用対効果はウェブサイトの特性やチームの環境によりけりですが、少なくとも構造化データのマークアップ自体はそれほど大きな開発工数や運用コストを伴う施策ではありません。
構造化データとSEOの未来
構造化データがSEOにおける一時的な競争力になるとはいえ、それが中長期的に優位性を保つかと問われれば、それは否だと思います。
現在の自然言語処理の技術水準では、世界中のウェブサイトのソースコードの意味を検索エンジンが解読するのは余りに費用対効果が合わないのが実態です。
故に現在はソースコードの意味の宣言をウェブサイト運営者に委ねている部分があり、そのための技術の一つが構造化データです。
ある種辞書ありきのディレクトリ型のセマンティックウェブは、自然言語処理の能力が構造化データによるエンティティの解像度を超えた時に寿命を迎えると思います。
何せそれを牽引するGoogleは、検索エンジンからディレクトリを消し去った張本人なのですから。
どんな施策・技術であれ、その価値は時代とともに変容するので、それ単体の価値ではなく、それが価値を持つ背景とその流れと向き合うことが一番のSEOなのではないかと思います。
長文にお付き合いいただきありがとうございました。
SEO野郎でした。
気軽にクリエイターの支援と、記事のオススメができます！
