FAQ構造化データの書き方｜JSON-LDのコピペ用サンプルと注意点

FAQ構造化データの書き方は、schema.orgが定義する「FAQPage」というJSON-LD形式のコードを用意し、質問と回答をそのまま自社のQ&Aに書き換えて、HTMLのhead内かbody内に貼り付けるだけで完了します。ただし2026年5月7日にGoogleがFAQのリッチリザルト表示を終了したため、検索結果の見た目が変わることは基本的にありません。この記事では今すぐ使えるコピペ用JSON-LDサンプル、書き換え箇所、検証手順、ガイドライン違反にならない注意点に加え、リッチリザルト終了後もLLMO・AIO観点で実装する意味があるのかまで、実務目線で解説します。

FAQ構造化データの書き方は？結論と全体像

結論として、FAQ構造化データの書き方はJSON-LDの完成コードをコピペし、質問文（name）と回答文（acceptedAnswer.text）を自社のQ&Aに書き換えて、HTMLのhead内またはbody内に貼り付けるだけです。やることは大きく3つ、ページにQ&Aを記載する、JSON-LDでマークアップする、リッチリザルトテストで検証するという流れになります。

この3ステップは多くの解説サイトでも共通して紹介されている手順です。まずはページ本文に質問と回答をテキストとして用意し、その内容とJSON-LDの記述内容を完全に一致させることが前提になります。マークアップだけを先に書いて、ページ側のQ&Aが未公開のまま公開してしまうと、後述するガイドライン違反や表示不一致の原因になります。

TechSuite株式会社の「AI検索パートナーズ」は、構造化データの実装を担う技術人材とAIを活用したコンテンツ制作人材が同じチームで連携し、Q&Aコンテンツの企画からJSON-LDの実装、公開後の効果測定までを一気通貫で支援しています。書き方だけを知っても実際の運用まで手が回らないという担当者の声に対応できる体制です。

まず結論（コピペ用サンプルの場所とやること3つ）

コピペ用のJSON-LDサンプルは本記事の後半で提示しており、書き換えるのは質問文と回答文の2箇所だけです。ページへの記載、マークアップ、検証という3ステップさえ踏めば、専門的なプログラミング知識がなくても実装は可能です。

手順を先に一覧にすると、次のとおりです。この順番を守ることで、ページ内容とマークアップの不一致という代表的なミスを避けられます。

• ステップ1 ページ本文にQ&Aをテキストで記載する
• ステップ2 その内容と一致させたJSON-LDを記述する
• ステップ3 リッチリザルトテストやSchema Markup Validatorで検証する

【重要】2026年の最新仕様（リッチリザルトは表示されなくなった）

Google公式の更新履歴によると、FAQのリッチリザルト機能は2026年5月7日をもって検索結果に表示されなくなり、2026年6月には関連ドキュメントも削除されています（Google検索セントラル 構造化データの更新履歴）。それ以前の2023年8月にも、表示対象が「よく知られた信頼のおける政府機関および保健衛生関連のウェブサイト」に限定されていました。

つまり2023年時点でも一般企業のFAQは基本的にリッチリザルトの対象外であり、2026年5月以降は仕様上どのサイトでも表示されません。「設定したのに表示されない」という悩みは、そもそも現在は誰にも表示されない仕様変更の結果である可能性が高いです。この前提を踏まえたうえで、実装の目的を検索結果の見た目ではなく別の価値に置き直す必要があります。

そもそもFAQ構造化データ（FAQPage）とは？

FAQ構造化データとは、schema.orgが定義するFAQPageという語彙を使い、ページ内のよくある質問と回答のセットをHTMLの裏側で機械可読な形式に整理するマークアップのことです。人間が見るデザインには影響せず、検索エンジンやAIがページの内容を正確に理解する手助けをする役割を持ちます。

実際、正しく埋め込むとFAQがリッチリザルトとして表示されていた時期もありました（デジタルアイデンティティ 構造化データ解説）。現在は表示自体が終了していますが、Q&Aの構造をデータとして明示する仕組み自体は引き続きschema.orgに存在しています。

TechSuite株式会社の「AI検索パートナーズ」は、構造化データや意味的文脈、エンティティ認識、想定質問の分解といった生成AIが引用・推薦する仕組みを技術的に捉え、LLMOやGEO、AEOの施策として一次情報設計まで踏み込んで支援しています。FAQPageの定義を正しく理解することは、その一次情報設計の入口にあたります。

schema.orgとFAQPageの基本（質問と回答のセットを機械可読にする）

