日名開発
中文相談する

JSON-LD（構造化データ）実用入門。FAQ が消えた 2026 年に、何を入れて何を捨てるか

公開

2026 年 5 月 7 日、Google は FAQ リッチリザルトの表示を終了しました。それでも「構造化データ」で検索して出てくる日本語記事の多くは、いまも FAQPage の実装を勧めています。制作会社に「構造化データは入れてあります」と言われた担当者が Search Console を開いても何も変わっていない理由は、だいたいここにあります。

この記事では schema.org の全部を説明しません。2026 年に中小企業のサイトへ入れる価値が残っている型を 3 つに絞り、コピペできる JSON-LD と、現場で実際に起きる事故、検証の手順を書きます。

JSON-LD とは何か

構造化データは、ページの内容を検索エンジンが読める形で添える注釈です。語彙は schema.org、書き方は JSON-LD、microdata、RDFa の 3 つがあります。Google は JSON-LD を推奨しています。

一般的に、Google はサイトの設定で許容されている限り、JSON-LD を構造化データに使用することを推奨します。 （Google 検索セントラル「構造化データの仕組みについて」）

HTML の中に、こういう <script> を 1 つ置くだけです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "日名開発",
  "url": "https://hinadev.com/"
}
</script>

順位には直接効きません。 Google 自身が 2020 年に「構造化データはそれ自体ではランキング要因ではない」と書いています。効くのは、検索結果の見た目（リッチリザルト）と、Google がページや会社を取り違えなくなること。この 2 点だけです。

2026 年に消えた型、残っている型

消えたものを知らないまま作業すると、誰にも読まれないマークアップを書くことになります。

時期 何が起きたか
2023 年 8 月 FAQ リッチリザルトを政府と医療系の権威サイトに限定。HowTo をモバイルで終了
2023 年 9 月 HowTo をデスクトップでも終了、非推奨に
2024 年 11 月 サイトリンク検索ボックスを終了
2025 年 6 月 Book Actions、Course Info、Claim Review、Estimated Salary、Learning Video、Special Announcement、Vehicle Listing の 7 種類を段階的に終了
2026 年 5 月 7 日 FAQ リッチリザルトを全サイトで終了。6 月にドキュメントも削除

出典はすべて Google 検索セントラルのブログと更新履歴で、記事末尾にまとめています。

Google はどの発表でも「マークアップを消す必要はない」と書いています。放置して減点されることはありません。ただ、新規で入れる理由もありません。2026 年に「FAQPage を入れると AI 検索に引用されやすい」と勧める記事には、根拠がありません。 Google は AI 機能向けの特別な構造化データは不要だと明言しています（後述）。

正直に書くと、このサイトのトップと /ja/seo にも FAQPage が入っています。2026 年 5 月以降は何も表示されません。消すか迷いましたが、見えている Q&A をそのまま写しているだけで害がないので、そのままにしています。

残す価値があるのは 3 種類

中小企業のコーポレートサイトなら、次の 3 つで足ります。

  1. BreadcrumbList（パンくず）。 検索結果の URL 表示が階層名に変わります。2025 年 1 月からデスクトップ限定になりましたが、実装コストがほぼゼロです。
  2. Article（BlogPosting）。 お知らせやブログがあるなら。日付と著者を Google に正しく伝えるのが主な役目です。Top stories に出るための必須条件ではありません。
  3. Organization または LocalBusiness。 会社情報の名寄せ用です。ロゴやナレッジパネルの表示にも使われます。

Organization と LocalBusiness、どちらか

判断基準は 1 つです。お客様が来店する住所があるかどうか。

  • 店舗、クリニック、事務所に人が来る。LocalBusiness にして、Dentist や Restaurant など一番具体的なサブタイプを使います。必須プロパティは name と address の 2 つだけです。
  • 来店しない（受託開発、EC、SaaS）。Organization です。
  • 自宅を拠点にしている。Organization にして、住所は書きません。Google ビジネスプロフィールのガイドラインが自宅住所を載せないよう求めているのと同じ考え方です。

