構造化マークアップとは？知るべき基本を解説
副業で内部SEO対策のご依頼をいただきました。その一部で、構造化データの設定を任されました。
ただ静的なデータを置くだけでなく、WordPressの動的データと連動させる必要がある案件でした。構造化マークアップは、こういう場面できちんと理解できているかどうかが如実に出る分野です。
基本的な考え方から、実案件で使うところまでをコード例つきでまとめます。
構造化マークアップとは？
構造化マークアップとは、Webページの内容を検索エンジンに「意味」として伝えるための仕組みです。
Googleの公式ドキュメントでは「構造化データ」と呼ばれています。構造化マークアップ・構造化データマークアップも、同じものを指す言い方です。
普段書いているHTMLは、人間がブラウザで読むためのものです。見出し・段落・リストなど、見た目の構造は伝わります。
でも「このページは会社概要です」「この部分はパンくずリストです」といった意味までは、検索エンジンに正確には伝わりません。
HTMLタグそのものの選び方はHTMLタグを意識してコーディングしよう！にまとめています。
構造化マークアップを使うと、ページの内容を機械が理解できるデータとしてHTMLに追加できます。Googleなどの検索エンジンが、ページの内容をより正確に把握してくれるようになります。
リッチリザルトとの関係
構造化マークアップを正しく実装すると、検索結果にリッチリザルト（通常よりも情報量の多い特別な表示）が出ることがあります。
たとえば次のような表示です。
- パンくずリスト：URLの代わりに「トップ ＞ サービス ＞ Web制作」のような階層表示になる
- FAQ（よくある質問）：質問と回答がアコーディオン形式で開く
- レビュー・評価：星マークと評価点
- レシピなら、調理時間やカロリーまで検索結果に出ます
リッチリザルトが表示されると検索結果の中で目立つので、クリック率（CTR）が上がりやすくなります。
この記事で使うのは JSON-LD という書き方です。
<script> タグの中にデータをまとめて書く形式で、HTMLの中身には手を入れません。
構造化マークアップはSEOに効くのか？
検索順位が直接上がるわけではない
Googleは構造化データを、ランキング要因として使わないと明言しています。ランキング要因とは、検索順位を決めるための材料のことです。
「構造化データを入れれば順位が上がる」という説明もよく見かけます。でも公式の見解は違います。
Google検索セントラルには、構造化データはページの内容理解を助けるものだと書かれています。順位そのものを押し上げる仕組みではありません。
変わるのは検索結果の見え方
差が出るのはクリック率のほうです。
同じ5位でも、見え方はかなり変わります。
質問と回答がアコーディオンで開く枠と、タイトルだけの枠。目に入る面積が全然違いますね。
パンくずリストを入れると、URLの文字列が階層表示に変わります。
「トップ ＞ サービス ＞ Web制作」のような形です。何のページなのか、開く前に伝わります。
同じ順位のまま、取れるクリックを増やす。これが構造化マークアップの立ち位置だと思います。
クライアントへの説明で気をつけること
「SEO対策になります」だけで伝えると、順位が上がる話として受け取られます。
「順位ではなく、検索結果での見え方が変わるもの」。この形で先に伝えておくと、認識のずれを防げると思います。
実案件で使うスキーマ
構造化マークアップで使う「どんな種類の情報か」を表す定義のことをスキーマと呼びます。Schema.org というサイトに何百種類も定義されていますが、すべてを覚える必要はありません。
実案件でよく使うものは限られています。実際に手を動かすのは、だいたいいつも同じ顔ぶれです。
1. Organization（会社・団体の情報）
コーポレートサイトで必ずと言っていいほど使います。会社名・ロゴ・URL・SNSアカウントなどを検索エンジンに伝えます。トップページの<head>内に設置するのが一般的です。
2. BreadcrumbList（パンくずリスト）
ページの階層構造を検索エンジンに伝えます。実装すると、検索結果のURLが「トップ ＞ カテゴリ ＞ ページ名」のような階層表示に変わります。実案件での使用頻度が最も高いスキーマです。
3. Article（記事）
ブログやニュースの記事ページで使います。タイトル・著者・公開日・アイキャッチ画像などの情報を伝えることで、Googleが記事として正しく認識してくれます。
4. FAQPage（よくある質問）
質問と回答のセットを伝えるスキーマです。正しく実装すると、検索結果に質問と回答がアコーディオン形式で表示されることがあります。リッチリザルトの効果が特にわかりやすいスキーマです。
実装してみよう（コード例）
ここからは、実際のコードです。JSON-LDは、あるタグの中に書きます。使うタグは<script type="application/ld+json">です。設置場所は<head>内でも<body>の末尾でも動作します。
JSON-LD・Microdata・RDFaの違い
構造化データの書き方は、JSON-LDだけではありません。
HTMLタグに itemprop 属性を1つずつ書き足していく Microdata という方式があります。
よく似た RDFa もあります。こちらは属性の名前が違うだけですね。
どちらもマークアップと中身が混ざるので、あとから直すのが面倒になります。
その点 JSON-LD は <script> タグの中にまとめて書きます。
HTMLの構造から独立しているので、データが1箇所にまとまります。
WordPressのように本文を動的に出力するサイトとも相性が良いです。
Googleも公式ドキュメントでJSON-LDをすすめています。今から新しく入れるなら、これだけ覚えれば足ります。
BreadcrumbList（パンくずリスト）の実装例
「トップ ＞ サービス ＞ Web制作」という3階層のパンくずリストを実装する例です。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "トップ",
"item": "https://example.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "サービス",
"item": "https://example.com/service/"
},
{
"@type": "ListItem",
"position": 3,
"name": "Web制作"
}
]
}
</script>この時点でコードの意味が分からなくても、そのまま先に進んで問題ありません。
上から順に、それぞれの行が何をしているかを見ていきます。
@contextと@typeは決まり文句です。Schema.org の定義を使うことと、データの種類を宣言していますitemListElement：パンくずの各階層を配列で並べますpositionは左から何番目かの数字name：表示するテキストですitemにはリンク先のURLを書きます。最後の階層＝現在のページには要りません
FAQPage（よくある質問）の実装例
よくある質問ページに2つのQ&Aを設定する例です。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "制作期間はどのくらいですか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "一般的なコーポレートサイトの場合、デザインからコーディングまで約1〜2ヶ月が目安です。ページ数や機能により変動します。"
}
},
{
"@type": "Question",
"name": "WordPressでの制作は可能ですか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "はい、対応しています。オリジナルテーマでの制作を行っており、更新しやすい管理画面をお作りします。"
}
}
]
}
</script>mainEntity の中に、質問（Question）を配列で並べていきます。
各質問は name（質問文）と acceptedAnswer（回答）がセットです。
質問の数に制限はありません。ただしページ上に表示しているQ&Aと一致させます。
ページにない質問を構造化データだけに書くと、リッチリザルトの対象から外れます。
Organization（会社情報）の実装例
コーポレートサイトのトップページに設置する例です。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "株式会社サンプル",
"url": "https://example.com",
"logo": "https://example.com/images/logo.png",
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+81-03-1234-5678",
"contactType": "customer service",
"availableLanguage": "Japanese"
},
"sameAs": [
"https://twitter.com/example",
"https://www.instagram.com/example/"
]
}
</script>sameAsには、公式のSNSアカウントのURLを配列で並べます。Googleがその企業の公式アカウントを認識する手がかりになります。
WordPressに入れるときは
プラグインが入れてくれる範囲
Yoast SEOやRank MathといったSEOプラグインを使っているサイトは多いと思います。
これらは初期設定のままでも、ArticleやBreadcrumbListを出力してくれることが多いです。
記事ページだけなら、プラグインを入れた時点で終わっている場合もあります。
今のサイトに何が入っているかは、あとで紹介するリッチリザルトテストで確認できます。
テンプレートに自分で書く場合
FAQPageやOrganizationは、プラグインだけでは足りないことが多いです。
その場合は functions.php から wp_head に流し込みます。
テーマを更新しても消えないように、子テーマ側に置いてください。
add_action( 'wp_head', function () {
if ( ! is_singular( 'post' ) ) {
return;
}
$schema = [
'@context' => 'https://schema.org',
'@type' => 'Article',
'headline' => get_the_title(),
'datePublished' => get_the_date( 'c' ),
'dateModified' => get_the_modified_date( 'c' ),
'author' => [
'@type' => 'Person',
'name' => get_the_author(),
],
'mainEntityOfPage' => get_permalink(),
];
echo '<script type="application/ld+json">'
. wp_json_encode( $schema, JSON_UNESCAPED_UNICODE )
. '</script>';
} );投稿のタイトルと日付を、そのまま構造化データに渡している形です。
ここでPHPの中身が分からなくても、そのまま先に進んで問題ありません。
本文に手を入れなくても、記事が増えるたびに自動で出力されます。
動作確認の方法
構造化マークアップを書いたら、動作確認は欠かせません。JSONの構文ミスやプロパティの書き間違いがあると、リッチリザルトが表示されません。
そのまま、クライアントのサイトが公開されてしまいます。僕はいつも決まったツールで確認しています。
1. リッチリザルトテスト（Google公式）
リンクはこちらから
Googleが提供している公式の検証ツールです。URLを入力するか、コードを直接貼り付けてテストできます。
- リッチリザルトとして認識されるかどうかが一目でわかる
- エラーや警告があれば具体的に表示される
- 本番公開前の最終チェックに最適
2. Schema Markup Validator
リンクはこちらから
Schema.org の仕様に沿っているかをチェックするツールです。Google特有のルールではなく、構造化データとしての正しさを検証してくれます。
JSON-LDの構文エラーや、必須プロパティの抜けをここで拾えます。
僕はリッチリザルトテストと併用しています。
確認時のチェックポイント
- エラーが0件であること。警告は許容範囲ですが、なるべく対処しましょう
- ページの内容と構造化データが一致していること（ページにない情報を書かない）
- URLが正しいこと。特にパンくずリストのリンク先
- 画像のURLが404になっていないか
実装したのにリッチリザルトが出ないとき
書き方が正しくても、検索結果にすぐ反映されるとは限りません。
- 公開したばかり。Googleが再クロールするまで、数日から数週間かかります
- ページに表示していない内容を書いている — FAQPageで本文にない質問を足すと無効です
- 警告が残っている。必須プロパティが揃っていても、推奨プロパティの抜けで出ないことがあります
FAQPageには、もうひとつ大きな前提があります。
2023年8月にGoogleが方針を変えました。
FAQのリッチリザルトは、政府機関や医療系など一部のサイトにしか表示されません。
一般の企業サイトでは、正しく書いても検索結果には出ません。それでもページの内容を伝える意味はあるので、無駄になるわけではないです。
最終的に表示するかどうかを決めるのはGoogleです。仕様を満たしていても、必ず出るとは限りません。
認識されているかどうかは、Search Consoleの「拡張」レポートで確認できます。
リッチリザルトテストが通っていても、こちらに出てこないことがあります。
そのときはクロール待ちだと考えて問題ありません。
おわりに
構造化マークアップは、ページの中身を検索エンジンに「意味」として渡すための仕組みでした。
正しく実装しても、リッチリザルトが必ず表示されるわけではありません。最終的な表示はGoogle側の判断に委ねられます。
ほぼすべてのサイトに設置でき、コード量も少ないBreadcrumbListから、ぜひ試してみてください！
内部SEOまわりの相談はお問い合わせから受け付けています。