コラムのイメージ画像

ホームページ制作・運用コラム COLUMN

AIO対策SEO対策

Article JSON-LDの設定と最適化 SEO・AIO対策に効く構造化データ実践法

Article JSON-LDの設定と最適化 SEO・AIO対策に効く構造化データ実践法

「記事ページに構造化データを実装しているのに、なぜGoogle AIの回答に引用されないのだろう」とお悩みの担当者の方は少なくありません。構造化データの中でも、記事コンテンツに対して使用するArticle構造化データ(Article schema)は、設定方法を誤ると検索エンジンにまったく評価されないケースがあります。

本記事では、Article構造化データの基本からBlogPostingとNewsArticleの使い分け、JSON-LD形式での具体的な実装方法、そしてAIO(AI Overview)に引用されるための最適化手順まで、Webサイト担当者が実務で使える形で体系的に解説します。

この記事でわかること

  • Article構造化データ(Article schema)とは何か、なぜ重要なのか
  • Article・BlogPosting・NewsArticleの違いと使い分けの基準
  • JSON-LD形式での実装コード例と各プロパティの役割
  • WordPressでのArticle schema設定方法
  • AIO(AI Overview)評価を高めるための最適化ポイント
  • リッチリザルト検証ツールを使った動作確認の手順

1. Article構造化データとは何か

1-1. Article schemaの定義

Article構造化データとは、Webページ上の記事コンテンツをGoogleなどの検索エンジンが機械的に理解できる形式で記述するためのマークアップです。schema.orgで定義されたArticle型を用いて、記事タイトル(headline)・著者情報(author)・公開日(datePublished)・更新日(dateModified)・サムネイル画像(image)・発行者情報(publisher)などを構造化データとして記述します。

たとえば、ある医療機関のコラムページに「糖尿病の食事療法について」という記事があったとします。HTMLテキストとして書かれた内容は、検索エンジンから見れば単なる文字列の集合にすぎません。しかしArticle schemaを実装することで、「この記事の著者は山田医師であり、2026年3月に更新された専門的なコンテンツである」という意味情報を機械が読み取れる形で提供できます。これにより、検索エンジンがコンテンツの信頼性・専門性・鮮度をより正確に評価できるようになります。

1-2. Article schemaがSEO・AIO対策で重要な理由

Article構造化データがSEO・AIO対策において重要な理由は、大きく3点あります。

第一は、リッチリザルト(強調表示)の獲得可能性です。Articleスキーマを正しく実装することで、Googleの検索結果にサムネイル画像付きの記事カードや著者名・更新日などの付加情報が表示されるリッチリザルトが表示される可能性が高まります。リッチリザルトはクリック率(CTR)の向上に直結します。

第二は、AIO(AI Overview)への引用率向上です。GoogleのAIは、コンテンツの著者情報・更新日・出典元などが構造化されたページを信頼性の高い情報源として判断しやすい傾向があります。構造化データが整備されたページは、AI回答の引用元として選ばれる可能性が高まります。

第三は、E-E-A-T(経験・専門性・権威性・信頼性)の可視化です。著者のプロフィールページへのリンク(author.url)や所属組織(author.affiliation)を構造化データで明示することで、コンテンツの専門性・信頼性をGoogleに伝えやすくなります。

AI検索時代における構造化データ全般の役割については、「SEOだけでは通用しない?AI検索時代に勝つホームページ戦略」で体系的に解説しています。あわせてご参照ください。

2. Article・BlogPosting・NewsArticleの違いと使い分け

2-1. 3つのスキータイプの位置づけ

schema.orgにおけるArticleは、BlogPostingとNewsArticleの親型(スーパータイプ)です。3つの型はいずれも記事コンテンツを表しますが、それぞれコンテンツの性質・目的・対象に応じて使い分けが必要です。2026年時点でのGoogleの仕様を踏まえた整理を以下に示します。

Article:あらゆる記事コンテンツに対応する汎用型です。BlogPostingやNewsArticleのどちらにも該当しない記事、または分類に迷う場合のフォールバックとして使用します。技術解説記事・事例紹介・ホワイトペーパーなど、ブログとも速報ニュースとも言い難いコンテンツに適しています。

