筆者が最近になって見かけるようになったもののひとつ、「構造化データ」。導入にあたりゼロ知識の状態から、そもそも何のためにあるの？目に見える効果があるの？などと自分が抱いた疑問をもとに、構造化データとはどのようなものかをまとめてみました。
構造化データとはそもそも何なのか
検索結果画面にリッチリザルトを表示してくれるもの
Googleなどの検索エンジンは、ウェブページのソースコードに記述されているtitleタグやdescriptionタグの内容を自動的に拾って検索結果画面に表示しています。しかし、そのテキストの意味までは理解していません。
例えば弊社名の「スマイルミッション」を検索エンジンが読み込むだけでは、「スマイルミッション」という文字列が会社名なのか、何かのプロジェクト名なのか、はたまた場所の呼称なのかすらわかっていないような状態です。
そこで、検索エンジンにその文字列が何を指しているかを教えることで、検索エンジンが自ら判断し、必要としているユーザーにより適切な情報を提供できるようにしよう、という考えが生まれました。この考え方を「セマンティックWeb」といい、検索エンジンに文字列の意味を教える記述を「構造化データ」といいます。
「スマイルミッション」は会社名、「前橋市」は会社の所在地だと意味づけることで、機械でも「前橋市という場所にあるスマイルミッションという会社」ということが理解できるようになります。
社名以外にも、ウェブページ上に記載されている数字を「電話番号」や「評価」と紐付けることもできます。
これは、Googleで「肉じゃが 作り方」と検索したときに表示される画面です。レシピ名以外にもレビュー数や、調理時間が表示されています。このような詳細な情報の表示を「リッチリザルト」と呼びます。
構造化データをマークアップすることで、ユーザーが閲覧するページを選ぶ上で参考になりそうな情報を検索エンジンが判断し、検索結果画面を自動でカスタマイズしてくれます。
探しているページを早く見つけることができる便利な機能だね！
構造化データはあまり普及していない？
構造化データは、ウェブページのソースコード上に書く必要があります。実際に10社程度のウェブサイトのコードを見たのですが、構造化データが書かれているサイトはそのうち１、２社しかなく、ほんの一握りにしか普及していないという印象でした。
世界で初めてのウェブサイトが公開されたのは1990年。さらに構造化データの根本になっている「セマンティックWeb」は、1998年にW3C（World Wide Web Consortium／Web技術の標準化を行う非営利団体）のティム・バーナーズ=リー氏が提唱したものです。いつ頃から体系化されたのかは定かではありませんが、構造化データについて筆者が調べたうち、最も古い日付の記事は2014年となっており、今日までにすでに10年近く経過しています。ウェブ史上では、構造化データはかなり古くからあるものと思われますが、なぜ導入しているウェブサイトが少ないのでしょうか。
構造化データが普及しない原因を、実装しながら考えてみた
似たような意味の単語が多く、選定が難しいうえに、検証に手間がかかる
普及が進まない原因として、実装難易度の高さがあると考えられます。
構造化データでは、ターゲットとなる文字列と、それが何を示すのかを決める「プロパティ」とを紐づける必要があります。
今回は企業サイトの求人ページに対して構造化データを作成したのですが、
「求人情報」を示すプロパティはJobPosting
「人材募集」を示すプロパティはRecruiting
など、日本語でも英語でも意味が似ているものがいくつかあり、どれを採用するべきか非常に迷いました。
構造化データは英語ベースで作られているため、個人的な体感ですが日本語に当てはめてニュアンスを揃えることが難しいプロパティもあるようでした。
また、せっかく意味を調べて設定できても、構造化データをどの程度理解できるかは検索エンジンの仕様によるため、プロパティによってはうまく認識されないケースもあります。今回はGoogleのリッチリザルトテスト（後述）で検証を行ったのですが、「Recruiting」プロパティが認識されなかったため、「JobPostiong」プロパティを採用するに至りました。
ですが、毎回検証ツールにかけて、その結果次第で内容を修正するというのは、制作者にとって少なからず手間に感じるのではないかと思います。
どこまでの情報をまとめればいいのかが不明瞭
例えばとある企業のページに対して、以下のような２通りの構造化データを用意したとします。
情報量はパターン２のほうが充実していますが、パターン１の量でも構造化データとして問題はありません。さらに、パターン２ほど充実させても、入力した情報全てがリッチリザルトに反映されるわけではありません。
ページに記載されている全ての情報を構造化してもよいのですが、かなりの手間がかかります。サイト内の全てのページに反映させるとなると、ページの内容によって記述を替えなくてはいけないからです。ウェブサイトの管理のしやすさも考慮すると、なるべく最低限の構造化に留めたいところですが、「ここまで明記されていれば十分」という条件が明確に示されていないために工数が測りしれず、導入のハードルが高く感じられるのではないでしょうか。
構造化データは必要なのか？
あってもなくてもいいが、あればクリックを促せる
ここまでで導入の難しさを紹介しましたが、正直、「めんどくさそう…」と感じると思います。
構造化データの記述は、必ずしも行わなければいけないものではありません。
記述がなくても、検索結果画面への表示やページの表示速度、SEOにめっぽう不利になる、などのデメリットもありません。
そのかわりというと変な気もしますが、構造化データは必ずしもサイトにいい影響を及ぼすとも言い切れません。
Googleのジョン・ミューラー氏によって、構造化データは検索順位に直接的な影響がないことが言及されていてかつ、構造化データを記述したからといって、必ずしもリッチリザルトに反映されるとは限らないようです。
構造化データが検索結果画面に反映されるかどうかは「検索エンジンの御心次第」ですが、リッチリザルトとしてきちんと反映されれば、ユーザーのクリックを後押しする重要な要素になり得ます。そのため、実装してもしなくても問題はないのですが、あれば便利と思っていれば間違いないでしょう。
リッチリザルトに採用されやすくなる方法
検索エンジンにリッチリザルトとして採用される可能性を上げるためには、構造化データの精度とページの品質をそれぞれ向上させることが重要です。
構造化データの精度を上げるためには、Googleが公表している「構造化データに関する一般的なガイドライン」に準じた記述を行うことや、構造化データが正しく記述されているかどうかをテストできるWebツール、「リッチリザルトテスト」で検証を行うことが有効です。
また、ページの品質を上げるためには、ユーザーがスムーズに目的の情報を得られて、検索エンジンにも構造を理解しやすいページにすることが重要です。例えば、
- HTMLタグのルールを遵守する
- 読みやすい文章設計や構成にする
- ページの読み込み速度が重たくならないよう画像の圧縮などを行う
などの施策が挙げられます。
誤った記述方法は直すべし！ペナルティのおそれも…
構造化データは、誤った書き方をしてしまうとエラーが発せられ、マークアップした内容がうまく反映されない場合があります。また、すぐに直さず放置しているとSEOにもマイナスの評価が付く可能性があります。
構造化データを記述する場合は、ミスがないかしっかり確認・修正を行いましょう。
終わりに
構造化データの考え方自体は古くからあるものの、その導入の難しさや、実際に反映されるかどうかの不確実性、SEOへの効果の薄さにより現在まで敬遠されてきている印象があります。しかし、冒頭に紹介した「肉じゃが 作り方」と検索したときのように、リッチリザルトが表示されることで、サイト名やタイトル以外でもページの魅力を発信でき、インプレッションの増加に繋がりやすくなるメリットもあります。
別の記事で、リッチリザルトにはどのような種類があるのかについてご紹介できたらと思います。構造化データが実際にどのように検索結果画面に影響するのかをもとに、より適切なプロパティを選択できる判断材料になれば良いなと思います。
