構造化マークアップについて個人的まとめ（82slides）

1
構造化データ（マークアップ）について個人的まとめ
2019年1月11日 Capybara Design 竹内直人

2https://coding-salon.pro/articles/
構造化
マークアップ
とは？

言葉に対して意味をメタデータとして持たせること
つまり
コンピューターがそのもつ内容の解釈が容易になる
つまり
検索エンジンはより有用な検索結果をユーザーに提供できるようになる

HTMLにおけるマークアップとの違いは？
HTMLのマークアップはあくまでも文書構造における意味付けである
つまり
「竹内直人」が人名なのか地名なのかは意味付けできない
つまり
検索エンジンは言葉自体の意味を解釈できず、再利用が難儀

構造化マークアップはそういった問題を解決する手段の一つ

構造化データは、
「『これ』は『あれ』である」というのを
コンピューターに知らせる役目。

「『わがはい』は『猫』」であるという感じ。
「『名前』は『まだない』」
「『この店の名前』は『注文の多いレストラン』」
みたいな感じ。
※ちょっと違うけど…雰囲気ね。。

もう少し具体的にすると
『レシピ』の『材料』『画像』『調理時間』
『イベント』の『会場』『開催時間』『出演者』
といった情報を明示的にマークアップが可能です

これらの、主語（定義語）や目的語（内容）に入り得る言葉を定義しているのが、
schema.org
Google、Yahoo！、Bingのコラボレーションで
正式な標準化団体ではないとのこと
（W3Cかなと思ったら違った）
※スキーマ・オルグ

同様のものとしては
data-vocabulary.org
があるが、
こちらは開発が終了している。
（schema.orgの方が後発。Googleもschema.orgを推奨）

どうやって
使うの？

結論から言えば
JSON-LD（JavaScript Object Notation Linked Data）
の書式に則ってHTML内に記述すればいい
（※JSON-LDがW3C勧告になったのは2014年の1月。だいぶ昔）

JSON-LDの他には
RDFa や microdata といったものがある
こちらの方が聞き覚えがある人の方が多そう
でも
RDFa や microdata はオワコン
※なんて言ったら怒られますね。これを読んでいる段階の人はとりあえず JSON-LD で間違いないと思います

僕はその昔、microdata を少し眺めて
「えっ？これを全部判断してマークアップするの？」
って思っていました。
SEOにも強く関与する訳じゃないのに、
費用対効果が悪過ぎますし、
そもそもクライアントを説得する材料が少な過ぎました

これを読んでくれいている方は
同じ感想を抱いて今日まで放っておいた方が多いのではないかと
勝手に思っています

結論から言いますと
その当時から基本的なことは変わっていませんが、
JSON-LD の書式を用いると少し楽になっている気がします

JSON-LD と microdata は同居できるので
・itemscope
・itemtype
・itemprop
という microdata で見たことある書式を
引き続き使うこともできます

ではどうして JSON-LD を使うのがよいのか？
それは
・HTML（マークアップ）に直接編集を加えなくてよいので構造が崩れない
・Googleが推奨している ※以前はmicrodataを推奨していました
の2点が大きな要因と言えると思います

何に
使われるの？

様々な用途で使われることが見込まれますが、
現状で一番の利用場所は
検索結果画面（リッチリザルト）での利用でしょう

詳しくは
https://developers.google.com/search/docs/guides/search-gallery
こちらをご覧ください

こういった箇所のデータとして用いられることがあり
サイトへの流入数UPなどに寄与します

構造化データ（マークアップ）はランキングには無関係と
みなさん大好き John Mueller（ジョン・ミューラー）氏は
言っているそうですが、
「記事の公開日」や「編集日」、文章の正確な意味などを
ロボットに読み取らせることは
それなりの意味を持つはずだと僕は思います。
※「構造化マークアップスパム」の検出はしているようなので逆に言えばランキングに利用することも…

これらの状況を加味して
それでも「やる」か「やらない」かは状況次第かと思います
※個人的にはアクセシビリティの向上（バリアフリー化/ユニバーサル化）に力を入れるべきだとは思いますが

具体的な
書き方

