Yoast SEOによるJSON-LD階層構造化マークアップの方法

Yoast SEOが指摘した問題点

Yoast SEO が指摘したのは、 JSON-LD でマークアップした項目同士の関連性をクローラーが理解できるのか？という問題提起です。

上の図をご覧ください。 POCO の開発初期に実装した JSON-LD コードをGoogle の「構造化データテストツール」で検査した結果です。

この例は投稿ページで、 BlogPosting （投稿ページ本体）と BreadcrumbList （パンくずリスト）というふたつの項目が別々に表示されています。

Yoast SEO が指摘したのは、これまでのマークアップ方法ではこのふたつ（サイトによってはもっと多くの項目）が独立して存在しているという点です。

別々に出力した項目は検索エンジンのクローラーが理解できない（混乱する）のでは？という問題提起をしました。

改善案は @graph と @id による連結

この問題提起に対して提案された対策、それは @graph の使用と @id による項目同士の連結でした。イメージとして説明します。

上の図をご覧ください。ひとつの投稿ページに対して以下の項目 (@type) を用意します。

1. WebSite （ウェブサイト本体）
2. WebPage （ウェブサイト内のあるページ、記事を入れるフレーム）
3. Article （あるウェブページ内にある記事）
4. BreadcrumbList （パンくずリスト）
5. Person （記事の執筆者）
6. Organization （サイトを運営している組織）

上記6項目が @graph の配列要素として横並びになっています。上の図ではスペースの関係上、横一列ではなく @graph の要素というイメージになっています。

このスタイルで書かれた JSON-LD コードを構造化データテストツールにかけると、 Article という1つの大きな階層構造になります。6項目を別々に認識しません。

どうして各項目が連結するのでしょうか？

ここで @id が登場します。 @graph 内の項目同士に同じ @id が存在していたら、クローラーは関連性があるものとみなしてリンクするのです。このリンクを Yoast SEO の記事では接着 (glue) と呼んでいます。

Schema.org では膨大な量の属性を用意しています。私も含めて、あの資料を見た人はうんざりしたのではないでしょうか？

Yoast SEO はその中から厳選して、以下の属性値と @id を使って連結化に成功したのでした。

• isPartOf: WebSite と WebPage を連結するため、また WebPage と Article を連結するために使用
• breadcrumb: パンくずリスト (BreadcrumbList) の指定に使用
• author: 記事の執筆者 (Person) を指定するために使用
• publisher: 記事のリリース元 (Organization) を指定するために使用

ちなみに、この @graph と @id による連結方法は W3C による JSON-LD 形式の仕様として書かれています（ただし、非規範的としていますが）。トリッキーな方法ではないのです。

外部リンク：Named Graphs | JSON-LD 1.1, W3C Editor’s Draft

POCO で対応しているページタイプ

POCO では以下の 4 タイプのページで JSON-LD の階層構造マークアップを生成します。

• 投稿ページ
• 固定ページ
• ホームページ（固定ページの場合）
• ホームページ（最新記事一覧の場合）

投稿ページのイメージは前節で紹介した構造化マークアップのしくみと同じです。残りの 3 タイプについては下のイメージになります。いずれも投稿ページを簡略化させた形になります。

POCO では原則投稿ページと固定ページしか構造化マークアップはやりません。しかし Yoast SEO のワードプレスプラグインを使うとアーカイブページなども対応します。

外部リンク：Yoast SEO 11.0: Structured data awesomeness • Yoast

投稿ページの例による JSON-LD コード

前節で紹介した 4 タイプのページのうち、投稿ページは他の 3 タイプをカバーしている最も詳細なマークアップとなっています。

下の図は投稿ページのマークアップ結果です。構造化データテストツールで解析すると、これだけ細かくなるのです。

コードの総量は増えました。ただし、最初に紹介した WebPage, Article など 6 項目がすべて含まれていますし、 Google が要求する全項目をひとつの Article 項目として階層構造化することができました。

構造化テストツールの検査の結果、エラーも警告もありません。

WebSite

WebSite はサイト（ブログ）全体の情報なので、属性は多くありません。

ただし気になったこともあります。属性の image と description が Yoast SEO では出力していませんでした。そのため POCO ではこのふたつを追加しました。

