【プレミアム】あなたのサイトで構造化データを導入すべきか否かの判断基準について(2) あとで読む

画像：Pixabay

目次

• あなたのサイトで構造化データを導入すべきか否かの判断基準について(1)
  • 1.SEOの順位決定要因について
  • 順位の上下について
  • リッチ スニペットやその他の機能を検索結果に追加して他社より目立つ
  • まとめと構造化データを導入すべきかの判断基準
• あなたのサイトで構造化データを導入すべきか否かの判断基準について(2)
  • 2.構造化データが難しくてよくわからない
  • 2-1．そもそも構造化データという言葉が難しい
  • 2-2．設定方法を読んでもプログラムみたいでよくわからない
  • 2-3．具体的にどうサイトを変更したらよいのかわからない。
  • データ構造化の判断基準まとめ
• あなたのサイトで構造化データを導入すべきか否かの判断基準について(3)
  • Appendix:構造化データツールのまとめ

2.構造化データが難しくてよくわからない

もうひとつの理由である構造化データが難しいという問題について考えます。そもそもなぜ難しいのかというと、３つ理由があると思います。

1. そもそも構造化データという言葉が難しい
2. 設定方法を読んでもプログラムみたいでよくわからない
3. 具体的にどうサイトを変更したらよいのかわからない。

2-1．そもそも構造化データという言葉が難しい

構造化データというと漠然としていて、よくわからないですね。 なぜこんなに難しい単語かというと英語の訳だからですね。

英語では「Structured Data markup」といわれています。 英語から意訳してみると 「カチッとしたデータを記述するためのマークアップ」 といったニュアンスになります。

構造化データ＝カチッとしたデータを記述するためのマークアップ？

よく考えてみるとHTMLというのは、かなり曖昧なものです。 例えば、Tシャツを販売する場合、だいたいこんな風に記載していますね。


<p>
激ヤバなTシャツ<br>
メーカーはラルフポーレン。<br>
今だけ半額 3900円！
</p>


人間であればブランドや値段はすぐにわかりますが、Googleが機械的に解読するのは困難です。 そこでこうやって書いてあげたらどうでしょう？


<p>
激ヤバなTシャツ<br>
メーカーは<brand>ラルフポーレン</brand>。<br>
今だけ半額 <price>3900円</price>！
</p>


こうすればどれがブランドや価格かGoogleもすぐにわかります。

しかし当然こんなHTMLタグはありません。 なかったら作ればいい！ということで誕生したのが「Structured Data markup」。いわゆる構造化データ用の仕組みです。

※マークアップとは「印をつける」といった意味。ちなみに筆者は構造化データマークアップという単語は別名で「Googleのためのマークアップ」とした方がユーザーにとってわかりやすかったと思っています。

2-2．設定方法を読んでもプログラムみたいでよくわからない

構造化データの意味がわかれば、あとは設定するだけなので簡単ですね。
ところが設定方法を読んでみると意外に難しい。

そこでポイントを整理しましょう。構造化データを理解する手順としては下記になります。

1. 最初にMicrodataかJSON-LDを選ぶ
2. １で選んだ方の記述方法を理解する
3. 試しにシンプルなコードを書いてみて、構造化データテストツールでコツをつかむ

１．最初にJSON-LDかMicrodataかを選ぶ

まず現実的な構造化データのマークアップの方法には大きく２つの方法があり、最初にどちらかを選択しなくてはなりません。 下記に概要の説明と、主に誰向けかを書いておきます。

JSON-LD

Who?

どちらかというとシステムやWordpressなどのCMSがわかる人向け。

メリット

一箇所の記述で終わるので、ソースコードが見やすくなる。
メンテナンスもその箇所だけを変更すればいいので、既存への追記も簡単。特にCMSを導入している場合、できればこちらを覚えた方が運用が楽。
GoogleもJSON-LDをオススメしている。

デメリット

一見するとJavaScriptプログラムっぽく、慣れないと難しく感じる。

Microdata

Who?

どちらかというとデザイナーさん向け。

メリット

HTMLタグがわかっていれば比較的理解が簡単

デメリット

商品名や価格など、それぞれにタグを一個ずつ設定する必要があるので記述が面倒くさい。 HTMLタグ以外の余分なコードが入るのでソースコードが読みづらくなる。

２．１で選んだ方の記述方法を理解する

今回はどちらも説明します。