ざっくりと例示するとこんな感じです
<!doctype html>
<html lang="ja">
<head><meta charset="UTF-8"><title>コーディングサロンパソコンの商品詳細</title></head>
<body>
<header>【略】</header>
<main>【略】</main>
<footer>【略】</footer>
<script type="application/ld+json">
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "コーディングサロンパソコン",
"image": [
"https://coding-salon.pro/photos/1x1.jpg",
"https://coding-salon.pro/photos/16x9.jpg"
],
"description": "コーディングサロンパソコンは、コーディングが便利になるツールがプリインストールされたPCです",
"releaseDate":" 2019-01-01T00:00:00+09:00 "
}
</script>
</body>
</html>

JSON-LD はページのどこにでも配置することが可能です。
ブラウザに描画されるものではないので
HTML/CSSの描画を邪魔することはありませんが
わずかなテキストデータの読み込みの順序を考えると
</body>
の直前に記載するのが望ましいでしょう

JSON-LDフォーマットの宣言として
<script type="application/ld+json"></script>
でマークアップします

scriptタグであることに違和感がありますが
特に何かscriptが実行される訳ではありません

なぜscriptタグなのか、このtype属性値は何なのか、
こういった疑問はもっともですが、
既に皆さん慣れていらっしゃると思いますが、
「そういうもの」
でございます。
※本筋から外れてしまうので説明を割愛する方が望ましいという感じです

続いてscriptタグの中では
・ { で始まり } で閉じます。
・Key（キー）とValue（バリュー）のペアで構成されます。
・キーとバリューは「:」（コロン）で区切ります。
・「"」（ダブルクォーテーション）で共に囲みます。
・続けて書く場合は「,」（カンマ）で区切ります。

もう一度、 JSON-LD の箇所だけに注目してみます
{
"@context": "https://schema.org/",
"@type": "Product",
"image": [
],
"description": "コーディングサロンパソコンは、コーディングが便利になるツール
がプリインストールされたPCです",
"releaseDate":" 2019-01-01T00:00:00+09:00 "
}
</script>

@context のバリューは
"https://schema.org"
で固定です
これは
「https://schema.org の定義に従って記述しますよ」という
宣言のようなものです。
※DTD宣言に似ていますね。http か https かはどちらでもいいようですが、将来的にはhttpsになりそうとのこと

@type のバリューは
schema.orgで定義されているモノ（アイテム）が入ります
「イベント」とか「商品」とか「レシピ」とか

ここには何でも入れられる訳ではなく
schema.orgで定義されているモノ（アイテム）が入ります
一覧は
https://schema.org/docs/full.html
ここにあります

「ここにあります」って言われても・・・

全部で 1620個！？？
https://schema.org/version/3.4/schema.jsonld

とても覚えられない・・・

ん？
https://schema.org/docs/schemas.html
「you can jump directly to a commonly used type」
（訳：よく使われるタイプに直接ジャンプすることができます）

キタコレ！

Creative works: CreativeWork, Book, Movie, MusicRecording, Recipe, TVSeries ...
Embedded non-text objects: AudioObject, ImageObject, VideoObject
Event
Health and medical types: notes on the health and medical types under MedicalEntity.
Organization
Person
Place, LocalBusiness, Restaurant ...
Product, Offer, AggregateOffer
Review, AggregateRating
Action

Google翻訳！
（あっ、そもそも日本語訳は http://schema-ja.appspot.com/ こちらにあります）

クリエイティブ作品：CreativeWork、本、映画、ミュージックレコーディング、レシピ、TVシリーズ...
埋め込まれた非テキストオブジェクト：AudioObject、ImageObject、VideoObject
イベント
健康と医療の種類：MedicalEntityの健康と医療の種類に関するメモ。
組織
人
場所、ローカルビジネス、レストラン...
製品、オファー、アグリゲートバッファ
レビュー、AggregateRating
アクション

う～ん。。なんか違う。
「普通のサイト」で使いそうな
「WebPage」とか「breadcrumb」とか「JobPosting」とか
ないじゃん…

きっとどこかの誰かがまとめてくれているはず！
（探し中です。なければ自分で頑張ります）
※だ・・・誰か。