FAQPageとは、質問（Question）と回答（Answer）のペアを配列で持つschema.orgの型のことです。1つのFAQPageの中に複数のQuestionを格納し、それぞれのQuestionが1つのacceptedAnswerを持つという入れ子構造になっています。

FAQPageはあくまで運営者が作成した質問と回答を表現する型であり、誰でも投稿できるコミュニティ型の質問には使いません。この違いは次のQAPageとの区別で重要になります。

見た目（ページデザイン）には影響しない裏側の記述

JSON-LDやmicrodataでFAQPageを記述しても、実際のページの見た目（アコーディオンやレイアウト）は一切変わりません。あくまで検索エンジンやAIに向けた裏側の情報付与であり、デザインの変更は別途CSSやHTMLで行う必要があります。

そのため、既存のよくある質問ページのデザインを変えずに、構造化データだけを後から追加することも技術的には可能です。見た目とマークアップは独立して管理できる点を理解しておくとよいでしょう。

FAQPageとQ&A（QAPage）の違い

FAQPageは運営者が作成した質問と回答を表す型で、QAPage（Q&A）は1つの質問に対して複数のユーザーが回答できる投稿型ページ向けの型です。よくある質問ページには基本的にFAQPageを使い、QAPageは使いません（デジタルアイデンティティ 構造化データ解説）。

項目	FAQPage	QAPage
想定される質問元	運営者が作成	ユーザーが投稿
回答者	運営者・編集部	複数の一般ユーザー
回答の数	1問につき1回答	1問につき複数回答が可能
典型的な利用例	よくある質問ページ	Q&Aコミュニティサイト

【コピペ用】JSON-LDサンプルコードと書き換え方

結論として、下記のコードをそのままコピーし、質問文（name）と回答文（acceptedAnswer内のtext）だけを自社のQ&Aに書き換えれば実装が完了します。@contextとFAQPage、mainEntityの構造自体は変更する必要がありません。

JSON-LDはscript要素の中にJSON形式で記述する方式で、複数のQ&Aを1つのFAQPageの中にmainEntityの配列として格納します（technical-seo.jp FAQ構造化データ解説）。以下のサンプルは2問構成ですが、質問を増やす場合はQuestionのオブジェクトを配列内にコピーして追加するだけで対応できます。

TechSuite株式会社の「AI検索パートナーズ」は、AIを活用した高度なコンテンツ制作の仕組みを「バクヤスAI記事代行」事業で培っており、その制作エンジンとナレッジをLLMO対策に転用しています。想定質問の分解に沿ってQ&Aコンテンツと構造化データをセットで高速に設計できる点が特徴です。

基本テンプレート（複数FAQを入れた完成コード）

まずはコピペしてそのまま使える完成コードの構造を示します。@contextはhttps://schema.org、@typeはFAQPage、複数のFAQはmainEntityの配列に格納するという3点が必須プロパティです。

• <script type=”application/ld+json”>
• {
• “@context”: “https://schema.org”,
• “@type”: “FAQPage”,
• “mainEntity”: [
• {
• “@type”: “Question”,
• “name”: “FAQ構造化データとは何ですか？”,
• “acceptedAnswer”: {
• “@type”: “Answer”,
• “text”: “FAQ構造化データとは、よくある質問と回答をJSON-LD形式で機械可読にマークアップしたものです。”
• }
• },
• {
• “@type”: “Question”,
• “name”: “設定するとリッチリザルトに表示されますか？”,
• “acceptedAnswer”: {
• “@type”: “Answer”,
• “text”: “2026年5月7日以降、FAQのリッチリザルトは表示されなくなりました。”
• }
• }
• ]
• }
• </script>

書き換える箇所と記載場所（head内・body内どちらでもOK）

書き換えるのは各Questionの”name”の値と、その直下にあるacceptedAnswerの”text”の値だけです。@type等の構造部分やカギ括弧の位置は変更しないことがポイントです。

記載場所についてはHTMLのhead内でもbody内でも構わないとされています（technical-seo.jp FAQ構造化データ解説）。WordPressなどのCMSであれば、テーマのheader.phpに直接記述するか、カスタムフィールドやプラグインからJSON-LDを出力する方法が一般的です。

回答文（text）で使えるHTMLタグ一覧

回答文のtextプロパティ内では、h1からh6、br、ol、ul、li、a、p、div、b、strong、iやemといったHTMLタグを使うことができ、箇条書きやリンクを含めた回答を書けます（technical-seo.jp FAQ構造化データ解説）。

