ポータルサイトと構造化データ

Googleが推奨する「構造化データ」。ポータルサイトとの相性が良く、インパクトが大きいためSEO効果が期待できます。その「構造化データ」についてご紹介します。

インパクトの大きい構造化データ

ポータルサイトは個々の情報を集約したサイトですが、その個々の情報を正しく伝える(コンピュータが解析しやすくなるようにする)手段が「構造化データ」です。

Webページの構造や内容はさまざまため、検索エンジンにとっては、必要な情報がどこにあるのかがわからない場合もあります。 そこで「構造化データ」を使って検索エンジンに正しく情報を伝え、SEOの効果をより引き出します。

さらに、データの内容によってはGoogle検索結果で目立つことができます。
例として「心菜 新宿」でGoogle検索してみると、右側にパネルが表示されます。(デスクトップ版。下図参照)

「心菜 新宿」の検索結果画面

このパネル(「リッチスニペット」や「リッチカード」と呼ばれます)の情報の一部(※1)は、構造化データによって表示されています。

情報元のひとつは食べログの詳細ページです。
このページのソースコードには構造化データが記述されており、Googleはそれを読み取って施設の基本情報やレビュー、予約リンクなどを表示しています。

「構造化データ」の仕様

構造化データには、上記のパネルのようなもの以外にも様々な表示形式があります
記述方法も数種類ありますが、Googleが推奨するのは JSON-LD(ジェイソンエルディー) というデータ形式を用いた記述方法です。
JSON-LD は、Web開発者には馴染みの深い JSON形式 のデータで記述できるため、既存サイトへの組み込みも容易です。

しかし、適当に情報を記述すれば良いわけではなく、書き方には決まりがあります。
例えば「施設」や「求人」、「人物」や「イベント」など、情報の種別によって書き方が変わります。

各種別は schema.org という団体によって規定されています。
この団体は Google、Microsoft、米Yahoo などの大手企業や一般の開発者などが共同で運用しています。

ポータルサイトでの活用

ポータルサイトで構造化データを活用する場合、可能であれば「どのような情報を掲載するか」という設計段階から視野に入れるとスムーズです。
schema.org の仕様に当てはめにくいデータだと、検索エンジンが正しく読み込んでくれない可能性が出てくるためです。

例えば、施設検索系のポータルサイトでの「住所」の表記について考えてみます。

管理画面での住所入力の際、1つの入力欄に「東京都新宿区~」と住所の全てを記入することも多いですが、この場合、構造化データに使用する場合も1行のデータとして記述します。

これでも構造化データの仕様としては問題ありませんが、schema.orgには PostalAddress形式 というものがあり、この仕様に従うと、より正確な情報を検索エンジンに伝えることができます。
具体的には、「都道府県(addressRegion)」「市区町村(addressLocality)」「町域以下(streetAddress)」「郵便番号(postalCode)」を各個別データとして分けて入力します。

こういった分割はポータルサイト完成後の変更に手間がかかるため、設計段階から意識すると良いでしょう。

構造化データを設定できたら、構造化データテストツールでエラーがないか検証することができます。
試しに、前述で検索した食べログの「心菜」のページの検証結果を見てみましょう。

schema.org の「Restaurant形式」に基づいて記述されているのがわかります。

「心菜」のページ検証結果

レビュー数(ratingCount)や平均点(ratingValue)などのデータが含まれており、これがGoogle検索結果にも表示されます。
表示されることでユーザーの目を惹き、訪問の増加が期待できます。

以上のように、ポータルサイトで構造化データを活用することでアクセスアップが期待でき、さらに schema.org の仕様や分類法を参考にすることで情報の整理にも役立ちます。
もしポータルサイトの情報設計にお困りでしたら、ぜひ考慮ください。

※1:リッチスニペットの情報は様々なサイトから収集されているため、全てではありません。