構造化データの監査と直し方｜有効でも本文と違えば直す

制作会社やプラグインやAIに入れてもらった構造化データ（JSON-LDなど、ページの内容を検索エンジンが読める形式で書き添えたもの）は、リッチリザルト テストで「有効」と出た時点で確認が止まりがちです。有効と出たあとにその中身が本文と合っているかを確かめる手順は入れた側からはたいてい渡されず、当社も2026年9月24日にSearch Consoleの求人情報レポートが有効0件になっているのを見つけるまで採用ページの置き場所の誤りに気づきませんでした。以下は当社が自社サイト74ページで行った監査の手順と結果で、末尾に読者が自社サイトで同じ確認をするための道具4つと問い3つを置きました。

Googleのルールは、Google 検索セントラルとSearch Console ヘルプの日本語版と英語版を2026年9月27日に読み合わせた範囲だけを書きます。監査の結果はすべて当社1サイトの観測で、業界の一般値でも他社に当てはまる値でもありません。構造化データの修正が検索順位に与える影響はこの記事では扱わず、順位が動いたという主張もしません。ドキュメントは予告なく更新されるため、引用したページの最終更新日を本文に添えました。

「有効」と出た構造化データでも、本文に見えない内容を書いていればガイドラインに合わない

リッチリザルト テストが「有効」と返すのは、構文が読めて必須プロパティが揃っているという意味です。Googleはこのツールを、ページ上の構造化データからどのGoogleリッチリザルトを生成できるかをテストする公式ツールと位置づけています（英語版の説明を当社が訳したもの。Google 検索セントラル「Schema Markup Testing Tool」／2026年9月27日閲覧）。ツールが見ているのは構造化データの側で、その内容がページの本文と合っているかは見ていません。

Googleの構造化データ ガイドラインには「ページの読者に表示されないコンテンツをマークアップしないでください」とあります。同じページに「構造化データはページ コンテンツを正確に表している必要があります」ともあります。さらに「関連性がないコンテンツや誤解を招くコンテンツ（虚偽のレビュー、ページの内容と関係のないコンテンツなど）をマークアップしないでください」と続きます（Google 検索セントラル「構造化データに関する一般的なガイドライン」／日本語版最終更新2026年9月16日／2026年9月27日閲覧）。JSON-LDに書いた電話番号や著者名や日付は、そのページの本文に同じものが見えている必要があるというのが当社の読み方です。

守らなかった場合の扱いも同じページにあります。「構造化データに関する手動による対策が実施されると、ページがリッチリザルトとして表示されなくなります。ただし、Google ウェブ検索でのページの掲載順位には影響しません」。逆に守っても「構造化データが検索結果に表示されるとは限りません」と明記されています。「構造化データを使用して、ある機能が表示されるよう設定することはできますが、その機能が必ず表示されるとは限りません」（Google 検索セントラル「構造化データに関する一般的なガイドライン」／2026年9月27日閲覧）。構造化データは表示の条件を満たすための作業で、表示や順位を約束する作業ではありません。

プロパティには必須と推奨の2段階があります。「必須プロパティが指定されていないアイテムは、リッチリザルトに表示されません」。推奨プロパティについては「指定する推奨プロパティが多いほど、表示される検索結果の質が高くなります」とあります（Google 検索セントラル「構造化データに関する一般的なガイドライン」／2026年9月27日閲覧）。推奨は足すほどよいという書き方ですが、足した値も本文に見えている必要がある点は変わりません。後で見る営業時間の例はここで詰まりました。

読む相手も決まっています。Googleは「一般的に、Google はサイトの設定で許容されている限り、JSON-LD を構造化データに使用することを推奨します」としています。あわせて「Google 検索の動作の定義には、schema.org のドキュメントではなく、Google 検索セントラルのドキュメントを使用してください」と書いています。確認の道具としては、開発時の検証にリッチリザルト テスト・Googleがマークアップを検出したかの確認にURL 検査ツール・数か月分の記録とURLごとの比較にSearch Consoleの検索パフォーマンス レポートを挙げています（Google 検索セントラル「Google 検索における構造化データのマークアップの概要」／日本語版最終更新2025年12月18日／2026年9月27日閲覧）。監査で突き合わせる原文は、型ごとのGoogle 検索セントラルのページです。