ただし文字列としてエスケープする必要があるため、ダブルクオートは"や\”に置き換える点に注意が必要です。以下に主に使う要素をまとめます。

用途	使えるタグ	注意点
見出しを入れる	h1〜h6	回答内で多用しすぎない
改行する	br	連続使用は避ける
箇条書きを入れる	ol・ul・li	入れ子構造は崩さない
リンクを入れる	a	href属性の記述ミスに注意
強調する	b・strong・i・em	装飾目的の乱用は避ける

microdata形式との違い・JSON-LD推奨理由

microdata形式ではFAQPage、各FAQのQuestion、質問文のname、回答全体のAnswer、回答文のtextという5つの要素にitemscopeやitemprop属性を直接HTML要素へ付与します（デジタルアイデンティティ 構造化データ解説）。ページ本文のHTMLに属性を書き込む方式のため、既存のマークアップを壊しやすいというデメリットがあります。

一方JSON-LDはページ本文とは独立したスクリプトとして記述できるため、既存のデザインやHTML構造に影響を与えずに追加・削除ができます。この管理のしやすさから、多くの解説サイトでもJSON-LD形式が推奨されています。

実装後の検証方法と「表示されない」原因の切り分け

結論として、実装後はまずリッチリザルトテストかSchema Markup Validatorで構文エラーがないかを確認し、公開後はGoogleサーチコンソールのURL検査でクロール状況をチェックします。「表示されない」という悩みは構文エラー、未クロール、ページ内容との不一致、そして仕様上そもそも表示対象外という4つの原因に分けて考える必要があります。

リッチリザルトテストはURLを入力する方法とHTMLコードを直接貼り付ける方法の両方に対応しており、公開前のページでも検証が可能です（funbox FAQ構造化データ解説）。Schema Markup Validatorはschema.org公式の検証ツールで、FAQPage以外の構造化データも含めてより厳密にプロパティの整合性を確認できます。

TechSuite株式会社の「AI検索パートナーズ」は、自社サイトにおけるAI Share of Voiceを高水準に保っており、支援先ではAI Overviewの引用率を改善した実績があります。構造化データの検証を含む効果測定を継続的に行うことで、見た目の表示だけでなくAI経由の露出状況まで把握できる体制を整えています。

リッチリザルトテスト／Schema Markup Validatorの使い方

リッチリザルトテストは検証したいページのURLを入力するか、実装前のHTMLコードを直接貼り付けることでエラーの有無を確認できます。公開前にコードを貼り付けて検証できるため、本番環境に反映する前に構文ミスを見つけられる点が実務上のメリットです。

Schema Markup Validatorはschema.orgが提供する検証ツールで、Googleのリッチリザルトテストよりも広い範囲の構造化データ仕様に対応しています。両方のツールで確認しておくと、将来的に他の検索エンジンやAIサービスの仕様変更にも対応しやすくなります。

サーチコンソール（URL検査・検索パフォーマンス）でのモニタリング

公開後はGoogleサーチコンソールのURL検査ツールで、該当ページが正しくクロール・インデックスされているか、構造化データにエラーが出ていないかを確認できます（technical-seo.jp FAQ構造化データ解説）。

エラーが検出された場合はインデックス登録をリクエストして再クロールを促すことも可能です。検索パフォーマンスのレポートと合わせて見ることで、FAQページ全体のクリック状況も継続的に把握できます。

よくある構文エラー（末尾カンマ・コメント記述はNG）

JSONの記述ミスで最も多いのは、配列やオブジェクトの最後の要素の後ろに余分な「,」（カンマ）を残してしまうケースです（technical-seo.jp FAQ構造化データ解説）。また、JSONの仕様上「/* */」や「//」といったコメントの記述も認められていません。

次の表に、実装時に見落としやすい構文エラーをまとめます。公開前に一つずつ目視で確認しておくと、後からの修正コストを減らせます。

エラーの種類	具体例	対処法
末尾の余分なカンマ	最後の要素の後に「,」が残る	ブロックの最後はカンマなしにする
コメントの記述	// や /* */ を書き込む	JSON内にコメントは書かない
引用符の不統一	シングルクオートの混在	ダブルクオートに統一する
括弧の不一致	{}や[]の閉じ忘れ	検証ツールでエラー行を確認する

表示されない本当の原因（対象サイト制限・未クロール・不一致）

