WordPressの構造化データ（JSON-LD）を確認する方法｜重複と情報の不一致を防ぐ実務ガイド

「構造化データを入れれば、AI検索に会社を表示できる」「FAQやHowToのコードを足せば検索結果で目立つ」と聞き、WordPressの設定を増やそうとしていませんか。まず確認したいのは、何を表示・整理したいのかと、公開ページにすでに何が出力されているかです。構造化データはAI検索への掲載に必須ではなく、追加コードがすでにある出力と重なる場合もあります。

Googleの生成AI機能について、Googleは特別な構造化データやAI向けマークアップを追加する必要はないと案内しています。構造化データはページの内容を検索サービスへ明示するための仕組みであり、Google検索の一部の表示機能に適格となる場合があります。正しく記述しても表示は保証されません。この記事では、まず公開HTMLを確認し、ページの目的と現在サポートされる表示を照合し、WordPressの出力を安全に検証する流れを説明します。

AI検索のために急いで追加する前に、構造化データの目的を決める

構造化データは、ページ上の情報を決まった語彙と形式で示す方法です。Schema.orgの語彙をJSON-LD、Microdata、RDFaなどの形式で記述できます。JSON-LDはHTML本文へ属性を埋め込まず、ページ内のscript要素にまとめて記述できる形式です。Googleは、対応する検索機能の案内でJSON-LDを推奨していますが、ほかの形式を使えないという意味ではありません。

Google検索内のAI OverviewsやAI Modeに表示させるための特別な構造化データはありません。Googleの案内は、通常の検索で必要なクロール・インデックス・掲載の条件を満たすこと、読者にとって役立つ内容を作ること、ページを適切に技術実装することを基本としています。構造化データを足すことだけで、他社の生成AIがページを読み取る方法や、回答での引用を変えられるとは確認できません。提供元が公表していない仕組みは推測しないでください。

作業を始める前に、目的を次のように分けます。

「AI検索対策だからJSON-LDを増やす」という理由だけなら、コードを追加する前に、通常のSEO、ページ本文、クロール、会社情報の整合を確認します。自社で目的を説明できない項目は、追加しないという判断も有効です。検索結果の見え方を調べる場合は、Googleの生成AI機能向け公式ガイドと構造化データの概要を読み、Googleの検索機能に関する話と他社サービスの話を分けてください。

公開ページにすでに出ている情報を確認する

WordPressは、SEOプラグイン、テーマ、ブロック、カスタムコードなどが構造化データを出力することがあります。入力画面でJSON-LDを見つけられなくても、公開HTMLにはすでに情報が出ているかもしれません。先に追記してしまうと、同じ会社や記事を表すデータが複数になり、値や参照先が食い違うことがあります。

パスワードを使わずにできる最初の確認は、対象ページの公開HTMLです。ブラウザーでページを開き、ページのソースを表示して「application/ld+json」または「@type」を検索します。環境によってはブラウザーのメニューからソース表示を選びます。ソース内に見つからなくても、JavaScriptで描画後に追加される場合があります。その場合は、ブラウザーの開発者ツールで描画後のDOMを確認するか、GoogleのJavaScriptで構造化データを生成する手順を参考にURLを使ってテストします。Googleは描画後のDOMにある構造化データも処理できると説明しています。開発者に確認を依頼する場合は、URLと確認したHTMLを渡し、scriptの数、各scriptの型、同じ対象を表すノード、@idの参照先を見てもらいます。

たとえば、2026年9月24日に確認したこの記事の公開HTMLには、BlogPosting、BreadcrumbList、Organization、WebPage、WebSiteの各ノードを含むJSON-LDがすでに出力されていました。記事本文には「コピペで追加」と書かれている一方で、このページ自身に記事・組織・サイト情報のグラフがあります。出力元のWordPress管理設定までは公開HTMLだけでは特定できないため、どのプラグインやテーマが生成したかは別途管理画面か設定資料で確認します。

確認したい値は、記事名、ページURL、公開日・更新日、著者、パンくず、組織名、ロゴ、会社情報などです。公開画面とJSON-LDで表記が異なる、古い日付や別URLが残る、同じ@idを意図しない内容が使う、同じ情報を複数の出力元が別々に生成する、といった差があれば、追加作業より先に正本を決めます。