求人情報レポートで有効な項目が消えていた採用ページは、一覧ページにJobPostingを置く形が合っていなかった

採用ページ/recruitに置いていたJobPostingは、3つの職種を1ページに並べた一覧にオブジェクトを3つ出す形で、Googleが求める1求人1ページの置き場所に合っていませんでした。気づいたきっかけは2026年9月24日にSearch Consoleで開いた求人情報（JobPosting）レポートで、有効なアイテムは0件でした。グラフを遡ると8月中旬から3件の有効なアイテムが続き、9月5日ごろを境に0件になっていました（当社の計測、2026年9月24日）。

同じ日にURL 検査ツールで/recruitを調べると、結果は「3 件の有効なアイテムを検出しました」「重大ではない問題を検出しました」でした。推奨プロパティの不足として「validThrough がありません」「baseSalary がありません」が並んでいました（当社の計測、2026年9月24日）。レポートは0件と言い、URL検査は3件と言う。この食い違いの理由として当社が確認できたのは、2つの画面が別のものを見ているという点までです。URL 検査ツールの結果には「これはライブテストではありません。結果に表示されるのは、直近にインデックスに登録されたバージョンのページであり、ウェブ上で現在公開されているバージョンとは限りません」と注記があります（Search Console ヘルプ「URL 検査ツール」／2026年9月27日閲覧）。

一方のリッチリザルト レポートは「検出されるすべてのアイテムを網羅したものではありません。検出されるアイテムのサンプルを表示」するものです。「前回のクロール」は「Google が問題のあるページをクロールした直近の日付」を指します（Search Console ヘルプ「リッチリザルト レポートの概要」／2026年9月27日閲覧）。項目が無い・減る理由としてGoogleは、インデックス未登録・解析できない構文エラー・アクセス制限・クロールの遅れ・サンプル表示・インデックス登録ページ数の減少・重大なマークアップ エラーを挙げています。確認にはURL 検査ツールとリッチリザルト テストを使うよう案内しています（Search Console ヘルプ「構造化データの欠落や構造化データ項目の減少をデバッグする」／2026年9月27日閲覧）。当社の場合はこのどれに当たるかを画面から特定できませんでした。0件になった理由を当社は断定していません。

GoogleのJobPostingのドキュメントには「構造化データは、可能な限り最も詳細なリーフページに実装します。求人リストを提供することを目的としたページ（検索結果ページなど）には追加しないでください」とあります（Google 検索セントラル「求人検索用の求人情報（JobPosting）の構造化データ」／日本語版最終更新2026年9月12日／2026年9月27日閲覧）。3職種を並べた/recruitは、この「求人リストを提供することを目的としたページ」でした。同じ日に公開した求人広告の出稿自動化の記事にはこのルールを書いていながら、自社の採用ページはその形になっていませんでした。

URL検査が示した2つの不足も、同じドキュメントの推奨プロパティです。JobPostingの必須プロパティはdatePosted・description・hiringOrganization・jobLocation・titleの5つです。validThrough・baseSalary・employmentType・directApplyなどは推奨に分類され、validThroughは「求人情報が期限切れになる日付（ISO 8601 形式）」です（Google 検索セントラル「求人検索用の求人情報（JobPosting）の構造化データ」／2026年9月27日閲覧）。必須は揃っていたので「有効」と出ていましたが、置き場所のルールは有効・無効の判定に現れません。

当社は2026年9月24日に/recruitからJobPostingのブロックを外しました。外したことで求人検索に載る状態に戻るわけではなく、構造化データのない一覧ページになっただけです。職種ごとに1ページずつ作ってそれぞれにJobPostingを付けるかどうかは、代表の判断待ちです。分ける場合は掲載終了の扱いまで運用に入れる必要があります。Googleは「期限切れの求人情報は掲載できません」とし、「終了した求人に対してタイムリーな措置を講じないと、手動による対策が必要になる場合があります」と書いています（Google 検索セントラル「求人検索用の求人情報（JobPosting）の構造化データ」／2026年9月27日閲覧）。期限切れにする3通りの処理と、求人URLの通知にサイトマップよりIndexing APIを勧める理由は、求人広告の出稿自動化の掲載終了の節に公式資料の出典ごと置いてあります。