構文が正しくても表示されない場合、クローラーがまだページに到達していない、指定したFAQの内容がページ本文に表示されていない、あるいはFAQの数が過不足しているといった原因が考えられます（デジタルアイデンティティ 構造化データ解説）。旧仕様の目安ではFAQの数が2個以下または11個以上だと表示されにくいとされていました。

そして最も大きな前提として、2026年5月7日以降はどのサイトでもFAQのリッチリザルトは表示されません。表示不良のトラブルシューティングを行う前に、まずこの仕様変更を確認しておく必要があります。

ガイドライン違反にならないための注意点

結論として、構造化データで指定した質問と回答は、実際にページに表示されている内容と完全に一致させる必要があります。隠しテキストとしての利用、宣伝目的での利用、同一質問の重複マークアップはいずれもガイドライン違反にあたり、最悪の場合は検索順位への悪影響につながる可能性があります。

これらの注意点は表示終了後の現在でも変わらず有効です。構造化データはGoogleに送るデータの一種であるため、実際のコンテンツと異なる情報を送ってしまうと、スパムに近い扱いを受けるリスクが残ります。

TechSuite株式会社の「AI検索パートナーズ」は、業種や規模、商材ごとにガイドライン上のリスクの出方が異なることを踏まえ、サイトごとのコンテンツ構造や運用体制を確認したうえで、無理のない範囲での構造化データ運用を個別に設計し実行まで伴走しています。テンプレートを一律に当てはめるのではなく、各サイトの事情に合わせた運用ルールづくりを支援できる点が特徴です。

ページ表示内容と一致させる（隠しテキストNG）

構造化データに書いた質問と回答は、必ずページ本文にも同じ内容が表示されている状態にする必要があります（digital-marketing.jp FAQ構造化マークアップ解説）。CSSで非表示にしたテキストだけをマークアップに使う、いわゆる隠しテキストはガイドライン違反です。

アコーディオンなどで折りたたまれていても、ユーザーがクリックすれば表示される状態であれば問題ないとされています。完全に非表示のまま復元できないテキストを使わないことがポイントです。

宣伝目的で使わない・投稿型はQAPageを使う

キャンペーンの宣伝や商品の販促を目的とした質問文をFAQ構造化データとして使うことは、ガイドライン上推奨されていません。あくまで利用者が本当に知りたいであろう質問と、それに対する誠実な回答をセットにする必要があります。

また、コミュニティサイトのように1つの質問に複数のユーザーが回答する形式のページには、前述のとおりFAQPageではなくQAPageを使うことが適切です。よくある質問ページでQAPageを使ってしまう、逆にユーザー投稿型のページでFAQPageを使ってしまうといった取り違えにも注意が必要です。

同一質問の重複マークアップを避ける

同じ質問がサイト内の複数ページに掲載されている場合、サイト全体で1つのページだけに構造化データを付与し、他のページでは重複してマークアップしないことが推奨されています（digital-marketing.jp FAQ構造化マークアップ解説）。

下記のチェックリストを使って、公開前にガイドライン上の注意点を一通り確認しておくと安心です。

FAQリッチリザルト終了後も実装する意味はある？

結論として、検索結果の見た目という観点では実装する意味は薄くなりましたが、AIが学習・引用する一次情報としての価値は残っており、LLMOやAIOの観点では今も一定の実装意義があると考えられています。判断の軸を「リッチリザルトが出るか」から「AIに正しく読み取られるか」に切り替える必要があります。

もともと構造化データ自体はランキング要因ではなく、マークアップしても検索順位が直接上がるわけではないと説明されています（funbox FAQ構造化データ解説）。見た目（CTR）への影響が期待できた時期でも、あくまで間接的な効果にとどまっていた点は変わりません。

TechSuite株式会社の「AI検索パートナーズ」を通じた支援では、AI検索経由での受注率が従来のSEO経由の約3倍という結果が確認されており、露出や順位そのものではなく受注という成果に施策をつなげることを重視しています。FAQ構造化データも見た目の表示ではなく、AI経由での正確な引用や案件化にどう寄与するかという視点で位置づけることができます。

2023年8月〜2026年5月の仕様変更の経緯

2023年8月、Googleの公式ドキュメントにはFAQのリッチリザルトが「よく知られた信頼のおける政府機関および保健衛生関連のウェブサイト」にのみ表示されると明記されました（Google検索セントラル 構造化データの更新履歴）。この時点で一般企業のFAQはほぼ対象外になっていたことになります。