Organization は全ページに入れる必要はありません。Google は「ホームページか、会社概要のような単一のページ」への設置を推奨しています。

このサイトは個人事業なので、Organization ではなく Person を全ページに出しています。福岡で仕事をしていることを、文章だけでなく機械が読める形でも残しておきたいからです。実物を貼ります。

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Kalan (陳 愷開)",
  "jobTitle": "Freelance Software Engineer",
  "url": "https://hinadev.com/",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "福岡市",
    "addressRegion": "福岡県",
    "addressCountry": "JP"
  },
  "knowsLanguage": ["ja", "zh-Hant", "en"],
  "sameAs": ["https://github.com/kjj6198", "https://zenn.dev/kalan"]
}

コピペして使える 3 型の例

福岡市の架空の会社「株式会社サンプル」の、お知らせ記事ページ 1 枚分です。3 つの型を @graph で 1 つの <script> にまとめ、@id で会社情報を参照しています。会社情報を 2 回書かずに済み、値の食い違いも起きません。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.example.com/#organization",
      "name": "株式会社サンプル",
      "url": "https://www.example.com/",
      "logo": "https://www.example.com/logo.png",
      "address": {
        "@type": "PostalAddress",
        "addressLocality": "福岡市",
        "addressRegion": "福岡県",
        "addressCountry": "JP"
      },
      "sameAs": ["https://www.linkedin.com/company/example"]
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "ホーム", "item": "https://www.example.com/" },
        { "@type": "ListItem", "position": 2, "name": "お知らせ", "item": "https://www.example.com/news/" },
        { "@type": "ListItem", "position": 3, "name": "新オフィス移転のお知らせ" }
      ]
    },
    {
      "@type": "BlogPosting",
      "@id": "https://www.example.com/news/office-move/#article",
      "mainEntityOfPage": "https://www.example.com/news/office-move/",
      "headline": "新オフィス移転のお知らせ",
      "image": "https://www.example.com/images/office-1200x675.jpg",
      "datePublished": "2026-09-01T10:00:00+09:00",
      "dateModified": "2026-09-15T14:30:00+09:00",
      "author": { "@id": "https://www.example.com/#organization" },
      "publisher": { "@id": "https://www.example.com/#organization" }
    }
  ]
}
</script>

読むときの注意点は 3 つです。

  • 日付は +09:00 まで書きます。Google は「タイムゾーン情報を提供することをおすすめします」と書いていて、省くと Googlebot 側のタイムゾーンで解釈されます。
  • image と logo は絶対 URL で、クロールできる場所に置きます。ロゴは 112 × 112 px 以上が条件です。
  • @graph は Google のドキュメントに説明がありませんが、JSON-LD の標準機能です。WordPress の Yoast SEO もこの形で出力しています。

現場で起きる事故 5 つ

技術 SEO の調査で構造化データを見ると、書き方の間違いより、こちらのほうが多く見つかります。

1. 同じ型が二重に出ている

WordPress で一番多い事故です。Cocoon や SWELL などのテーマがパンくずを出しているところに All in One SEO を入れると、BreadcrumbList が 2 本になります。Shopify のテーマと構造化データアプリの組み合わせでも同じことが起きます。2 本の値が食い違うと、Google はどちらを信じるか決められません。

直し方は単純で、ページのソースで ld+json を検索し、型ごとに 1 本になるまで片方を止めます。Yoast は自前のプラグイン側の出力を止めて Yoast のグラフに統合するよう案内しています。

2. ページに見えない内容を書いている

ページの読者に表示されないコンテンツをマークアップしないでください。 （Google 検索セントラル「構造化データに関する一般的なガイドライン」）

表示していないレビュー、折りたたみもされていない Q&A、ページに載っていない住所。文法が正しくても、手動による対策の対象になり、そのページはリッチリザルトに出なくなります。