分けたあとの監視も同じドキュメントにあります。「ページがインデックスに登録されたら、関連するリッチリザルトのステータス レポートを使用して、問題がないかどうかを確認します。有効な項目が増え、無効な項目が増えていない状態が理想的です」（Google 検索セントラル「求人検索用の求人情報（JobPosting）の構造化データ」／2026年9月27日閲覧）。当社が9月24日まで見落としていたのは、この「増えていない状態」の逆で、有効が3件から0件に減った局面でした。レポートは定期的に開く前提で運用に組み込みます。

監査は公開HTMLからJSON-LDを取り出し、型ごとに公式ドキュメントと突き合わせ、反証役2つを通す

求人ページの件で、同じ見落としがほかの型にもある前提に立ちました。2026年9月25日に自社サイトの全ページを対象に監査を回しました。図はその流れで、左から公開HTML74ページ・JSON-LDの取り出し・型ごとの突き合わせ・候補19件・反証役2つ・残った10件と消えた7件・修正と保留の順に並んでいます。

対象にしたのは、CMSやテンプレートの設定ではなく本番ビルドで生成されたHTML74ページです。Search Console ヘルプは「構造化データは Google のサーバーではなく、お客様のウェブサイトに存在します」と書いています（Search Console ヘルプ「リッチリザルト レポートの概要」／2026年9月27日閲覧）。Googleが読むのは配信されたHTMLの中のJSON-LDなので、監査もそこから取り出したものを読みます。取り出した型はOrganization（ProfessionalService）・ContactPoint・PostalAddress・Offer・Service・WebSite・WebPage・AboutPage・Person・Article・NewsArticle・BreadcrumbList・FAQPage・VideoObjectの14種でした。

当社のサイトはAnthropicのClaude Codeで作っており、監査も同じ道具のエージェントで回しました。手順は3段です。1段目は監査役で、ページ群ごとに分けた3つのエージェントがHTMLからJSON-LDを読み、型ごとにGoogleのドキュメントを開き直します。そのうえでルールの原文・該当ページ・JSONの中の位置・直し方を1件ずつ書き出します。ここで候補が19件出ました。

2段目は反証役です。候補1件につき独立した2つのエージェントが、その候補を否定するつもりでドキュメントとHTMLをもう一度開きます。確かめるのは4点です。ルールの引用が原文どおりか・そのルールがこの型に当てはまるか・HTMLが本当にそうなっているか・直し方が新しい問題を生まないか。それぞれが支持か反証かを理由付きで返します。両方が支持した候補だけを問題として扱い、両方が反証した候補は消します。片方だけが支持した候補は任意の精度として残します。結果は19件のうち支持10件・意見が割れた2件・消えた7件でした。

3段目は人の判断です。10件のうち何をコードで直し、何を代表判断に回し、何を観察期間明けや本文の変更の判断まで待つかを決めました。違反ではない2件は対応不要としました。当社は検索順位を観察中のページの構造化データを観察期間中は触らない方針です。これはLLMOの測定で書いた、介入を記録して判定日まで待つ考え方と同じです。修正は2026年9月25日にコードに入れ、翌26日に代表が本番に反映しました。この修正でJSON-LDが変わったページは13ページで、見える本文が変わったページは0でした。変更を日付付きで記録して公開する形は、プレスリリース配信の実測レポートから続けているものです。

反証役を置いた理由は、監査役が見つけすぎるからです。ドキュメントを読んだエージェントは原文に無い一文を引用したり、ドキュメントに無い項目を要件に足したりします。見つける役と消す役を分けて初めて、残った件数が人の信用できるものになりました。消えた7件の中身は後の節に書きます。

残った指摘は、見えないものを書いていた・ページと違うものを書いていた・推奨項目の扱いの3つに分かれる

10件を型で分けると3つになります。表は当社が判断した内容と、2026年9月27日時点の状態です。

表は横にスクロールできます。

見えないものを書いていた｜電話番号・お知らせの著者・事例の日付