BlogPosting:ブログ形式のコンテンツに対して使用するArticleのサブタイプです。コーポレートサイトやサービスサイトのコラム記事、個人ブログ、ハウツー記事などに最適です。Googleはリッチリザルトの文脈で、BlogPostingをArticleと同等に扱います。コンテンツの性質がブログに近い場合はArticleよりBlogPostingが推奨されます。

NewsArticle:時事的なニュース記事を対象としたサブタイプです。Top Storiesカルーセル(Googleのニューストップ面)への掲載資格を持ちますが、適用できるのはGoogleが認定するニュースパブリッシャーに限られます。また、時事性のあるコンテンツに限定されるため、エバーグリーンコンテンツ(長期間価値が変わらないコンテンツ)には不適切です。

2-2. コンテンツタイプ別の選択基準

実務での判断基準を整理すると以下のようになります。企業のコーポレートサイトやサービスサイトのコラムページには、原則としてBlogPostingを使用するのが適切です。ニュースリリースや速報性の高い告知記事には、報道機関であればNewsArticleを、一般企業であればArticleまたはBlogPostingを使用します。事例紹介・技術解説・業界動向分析などの専門記事にはArticleまたはBlogPostingが適しており、コンテンツの性質に合わせて選択します。

なお、BlogPostingはArticleを継承(サブタイプ)しているため、BlogPostingを使用するとArticleの要件も自動的に満たされます。同じページに対してArticleとBlogPostingを二重に設定する必要はなく、最も具体的なタイプを1つ選択することがGoogleの推奨事項です。

2-3. 2026年時点のリッチリザルト適用条件

2026年3月時点の情報として、Articleリッチリザルト(サムネイル付き記事表示)の獲得には、headline・author・datePublished・imageの4プロパティが必須です。特にimageは幅1200ピクセル以上の高解像度画像が求められており、この要件を満たさない場合、スキーマのコードは有効でもリッチリザルトは表示されません。

FAQリッチリザルトについては、2026年3月のアップデートにより、一般的な記事内のFAQセクションへのリッチリザルト適用が廃止されました。FAQリッチリザルトが引き続き有効なのは、FAQコンテンツを主目的としたページに限られます。これはArticle schemaにFAQPageスキーマを組み合わせる「スキーマスタッキング」戦略に影響するため、設計段階で考慮が必要です。

3. Article構造化データのJSON-LD実装方法

3-1. JSON-LDを選択する理由

構造化データの記述形式にはJSON-LD・Microdata・RDFaの3種類がありますが、現在Googleが最も強く推奨しているのがJSON-LD(JSON for Linking Data)形式です。JSON-LDはHTMLのheadタグ内にscriptタグとして記述するため、既存のHTMLコードとは完全に分離して管理できます。デザインや本文のHTMLを変更しても構造化データに影響が出ない保守性の高さが最大のメリットです。

また、GTM(Googleタグマネージャー)経由でJSON-LDを注入するケースがありますが、これはクライアントサイドレンダリングとなり、Googleのクローラーが最初のHTML取得時に構造化データを読み取れない可能性があります。リッチリザルトの表示には、HTMLソースに直接記述するサーバーサイドでの実装が推奨されます。

3-2. BlogPostingスキーマの基本実装コード

以下は、企業コラム記事に対して推奨するBlogPosting schemaのJSON-LD実装例です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "記事タイトル(110文字以内)",
  "description": "記事の概要文(メタディスクリプションと同一でも可)",
  "image": {
    "@type": "ImageObject",
    "url": "https://example.com/images/article-thumbnail.jpg",
    "width": 1200,
    "height": 630
  },
  "datePublished": "2026-04-01T09:00:00+09:00",
  "dateModified": "2026-04-15T12:00:00+09:00",
  "author": {
    "@type": "Person",
    "name": "著者名",
    "url": "https://example.com/author/profile/",
    "affiliation": {
      "@type": "Organization",
      "name": "株式会社サンプル"
    }
  },
  "publisher": {
    "@type": "Organization",
    "name": "株式会社サンプル",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png",
      "width": 600,
      "height": 60
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/column/article-slug/"
  }
}
</script>