3. 日付がずれている

Google は「ユーザーに表示される日付と構造化データの日付を一致させる」ことを求めています。ページに「2026 年 9 月 1 日」と出ていて、JSON-LD が 9 月 2 日なら、どちらも信用されません。

内容を変えずに dateModified だけ毎週更新するのも同じです。表示と一致しなくなった時点で、日付そのものが使われなくなります。

4. JavaScript で後から差し込んでいる

Google はレンダリング後の DOM を読むので、JavaScript で挿入した JSON-LD も認識します。ただしレンダリングはキューに入り、Google 自身が「数秒で済むこともあれば、もっとかかることもある」と書いています。Google 以外のクローラーが JavaScript を実行する保証はありません。

Next.js や Astro を使っているなら、サーバー側で HTML に出します。Next.js の公式ガイドはこの形です。

<script
  type="application/ld+json"
  dangerouslySetInnerHTML={{
    __html: JSON.stringify(jsonLd).replace(/</g, '\\u003c'),
  }}
/>

replace があるのは、文字列に </script> が混ざると script タグが途中で閉じ、ページが壊れるか XSS になるからです。Astro は set:html={JSON.stringify(jsonLd)} で出せますが、set:html はエスケープしないので同じ対策が要ります。

5. JSON として壊れている

末尾のカンマ、シングルクォート、コメント。この 3 つで Search Console の「解析不能な構造化データ」レポートに出ます。注意したいのは、リッチリザルト テストがコメントを無視して通してしまうことです。テストで緑でも、本番の Googlebot は読めません。

検証の手順

順番に 3 つ使います。

  1. リッチリザルト テスト。 URL を入力します。コード貼り付けは JavaScript の制限があるので、公開後は URL で試します。判定するのは Google がリッチリザルトを出せる型だけです。
  2. Schema Markup Validator（validator.schema.org）。 schema.org としての文法チェック。Person のように Google のリッチリザルト対象外の型はこちらで確認します。
  3. Search Console の「拡張」レポート。 公開後、本番で Google が実際に読んだ結果です。反映まで数日から数週間かかります。

旧「構造化データ テストツール」は 2020 年に終了しています。まだ紹介している記事は、それ以降更新されていません。

AI 検索と構造化データ

「AI に引用されるための構造化データ」を売る営業には、Google のこの一文を見せてください。

AI による概要や AI モードにコンテンツが表示されるための追加の要件はなく、別途特別な最適化を行う必要もありません。（中略）特別な schema.org の構造化データを追加する必要もありません。 （Google 検索セントラル「AI 機能とウェブサイト」）

構造化データは、通常の SEO の一部として正しく入っていれば十分です。AI 向けに型を増やす必要はありません。

自分でやるか、頼むか

自分でできる範囲は広いです。WordPress、STUDIO、Shopify なら、テーマかアプリの設定で 3 型が出ていることを確認し、二重出力を止めれば終わります。

頼んだほうが早いのは、次の場合です。

  • Next.js や Astro で組んでいて、サーバー側の出力に組み込みたい
  • 日本語と中文、English を持っていて、hreflang とセットで設計したい
  • CMS の出力と手書きが混在して、どれが生きているか分からなくなっている

私は記事を書きません。書いた記事が Google に正しく評価される状態をつくるのが仕事です。コーポレートサイトを新規で作る場合は、料金ページの 60 万円〜のプランに構造化データ、OG 画像、sitemap まで含めています。

10 分でできること

いま自社サイトのソースを開いて、ld+json で検索してください。

  • 0 件なら、この記事のサンプルから BreadcrumbList だけでも入れる価値があります。
  • FAQPage と HowTo しかなければ、2026 年の検索には何も届いていません。
  • 同じ型が 2 本以上あれば、それが Search Console に何も出ない理由です。

出典

関連記事

ブログ一覧へ