image はサイトのイメージ画像を指定すべきです。ただひと口にイメージといっても、正方形アイコンなのか、横長ロゴ画像なのか、テーマ画像なのか、複数候補があります。

ここでは正方形のアイコンの URL を image に指定しました。根拠はあります。ブラウザでブログにアクセスすると、ブラウザ左上に出るイメージは正方形アイコンです。またスマホのホーム画面で表示される画像も正方形アイコンだからです。

description はサイトの説明です。ワードプレスでは bloginfo(‘description’) 関数でサイトの説明文を取得することができます。せっかくある項目を省略するのはもったいないため、 POCO では description 属性を追加しました。

WebPage

WebPage はとても混乱しました。調べると似たような項目がたくさんあります。

• WebPage
• Article
• BlogPosting
• NewsArticle

NewsArticle は一部の情報によると検索結果でカルーセル表示されやすいとも言われています。しかしブログはニュースではありません（ニュースの解説記事に NewsArticle を使っても良い）。

何を使うべきでしょうか？ BlogPosting にすべきでしょうか？

検討の結果、私はこのように判断しました。

• WebPage は記事を部品として含むウェブページのフレームと解釈する。なぜなら WebPage 項目でも投稿ページならをパンくずリスト入れ、固定ページの場合は入れないなど分けて処理している。
• Article を記事本文と位置付ける。 パンくずリストと同じで WebPage を構成する部品とする。ただし記事の URL （パーマリンク）は Yoast SEO にならって Article ではなく WebPage に記載する。
• BlogPosting は使わずに記事本文は Article で統一する。

そのほか、 Yoast SEO との変更点はこのようになっています。

• image 属性は削除、なぜなら WebPage だけ primaryImageOfPage という専用属性があるから。両方あってもエラーではないが、冗長ではないか？
• datePublished, dateModified は Article と重複しているので削除。ただし WebPage 内に複数の記事を表示させるのであれば、最終更新日などの情報を WebPage が持っても良いという考え。
• description は記事の概要という解釈。そのため WebPage ではなく Article で記載すべきとして削除。複数の記事があったり、まとめページやアーカイブ（記事一覧）ページであれば WebPage でも持っても良いという考え。

Article

Article は記事本文なのでマークアップの最も重要な部分です。そのため抱えている属性も一番多いです。

Yoast SEO では description を Article ではなく WebPage の属性としていました。私には違和感だったので Article に移動しました。少なくとも個人ブログなら Article に記載すべき属性です。

keywords は記事の内容を簡潔に表す SEO 的には本来必要な項目です。しかし W3C によると、スパム攻撃に使われてきた経緯があり現在は利用を推奨していません。この考え方にならい POCO でも削除しました。

commentCount は記事に対するコメント数です。通常のワードプレスブログならコメント欄があるのが普通です。しかし POCO ではスパム対策のためコメント欄はありません。したがってこの属性も削除しました。

Organization

Organization はサイト運営組織の情報を記載します。法人向けの属性であり個人ブログでは本来は不要なはずです。しかしそれではもったいないので、 WebSite と同じサイト情報を Organization でも持たせています。

image と logo はともに #logo という属性値でした。法人であれば会社のロゴが別にあり、 #logo でもいいでしょう。しかし個人ブログでは基本的に運営者ロゴとサイトロゴは同じなはずです。そのため属性値をそれぞれ #siteimage, #sitelogo に変更しました。もちろん他の名前に変更可能です。

そして、 image は正方形アイコン、 logo は横長のアイコンを別々に指定しています。 POCO は元々正方形アイコンと横長のロゴを両方実装しているためです。アイコンしかない場合は logo もアイコン画像を指定すれば良いでしょう。

Person

Person は特に変更した属性はないのですが、 POCO 独自の設定（定数）を使っているので簡単に説明します。

image (#personlogo) は portrait.png を出力します。必ず自画像を用意してください。

url はプロフィールページです。ブログ内の詳細なプロフィールページを指定することをお勧めします。

sameAs は SNS サービスのアカウント (URL) を指定します。 POCO では標準でツイッターのアカウントを作ることになっています。そのため Twitter プロフィールページの URL が出力されます。

他にも facebook や他の SNS のアカウントがあれば追加しましょう（その際はコード修正が必要）。