3-3. 各プロパティの役割と設定のポイント

@context と @type:「https://schema.org」をコンテキストとして宣言し、コンテンツに合ったスキーマ型を指定します。コーポレートサイト・サービスサイトのコラム記事であれば「BlogPosting」が適切です。

headline(必須):記事のタイトルを記述します。110文字以内に収める必要があり、ページのH1・titleタグと一致または近い内容にします。スキーマ上のheadlineとページ上の表示タイトルが大きく異なる場合、Googleがスパム的な構造化データとみなすリスクがあります。

image(リッチリザルト取得に必須):幅1200ピクセル以上の画像URLを指定します。ImageObjectとしてurl・width・heightを明示することが推奨されます。画像が存在しない、または小さすぎる場合はリッチリザルトが表示されません。

datePublished・dateModified(必須):ISO 8601形式(例:2026-04-01T09:00:00+09:00)で記述します。dateModifiedは実際にコンテンツを更新した日付に合わせて正確に記述することが重要です。コンテンツを更新した際には必ずdateModifiedも更新してください。

author(必須):著者をPersonまたはOrganization型で記述します。Personの場合は著者のプロフィールページへのURL(url)と所属組織(affiliation)を加えることで、E-E-A-T(経験・専門性・権威性・信頼性)の評価向上に貢献します。著者プロフィールページにも対応するPersonスキーマを実装することで相互参照の関係が構築できます。

publisher(推奨):発行組織をOrganization型で記述し、ロゴ画像を含めます。ロゴはImageObjectとしてurl・width・heightを指定します。publisherのnameはOrganizationスキーマと一致させることでGoogleの知識グラフとの紐づけが強化されます。

mainEntityOfPage(推奨):このコンテンツが掲載されているWebページのURLをWebPage型で指定します。ページのcanonical URLと一致させることが原則です。

description(推奨):記事の概要文を記述します。メタディスクリプションと同一内容でも問題ありません。AIが記事の内容を把握する際の補助情報として機能します。

4. WordPressでのArticle schema設定方法

4-1. SEOプラグインを活用した自動設定

WordPressでArticle構造化データを実装する方法として、最もコストが低いのがSEOプラグインを活用した自動設定です。Yoast SEOやRank Mathといった代表的なWordPress SEOプラグインは、投稿記事に対して自動的にArticle(またはBlogPosting)スキーマを出力する機能を持っています。

Yoast SEOでは、投稿の編集画面内のYoastパネルから「スキーマ」タブを選択し、コンテンツの種類(記事・ブログ投稿など)と著者の役割を設定できます。Rank Mathでは、投稿ごとに「スキーマ」タブから詳細なスキーマタイプを選択し、必要なプロパティを個別に設定できます。いずれのプラグインも、headline・datePublished・dateModified・publisher・imageなどの主要プロパティを投稿データから自動で取得し、JSON-LDを生成します。

これらのプラグインを使用する際の注意点として、自動生成された構造化データが実際のページコンテンツと一致しているかどうかを定期的にGoogleのリッチリザルトテストで検証することが重要です。プラグインの設定ミスや、テーマ側のテンプレートとの競合により、意図しない構造化データが出力されるケースがあります。

4-2. カスタムコードによる実装

プラグインの自動出力では細かい制御が難しい場合は、functions.phpやカスタムプラグインを使ってJSON-LDを直接出力する方法が有効です。PHPでwp_headフックを使い、投稿の情報を動的に取得してJSON-LD形式で出力します。

たとえば製造業のWebシステムを運用している企業が、製品技術解説記事ページに著者プロフィールと詳細な組織情報を含む構造化データを実装したい場合、プラグインの標準機能では対応しきれないプロパティ(author.affiliationの詳細設定や、複数の著者指定など)をカスタムコードで補完することで、より精度の高い構造化データを実現できます。

