検索エンジンは文章を読むのが得意ですが、それでも物事が何なのかを推測しなければなりません。「Apple」は果物でしょうか、それとも会社でしょうか。「4,980円」は価格でしょうか、そうだとしたら何の価格でしょうか。その日付はイベントの開始日でしょうか、それとも記事の公開日でしょうか。
構造化データは、その推測をなくします。共通の語彙である schema.org を使ってページのコンテンツにラベルを付けるコードで、検索エンジンや AI システムが内容を正確に理解できるようにします。
構造化データがもたらすもの
- リッチリザルトの対象になる – 商品の価格や評価、パンくずリスト、イベントの日付、レシピの詳細、動画のサムネイルなど、強化された表示
- よりよい理解 – 検索エンジンが組織、商品、著者、コンテンツをエンティティとして結び付ける助けになる
- AI システムへのより明確なシグナル – ページを読んで回答を組み立てるシステムに伝わりやすくなる
構造化データは直接のランキング要素ではありません。しかし、リッチリザルトは検索結果ページで目立ち、多くのクリックを集めることが多く、明確なエンティティ情報は機械がビジネスを正確に表現する助けになります。
JSON-LD:推奨される形式
形式には JSON-LD、Microdata、RDFa の3つがあります。Google が推奨するのは JSON-LD で、HTML と絡み合うことなくページ内に置けるスクリプトのブロックです。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Acme Coffee Roasters",
"url": "https://acmecoffee.example",
"logo": "https://acmecoffee.example/logo.png",
"sameAs": [
"https://www.instagram.com/acmecoffee",
"https://www.linkedin.com/company/acmecoffee"
]
}
</script>
@contextは使う語彙を示します(schema.org)@typeはそれが何であるかを示します- ほかのプロパティがそれを説明します
記事、FAQ、商品、ビジネス、イベントなどの JSON-LD 構造化データを作成します。
ほとんどのサイトに必要な schema のタイプ
Organization(または LocalBusiness) – トップページに
あなたが誰かを説明します。名前、URL、ロゴ、SNS のプロフィール、連絡先です。地域のビジネスは LocalBusiness(または Restaurant や Dentist など、より具体的なサブタイプ)を使い、住所、電話番号、営業時間を記載しましょう。
WebSite – トップページに
サイト名を宣言します。Google は検索結果に表示するサイト名としてこれを使うことがあります。
BreadcrumbList – ほとんどのページに
サイトの階層におけるページの位置を説明します。Google は検索結果で、URLそのものの代わりにパンくずリストを表示することがよくあります。
{
"@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/guides/" },
{ "@type": "ListItem", "position": 3, "name": "家庭でのコンポスト" }
]
}
Article / BlogPosting – 記事に
見出し、著者、公開日と更新日、画像です。著者と日付の情報は信頼性のシグナルにもなります。
Product – 商品ページに
名前、画像、説明、ブランド、そして価格、通貨、在庫状況を含む Offer です。本物のレビュー評価を追加すると、商品がレビューの星の表示対象になることがあります。販売者向けリスティングの機能では、配送や返品ポリシーの情報も使われます。
そのほかの便利なタイプ
- Event – 名前、日程、場所、チケット
- Recipe – 材料、調理時間、評価
- VideoObject – タイトル、サムネイル、アップロード日、長さ
- JobPosting – Google のしごと検索に表示される求人
- FAQPage – 質問と回答
FAQ と HowTo についての注意:2023年以降、Google は FAQ のリッチリザルトを主によく知られた権威ある政府系・医療系サイトにのみ表示し、HowTo のリッチリザルトの表示は終了しました。マークアップ自体は有効で、機械が Q&A コンテンツを理解する助けにはなりますが、ほとんどのサイトはこれらのリッチリザルトを期待すべきではありません。
守るべきルール
- ページ上に表示されているものだけをマークアップする。 ユーザーに見えないコンテンツを記述するのは Google のガイドライン違反です。
- 正確にする。 価格、在庫状況、評価はページと一致していなければなりません。
- 偽のレビューは禁止。 自社サイトで自社についてのレビューをマークアップする自己言及的なレビューは、Google のレビューの星の対象になりません。
- 当てはまる最も具体的なタイプを使う(単なる LocalBusiness ではなく Restaurant)。
- 狙うリッチリザルトの必須プロパティと推奨プロパティを含める。
これらのルールを破ると、サイトからリッチリザルトが削除される手動による対策を受けることがあります。
構造化データの追加方法
- WordPress:SEO プラグイン(Yoast、Rank Math、All in One SEO)が Organization、WebSite、Article、Breadcrumb のマークアップを自動で追加し、WooCommerce が Product のマークアップを追加します
- Shopify:ほとんどのテーマに Product のマークアップが含まれ、アプリで拡張できます
- 独自開発のサイト:ページを構成するのと同じデータから JSON-LD を生成し、ページのテンプレートに追加します
- Google タグマネージャーでも JSON-LD を挿入できますが、サーバー側で出力したマークアップのほうが信頼性は高いです
マークアップのテスト方法
- 構文を検証する – カンマが1つ抜けるだけでブロック全体が無効になります
- 推奨プロパティの欠落を確認する
- Google のリッチリザルト テストを使い、特定のリッチリザルトの対象になるかを確認する
- Search Console の拡張レポートを監視し、サイト全体のエラーを把握する
ページの JSON-LD と microdata のスキーマを抽出してチェックします。コードを貼り付けてテストすることもできます。
@graph で複数のタイプを組み合わせる
ページには複数のタイプが必要になることがよくあります。複数のスクリプトブロックを使うことも、1つの @graph にまとめて @id の参照でつなぐこともできます。たとえば、同じページで定義した Organization を publisher とする Article です。どちらの方法も有効です。
地域ビジネスの完全な例
架空のカフェのトップページで、複数のタイプを1つの @graph にまとめたマークアップです。
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "CafeOrCoffeeShop",
"@id": "https://mameha.example/#business",
"name": "カフェ 豆と葉",
"url": "https://mameha.example/",
"image": "https://mameha.example/images/storefront.jpg",
"telephone": "+81 3-1234-5678",
"priceRange": "¥¥",
"address": {
"@type": "PostalAddress",
"streetAddress": "神宮前1-2-3",
"addressLocality": "渋谷区",
"addressRegion": "東京都",
"postalCode": "150-0001",
"addressCountry": "JP"
},
"openingHours": ["Mo-Fr 07:30-17:00", "Sa 09:00-16:00"],
"sameAs": ["https://www.instagram.com/mameha"]
},
{
"@type": "WebSite",
"@id": "https://mameha.example/#website",
"name": "カフェ 豆と葉",
"url": "https://mameha.example/",
"publisher": { "@id": "https://mameha.example/#business" }
}
]
}
@id の値を使うことで、WebSite は詳細を繰り返さずにビジネスを参照できます。マークアップ内の住所、電話番号、営業時間などの情報はすべて、訪問者がページ上や Google ビジネス プロフィールで目にする内容と一致していなければなりません。
商品の構造化データを詳しく
商品ページは、構造化データが最も目に見える成果を出しやすい場所です。しっかりした Product のブロックには次の内容が含まれます。
name、image(可能なら複数)、descriptionbrand、sku、可能であればgtinなどのグローバルな識別子price、priceCurrency、availability、商品のurlを含むoffersaggregateRatingとreview– ページに表示されている、顧客からの本物のレビューに限る- 配送の詳細と返品ポリシーの情報(Google の販売者向けリスティングの機能に使われます)
価格は常に同期させましょう。マークアップでは4,980円、ページでは5,980円となっていると、Google がマークアップを無視したり、Search Console で警告したりすることがあります。
構造化データと AI システム
検索エンジンや AI システムは、人、組織、商品、場所といったエンティティと、それらの関係で物事を考えるようになっています。構造化データは、誰がこの記事を公開したか、どの組織がこの商品を販売しているか、このビジネスがどこにあるか、といった事実を伝える最も明確な方法の一つです。サイト、構造化データ、SNS のプロフィール、ビジネス情報の掲載先でエンティティ情報を一貫させておけば、どんな機械でもあなたのビジネスを正しく説明しやすくなります。
構造化データを維持し続ける
マークアップは、テンプレートが変わると気づかないうちに壊れます。いくつかの習慣を身につけましょう。
- ページを表示するのと同じデータから JSON-LD を生成し、両者がずれないようにする
- テンプレートやテーマを更新したら、そのたびにマークアップを検証する
- Search Console の拡張レポートを毎月確認し、新しいエラーや警告がないか見る
- 年に1回、schema.org と Google のドキュメントを見直し、新しいプロパティや廃止された機能を確認する
重要なポイント
- 構造化データは schema.org の語彙でコンテンツにラベルを付け、機械が正確に理解できるようにします。
- Google が推奨する形式である JSON-LD を使いましょう。
- ほとんどのサイトには、Organization または LocalBusiness、WebSite、BreadcrumbList、Article または Product のマークアップが必要です。
- ページ上に表示されている情報だけをマークアップし、正確に保ちましょう。
- 有効なマークアップはページをリッチリザルトの対象にしますが、表示を保証するものではありません。
- テンプレートの変更後はマークアップを検証し、Search Console の拡張レポートを確認しましょう。
よくある質問
Schema マークアップで順位は上がりますか?
直接は上がりません。検索エンジンがコンテンツを理解する助けになり、リッチリザルトを獲得できれば、クリック率が上がることがよくあります。
マークアップは有効なのに、なぜリッチリザルトが表示されないのですか?
有効なマークアップはページを対象にするだけで、リッチリザルトの表示を保証するものではありません。Google はコンテンツの質、ポリシーの遵守、リッチリザルトがクエリに適しているかも考慮します。
1つのページで複数の schema タイプを使えますか?
使えます。商品ページなら、Product、BreadcrumbList、Organization を一緒に使えます。
Microdata と JSON-LD のどちらを使うべきですか?
JSON-LD です。Google が推奨する形式で、最も管理しやすい方法です。
自分のサイトをチェック
55 以上の項目を無料で診断し、すべての問題の改善方法を確認しましょう。