JSON-LDを選んだ方

JSONーLDとはJavaScript Object Notation-for Linked Dataの略です。なんだか難しそうですね。

一言でいうと「GoogleにわかるようにデータをJSONというルールで記述したもの」という意味です。
（Linked Dataはウェブ上で処理しやすいデータを指します。）

百聞は一見にしかず。JSONのルールは人間にもすぐ理解できます。


{
"name": "ウェブ担当者通信",
"homepage": "https://webtan-tsushin.com/",
}


JSONの主な文法ルールは下記です。

1. {ではじまり}で終る。
2. 文字列は”（ダブルクォーテーション）か’（シングルクォーテーション）でくくる
   例）
   “name”
   “ウェブ担当者通信”
3. CSSのように:（コロン）を挟んで内容を記述する
   例）
   “name”: “ウェブ担当者通信”
4. ,(コンマ)で次のデータを記載する。次のデータがなかったらコンマは必要なし
   例）
   “name”: “ウェブ担当者通信”,
   “url”: “https://webtan-tsushin.com/”

なんとなくわかりますね。
このようにJSONのルールは全く難しくありません。

辞書を明確にする

しかしこのままでは人間は理解できてもGoogleには理解できません。
例えばWebsiteのURLを表すのに、urlと書く人もいれば、homepage-urlと書く人もいたりするとカオスになります。

そこで共通認識をもつためにウェブ上の辞書を使います。
一般的に使われるのがschema.orgというサイトで公開されているものです。（英語のサイトです）

そのschema.orgの辞書を使い、それをGoogleに伝える形で書き直すと下記になります。


{
"@context": "http://schema.org",
"@type": "WebSite",
"name": "ウェブ担当者通信",
"url": "https://webtan-tsushin.com/"
}


これも見てなんとなくわかりますね。
ルールは下記です。

1. 最初にschema.orgの辞書を使うことを宣言する
   例）
   “@context”: “http://schema.org”,
2. 次に、辞書の中のどのタイプを使ったのか伝える
   例）
   “@type”: “WebSite”,

実際のschema.orgの辞書はこちらにあります。
schema.org/WebSite

辞書なのでたくさんの単語登録がありますが、今回使ったのはnameとurlだけです。これで十分にGoogleに伝わります。
難しくないですね。

Microdataを選んだ方

Microdataはより直感的に理解しやすいかも知れません。 基本的な記述方法は「文章中の該当箇所にそれぞれ埋め込む」です。 例えば、商品ページの場合下記のようになります。


<p itemscope itemtype="http://schema.org/Product">
激ヤバなTシャツ<br>
メーカーは<span itemprop="brand">ラルフポーレン</span>。<br>
<meta itemprop="priceCurrency" content="JPY" />
今だけ半額 <span itemprop="price">3900</span>円
</p>


なんとなくわかりますね。

まずJSON-LDの時と同様、追加であなたがschema.orgの辞書中の単語を使ったということをGoogleに伝えないといけません。
そうしないとGoogleはbrandという単語を商品のブランドと理解すべきか、それとも英訳の燃え木と理解すべきか判断ができないからです。

schema.orgの辞書使用をGoogleに伝えるには、最初の一行目に以下を追加します。

そして具体的なデータ部分に関しては

という記述方法になっています。種類はブランドや通貨、価格などです。
これで完成です。

データハイライターについて

構造化データを検討している人はGoogleサーチコンソールについているデータハイライター機能を知っている人もいるでしょう。
これは、上記２つのコーディングができない人でもGoogleに自己申告できるようにした仕組みです。

具体的には、Googleに具体的なページのURLを通知し、そのページの任意の箇所をマウスで選んでGoogleに意味を伝えます。

例えば、イベント日付を記載している箇所をマウスで選んで、そこをGoogleに「イベント日です」と伝えます。
詳しくはこちらをご覧ください。

▼データハイライターについて

support.google.com/webmasters/answer/2692911?hl=ja

しかしページ数が多いサイトでは効率も悪く、細かいコントロールもできないのえ、今後もしっかり運用される場合はなるべくJSON-LDを活用する方がオススメです。

３．試しにシンプルなコードを書いてみて、構造化データテストツールでコツをつかむ

最後に、シンプルなコードを書いてみます。

テストに一番よいのはどんなサイトでも活用できる「パンくず」のマークアップだと思います。
Googleの公式ページにもサンプルがありますので記載しておきます。