いちばん重いと判断したのは電話番号です。当社の全ページに出るOrganizationのノードにはtelephoneとcontactPoint.telephoneの2か所に会社の電話番号が入っていますが、電話番号はどのページの本文にも表示されていません。会社情報の表には住所とメールが、フッターには社名と住所が見えていて、電話だけが構造化データにしか無い状態でした。Organizationのドキュメントでtelephoneは推奨プロパティで、英語版の説明は "A business phone number meant to be the primary contact method for customers, if applicable." です（Google 検索セントラル「Organization (Organization) structured data」／2026年9月27日閲覧）。書いてよい項目ですが、「ページの読者に表示されないコンテンツをマークアップしないでください」（Google 検索セントラル「構造化データに関する一般的なガイドライン」／2026年9月27日閲覧）に照らすと本文に出すか構造化データから外すかのどちらかにする必要があります。サイトに電話番号を出すかどうかは会社としての判断なので、代表に回しました。

2つ目はお知らせ6ページの著者です。NewsArticleのauthorに代表個人（Person型）を入れていましたが、お知らせのページには署名が表示されていません。ブログの記事ページには「執筆」の署名が出るのに、同じ部品を使うお知らせでは署名を出していなかったのが原因です。記事の構造化データのドキュメントには「個人には Person タイプを、組織には Organization タイプを使用します」とあります。author.nameには「作成者の名前のみを指定します」ともあります（Google 検索セントラル「記事（Article、NewsArticle、BlogPosting）の構造化データ」／日本語版最終更新2026年9月12日／2026年9月27日閲覧）。お知らせは会社の発表なので、9月25日に著者を組織（株式会社SAI）に変えました。事例ページはもともと組織を著者にしていたので、これで揃いました。署名を出して個人のままにする案もありました。ただ代表が書いたという記録が無い発表に署名を足すのは新しい主張を足すことになるため採りませんでした。

3つ目は事例2ページの日付です。ArticleにdatePublishedとdateModifiedを入れていましたが、ページには日付が表示されていません。Googleは「ユーザーに表示される日付をページに追加し、目立つ位置に配置します」としています。「ユーザーに表示されるデータと対応する構造化データの間で、日付（および任意で指定する時刻とタイムゾーン）が整合するようにしてください」とも書いています（Google 検索セントラル「Google 検索で署名日に影響を与える」／日本語版最終更新2026年2月20日／2026年9月27日閲覧）。直し方は本文に日付を出すことですが、それは見える内容の変更なので今回の修正の範囲から外して保留にしました。構造化データから日付を消す案は、同じページが日付の指定を勧めているので採っていません。

ページと違うものを書いていた｜記事の画像・共通部分のOffer・根拠を示せないFAQの一文

事例2ページとお知らせ6ページのArticle.imageには、サイト共通のOG画像（SNSで共有したときに出るロゴ入りのカード）を入れていました。その画像はページに表示されておらず、記事の内容を表すものでもありません。記事のimageの条件は「ロゴやキャプションではなく、記事に関連する画像を使用してください」「画像はマークアップされたコンテンツを表している必要があります」です。Articleには「必須プロパティはありません。代わりに、コンテンツに適用されるプロパティを追加します」とあります（Google 検索セントラル「記事（Article、NewsArticle、BlogPosting）の構造化データ」／2026年9月27日閲覧）。imageは推奨であって必須ではないので、9月25日に構造化データから外しました。SNS用のog:imageはそのまま残しています。ブログの記事はもともと記事固有の画像があるときだけimageを出す作りだったので、事例とお知らせだけが違っていました。

2つ目は共通部分のOfferです。全ページに出るOrganizationのノードが、当社の各サービスをOffer型で包んでいます。当社はサイトに金額を書かない方針なので、Offerにpriceはありません。このうち売上連動型のサービスのページでは、priceの無いOfferを機械が実際と違う提供条件に要約する余地があるという理由で、ページ側のOfferをあえて置いていません。ところが共通部分のOfferがそのページにも出るので、ページごとの判断と共通部分が食い違っていました。Googleのルールに直接反する箇所ではありませんが、「構造化データはページ コンテンツを正確に表している必要があります」（Google 検索セントラル「構造化データに関する一般的なガイドライン」／2026年9月27日閲覧）に照らして共通部分から外す方向です。共通部分の変更は観察中のページにも及ぶため、観察期間が明けるまで保留にしました。

