Article・BlogPosting schemaの書き方ガイド

いま読んでいるこのページにも、Article構造化データが埋め込まれています。ブラウザでソースを表示しapplication/ld+jsonで検索すれば、実物を確認できます。本記事は、Google公式ドキュメントとschema.orgにもとづく実装手順に加えて、このメディア自身がなぜその書き方を選んだのかまで開示します。

01この記事でわかること

• Article・NewsArticle・SocialMediaPosting・BlogPostingの継承関係と使い分け
• 必須プロパティが存在しないという前提と、推奨プロパティの実装例
• 複数著者を指定する際の正しい書き方
• 本メディア自身のArticle実装と、そこで下した3つの判断
• 実装後の検証と、公開後に崩れやすいdateModifiedの運用

03Article・BlogPosting schemaとは（基礎定義）

schema.orgの定義では、Article型は「ニュース記事や調査報告書など、様々なタイプの記事」を表す型です(出典: schema.org/Article)。継承構造はThing > CreativeWork > Articleです。Article直下のサブタイプにはNewsArticleやSocialMediaPostingなどがあります。

企業ブログの記事にはBlogPostingを、報道機関のニュース記事にはNewsArticleを使うのが一般的です。なおBlogPostingはArticleの直下ではなく、Article > SocialMediaPosting > BlogPostingという階層に位置します。

04推奨プロパティ5項目と、最小構成のテンプレート

Google公式ドキュメントは「There are no required properties」と明記しています。そのうえで、該当するプロパティを追加するよう案内しています。推奨プロパティの主要な5項目は次のとおりです(authorにはauthor.name・author.urlも推奨されています)。

以下は、企業ブログの記事を想定したBlogPostingのテンプレートです。

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "記事のタイトルをここに入力",
  "image": "https://sample.example.com/images/article-thumbnail.jpg",
  "author": {
    "@type": "Person",
    "name": "山田太郎",
    "url": "https://sample.example.com/author/yamada-taro"
  },
  "publisher": {
    "@type": "Organization",
    "name": "株式会社サンプル",
    "logo": {
      "@type": "ImageObject",
      "url": "https://sample.example.com/images/logo.png"
    }
  },
  "datePublished": "2026-07-28",
  "dateModified": "2026-07-28"
}

headlineは、長すぎるとデバイスによって途中で切り詰められる可能性があります。具体的な文字数上限はGoogle公式ドキュメントに明記されていません。簡潔なタイトルにすることが推奨されています。

著者情報をさらに詳しく実装したい場合は、別記事『著者Person schemaの書き方とE-E-A-T効果』のテンプレートを参照してください。組織全体の情報を伝えるOrganization schemaは、別記事『Organization schemaの書き方｜企業情報の伝え方』で解説しています。

05複数著者の指定方法

記事に複数の著者がいる場合、書き方を誤ると片方しか認識されないことがあります。Google公式ドキュメントは、著者ごとに独立したオブジェクトを配列で並べる書き方を示しています。

"author": [
  { "@type": "Person", "name": "著者1の氏名" },
  { "@type": "Person", "name": "著者2の氏名" }
]

複数著者の氏名を1つのnameフィールドにカンマ区切りでまとめる書き方は、推奨されていません。著者ごとにオブジェクトを分けて、配列に並べてください。

06本メディア自身のArticle実装｜3つの判断

型の使い分けに公式の正解がない以上、参考になるのは他サイトの実際の選択と、その理由です。ここではこのメディアの実装を開示します。

構造化データは「良さそうな値」ではなく「実態と一致する値」を書く場所です。この原則は、Googleの構造化データ全般のガイドラインが繰り返し求めている点でもあります。存在しない個人著者名を置いてE-E-A-Tを演出するより、編集部という実在の主体を正確に書くほうが筋が通ります。

記名著者を立てている媒体であれば、判断は逆になります。その場合のPerson実装は、別記事『著者Person schemaの書き方とE-E-A-T効果』を参照してください。

AI検索での引用との関係

ここで期待値を正しておきます。Article schemaを実装すればAI検索に引用されやすくなる、という因果関係は現時点で証明されていません。SSRNで公開された検証論文では、構造化データの有無とAI引用の関連は交絡要因の補正後に統計的に消えています。詳細は別記事『Schema markupとAI引用の相関｜SSRN論文検証』で扱っています。

そのうえで、Article schemaを書く実務的な意味は残ります。著者・公開日・更新日という「誰がいつ書いたか」の情報を、本文とは別に機械可読な形で置いておくこと自体が目的です。引用率を上げる施策としてではなく、記事の素性を明示する土台として実装してください。

07実装後の検証と、dateModifiedの運用

実装作業そのものより崩れやすいのは、公開後の運用です。まず公開前にリッチリザルトテスト(search.google.com/test/rich-results)へURLまたはコードを入力し、検出された型とエラー・警告を確認します。エラーが出た場合は、該当プロパティ名とJSON構文のカンマ・括弧の過不足を見直してください。ツールの詳しい使い方は、別記事『構造化データのテスト・検証ツールの使い方｜旧ツールとの違いも解説』で解説しています。

問題はその先です。CMSが本文の編集に合わせてdateModifiedを自動更新するとは限りません。誤字修正のような軽微な編集で日付が動くケースもあれば、大幅な加筆をしても日付が初回公開時のまま止まるケースもあります。

公開後は、次の2点を運用ルールとして決めておいてください。

1. dateModifiedをCMSが自動出力するのか、手入力なのかを実際の記事1本で確認する
2. 自動出力の場合、どの操作で更新されるか(本文編集・タイトル変更・カテゴリ変更)を確かめ、実態と合わない挙動なら手動運用へ切り替える

08チェックリスト

• Article・NewsArticle・BlogPostingのいずれか、記事内容に合う型を選んでいる
• headline・image・datePublished・dateModified・authorを実装している
• 複数著者がいる場合、配列で個別のオブジェクトとして記述している
• マークアップの内容が、ページに実際に表示されている情報と一致している
• リッチリザルトテストでエラー・警告がないことを確認している
• 記事を編集したときにdateModifiedが更新されるかを、実際の記事1本で確認している

09よくある失敗

BlogPostingとNewsArticleを混同してしまう。企業ブログの記事にNewsArticleを使うなど、実態と異なる型を選ぶケースがあります。自社コンテンツの性質に合った型を選ぶことが基本です。

複数著者を1つのnameフィールドにまとめてしまう。「山田太郎、鈴木花子」のようにカンマ区切りで1つのnameに詰め込む書き方は、著者ごとに個別のPersonオブジェクトとして認識されません。

dateModifiedを更新せず放置してしまう。記事を編集してもdateModifiedを書き換えないままだと、実際の更新日と構造化データの内容が食い違います。

10FAQ

11まとめ

Article schemaとは、記事のタイトル・著者・公開日を伝える構造化データです。必須プロパティは存在しませんが、headline・image・datePublished・dateModified・authorの5つを軸に実装することが基本になります。

この実装で本当に難しいのは、初回の記述ではなく公開後の維持です。まずは自社の記事を1本開き、本文を編集したときにdateModifiedが動くかどうかを確かめてみてください。動かないなら、そこがこの構造化データで最初に手を入れるべき箇所です。