まぁ、ともあれ
じゃあ何を基準に「よく使われるのか？」というのは
ケースによって違うと思うので
逆に考えてみました

「どの構造化データが検索結果画面で利用されているのか？」
から逆算してみると
Googleのページにしっかりと載っていました

一般的に使われそう（＝Googleが利用している）なものはここに載っています
https://developers.google.com/search/docs/data-types/article
https://developers.google.com/search/docs/guides/mark-up-content
こちらには、実際の使われ方（リッチリザルト）の一覧が載っています
https://developers.google.com/search/docs/guides/search-gallery

まずはこれらを参考に
自サイト・メディアのテコ入れが可能な個所から
実装していくというのが現実的かもしれません

こうして
@type のバリューが決まったら
それに応じて指定できるプロパティも決まっています

例えば「Product」であれば
https://schema.org/Product
を見ましょう

このように、「https://schema.org/」の後ろに
@type のバリューをつけて
https://schema.org/@type のバリュー
にアクセスすると
その仕様（指定できるプロパティ）が確認できます

https://schema.org/JobPosting
https://schema.org/breadcrumb
https://schema.org/WebPage
https://schema.org/Person
こんな感じです

プロパティの値の書き方は種類が多いので割愛しますが
Textだったり、Date だったり、URLだったり色々です

この Text には HTML も含められるのかについては
明確な記述が見つけられませんでしたが
https://developers.google.com/search/docs/data-types/job-posting#JobPosting-definition
こちらのGoogleのドキュメントでは
JobPosting の description の値は Text の指定となっていますが
HTML形式での指定が求められていました

また、プロパティの値には入れ子で構造化データを
指定することもできます

ざっくりと書くとこんな感じで「 Review 」が入れ子になります
{
"@context": "http://schema.org/",
"@type": "Product",
"description": "コーディングサロンパソコンは、コーディングが便利になるツールがプリインストー
ルされたPCです",
"review": {
"@type": "Review",
"author": "竹内直人",
"name": "コーディング初心者の自分にはベストマッチでした！",
"description": "コーディングを習い始めてもう少しスペックの高い・・・",
}
}
</script>

説明し忘れましたが
値には配列を用いることもできます

前の例では「image」の値が配列になっています
{
"@context": "http://schema.org/",
"@type": "Product",
"image": [
],
"description": "コーディングサロンパソコンは、コーディングが便利になるツール
がプリインストールされたPCです",
"releaseDate":" 2019-01-01T00:00:00+09:00 "
}
</script>

このように一つのkeyが複数の値をとる場合は配列を用いるので
逆に言えば同じkeyが複数回登場することはありません

実際にどの
ページに設置
したらいい？

基本的にはデータの詳細が掲載されているページに追加します
「会社概要」「商品詳細」「スタッフ紹介」「レシピ詳細」
などなどのページに追加します

サイトによってはフッターなどの共通部分に
著者情報や会社情報などが載っていることがあると思いますが
全ページでこれを構造化マークアップするのは望ましくありません

それぞれについて詳細が記載されたページに
構造化マークアップを施すようにしましょう

ただ、その詳細ページがない場合は
TOPページにのみ記載するのがベターみたいです

その他細かいガイドライン（これはGoogle製ですが）は
https://developers.google.com/search/docs/guides/sd-policies#header_7
こちらに載っています
抜粋すると・・・

・構造化データは、内容を記述するページに実装する。
・構造化データを概要ページに実装し、ページを他の詳細ページにリンクするこは可能
・その場合、詳細ページが他サイトでも構わないが、「カルーセルの概要ページ」の場合だけは、
自分のサイトの詳細ページにリンクする必要がある。
・同じコンテンツの重複するページがある場合は、正規ページだけでなく、
重複するすべてのページに同じ構造化データを実装することをおすすめします。
・複数の構造化データオブジェクトを 1 ページに含めることができます。
・ただし、リスト内の 1 つのアイテムをマークアップする場合、
すべてのアイテムをマークアップする必要があります。
・ページでリストされているすべてのカテゴリエンティティの中から 1 つだけをマークアップすることは
ガイドライン違反