WordPressの管理者パスワードやサーバー認証情報を第三者へ送る必要はありません。まずは公開URL、見つかった型、ずれている公開情報、利用中と分かる範囲のプラグイン名を整理すれば、調査の出発点になります。公開HTMLに個人情報や非公開情報を載せていないかも、あわせて確認します。

型は「サイト全体の必須セット」ではなく、ページの実態で選ぶ

構造化データの型を決めるときは、まずそのページの主題と、対象のGoogle検索機能の案内を確認します。Schema.orgに存在する型であっても、Googleの特定の拡張表示で使えるとは限りません。逆に、Googleのリッチリザルト向けではない型もSchema.orgの語彙として意味を持つことはあります。語彙の存在と、特定の検索画面で表示されることは別の判断です。

OrganizationとLocalBusinessをどちらにするかは、「会社ならOrganization、地域名があるならLocalBusiness」といった単純なキーワード選択ではありません。実際に利用者が訪れる拠点があるのか、ページがその拠点を説明しているのかを確認します。オンライン中心の事業へ架空の店舗住所・営業時間・地図座標を付けないでください。GoogleのOrganizationとLocalBusinessの案内は、それぞれの適用範囲とプロパティを別に説明しています。

FAQPageとHowToも、昔の検索表示や他社の紹介記事だけを根拠に優先しないようにします。GoogleはFAQ/HowToリッチリザルトの変更で、FAQの拡張表示を権威ある政府・医療サイトに限定し、HowToの拡張表示を終了すると発表しています。現在のGoogle AI検索の案内でも、生成AI機能向けの専用スキーマは不要とされています。質問への回答や手順を本文に分かりやすく載せることと、同じ内容を構造化データに記すこと、検索結果に特別表示されることはそれぞれ別です。

Google対応の表示形式・対象を確かめる場合は、Googleが検索でサポートする構造化データの一覧を基準にします。Schema.org側の型を調べる場合は、Schema.orgの型の説明も確認します。どちらか一方を見て、すべての検索サービスの仕様だと読み替えないことが大切です。

JSON-LDの値は、表示内容と確認できる資料に合わせる

構文が正しくても、値が現実と違えば適切な実装とはいえません。Googleの一般ガイドラインは、構造化データに記した内容がユーザーに見えるページ内容と一致すること、誤解を招く情報や非表示の情報をマークアップしないことを求めています。必須・推奨プロパティは型や機能によって異なります。「この型なら、この欄をすべて埋める」という一律の入力表を使わず、対象ページの公式仕様を読みます。

記事情報なら、ページ上のタイトルをheadlineに、公開日をdatePublishedに、実際に更新した日をdateModifiedに対応させます。内容を変えずに日付だけを新しくしたり、本文で著者を表示していないのに特定の人物をauthorとして書いたりしないでください。GoogleのArticle構造化データの案内には、日付をISO 8601形式で記載する例や著者情報の推奨事項があります。これは記事の情報を正確に記述する案内であり、日付を変更すればAIに新しさを認識させられるという保証ではありません。

実装依頼の説明には、次の対応表を使うと、確認と修正の範囲を共有できます。

Organizationに入れるsameAsは、本人・組織の公式プロフィールと確認できるURLだけにします。会社名の表記ゆれを寄せたいという理由で、関係が曖昧なSNS、第三者の名簿、未承認プロフィールを一括登録しないでください。LocalBusinessでgeoや営業時間を使う場合は、公式ページや現地情報に基づく実値を確認し、存在しない営業時間や住所を補わないこと。架空のデータをサンプルに使うなら「記入例」と明記し、そのまま公開へ貼れないことを説明します。

コード例を手元で試すときは、コードの有効性と事実の正しさを別に確認します。JSONとしてパースできても、ページと一致するとは限りません。反対に、ページの目的に合った情報でも必須項目が欠ければGoogleの特定機能には適格にならないことがあります。まず対象機能の説明を確認し、必要な範囲だけを記述してください。