developers.google.com/search/docs/data-types/breadcrumbs

こちらのJSON-LDやMicrodataのサンプルをもとに、自社サイトの１ページを選んでパンクズをマークアップしてみましょう。

＃テキストエディタなどでつくってみましょう。

完成したら、構造化データテストツールを使うと、正しくかけているかがわかります。

▼構造化データテストツール

search.google.com/structured-data/testing-tool/u/0/

ぜひコツを掴んでください。

2-3．具体的にどうサイトを変更したらよいのかわからない。

構造化データの設定方法がわかったら、実際の設定に入ります。 しかしここで、どのデータを設定したら良いのかわからなくなる人が多いと思います。 ウェブサイトの名称だけやればいいのか、それとも商品データも構造化すべきなのか。

どこまで対応すべき？

ここで判断基準を思い出してみましょう。

Googleからボーナス表示を受けるのが目的なので、逆にいえばボーナスがないものは対応しなくてもいいです。設定が大変ということもあるので、慣れるまではなるべく効果的なところだけ取り入れるという姿勢でよいと思います。

以下に2017年1月時点のボーナス表示の可能性があるサイト一覧を記載しますので、ぜひこの中から選んでみてください。
（URLはGoogle公式サイト（英語）を紹介しています。それぞれサンプルコードもありますので作りやすいと思います。）

ページ内のどこに記載すべき？

どの記述を入れるかが決まったら、あとはどのページのどこにデータ構造化コードを入れるべきか？という問題になります。

どのページに記載すべき？

まず記載するページの選択については、「そのデータが記載されているページ」です。

例えば、セミナーイベントデータをデータ構造化するならば、そのイベントが記載されているページにだけ記述を入れればよいです。

では問い合わせ先情報についてはどうでしょうか？

全部のページに入れても間違いではないですが、現実的なお話をすれば問い合わせページだけで構いません。
Googleが「問い合わせ先」として検索結果にボーナス表示してくれた時、そのリンクの飛び先としてどのページが適切か？と考えて導入しましょう。

一方、パンくずは全ページで違いますから、全ページでそれぞれマークアップすべきですね。

特殊ケース

複数のデータが入っているページの場合

例えば、Tシャツ販売ページにそのコーディネイト方法のビデオもある場合。
そのページにはと「商品」と「ビデオ」のデータ構造化コードが入って大丈夫です。

カテゴリページ

販売ページと違い、カテゴリページに関しては一つしか許されません。
例えば、Tシャツ一覧ページにコーディネイト方法の動画があったとしても、それが「商品の一覧」なのか、「ビデオの一覧なのかどちらか選ぶ必要があります。

この場合はおそらく「商品」ですよね。販売しているのはビデオではなくTシャツですから。
そこで商品の構造化データマークアップをした方がより適切だと思います。

商品画像が複数ある場合

販売ページに商品画像が複数ある場合、データ構造化では１つしか選べないので、どれか代表の画像を選ぶ必要があります。

記載するソースコードの位置は？

これはMicrodataとJSON-LDでそれぞれ違います。

重複はNG

注意事項として同じ内容を重複して記載してはいけません。
Microdataでも書いて、JSON−LDでも書いてという重複はやめましょう。

構造化データの判断基準まとめ

• 構造化データを導入するか否かは「少しでもSEOの順位をポイントアップしたいかどうか」と「Googleのボーナス表示」を期待するかどうかで考える
• ボーナス表示は、現在と未来で考える。現在のところは主に下記３つ。そんなに多くない。
  1. 全てのサイトに恩恵があるのはSEO目的のパンくず
  2. ECサイトの場合、対応すれば商品情報が目立つように表示される
  3. ユーザーレビューの関連するサイトの場合、ユーザー評価が★マークで表示される
• 構造化データの作業の費用対効果は、計算が難しい。
  • 現在はECサイトとレビュー以外は費用対効果がでないだろうから様子見でも構わない
  • ただし他のサイトがやっていないなら、突然何かがボーナス表示される可能性もあるので、今のタイミングで構築してもよい
  • その際には、schema.orgの辞書を確認しながら各種データをマークアップする。
• 導入の際はシステム(CMSとJSON-LD)を使った方が今後のメンテナンス作業は効率化される。

あなたのサイトで構造化データを導入すべきか否かの判断基準について(3)につづく