現在作成しているNextJSのプロジェクトの中でSEO対策をどうしようとGPTに相談したところ、JSON-LDを勧められたので公式ドキュメントを参考にしながらどういうったものかと使い方をインプットしてみました。
といっても使い方としてはHeadタグの中にJSON-LDの規格に沿ったJSONオブジェクトを埋め込むだけなのですが、そもそもこれがどこにどのように使われるのか、どうしたメリットがあるのかよくわからなかったので調べてみます。
JSON-LD公式サイト: https://json-ld.org/
Schema.org公式サイト： https://schema.org/
JSON-LDとは
JSON for Linking Data の略称で、構造化データの標準仕様のことでJSON-LDはW3C JSON-LD Community Groupによって開発されているそうです。
機械(以降クローラー)がサイトの内容を理解するのを助けてくれるそうで、HTMLタグだけだと汲み取れない内容について示すことができるそうです。
そしてJSON-LDに指定するプロパティの標準化はGoogle、Microsoft、Yandex、Yahoo！などの検索エンジンが関わり規定しておりSchema.orgという組織として規格とその周辺について運営されているとのこと。
ほとんどのウェブマスターは、ページのHTMLタグに精通しています。通常、HTMLタグはそのタグに含まれる情報をどのように表示するかをブラウザに指示します。たとえば、<h1>アバター</h1>は、「アバター」という文字列を見出し1の形式で表示するようブラウザに指示します。しかし、HTMLタグはそのテキスト文字列が何を意味するのかについての情報を与えません。「アバター」は大成功した3D映画を指すかもしれませんし、プロフィール写真の一種を指すかもしれません。
Schema.orgは、ウェブマスターが主要な検索エンジンが理解できる方法でページをマークアップするために使用できる共有語彙のコレクションを提供する： Google、Microsoft、Yandex、Yahoo！
https://schema.org/docs/gs.html よりDeepL翻訳
引用した内容の通り、HTMLタグとその中身によって文脈が汲み取れない場合、正しく内容をクローラーに判定してもらえなくなることになります。各種検索エンジンにとって理解しやすいプロパティがSchema.orgであるためSchema.orgの規格に従いJSON-LDを埋め込む方が無難といえます。
Q: なぜグーグル、ビング、ヤンデックス、ヤフーが協力しているのですか？競合ではないのですか？
現在、ウェブページ上のさまざまなタイプの情報をマークアップするための標準やスキーマは数多く存在する。その結果、ウェブマスターが最も適切でサポートされているマークアップ標準を決定するのは困難です。
すべての主要検索エンジンでサポートされているスキーマを作成することで、ウェブマスターはマークアップを追加しやすくなり、検索エンジンはユーザーにリッチな検索機能を提供しやすくなります。
https://schema.org/docs/faq.html#0 より DeepL翻訳
JSON-LDを使うメリット
Googleが推奨している
Googleの公式サイトで推奨されています。ちなみにSchema.orgが規格を提供していますが推奨プロパティなどについてはGoogle側で用意しているものを参照することを勧めています。
SEO効果
アクセス数が増える効果があるようです。Google推奨とのことなので多少はJSON-LDが有利になるかもしれません。
JSON-LDは構造化データとのことですのでSEO効果とは構造化データ全般のメリットと同義です。
JSON-LDのメリットについて簡単に調べてみるとSEO向上につながると掲載されています。しかし具体的にどのような効果があるのか詳しく掲載されていませんでしたがGoogleの公式サイトに記載があります。
Rotten Tomatoes では、構造化データを 10 万ページに追加した結果、構造化データを含むページでのクリック率が、構造化データのないページに比べ 25% 増加しました。
The Food Network では、全ページの 80% で検索結果の機能を有効にした結果、アクセス数が 35% 増加しました。
楽天では、構造化データを実装したページでのユーザーの滞在時間が、構造化データのないページに比べ 1.5 倍長くなりました。また、検索機能がある AMP ページでのインタラクション率は、検索機能がない AMP ページに比べ 3.6 倍高くなっています。
Nestlé では、検索でリッチリザルトを表示するページのクリック率が、表示しないページに比べ 82% 高くなっています。
引用：Google 検索での構造化データのマークアップの仕組み概要 - https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data?hl=ja
特殊ページでの表示
レシピ検索結果など特定のジャンルにおいてにだけ表示されるUIにおいても構造化データを元に表示されるそうです。単純に表示される検索結果の数が増えることになるのでアクセス数は増えるかと思います。JSON-LDとは限らないと思います。
リッチスニペットの表示
リッチスニペットとは検索一覧でサムネイルを表示したり、レビューを表示したり、記事についての詳細以外のプラスアルファで表示されている部分にあたるそうです。これもJSON-LD限らずかと。
シンプルに検索表示された際に情報量を多く掲載できた方がクリックする前の判別に使えます。クリック前情報をあえて詰め込みたくない場合でない限り利用したいです。
JSON-LD以外との違い
構造化データはJSON-LD以外にもMicrodata、RDFaと３つの書き方があります。JSON-LD以外は趣旨ではないためGPT-4oにささっと比較テーブル作成してもらいました。
| 形式 | 主な特徴 | メリット | デメリット |
|---|---|---|---|
| JSON-LD | JavaScriptオブジェクト形式 | HTMLから分離、読みやすくメンテナンスが容易 | JavaScriptが使えない環境では無効 |
| Microdata | HTML属性形式 | HTMLと統合、即時レンダリング可能 | メンテナンスの複雑化、可読性の低下 |
| RDFa | HTML属性+リソース記述 | 複雑なデータモデルの表現が可能、更に互換性高 | 複雑さが高く、HTMLの冗長性が増す |
自分はなんらかの理由でJavaScriptが使えない場合を除いてあまりメリットはないように見えるためJSON-LDを使います。
JSON-LDの使い方
書き方
<script type="application/ld+json">
{
"@context": "https://schema.org/",
"@type": "Recipe",
"name": "Party Coffee Cake",
"author": {
"@type": "Person",
"name": "Mary Stone"
},
"datePublished": "2018-03-10",
"description": "This coffee cake is awesome and perfect for parties.",
"prepTime": "PT20M"
}
</script>
JavaScriptベタ書きであれば上記のように書くようです。
ReactだとHeadタグにscriptタグを埋め込んで使う形になるかと。
json-ldのライブラリもあります。 https://www.npmjs.com/package/jsonld
特殊なプロパティについて
プロパティとして "@item" というプロパティがあります。@はitem typeと呼ばれるもので、抽象化されたプロパティを指しています。
"@item": "Person" であればであれば人物の名前や特徴に対しての抽象化したitem typeです。
他にも色々な種類があり、オブジェクトの階層毎に@itemを追加することができます。
Here's a set of commonly used item types:
Creative works: CreativeWork, Book, Movie, MusicRecording, Recipe, TVSeries ...
Embedded non-text objects: AudioObject, ImageObject, VideoObject
Event
Organization
Person
Place, LocalBusiness, Restaurant ...
Product, Offer, AggregateOffer
Review, AggregateRating
JSON-LDの@typeを使ってみた例
{
"@context": "https://schema.org",
"@id": "http://dbpedia.org/resource/Taro_Tanaka",
"@type": "Person",
"name": "田中太郎",
"jobTitle": "Software Engineer",
"worksFor": {
"@type": "Organization",
"name": "Example Inc."
},
"email": "tanaka.taro@example.com",
"url": "https://www.example.com/tanaka-taro"
}
これをJSON-LD公式のplaygroundでデコードしたら下記のような形になりました。
[
{
"@id": "http://dbpedia.org/resource/Taro_Tanaka",
"@type": [
"http://schema.org/Person"
],
"http://schema.org/email": [
{
"@value": "tanaka.taro@example.com"
}
],
"http://schema.org/jobTitle": [
{
"@value": "Software Engineer"
}
],
"http://schema.org/name": [
{
"@value": "田中太郎"
}
],
"http://schema.org/url": [
{
"@id": "https://www.example.com/tanaka-taro"
}
],
"http://schema.org/worksFor": [
{
"@type": [
"http://schema.org/Organization"
],
"http://schema.org/name": [
{
"@value": "Example Inc."
}
]
}
]
}
]
JSON-LDはどこまで作り込むべきか
Q: すべてのプロパティをマークアップする必要がありますか？
マークアップはオール・オア・ナッシングの選択ではありません。しかし、可能な限り多くのコンテンツをマークアップすることで、検索エンジンがあなたの情報を利用して、最も有用な方法であなたのページをユーザーに提示することができます。一般的なルールとして、ウェブページを訪れた人に見えるコンテンツだけをマークアップし、隠しdivやその他の隠れたページ要素にあるコンテンツはマークアップしないようにしましょう。
https://schema.org/docs/faq.html#0 より DeepL翻訳
特別な理由がなければできるだけ多いに越したことはないようです。
おまけ：音声検索にも使われる構造化データ
音声検索最適化のことをVSO(Voice Search Optimization）と呼ぶそうです。
schema.orgのspeakableというプロパティを設定すれば音声検索の際にも参照されるそうです。
speakable schema.org プロパティを使用することで、テキスト読み上げ（TTS）を使用した音声再生に最適なセクションを記事やウェブページ内から指定できます。マークアップを追加すると、Google アシスタント搭載デバイスで TTS を使用して読み上げるコンテンツを、検索エンジンやその他のアプリが識別できるようになります。ウェブページに speakable 構造化データを導入すると、Google アシスタントを使用して新しいチャネルでコンテンツを配信することで、より多くのユーザーに訴求できます。
スマート スピーカー デバイスでは、Google アシスタントが speakable 構造化データを使用して話題のニュースに関する質問に答えます。ユーザーが特定のトピックに関するニュースについて尋ねると、Google アシスタントはウェブから最多で 3 本の記事を取得して質問に答えます。記事内の speakable で構造化されたセクションに対しては、TTS を使用した音声再生がサポートされます。Google アシスタントが speakable で構造化されたセクションを読み上げる際には、情報の提供元が示され、記事全文の URL が Google アシスタント アプリを通じてユーザーのモバイル デバイスに送信されます。
引用：読み上げ（Article、WebPage）の構造化データ（ベータ版）bookmark_border - https://developers.google.com/search/docs/appearance/structured-data/speakable?hl=ja