4-3. GTM経由の実装における注意点

GTM(Googleタグマネージャー)を使ってJSON-LDを注入する方法は、手軽ではありますが、いくつかの重要なリスクを伴います。GTM経由の実装はJavaScriptを通じてクライアントサイドで動作するため、Googleのクローラーが最初にHTMLを取得した時点では構造化データが存在しません。Googleのレンダリングパス(クローラーがJavaScriptを実行する段階)でのみ認識されるため、リッチリザルト表示のタイミングが遅延する可能性があります。

特にBlogPostingやNewsArticleなど時事性の高いコンテンツでは、公開直後にリッチリザルトが表示されないとSEO上の機会損失につながります。Article構造化データはHTMLのheadタグ内に直接記述することを原則とし、GTM経由の実装は最終手段として位置づけてください。

5. AIO(AI Overview)評価を高めるArticle schemaの最適化

5-1. 著者情報の充実がAIO引用率に与える影響

AIOに引用されやすいコンテンツの条件として、著者の専門性・信頼性が明確であることが挙げられます。Article schemaにおいてauthor.urlで著者プロフィールページへのリンクを設定し、そのプロフィールページにもPersonスキーマを実装することで、「この記事を書いた人物は誰か」という情報をGoogleが機械的に把握できるようになります。

さらに、author.affiliationで所属組織を明示し、そのOrganizationの公式サイトURLをsameAsプロパティで紐づけることで、著者と組織の関係性が構造化データ上で可視化されます。たとえば不動産業の企業サイトであれば、宅地建物取引士の資格保有者が執筆した市場分析記事において、著者のプロフィールページへのリンクと所属組織情報を明示することで、専門性の証明が強化されます。

5-2. dateModifiedの更新によるコンテンツの鮮度管理

AIOに引用されるコンテンツの重要な条件として、情報の鮮度があります。過去に公開された記事であっても、定期的に内容を見直し・更新したうえでdateModifiedを適切に更新することで、Googleはそのページを「最新情報を提供しているページ」として評価します。

ある調査では、直近30日以内に更新されたコンテンツはAIによる引用頻度が大幅に高くなることが示されています。Article schemaのdateModifiedは、実際に本文を更新した日付に合わせて変更することが必須です。ページ内容を変更せずにdateModifiedだけを更新する行為はGoogleのガイドライン違反となるため注意が必要です。

5-3. headlineプロパティの最適化

Article schemaのheadlineは、Googleが記事の主題を把握するうえで最も直接的な情報源です。headlineには記事の主要キーワードを自然な形で含め、ユーザーの検索意図と一致する表現を使うことが重要です。

headline は110文字以内という上限があります。ページのtitleタグやH1と内容が一致していることが原則であり、スキーマ上のheadlineとページ上の表示見出しが大幅に異なる場合、Googleがミスマッチな構造化データとして処理しリッチリザルトが無効化されるリスクがあります。制作会社のWebサイトや金融機関のコラムページなど、長い記事タイトルを持つページでは、特にこの110文字制限に注意が必要です。

5-4. Article schemaとFAQPageスキーマの組み合わせ

「スキーマスタッキング」と呼ばれる手法として、BlogPosting schemaとFAQPage schemaを1つのページに組み合わせて実装することで、記事本体の情報とQ&A情報の両方を構造化データとして提供できます。これにより、Googleは「このブログ記事は特定の質問にも答えている」という情報を構造化データから直接把握できます。

ただし、2026年3月のGoogleアップデート以降、一般的な記事内のFAQセクションに対するFAQリッチリザルト(検索結果での展開表示)は廃止されています。FAQPageスキーマを実装することはAIOへの情報提供という観点では有効ですが、リッチリザルトの表示を期待する場合は、FAQコンテンツが主目的のページに限って適用することが推奨されます。

5-5. speakableプロパティの活用

