スキーママークアップを実装したら、正しく設定されているかどうかを検証ツールで確認することが非常に重要です。
Googleのリッチリザルトテストやスキーマ・マークアップバリデーターなどのツールを使うことで、JSON-LDやMicrodataの記述エラーを発見し、検索エンジンによる正確なデータ読み取りを確認できます。
せっかく実装したスキーママークアップも、エラーがあればリッチリザルト（強調スニペットや星評価など）が表示されない原因になるかもしれません。
本記事では、スキーママークアップの検証ツールの種類・使い方・エラーへの対処法をわかりやすく解説していきます。
スキーママークアップの検証ツールとは？種類と概要
それではまず、スキーママークアップの検証ツールの種類と概要について解説していきます。
スキーママークアップの検証ツールとは、Webページに実装された構造化データ（スキーママークアップ）が正しく記述されているかどうかを確認するためのツールです。
主に以下の二つのツールが広く使われています。
Googleリッチリザルトテスト
Googleリッチリザルトテストは、Googleが提供する公式の検証ツールで、ページのスキーママークアップがGoogleのリッチリザルト表示の条件を満たしているかを確認できます。
URLを入力するか、HTMLコードを直接貼り付けることで、Googleがそのページからどのような構造化データを読み取るかをシミュレートします。
ツールの特徴として、「このページはリッチリザルトの対象です」という合否判定が表示される点が挙げられます。
SEOにおいてリッチリザルトの表示を狙う場合は、このツールでの確認が最重要です。
スキーマ・マークアップバリデーター（Schema Markup Validator）
スキーマ・マークアップバリデーターはSchema.orgが提供する検証ツールで、スキーマの構文的な正確さを検証します。
Googleリッチリザルトテストと同様にURLまたはHTMLコードを入力して使用しますが、こちらはGoogleのリッチリザルト要件ではなく、Schema.orgの仕様に基づいた検証を行います。
Googleリッチリザルトテストと組み合わせて使用することで、より網羅的な検証が可能になります。
Google Search ConsoleのリッチリザルトレポートとAMP
Google Search Consoleでは、サイト全体の構造化データのエラーや警告をまとめて確認できる「拡張機能」レポートが提供されています。
このレポートでは、ページ単位ではなくサイト全体のスキーママークアップの健全性を把握できるため、定期的なモニタリングに活用するとよいでしょう。
| ツール名 | 提供元 | 主な用途 | 特徴 |
|---|---|---|---|
| リッチリザルトテスト | リッチリザルト対応確認 | 合否判定あり・SEOに直結 | |
| スキーマ・マークアップバリデーター | Schema.org | スキーマ構文の検証 | Schema.orgの仕様に基づく |
| Google Search Console | サイト全体の監視 | 継続的なモニタリングに最適 |
Googleリッチリザルトテストの使い方
続いては、Googleリッチリザルトテストの具体的な使い方を確認していきます。
手順に沿って説明しますので、ぜひ実際に操作しながら確認してみてください。
URLを使った検証手順
最もシンプルな使い方は、検証したいWebページのURLを入力する方法です。
手順1：Googleリッチリザルトテスト（https://search.google.com/test/rich-results）にアクセスする
手順2：「URL」タブを選択し、検証したいページのURLを入力する
手順3：「URLをテスト」ボタンをクリックする
手順4：Googleボットがページをクロールし、構造化データを解析した結果が表示される
手順5：「リッチリザルトの対象」か「リッチリザルトの対象外」かの判定と、検出された構造化データの一覧・エラー・警告を確認する
URLを使った検証では、実際にGoogleボットがページにアクセスするため、本番環境のページをそのまま検証できます。
コードを使った検証手順
公開前のページや、HTMLを直接確認したい場合はコードを貼り付けて検証する方法が便利です。
「コード」タブを選択し、HTMLソースコードを貼り付けて「コードをテスト」をクリックするだけで検証できます。
JSON-LDのスニペットだけを貼り付けて確認することも可能なため、実装前の事前確認にも活用できます。
検証結果の見方とエラーへの対処法
検証結果には「エラー」と「警告」の二種類が表示されることがあります。
エラーは構造化データが正しく認識されない原因となる致命的な問題で、必ず修正が必要です。
警告は必須ではないが推奨されるフィールドの欠如などを示すもので、修正することでリッチリザルトの表示可能性が高まります。
よくあるエラーの例と対処法
エラー1：「必須フィールドがありません（name）」→ 対処法：@typeに対応した必須プロパティを追加する
エラー2：「無効な値の型」→ 対処法：プロパティに設定する値のデータ型（文字列・URL・数値など）を修正する
エラー3：「@contextが不正」→ 対処法：@contextの値が「https://schema.org」になっているか確認する
警告1：「推奨フィールドがありません（image）」→ リッチリザルトの表示品質向上のため追加を検討する
JSON-LDのスキーママークアップを正しく記述するためのポイント
続いては、JSON-LDを使ったスキーママークアップを正しく記述するためのポイントを確認していきます。
スキーママークアップの記述形式としてGoogleが推奨しているのがJSON-LDです。
JSON-LDはHTMLに埋め込む形で記述でき、既存のコードに影響を与えずに構造化データを追加できるという点で特に扱いやすいフォーマットです。
JSON-LDの基本構造
JSON-LDは「script」タグ内にJSON形式で記述します。
記事（Article）のJSON-LD記述例
<script type=”application/ld+json”>
{
“@context”: “https://schema.org”,
“@type”: “Article”,
“headline”: “スキーママークアップの検証ツールの使い方”,
“author”: {
“@type”: “Person”,
“name”: “山田太郎”
},
“datePublished”: “2024-01-01”,
“image”: “https://example.com/image.jpg”
}
</script>
@contextにはSchema.orgのURLを指定し、@typeにはマークアップするコンテンツの種類（Article・FAQPage・Product・BreadcrumbListなど）を記述します。
各@typeに対して必須・推奨のプロパティが決まっているため、Schema.orgのドキュメントを参照しながら記述することが大切です。
検証を習慣化することの重要性
スキーママークアップは一度実装して終わりではありません。
WordPressのプラグイン更新・テーマの変更・コンテンツの修正などによって、意図せずマークアップが壊れてしまうことがあります。
定期的にGoogle Search Consoleのレポートを確認し、エラーや警告が発生していないかをモニタリングする習慣をつけることが、SEO効果を継続的に維持する上で重要です。
まとめ
本記事では、スキーママークアップの検証ツールの種類・使い方・エラーへの対処法・JSON-LDの正しい記述ポイントについて解説してきました。
Googleリッチリザルトテストとスキーママークアップバリデーターを活用することで、スキーママークアップが正しく実装されているかを効率的に確認することができます。
検証ツールを活用し、エラーや警告をしっかりと修正することで、検索エンジンからの正確なデータ読み取りとリッチリザルトの表示につながっていくでしょう。
実装後の定期的な確認と改善を継続することが、SEOの長期的な成果につながります。
