このサイトではWordPress、Nuxt.js、AMP、ゲームサイト製作など、その時々で興味のあるテーマを自分用にまとめてきましたが、今回は構造化データについてです。
今回まとめるのは「Article(記事)」「BreadcrumbList(パンくずリスト)」などの単発の構造化データではなくて、それらを統合的に扱う「Yoast SEO式」なる構造化データです。
「構造化データとは何か?」「構造化データはどう書くのか?」みたいなことは今回の内容には含みません。
それらを知っている前提でYoast SEO式に統合していく上での考え方や手順をまとめたいと思います。
WordPressの上でな!
※ このブログはまだWordPress製です
このページの目次
Yoast SEO式の構造化データとは
「Article(記事)」「BreadcrumbList(パンくずリスト)」「Person(著者)」などの単品の構造化データを、そのページの中心となる構造化データ(ブログならArticle)を中心に関連づけた構造化データのようです。
「Yoast SEO式」という名前的におそらくWordPressのプラグイン「Yoast SEO」に導入されている構造化データなんじゃないかと思いますが、ここではWordPress以外でも実装できるように、プラグイン側に頼らずカスタマイズできるようにまとめていきます。
勉強するにあたりこちらのサイトを多分に参考にしています。
今回の記事では上の記事の内容を自分が理解しやすいよう噛み砕いたものなので、詳しく知りたい人は上のPOCOさんを見てください。
そもそも構造化データのメリット
Googleがページの内容を理解するのに使っているようです。
参考:構造化データの仕組みについて
Googleの検索セントラルの「上級者向けSEO」の項目に記載があるので、おそらく検索順位向上に有利になるのでしょう。
さて。
Googleに記載があるからと言って「本当に構造化データはSEOに効果があるのか?」と言われると、「どの程度?」の部分まで含めると疑問は尽きないわけでして。
自分で確認しようとするなら、全く同じページを構造化データを実装した場合とそうでない場合で、検索順位、検索結果に反映されるまでの速度など比較しないとはっきりとしたことは言えないわけでして。
そんなことは不可能なわけでして。
そんな中で僕が自分に「構造化データを実装する価値がある」と納得させたお話をします。
Googleが推奨している
まずはコレですよね。
上に書いたように自分で効果を確認するとなると難しいですが、Googleが書いている以上は「おそらく」効果はあるんでしょう。
構造化データは悪用されている
構造化データをGoogleのガイドラインとは異なる形で利用し、不当にページ評価を得られるケースがあるそうです。
前に見かけたのは、旅行サイトの「FAQPage」やニュースサイトの「Event」などでのガイドライン違反でした。
加えて、つい先日、友人と話しに上がったのですが、フィッシングサイトが根拠のない「AggregateRating」を利用し、検索結果の上位に出ている例を見かけました。 アクセスしても怪しいページにリダイレクトされるタイプだったので、意図的に悪用しているんでしょう。
ここから言えそうなのは…、
悪用する人がいるということは効果がある
ってことです。
(前者は悪用ではなく知識・技術不足ではないかと思っていますが)
これらの事実はGoogle公式の説明文より、ある意味においてはよっぽど説得力があると思います。
あ、悪用をしようって言ってるんじゃないですからね。 正しく効果を得ようとするための根拠の部分のお話です。
ただし必須でもない
先日、Nuxt.jsやら個人のゲーム攻略サイトやら、いくつかのテーマを掲げてオレGAME.comという実験場を作りました。
この中のひとつに「構造化データを使わない」というのがありました。
(ついでにパンくずリストも置かない)
結果は発売1カ月で100万PV達成という大成功。 詳しくはこのページあたりを見てください。
というわけで、僕の中での構造化データに対する認識は、
実装すれば確実に効果があるけど、「ないと必ず失敗する」という類いのものではない。
あとは実装コストと結果のバランスで検討すればいいのかなと。 特に今回のYoast式は自前実装となるとけっこう時間がかかります。
僕は構造化データ書くのがけっこう好きなので、よっぽど時間ない限りは書きたいなと思ってます。
Yoast SEO式の構造化データの基本的な考え方
最初にも書いた通り、構造化データのパーツをそのページの中心となる構造化データを中心に関連づけるものです。
どのような流れで関連付けまで行うのかを、先にざっくりとまとめます。
- 必要な構造化データを決める
- それぞれの構造化データを個別にマークアップする
- 構造化データのルートに「@graph」という名前で全ての構造化データを配列にする
- それぞれの構造化データを関連づける
バラバラの構造化データを定義して、参照という形で関連づけていく、みたいなイメージでしょうか。
この方法でマークアップすると、関連付けができるだけでなく、サイト情報やバナー画像など、複数回登場するデータも一度のマークアップで済むのもメリットです。
Yoast SEO式の構造化データの具体的な書き方
そのページに必要な構造化データをまず考える
ブログを例に考えます。
主軸となるのは「Article」です。
Articleには必須プロパティとして以下の3点が含まれています。
- Person:
「author」プロパティに著者として。 - ImageObject:
「image」「logo」プロパティに画像として。 - Organization:
「publisher」プロパティに運営団体として。
必須プロパティの他にもいくつか大事な情報があります。
- BreadcrumbList:
ページのパンくずリスト。 - WebPage:
ページ自体の情報。 - WebSite:
サイトの情報。
参考サイトに習い、この7種類を基本セットとします。
ページの内容によって「Article」が「FAQPage」になったり、そもそもなかったり(トップページとか)、変えればいいのかなと。
ArticleとWebPageはどちらかじゃないのか?
OrganizationとWebSiteはどちらかじゃないのか?
本来の用途としては、Organizationは所属団体・法人、WebSiteは自分のサイトの説明に使うそうです。
このサイトみたいな個人で運用してるブログの場合だと、WebSiteはあるけどOrganizationはない、というケースがほとんどだと思います。
ところが「Article」において、Organizationは必須プロパティなんですね。 逆にWebSiteはなくてもいい。
実態と必要性が真逆になってしまっているので、やむなしに両方実装します。
中身は同じでいいと思います。
(サイト=運営者)
それぞれの構造化データを個別にマークアップする
上に挙げた7つの構造化データを個別にマークアップします。
例えばPersonだとこんな感じ。
{
"@type":"Person",
"name":"山田 メガネ"
}
この時に下のように「@id」を必ず指定しておいてください。
{
"@type":"Person",
"@id":"#Author",
"name":"山田 メガネ"
}
あとで関連づけする時に使います。
実装する構造化データを配列にする
上で構造化したパーツを、「@graph」という名前で配列にします。 ImageObjectはロゴやバナーなど、用途に合わせて複数用意します。
{
"@context":"https://schema.org",
"@graph": [
{ "@type":"Article", //略 },
{ "@type":"Person", //略 },
{ "@type":"ImageObject", //略 },
{ "@type":"ImageObject", //略 },
{ "@type":"Organization", //略 },
{ "@type":"BreadcrumbList", //略 },
{ "@type":"WebPage", //略 },
{ "@type":"WebSite", //略 }
]
}
構造を見やすくするために極限までシンプルにしています。 もうちょっと具体的に書くと↓こんな感じ。
{
"@context":"https://schema.org",
"@graph": [
{
"@type":"Article",
"@id":"article",
//以下略
全文みたい人はこのページの構造化データを見てみてください。
各構造化データを関連づける
上のままではバラバラで意味を持たないデータになっているので、各要素を関連づけしていきます。
Articleへの関連づけ
Articleへ関連づけるのは次の4点です。
- Person(著者)
- ImageObject(記事のバナー画像)
- Organization(公開している団体)
- WebPage(フレームとしてのウェブページ)
それぞれのIDを「#Author」「#Banner」「#Organization」「#WebPage」として設定した場合、関連付けは次のようになります。
{
"@type":"Article",
//中略
"author":{"@id":"#Author"},
"image":{"@id":"#Banner"},
"publisher":{"@id":"#Organization"},
"isPartOf":{"@id":"#WebPage"}
}
データ自体は既に定義しているので、IDで参照先を指定するだけです。
Personへの関連づけ
Personへ関連づけ必須なものはなさそうですが、次の2点くらいはいけそうです。
- ImageObject(著者の写真やイラスト)
- Organization(著者の所属団体)
それぞれのIDを「#AuthorImage」「#Organization」として設定した場合、関連付けは次のようになります。
{
"@type":"Person",
//中略
"image":{"@id":"#AuthorImage"},
"memberOf":{"@id":"#Organization"},
}
Organizationへの関連づけ
Organizationへの関連づけは、次の2点くらいでしょうか。
- ImageObject(団体のロゴ)
- ImageObject(団体のバナー画像)
個人の場合は「サイトのロゴ」「サイトのバナー画像」と読み替えてください。
それぞれのIDを「#SiteLogo」「#SiteBanner」として設定した場合、関連付けは次のようになります。
{
"@type":"Organization",
//中略
"logo":{"@id":"#SiteLogo"},
"image":{"@id":"#SiteBanner"},
}
注意点として、Articleの「publisher」に指定するOrganizationのロゴ画像は60x600pxにする必要があるようです。
参考:記事 | Google 検索セントラル
これに対してサイトのロゴを指定する「Logo」は112x112px以上と指定があります。
参考:ロゴ | Google 検索セントラル
これをどう考えればいいのかがいまいちよく分かっていません。
画像を2つ用意すれば判別してくれるのかな?
WebPageへの関連づけ
WebPageへ関連づけは次の3点。
- BreadcrumbList(ページのパンくずリスト)
- ImageObject(ページのバナー画像)
- WebSite(母体となるサイト)
それぞれのIDを「#BreadcrumbList」「#Banner」「#WebSite」として設定した場合、関連付けは次のようになります。
{
"@type":"WebPage",
//中略
"breadcrumb":{"@id":"#BreadcrumbList"},
"primaryImageOfPage":{"@id":"#Banner"},
"isPartOf":{"@id":"#WebSite"}
}
WebSiteへの関連づけ
WebSiteへ関連づけは次の3点。
- ImageObject(サイトのバナー画像)
- Organization(公開している団体)
それぞれのIDを「#SiteBanner」「#Organization」として設定した場合、関連付けは次のようになります。
{
"@type":"WebSite",
//中略
"image":{"@id":"#SiteBanner"},
"publisher":{"@id":"#Organization"}
}
構造化データのチェック
マークアップが完了したら構造化データ テストツールで正しく書けているかチェックします。
HTMLとして公開していなくても<script>タグだけでもチェックかけられます。
まとめ
非常に複雑なYoast式の構造化データですが、要点だけ理解すれば意外と単純だなーと思ったんですが、いかがでしょう?
そもそもプラグインで自動でやってくれそう?なので、自前で実装する価値があるのかないのか分からないですが、知っていれば活かせるケースはありそうです。
誰かのお役にたてれば幸い。
以上、WordPressからお届けしました!