speakableプロパティは、音声検索やスマートスピーカーが読み上げるべきコンテンツ箇所を指定するプロパティです。現時点ではGoogleによる公式サポートは限定的ですが、AIアシスタントが音声で情報を提供する場面での活用が将来的に拡大する可能性があります。記事内でとりわけ重要な定義文や結論箇所をCSSセレクターまたはXPathで指定しておくことで、音声検索・AI音声応答での引用精度が高まる可能性があります。

6. 実装後の検証と継続管理

6-1. Googleリッチリザルトテストによる検証

Article構造化データを実装した後は、必ずGoogleが提供するリッチリザルトテスト(Rich Results Test)で検証を行います。リッチリザルトテストには実装済みのページURLを入力するか、コードを直接貼り付けて使用します。エラー・警告の有無、リッチリザルトの適格性の確認が行えます。

主なチェックポイントは次のとおりです。「headline」「author」「datePublished」「image」の4必須プロパティが設定されているか。imageの幅が1200ピクセル以上か。headlineがページの表示タイトルと一致しているか。著者のURLが実在するページに向いているか。これらをすべてクリアしていれば、リッチリザルトの適格性があると判定されます。

6-2. Google Search Consoleでの監視

リッチリザルトテストで問題がなくても、実際にGoogleがページをクロール・インデックスした後に構造化データの処理エラーが発生するケースがあります。Google Search Consoleの「拡張機能」セクションにある「記事」レポートでは、Googleが検出したArticle構造化データのエラー・警告・有効件数を確認できます。

特に注意が必要なのは、ページを大規模に更新した後や、CMSのテンプレートを変更した後です。こうした変更によって構造化データが意図せず削除・変形されるケースがあるため、Search Consoleを定期的に確認する運用フローを整備することが重要です。

6-3. よくある実装ミスと対処法

Article構造化データの実装でよく見られるミスとその対処法を整理します。

ミス1:headlineがページのH1と大きく異なる。対処法:headlineとH1の内容を一致させる、または表現を近づける。スキーマのheadlineはページ上で視覚的に確認できるタイトルと対応している必要があります。

ミス2:imageに指定したURLが存在しない(404エラー)、または画像サイズが小さい。対処法:絶対URLで1200px以上の画像を指定し、URLの有効性を確認する。相対パスはJSON-LD内では無効です。

ミス3:dateModifiedを更新せず古い日付のまま放置している。対処法:記事を更新するたびにdateModifiedを実際の更新日に書き換える運用ルールを設ける。

ミス4:同一ページにArticleとBlogPostingを二重に設定している。対処法:より具体的なBlogPostingのみ残し、Articleを削除する。

ミス5:GTM経由でJSON-LDを注入しているため、クロール時に構造化データが読み取れない。対処法:HTMLのheadタグ内にサーバーサイドで直接出力する方式に変更する。

7. まとめ

Article構造化データ(Article schema)は、Webサイトのコラム記事・ブログ投稿に対してSEO・AIO両面で効果的な技術施策です。JSON-LD形式でBlogPosting型を使用し、headline・author(プロフィールページへのURL・所属組織を含む)・datePublished・dateModified・imageの各プロパティを正確に記述することが基本です。

実装後はGoogleリッチリザルトテストとSearch Consoleで定期的に検証を行い、コンテンツ更新のたびにdateModifiedを更新する運用フローを整えることが、持続的なSEO・AIO効果につながります。特にAIOへの引用率向上を目指すなら、著者情報の充実・headlineの最適化・コンテンツの定期的な鮮度更新の3点が重要なアクションポイントです。

フォー・クオリアは、20,000件以上のWebサイト制作実績を持ち、製造業・金融・不動産・教育・官公庁など幅広い業界のホームページ制作・運用を手がけています。Article構造化データをはじめとする構造化データの実装設計から、SEO・AIO対策を組み込んだコンテンツ戦略の立案まで、技術とSEOを両立したWebサイト制作・運用改善のご支援が可能です。「自社サイトの記事がAIに引用されるようにしたい」「構造化データの実装状況を見直したい」といったご要望がございましたら、ぜひお気軽にご相談ください。

 まずはお気軽に
ご相談ください