・（簡易的な）一覧ページは構造化マークアップしない
・一覧を構造化マークアップする場合はリスト全部をしないと駄目
・基本的には「詳細ページ」の内容を構造化マークアップする
・「詳細ページ」ということは、そのアイテムのことが主に書かれているはずだが、
複数の構造化データオブジェクトを1 ページに含めることは可能
・全ページ共通のデータがある場合は、より詳細が記載されたページか、
なければTOPページに実装する
・パンくずなど、ページによって違うものはページ毎に実装する
なんとなくのイメージで覚えるのであれば

その他、Googleでは一般的なエラー（ミスですね）について
https://developers.google.com/search/docs/guides/prototype#common-sd-errors
こちらにまとめてられています

どのページにどのように設置するのが
正しいのかまでは判定してくれませんが
構造化データテストツール
（https://search.google.com/structured-data/testing-tool/u/0/）
を用いてマークアップが正しいかは検証可能です
他にもツールはたくさんあるみたいです
http://www.seoskeptic.com/structured-data-markup-validation-testing-tools/

最後に

ここまで読んで気が付かれ方は多いと思いますが
画面に表示されないデータをマークアップできるということは
スパムの温床にもなります

Googleでは品質に関するガイドラインを公開していて
https://developers.google.com/search/docs/guides/sd-policies#header_3
これを厳守しなければ手動による対策（ペナルティ）を
受ける可能性もあるので気をつけましょう
※と言うか…スパムはやめましょうｗ

また、これまでの説明を覆すようですが、
https://developers.google.com/search/docs/guides/intro-structured-data?hl=ja#header
このページには以下のように記載されており
「Google検索で用いる構造化データの仕様」＝「schema.orgの仕様」
ではないということにも注意が必要なようです
検索のための構造化データでは主に schema.org ボキャブラリが使用されていますが、
Google 検索の動作の定義としては、schema.org のドキュメントではなく developers.google.com のドキュメントを
信頼できる第一の選択肢としてください。
ここに記載されていない属性やオブジェクトは、schema.org で必須と示されていても、Google 検索では必須ではありません。

謝辞など

最後までお読み（スライド）いただきまして
誠にありがとうございます

当スライドはその題名の通り
僕が個人的に調べたことをまとめたものです

大きな間違いがないように気を付けてはいますが
必ず複数のソースをご確認頂ければと存じます

スライド内にも登場するものもありますが参考リンクです
【仕様】
http://schema.org/
【日本語訳】
http://schema-ja.appspot.com/
【基本知識】
https://www.suzukikenichi.com/blog/definitive-guide-of-schema-org-using-jsonld/
【Google関係】
https://developers.google.com/search/docs/data-types/article （Googleで使われているもの一覧）
https://developers.google.com/search/docs/guides/mark-up-content （リッチリザルトの関連タイプ）
https://developers.google.com/search/docs/guides/sd-policies （ガイドライン）
https://developers.google.com/search/docs/guides/search-gallery （リッチリザルト例）
【フォロー】
https://webtan.impress.co.jp/e/2017/12/04/27555 （全編・中編・後編の3記事あります）

このスライドが少しでもマークアップエンジニアの
構造化マークアップに対する理解を深めることに寄与し、
少しでも構造化マークアップが広まり
やがては検索結果として世の中（ユーザー）に還元されることを
期待しています

拙い資料で恐縮ですが
もしも少しでもお役に立てた部分がありましたら
SNS などでいいね/Like やシェア
をしていただけましたら幸いです

82
Thank you for watching!
This slide was written by Naoto Takeuchi belonging to CapybaraDesign on 2019-01-11T17:00:00+09:00
HOME：https://capybara-design.com/
BLOG：https://coding-salon.pro/articles/

構造化マークアップについて個人的まとめ（82slides）

Recommended

Recommended

More Related Content

Similar to 構造化マークアップについて個人的まとめ（82slides）

Similar to 構造化マークアップについて個人的まとめ（82slides） (20)

Recently uploaded

Recently uploaded (10)

構造化マークアップについて個人的まとめ（82slides）