3つ目はサービス案内のFAQの一文です。回答の中に「企業様に選ばれています」という一文があり、これは顧客に採用されているという主張です。当社の記録を探しても、この一文を裏づける実例を示せませんでした。本文と構造化データは一致しているので見えない内容の問題ではありません。ただ「関連性がないコンテンツや誤解を招くコンテンツ（虚偽のレビュー、ページの内容と関係のないコンテンツなど）をマークアップしないでください」（Google 検索セントラル「構造化データに関する一般的なガイドライン」／2026年9月27日閲覧）に照らすと、根拠を示せない主張はそもそも本文に置けません。実例があるかどうかを代表に確認中で、無ければ本文と構造化データを同時に直します。書いたのは当社で、監査で自分の文を疑うことになった1件です。

推奨項目の扱い｜営業時間・動画のcreator・動画の置き場所

営業時間は逆の形で引っかかりました。当社の組織ノードはOrganizationとProfessionalServiceの2つの型を持ち、ProfessionalServiceはschema.orgでLocalBusinessの下位型です（schema.org「ProfessionalService」／2026年9月27日閲覧）。LocalBusinessの必須プロパティはaddressとnameの2つで、openingHoursSpecificationは推奨です（Google 検索セントラル「ローカル ビジネス（LocalBusiness）の構造化データ」／日本語版最終更新2026年9月12日／2026年9月27日閲覧）。当社には無く、足せば推奨が1つ増えます。ただ営業時間はサイトのどこにも表示されておらず、社内の記録も「土日祝定休」と「土日定休」で食い違っていました。構造化データだけに足すと電話番号と同じ見えない内容になります。表記を1つに決めて本文に出してから構造化データに足す順にし、表記の確定は代表に回しました。

動画のcreatorは、ドキュメントの更新で生まれた項目です。VideoObjectの必須プロパティはname・thumbnailUrl・uploadDateの3つです（Google 検索セントラル「動画（VideoObject、Clip、BroadcastEvent）の構造化データ」／最終更新2026年9月24日／2026年9月27日閲覧）。英語版の推奨プロパティ表には2026年9月24日の更新でcreator（authorも可）が加わり、説明は "The person or organization that created or published the video." です（Google 検索セントラル「Video (VideoObject, Clip, BroadcastEvent) structured data」／Google 検索セントラル「Latest documentation updates」／いずれも2026年9月27日閲覧）。当社が9月27日に確認した時点で日本語版の推奨プロパティ表にはcreatorの行が無く、JSON-LDとMicrodataのコード例に現れるだけでした（Google 検索セントラル「動画（VideoObject、Clip、BroadcastEvent）の構造化データ」／2026年9月27日閲覧）。当社の動画は自社制作なので新しい事実を足さずに書けます。9月25日にサービス2ページと記事3本の計5件のVideoObjectにcreator（組織）を加え、観察中のサービス1ページは観察期間が明けるまで保留にしました。

動画の置き場所は、違反ではないが期待を下げる件です。VideoObjectは「動画を視聴できるページに追加する必要があります。動画を視聴できないページに誘導するのは、ユーザーの利便性を損ねます」とあります（Google 検索セントラル「動画（VideoObject、Clip、BroadcastEvent）の構造化データ」／2026年9月27日閲覧）。当社の記事3本とサービス3ページには動画が埋め込まれていてその場で視聴できるので、この条件は満たしています。ただし動画はどのページでも本文の補助で、動画を見せることが主目的のページではありません。Googleは動画機能（動画検索結果・動画モード・主な出来事など）の対象を各動画専用の再生ページとし、「埋め込み動画をレビューするブログ投稿」を専用ページではない例に挙げています（Google 検索セントラル「動画の SEO ベスト プラクティス」／最終更新2026年2月20日／2026年9月27日閲覧）。監査の判断は、これらのページに専用の再生ページ向けの動画機能を期待しないというものでした。構造化データは残し、コードは変えていません。