WordPressは出力元を一つに整理してから変更する

管理画面にSEOプラグインが一つ見えても、構造化データがそのプラグインだけから出ているとは限りません。プラグイン、テーマ、カスタムプラグイン、ブロック、外部連携が、同じOrganizationやArticleをそれぞれ作る構成もあります。プラグインの入力欄へ情報を追加しただけでは、公開ページのHTMLが意図どおり変わったか分かりません。

安全に整理する順序は次のとおりです。

1. 公開ソースで構造化データのscriptと@typeを一覧にする。
2. WordPress管理画面とテーマ・追加機能のうち、出力元が分かるものを記録する。
3. 同じ対象を示すデータについて、残す正本、参照関係、不要な重複を決める。
4. 本番に触る前にテスト環境または複製で一つの変更を試す。
5. 更新後の公開HTMLを再取得し、値・型・URL・scriptの数を変更前と比べる。
6. 意図しない差があれば変更を戻し、修正後の検証結果と担当者を記録する。

プラグインを使う場合は、そのプラグインの現在の公式説明で、サイト全体の組織情報、記事テンプレート、個別ページの型がどのように出力されるかを調べます。使っているバージョン、テーマ、ほかの拡張機能によって画面や機能が異なるため、「Schemaタブを開く」「このボタンを押す」といった別の製品や古い画面の手順をそのまま当てはめないでください。現在の設定と公開HTMLの両方が証拠になります。

テーマのfunctions.phpやheader.phpへ直接コードを貼るのは、出力元を確定してからです。既存テーマの更新で変更が消える、プラグイン出力と重なる、条件分岐が誤って全ページに出る、HTMLとして不正な文字列になる、といった問題が起き得ます。実装を依頼するなら、対象テンプレート、出力条件、使用する値の正本、重複させない出力元、公開後の確認を先に決めます。

一つのページのデータを複数scriptに分けて出すこと自体が常に誤りというわけではありません。ノード間の@id参照や関係が意図どおりにつながっている場合もあります。「同じ型が二つあるから片方を削除」と機械的に判断せず、対象エンティティ、ID、値、生成元を確認してください。問題があるのは、意味の異なる情報が同じ実体として扱われる、重複する出力が矛盾する、変更する担当者が分からないといった状態です。

テストは「構文」「Google対応機能」「公開後」の三つに分ける

検証ツールが一つ通ればすべて解決するわけではありません。何を確かめるツールなのかを分けて使います。

Schema Markup Validatorが構文を受け付けても、Googleの検索機能がその型の拡張表示に対応しているとは限りません。Rich Results Testで対象外の型が表示されない場合も、その型に関するSchema.orgの記述全体が壊れていることを意味しません。テスト対象の範囲と、確認したい機能の説明を合わせて読みます。

Googleの一般ガイドラインは、構造化データが正しくても検索結果への表示を保証しないと明記しています。また、Search Consoleのレポート案内は、Googleが対応する機能として検出・処理した項目を確認する方法を説明しています。すべてのSchema.org型やAI回答の引用数を一覧にするレポートではありません。現在のレポート項目や表示内容は、Search Consoleの対象プロパティを開いて確認します。

公開後に確認する基本手順は、対象の公開URLをURL検査へ入力し、Googleが見ている取得済みページと現在の公開ページの違いを確認することです。ページを変更した直後に、クロールやレポートの反映が済んでいるとは限りません。検査に合格した表示を見てすぐ再クロールを何度も依頼するのではなく、クロール日時と結果を記録し、次に確認する必要がある時点を決めます。

公開前後で、ページのタイトル・URL・著者・日付・画像が本文と一致するか、JSON-LDの構文に誤りがないか、意図しないscriptが増えていないか、ページがGooglebotから取得できるかを順に見ます。ある型に関連する警告をすべて消すために、内容に合わないプロパティを作り足してはいけません。テストの警告は、その機能に必要なのか、任意の推奨なのかを型の公式資料で確認してください。

企業担当者と制作会社で、確認・依頼の範囲を分ける