そして2026年5月7日、この機能自体のサポートが終了し、2026年6月には関連ドキュメントも削除されました。つまり現在は、対象サイトかどうかを問わず、FAQのリッチリザルトはすべてのサイトで表示されません。

構造化データはランキング要因ではない

構造化データを追加したこと自体が検索順位を直接押し上げる要因にはならないとされています。FAQ構造化データの価値は順位向上ではなく、コンテンツの意味を機械に正確に伝えることにあると理解しておく必要があります。

この理解がないと、「実装したのに順位が上がらない」という誤った期待とのギャップが生まれやすくなります。順位への影響を目的にするのではなく、後述するAI経由の価値を主目的に据えることが現実的な判断です。

LLMO/AIO・AI Overviews・Bing/Copilot・音声検索での価値

FAQ構造化データを実装する理由としては、AIへの学習データ提供、ハルシネーション（誤情報生成）の低減、PAA（他の人はこちらも検索）への好影響、Google以外のBingやCopilot、音声検索といったプラットフォームでの参照といった点が挙げられています（funbox FAQ構造化データ解説）。

これはLLMOやGEO、AIOと呼ばれるAI検索最適化の考え方と重なる部分が大きく、LLMOとは何かを理解しておくと、FAQ構造化データを含む一次情報設計の位置づけがつかみやすくなります。また、AI検索対策の進め方やAEOの基本と合わせて検討すると、FAQ構造化データを単独の施策ではなく全体戦略の一部として位置づけやすくなります。

実装すべきか？リソース配分の判断基準

実装可否は、CMSやプラグインで自動出力できるかどうか、そして対象ページが重要なLPや競合の多い記事かどうかで判断するのが現実的です（funbox FAQ構造化データ解説）。手動での実装工数が大きい一般記事に無理に時間をかけるより、コンテンツ品質そのものの向上にリソースを回す方が効果的な場合もあります。

状況	推奨度	理由
CMS/プラグインで自動出力できる	実装推奨	追加コストが小さく運用負担が少ない
重要LPや競合が多い記事	実装価値あり	AI経由の引用機会を確保しやすい
更新頻度の低い一般記事	優先度は中程度	効果と工数のバランスで判断
手動工数が非常に大きい記事群	優先度を下げても可	コンテンツ品質向上を優先しやすい

よくある質問

FAQ構造化データを設定すればリッチリザルトは表示されますか？

いいえ、2026年5月7日にGoogleがFAQのリッチリザルト機能のサポートを終了したため、現在は正しく設定してもリッチリザルトとしては表示されません。それ以前も表示対象は政府機関や保健衛生関連の信頼性の高いサイトに限定されていました。

FAQ構造化データを設定すると検索順位は上がりますか？

構造化データ自体は検索順位を直接決めるランキング要因ではないとされています。順位向上を直接の目的にするのではなく、AIによる内容理解の精度を高める目的で実装するのが現実的な考え方です。

WordPressでFAQ構造化データを実装する方法はありますか？

本記事のJSON-LDコードをテーマファイルに直接記述する方法のほか、構造化データ出力に対応したプラグインやカスタムフィールドを使って自動出力する方法があります。手動での書き換え工数を減らしたい場合は自動出力の仕組みを検討するとよいでしょう。

FAQPageとQAPageはどう使い分ければよいですか？

運営者が作成したよくある質問ページにはFAQPageを使い、1つの質問に複数のユーザーが回答できる投稿型のコミュニティページにはQAPageを使います。よくある質問ページでQAPageを使う必要はありません。

まとめ

FAQ構造化データの書き方は、JSON-LDの完成コードをコピペし、質問文と回答文だけを自社のQ&Aに書き換えて実装するというシンプルな作業です。一方で2026年5月7日にリッチリザルト表示が終了したため、検索結果の見た目を目的にした実装意義は薄れています。

これからはランキング要因ではないという前提を踏まえつつ、AIへの一次情報提供やLLMO・AIO観点での価値を主な目的として、CMSでの自動出力可否や対象ページの重要度に応じてリソースを配分することが現実的な進め方です。実装後はリッチリザルトテストやサーチコンソールで構文エラーとクロール状況を確認し、ガイドライン違反にならないよう運用を続けることが大切です。

参考にした情報源

• デジタルアイデンティティ よくある質問（FAQ）の構造化データ解説
• technical-seo.jp FAQ構造化データの書き方解説
• digital-marketing.jp FAQ構造化マークアップ解説
• funbox FAQ構造化データ解説（実装すべき理由と戦略判断）
• Google検索セントラル 構造化データの更新履歴