意見が割れた2件も動画でした。uploadDateに日付だけを入れて時刻とタイムゾーンを省いている点です。Googleは「タイムゾーン情報を提供することをおすすめします。提供されない場合は、デフォルトで Googlebot が使用するタイムゾーンが適用されます」と書いています（Google 検索セントラル「動画（VideoObject、Clip、BroadcastEvent）の構造化データ」／2026年9月27日閲覧）。反証役の一方は実害が無いとして反証し、もう一方は支持しました。当社は任意の精度として扱い、公開時刻を確かめられたときに足す扱いにしています。

反証で消えた候補は、ドキュメントにない要件を足して直しすぎる見本だった

監査役が挙げて反証役が消した7件は、どれも直していれば余計な変更になっていたものです。3つだけ挙げます。

1つ目は「会社概要ページのAboutPageにisPartOf（サイト全体を表すWebSiteノードとの結びつき）が無い」という指摘です。根拠として引かれた一文は、構造化データ ガイドラインのページに存在しませんでした（Google 検索セントラル「構造化データに関する一般的なガイドライン」／2026年9月27日閲覧）。原文に無い文を根拠にした指摘で、従っていればGoogleが求めていない項目を足していました。

2つ目は「動画の名前が『3分でわかる』なのに長さが1分59秒で食い違う」という指摘です。名前はYouTube上の実際のタイトルで、動画のドキュメントに名前と長さの一致を求める記述はありません（Google 検索セントラル「動画（VideoObject、Clip、BroadcastEvent）の構造化データ」／2026年9月27日閲覧）。名前を変えていれば、公開中の動画と違う名前を構造化データに書くことになっていました。

3つ目は「共通部分のOfferとサービスのノードに@id（JSON-LDの中でノード同士を結ぶ識別子）やurlが無い」という指摘で、2件ありました。GoogleのOrganizationとLocalBusinessのドキュメントはこれらの結びつきを使っていません（Google 検索セントラル「組織（Organization）の構造化データ」／Google 検索セントラル「ローカル ビジネス（LocalBusiness）の構造化データ」／いずれも2026年9月27日閲覧）。ドキュメントに無い項目を要件にした指摘でした。

残りは、代表のPersonノードのurlが会社概要ページと記事ページで違うという指摘（2件。@idは同じで解決していました）と、パンくずリストがページに表示されていないという指摘です。パンくずのドキュメントが定めるpositionは「パンくずリスト内のパンくずの位置」で「位置が 1 の場合、リスト内の最初のパンくずを示します」というもので、当社の値は1から順でした。ページへの表示を求める記述はありません（Google 検索セントラル「パンくずリスト（BreadcrumbList）の構造化データ」／日本語版最終更新2026年9月12日／2026年9月27日閲覧）。

ここから当社が持ち帰ったのは、直す前に原文を疑い直す手順を省かないことです。監査の指摘は、ツールやAIやドキュメントを読んだ人の善意から出ます。それでもドキュメントに無い文を引用する・ドキュメントに無い項目を要件にする・ルールの無いところに不一致を見つけるという3つの読み違えは繰り返し起きました。修正1件ごとにその修正が新しい不一致を生まないかまで反証させたことで、10件の修正と保留を落ち着いて決められました。

自社サイトで同じ確認をするなら、道具4つと問い3つで回す

読者が自社サイトで同じことをするなら、道具は4つで足ります。順番は公開HTMLを読むところからです。

道具｜公開HTML・リッチリザルト テスト・Schema Markup Validator・Search Console

1つ目は公開中のページのHTMLです。ブラウザでページのソースを表示し、<script type="application/ld+json">で始まる部分を探します。そこにあるのが実際に配信されている構造化データで、CMSやプラグインの設定画面に書いた内容とは限りません。取り出したJSON-LDを画面と並べ、値を1つずつ本文に探します。電話番号・営業時間・著者・日付・画像は、この作業で初めて見えないものだとわかります。

2つ目はリッチリザルト テストです。URLを入れる方式とコードを貼る方式があり、JSON-LD・RDFa・Microdataの3形式に対応しています。「ページのリソースはすべて、そのコードにインターネット経由で匿名ユーザーがアクセスできるようになっている必要があります」とあるので、公開前のページは貼り付けで試します。「必ずしもこのツールによるプレビューとまったく同じようにページが表示されるとは限りません」とも書かれています（Search Console ヘルプ「リッチリザルト テスト」／2026年9月27日閲覧）。