ページの本文や会社情報が頻繁に変わらず、現在のJSON-LDが画面と一致し、テスト上の問題もないなら、記事を読んで自社で確認できる範囲はそこで終わりにできます。構造化データの追加を「AI検索対策の必須作業」として見積もる必要はありません。必要な表示機能がない、組織名や日付に明らかなずれがある、複数の出力元が競合しているときに、影響するページを選んで修正を検討します。

社内にWeb担当者がいない場合は、次の三点を整理してから相談すると、何が決まっていないかを伝えられます。

• 対象となる公開URLと、画面で正しいと確認できる会社情報・記事情報。
• 期待すること。たとえば、公開画面とJSON-LDの会社名が揃うこと、Googleの対応するリッチリザルトで有効性を確認すること。
• 現在分かっているWordPressの構成、更新を任せたい範囲、社内の確認担当。

記事を読んで自力で解決できる場合は、その結果を記録して終えて構いません。サイト全体の更新や保守も含む依頼が必要なら、Acquaの企業向けWeb制作・運用と保守・運用を見て、対象作業や費用が現在の希望に合うか確認します。構造化データの個別診断、作業量、料金が公開ページだけで確定できるとは判断せず、相談時に対象と見積条件を確認してください。

制作会社がWordPress実装の一工程として依頼する場合は、対象テーマ・テンプレート、既存出力、採用する正本、値の出典、テスト環境、公開後の確認者を仕様メモへ書きます。引き渡し時には、変更ファイル、出力条件、テストURL、テスト結果、残課題、戻し方を渡します。Acquaの制作会社向けパートナー案内にはWordPress実装・修正・テスト等の工程案内がありますが、個別案件の受託可否や作業条件は案件ごとに確認が必要です。

Webサイト全体の検索導線や記事・サービスページの役割から整えたい場合は、SEO・LLMO対策の案内を確認できます。これは特定AIサービスへの掲載や順位を保証する案内ではありません。何をどこまで直すか、どの状態を完了とみなすか、費用と納期を相談前に確認します。相談時にWordPressやサーバーのパスワードをフォームへ記載する必要はありません。

改善後に目指す状態は、JSON-LDの量が増えることではありません。公開画面の事実と出力が一致し、意図しない重複や古い値がなく、必要なGoogle検索機能の範囲でテスト結果を確認でき、次の更新担当が変更箇所を追える状態です。修正のために作業時間や費用をかけるなら、公開前後の差分、確認にかかった工数、利用者への表示・問い合わせ動線への影響も記録してください。表示回数や順位の変化があっても、構造化データだけが理由だと断定しないでください。

構造化データの確認を、完了条件と記録に結びつける

「構造化データを設置した」という報告だけでは、誰の何の問題が解決したか分かりません。作業前に、読者や担当者が何に困っていて、何を変えたら解決と判断するかを決めます。たとえば「ブログ記事の著者名が本文と出力で異なる」なら、作業完了は著者表示とJSON-LDが一致すること、公開後の検証はソースを読み戻して値を確認することです。AIの回答へ掲載されることを完了条件にすると、作業者が制御できない結果を約束することになります。

出力を直したら、変更前後で何が変わったかを短い差分にします。公開URL、変更ファイルやCMS欄、対象script、確認ツール、確認日、未対応の警告を記録します。WordPressのバックアップやテスト環境を利用できる場合は、変更前の状態へ戻す方法も作業範囲に含めます。公開後に元へ戻せることと、ローカルの検証で問題がないことを確かめてから、本番反映の判断をします。

もし構造化データを直したのに検索結果の表示が変わらない場合、すぐ別の型を足すのではなく、ページがインデックスされているか、Googleが対象機能を提供しているか、本文が条件を満たすか、Googleが再取得したかを確認します。検索結果に出るかどうかはGoogleが判断し、テストの合格だけでは決まりません。他社AIの引用はさらに別の仕様・取得過程であり、この検証だけでは確かめられません。

記事の結論は、構造化データを無条件に増やすことではありません。目的を決め、公開ページの出力を読み、ページに合う範囲だけを正確に記述し、対象ごとに適切なツールで確認して、変更を引き継げる状態にすることです。必要な問題が見つからなければ、何も追加しない判断も完了です。