Webマーケティング内部施策の一つに構造化データ対応があります。聞いたことはあってもよくわかっていないことも多いのではないでしょうか?
この記事では、構造化データについて解説します。
構造化データとは?
構造化データはページとそのコンテンツに関する情報を検索エンジンなどに提供するための標準化された方法です。Webページに構造化データを埋め込むことで、検索エンジンはその情報を活用できます。
現在、Googleが対応している構造化データの種類は30を超えていますが、実際に使用するのはごく一部でしょう。提供するコンテンツの内容に応じて、適切な構造化データを使用する必要があります。
構造化データを記述するメリット
よく勘違いされがちですが、構造化データを使用すること自体はオーガニック検索の順位に直接影響しません。構造化データを使用する主な目的は、リッチリザルトを表示させることとキーワード検索以外の機能への対応です。
リッチリザルトが表示されると検索結果画面で目立つようになるので、クリック率の向上が期待できます。
また、適切に構造化データを記述することでGoogleマップの検索で表示されたり、Googleアシスタントのアクションにも対応できたりします。
構造化データを記述するデメリット
ユーザーが検索結果画面に表示された内容で満足してしまいページへの訪問につながらないということはありえますから、リッチリザルトが狙った成果につながっているかはよく調査した方がいいでしょう。
また、運用上の問題として、コンテンツ内容にあわせた適切な構造化データを維持管理する体制が維持できるかという問題もあります。
リッチリザルトとは?
Googleで検索したときに、検索結果画面によくある質問が表示されたり、商品の写真が表示されたりしたことはないでしょうか?それが、リッチリザルトです。
強調スニペットとの違い
強調スニペットは、Googleが検索クエリにマッチすると判断したWebページの一部を抜粋して検索結果に表示するものです。
強調スニペットは基本的にコントロールできないものであるのに対して、リッチリザルトは構造化データを元に生成されるので表示内容をコントロールできます。
エンリッチリザルトとは
通常のリッチリザルトはキーワード検索結果で表示のされ方に影響しますが、一部の構造化データはさらにエンリッチリザルトに対応しており、これは求人情報、レシピ、イベント検索などに影響して、ポップアップなどさらにリッチな機能が提供されます。
構造化データの種類
現在Googleが対応している構造化データの種類は30を超えています。
活用イメージを膨らませるために、いくつか例を見ていきましょう。
現在使える構造化データ一覧
- 記事
- 書籍
- パンくずリスト
- コース
- 新型コロナウイルスに関するお知らせ
- データセット
- 教育向けQ&A
- 雇用主の総合評価
- 給与推定額
- イベント
- ファクトチェック
- よくある質問
- ホームアクティビティ
- ハウツー
- 画像メタデータ
- 求人情報
- 学習用動画
- ローカルビジネス
- ロゴ
- 数学の解法
- 映画
- 練習問題
- 製品
- よくある質問
- レシピ
- クチコミ
- サイトリンク検索ボックス
- ソフトウェアアプリ
- 定期購入とペイウォール
- 動画
全て触れるには多すぎるので、詳しくは構造化データとリッチリザルトの種類一覧をご覧ください。本記事ではイメージを掴んでもらうためにいくつかピックアップして簡単にご紹介します。
パンくずリスト
ページの階層が検索結果に表示されるようになります。ユーザーがページ構造を理解する助けになるのはもちろん、Googleがサイト内のページを分類する際に手がかりとして使われます。
BreadcrumbListの構造化データを使用します。
この構造化データに対応できていると下記のように、「ホーム > 業務効率化」とページ階層が検索結果に表示されます。
イベント
イベント情報がGoogleのイベント機能の表示対象となり、Googleマップなどから見つけやすくなります。また、ロゴやイベントの説明などを目立たせることもできます。
Eventの構造化データを使用します。
求人情報
求人情報がGoogleの求人検索機能の表示対象となります。
求人情報の公開日、求人の有効期限、雇用形態、職種、勤務地、給与などが記載できるほか、検索結果画面に応募ページへのリンクボタンを表示することもできます。
JobPostingの構造化データを使用します。
よくある質問
よくある質問が検索結果画面に折りたたまれた状態で表示されるようになり、ユーザーはクリックして簡単に内容を確認できます。また、Googleアシスタントのアクションにも対応できるようになります。
FAQPage、Question、Answer の構造化データを使用します。
構造化データの実装手順
関連するものを全て構造化データとして記述できればいいですが、実際には自動化の可否や管理の手間などを考慮してどこまで対応するか考えましょう。
コンテンツに変更があれば構造化データもそれに合わせて適切に変更されるべきです。
開発費や運用費にも関わってくることですので、設計段階で検討しておく必要があります。
運用方法の検討
CMSがある場合、日々の投稿の構造化データを手作業で管理していくのは現実的ではないですから、できるだけ自動生成することを考えます。プラグインなどでできることもありますが、サイトの扱うコンテンツや性質に応じて臨機応変に対応しましょう。
使用する構造化データの決定
コンテンツに合わせて、使用する構造化データを選びます。ブログであれば記事を使うでしょうし、イベントを扱うサイトであればイベントの構造化データも記述するといいでしょう。また、パンくずリストを構造化データとして記述するかどうかも考えておきましょう。
特にパンくずリストは親ページが変更になった場合にその子ページすべてが影響を受けるので、自動化されていない状態での運用は困難です。
記述形式の選択
構造化データには複数の形式があります。JSON-LDが採用されることが多いかと思いますが、プロジェクトの開発環境やCMSに合わせて選択しましょう。
形式 | 概要 |
---|---|
JSON-LD | <script>タグ内に構造化データとして決められた形のJSONを記述します。動的に挿入しても読み取ることができます。 Googleはこの形式の使用を推奨しています。 |
microdata | HTMLタグの属性を使用して構造化データを記述します。タグの属性を使う性質上、HTMLが適切に構造化されている必要があります。 |
RDFa | こちらもHTMLタグの属性を使用して構造化データを記述しますが、microdataとは書き方が異なります。タグの属性を使う性質上、HTMLが適切に構造化されている必要があります。 |
実際に記述する
パンくずリストをJSON-LDで記述する場合は以下の様な形式になります。
headタグ内に決められた形でJSONを記述します。
<html>
<head>
<title>Award Winners</title>
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [{
"@type": "ListItem",
"position": 1,
"name": "Books",
"item": "https://example.com/books"
},{
"@type": "ListItem",
"position": 2,
"name": "Science Fiction",
"item": "https://example.com/books/sciencefiction"
},{
"@type": "ListItem",
"position": 3,
"name": "Award Winners"
}]
}
</script>
</head>
<body>
</body>
</html>
※Googleのサンプルコードから引用
https://developers.google.com/search/docs/appearance/structured-data/breadcrumb?hl=ja
リッチリザルトテストで確認する
構造化データの記述ができたら、リッチリザルトテストでミスがないかチェックしてみましょう。コードでの検索も可能ですし、自動化した場合はURLを指定して実際に出力された構造化データの検査も可能です。
ただし、リッチリザルトテストは文法が正しいかチェックできるだけで、内容が合っていることは保証されないので注意が必要です。
まとめ
構造化データは、検索エンジンに情報を提供するための標準化された方法です。
これにより、検索順位には直接的な影響はありませんが、リッチリザルトの表示によって目立つようになったり、Googleアシスタントに対応したりすることができます。現在、Googleは30以上の異なる構造化データの種類に対応しています。
構造化データの形式としては、JSON-LD、microdata、RDFaのいくつかがありますが、基本的にはJSON-LDが広く採用されています。ただし、プロジェクトの開発環境やCMSに合わせて選択することもできます。
構造化データの文法が正しいかどうかは、リッチリザルトテストを使用して確認することができます。
関連する情報をすべて構造化データとして記述できれば理想的ですが、実際には自動化の可否や管理の手間などを考慮して、どの程度まで対応するかを検討する必要があります!