3つ目はschema.orgのSchema Markup Validatorです。JSON-LD 1.0・RDFa 1.1・Microdataのマークアップを取り出して構文の誤りを示すツールです。schema.orgの説明では、以前Google Structured Data Testing Toolとして知られていたツールを基にGoogleがschema.orgコミュニティ向けに提供しているものです（当社訳。schema.org「Schema.org Markup Validator」／2026年9月27日閲覧）。Googleはこのツールを、Google固有の警告なしにschema.orgベースの構造化データを検証するものと説明しています（当社訳。Google 検索セントラル「Schema Markup Testing Tool」／2026年9月27日閲覧）。Google固有の警告は出ないので、リッチリザルトの無いOrganizationやWebPageの構文確認に向きます。

4つ目はSearch Consoleです。3つの画面を使い分けます。リッチリザルト レポートは種類別で、日本語版の対象一覧には求人情報・パンくずリスト・動画・販売者のリスティング・レビュー スニペットなどが並びます。2026年9月27日時点で「よくある質問」は含まれていません。「特定のリッチリザルト タイプのレポートは、次の場合にのみ表示されます。Google がプロパティ内で有効なマークアップを検出する。かつ、そのマークアップが、サポートされているリッチリザルト タイプである」とあります。項目は有効と無効の2区分で、重大でない問題は「検索での見え方を改善できるアイテム」の表に出ます（Search Console ヘルプ「リッチリザルト レポートの概要」／2026年9月27日閲覧）。

構文が壊れている場合は「解析できない構造化データ」レポートに出ます。「重大な構文エラーが原因で解析できなかった、サイト内の構造化データの一覧」です。「解析エラーがあると、構造化データの意図するタイプ（ジョブ、イベントなど）を判別できなくなります」とも書かれています。エラー名には「無効な JSON ドキュメントです」「解析エラー: 「,」または「}」がありません」「値の型が正しくありません」などがあります（Search Console ヘルプ「解析できない構造化データのレポート」／2026年9月27日閲覧）。

URL 検査ツールは前の節のとおりインデックス登録済みのバージョンを示すもので、公開中の状態を見るにはライブテストを使います。修正後の流れは、問題の特定と修正・修正のアップロードと確認・「修正を検証」の3段です。「検証には、クロール頻度に応じて 2 週間以上かかる場合があります」（Search Console ヘルプ「Search Console で構造化データの問題を修正する」／2026年9月27日閲覧）。修正した日と検証を押した日を控えておかないと、反映の遅れを別の問題と読み違えます。

問い｜見えているか・合っているか・1ページに1つの実体か

道具が返すのは構文と必須の判定までなので、残りは3つの問いを自分で当てます。

1つ目は「見えているか」です。JSON-LDにある値がそのページの本文に表示されているかを、値ごとに確かめます。「ページの読者に表示されないコンテンツをマークアップしないでください」（Google 検索セントラル「構造化データに関する一般的なガイドライン」／2026年9月27日閲覧）。当社で引っかかったのは電話番号・著者・日付でした。テンプレートやプラグインが会社情報を全ページに出す設計では、1ページで見えていても他のページで見えていないことがあります。

2つ目は「合っているか」です。見えていても、構造化データの値と本文の値が同じかを確かめます。日付は「ユーザーに表示されるデータと対応する構造化データの間で、日付（および任意で指定する時刻とタイムゾーン）が整合するようにしてください」（Google 検索セントラル「Google 検索で署名日に影響を与える」／2026年9月27日閲覧）。画像は記事を表しているか・著者は個人か組織か・本文の主張に根拠があるかまでがこの問いに入ります。当社で引っかかったのは画像とFAQの一文でした。

3つ目は「1ページに1つの実体か」です。JobPostingは1件の求人だけを載せたページに置きます（Google 検索セントラル「求人検索用の求人情報（JobPosting）の構造化データ」／2026年9月27日閲覧）。Organizationは「ホームページまたは組織の説明を掲載した単一のページ（例: 企業情報ページ）に配置することをおすすめします」（Google 検索セントラル「組織（Organization）の構造化データ」／日本語版最終更新2026年9月12日／2026年9月27日閲覧）。共通部分から全ページに出しているノードは、そのページの内容と関係なく毎ページに同じ主張を置くことになります。当社で引っかかったのは採用ページと共通部分のOfferでした。

読む原文は型ごとのGoogle 検索セントラルのページで、日本語版が英語版より遅れることがあります。動画のcreatorのように英語版だけに載っている項目があるので、日本語版で見当たらないときは英語版も開きます。

構造化データの監査についてよくある質問

Q. リッチリザルト テストで「有効」なら、そのままでよいですか？

構文と必須プロパティの確認としては十分ですが、本文と合っているかは別に確かめます。テストは構造化データからどのリッチリザルトを生成できるかを見るもので、「必ずしもこのツールによるプレビューとまったく同じようにページが表示されるとは限りません」（Search Console ヘルプ「リッチリザルト テスト」／2026年9月27日閲覧）。当社の採用ページはURL検査で有効3件と出ていながら、置き場所のルールに合っていませんでした。

Q. 構造化データを直したり外したりすると、検索順位は下がりますか？

Googleは構造化データの手動対策について「ページがリッチリザルトとして表示されなくなります。ただし、Google ウェブ検索でのページの掲載順位には影響しません」と書いています（Google 検索セントラル「構造化データに関する一般的なガイドライン」／2026年9月27日閲覧）。順位への影響を当社は計測しておらず、この記事では上がる下がるのどちらも主張しません。外した後に変わるのはリッチリザルトの表示条件です。

Q. FAQPageの構造化データは残しておいてもよいですか？

本文と一致していれば残せます。FAQのリッチリザルトは2023年8月に、よく知られた信頼性の高い政府と医療のサイトに限られました。その時点でGoogleは、この構造化データをサイトから外してもよいが積極的に削除する必要はないとしています（当社訳。Google 検索セントラル ブログ「Changes to HowTo and FAQ rich results」／2026年9月27日閲覧）。2026年5月7日以降は機能自体が表示されなくなったので、リッチリザルトを目的にFAQを増やす理由はありません（Google 検索セントラル「ドキュメントの最新の更新内容」／2026年9月27日閲覧）。

Q. 直したあと、Search Consoleにはいつ反映されますか？

すぐには反映されません。「新しく実装された構造化データがすぐに表示されないことがあります」（Search Console ヘルプ「構造化データの欠落や構造化データ項目の減少をデバッグする」／2026年9月27日閲覧）。修正の検証は「クロール頻度に応じて 2 週間以上かかる場合があります」（Search Console ヘルプ「Search Console で構造化データの問題を修正する」／2026年9月27日閲覧）。URL 検査ツールからインデックス登録をリクエストした場合は「通常、インデックス登録は 1 日程度ですみますが、長くかかる場合もあります」（Search Console ヘルプ「URL 検査ツール」／2026年9月27日閲覧）。当社は修正した日と本番に反映した日を記録し、判定はレポートに現れてから行います。

SAIの視点：見えていることと書いてあることを合わせるのは、AI導入支援と同じ作業

自社サイトの10件のうちコードだけで直せたのは3件で、残りは電話番号を出すか・営業時間は何か・その一文に根拠はあるかという会社としての判断でした。構造化データの問題の多くは技術の問題ではなく、会社が公に何を言うかを決めていなかった問題として現れます。

当社のAI導入支援でも、AIが作った下書きや要約を業務で使う前に、現場に実際に見えている記録と合っているかを人が確かめる工程を置きます。構造化データの監査はその工程をサイトに当てただけで、見えていることと書いてあることを合わせるという作業は同じです。今回はAIのエージェントが監査役と反証役を分けて担い、どこまでを直してどこからを人が決めるかを表にして代表に渡しました。

最初に確かめるのは、電話番号・営業時間・著者・日付のうち構造化データにあって画面に無いものが何件あるかです。サイトのURLと、構造化データを入れた手段（プラグイン・制作会社・AIのいずれか）をお問い合わせからお送りください。公開HTMLから取り出したJSON-LDと画面を並べるところから始めます。