Article構造化データ

TL;DR — Article schemaは、ブログ記事やニュース記事に追加する小さなコードブロックで、検索エンジンに基本情報を示します。「これは見出し」「これは著者」「これは公開日」「これはメイン画像」とラベルを付けるものです。Googleが検索結果でこれらの詳細をより適切に表示する助けになります。Google自身のドキュメントはこれを「Article rich result」と呼びますが、RecipeやVideoのように派手な新しいカードが作られるわけではありません。また、Google NewsやDiscoverに入るための要件でもありません。そして、読んだことがあるかもしれませんが、AMPは必要ありません。

Article schemaとは

記事を読むとき、見出し、著者名、日付は見ただけで区別できます。検索エンジンはプレーンテキストを見て、そこから意味を推測しなければなりません。Article schemaは、共有のschema.org 語彙を使ってコードで明示し、どの部分が見出しなのか、誰が書いたのか、いつ公開されたのか、どの画像がメインなのかをGoogleに正確に伝えます。

ほとんどの場合、JSON-LDで記述します。ページの見た目を変えずにページ内へ置く小さなコードブロックです。Article、NewsArticle、BlogPostingとして表示されます。3つとも有効で、Googleは1つのガイドで扱っています。 Evidence for this claim Schema.org defines Article and the more specific BlogPosting and NewsArticle types. Scope: Schema.org vocabulary; type validity is separate from Google search-feature eligibility. Confidence: high · Verified: 2026-07-14 Schema.org: Article （詳しい選び方はAdvancedタブで説明します。）

実装する価値がある理由

多くのガイドが誇張する部分なので、率直に説明します。Article schemaは、RecipeやProductのような派手な新しい結果カードを作りません。実際にすることは、もっと控えめですが確かなものです。

• 通常の検索結果で、記事のよりよいtitleテキスト、よりよい画像、より明確な日付情報をGoogleが表示しやすくします。Google自身のドキュメントも実際にこれを「Article rich result」と呼んでいます。 Evidence for this claim Google says Article structured data can help it understand article pages and show better title, image, and date information. Scope: Google Search Article documentation; markup does not guarantee a particular appearance. Confidence: high · Verified: 2026-07-14 Google: Article structured data
• Google NewsとDiscoverは、コンテンツを理解するためにこのマークアップを読み取れますが、どちらも必須ではありません。特にDiscoverは、特別なタグや構造化データをまったく必要としないと説明しています。

つまり得られるのは、既存の結果をよりよく表示したものであり、新しい見た目のカードではありません。「article carousel rich result」を約束する人や、このマークアップがTop StoriesやDiscoverに入る仕組みだと示唆する人は、言い過ぎています。

よい知らせ：必須項目はない

GoogleのArticleガイドは、驚くほど柔軟です。必須プロパティはありません。 コンテンツに当てはまるものを追加します。実務上は次の項目を設定するとよいでしょう。

• headline — 記事のtitle（簡潔にします。Googleは長いものを切り詰めます）。
• author — 実在する個人または組織で、名前が記事のbylineと一致するもの。
• datePublishedとdateModified — 公開された日時と、最後に変更した日時。
• image — メイン画像（Googleは16x9、4x3、1x1など、少なくとも50 000ピクセルの画像を好みます）。

無視すべき神話

読んだことがあるかもしれない、単純に古いか間違っている2つの話があります。

• 「Article schemaにはAMPが必要」。必要ありません。Googleの現在のArticleガイドはAMPにまったく言及していません。
• 「プロパティは多いほどよい」。Googleは、当てはまるものだけを追加するよう明確に述べています。「勝つ」ために埋めるチェックリストはありません。

そして、常に正しいことが1つあります。有効なマークアップは適格性を与えるだけで、利用を保証するものではありません。 Googleは今も使うかどうかを判断します。

完全版では、ArticleとNewsArticleとBlogPostingの違い、推奨プロパティを適切に設定する方法、よくある実装ミス、過剰な約束をせずにTop StoriesやDiscoverとの関係を説明しています。Advancedタブに切り替えてください。

TL;DR — Article構造化データ（Article、NewsArticle、BlogPostingのいずれか。すべて有効で、Googleは1つのガイドで文書化しています）は、記事ページのheadline、author、datePublished／dateModified、imageをマークアップします。必須プロパティはありません。Googleはコンテンツに当てはまるプロパティを追加するよう案内しています。Google自身のドキュメントはこれを**「Article rich result」と呼びますが、RecipeやVideoObjectの特徴的なカードとは異なり、既存の結果をよりよく表示する形（titleテキスト、画像、日付）で現れ、別のスニペット形式ではありません。Top StoriesのようなGoogle Newsの機能にArticleマークアップは必要なく、Discover自身の指針も特別なタグや構造化データはまったく不要としています。そのため、ガイドが「article carousel」への切り替えスイッチとして約束するものではありません。Googleの現在のArticleガイドはAMPにまったく言及していません**。古い「Article schemaにはAMPが必要」という主張は廃れています。有効なマークアップは適格性を得るだけで、使うかどうかはGoogleが判断し、順位要因ではありません。

Article schemaが実際にすること（しないこと）

最もよくある誇張を先に訂正します。Google自身のドキュメントはこの機能を**「Article rich result」**と呼びますが、Recipeマークアップがレシピカードを、VideoObjectが動画サムネイル表示を提供するような、特徴的な新しいカードではありません。Articleには独立した見た目のスニペットに相当するものはなく、ここでいう「rich result」は既存の掲載結果をよりよく表示することです。具体的には次のとおりです。

• 既存の結果の表示を改善する — Googleが記事のよりよいtitleテキスト、メイン画像、明確な日付情報を表示できます。
• Googleがコンテンツを理解する助けになる — ただし、Top StoriesのようなGoogle Newsの機能に必須ではなく、Discoverの指針でも対象コンテンツに特別なタグや構造化データは不要です。Articleマークアップは詳細を明示できますが、どちらの面も解放しません。

これは独立した新しいスニペット形式や適格性の切り替えではなく、表示品質に関するシグナルです。「Article schemaでTop Stories／article carouselが解放される」と約束するガイドを見たら、誇張として読んでください。Google自身の説明は、カードやNews／Discoverの適格性をオンにすることではなく、ページを理解し、title／画像／日付をよりよく表示することです。（「よりよいtitleテキスト、画像、日付情報」という表現はGoogleの説明を要約したものとして扱っており、逐語引用ではありません。確認済みの逐語引用はQuotesタブを参照してください。）

ArticleとNewsArticleとBlogPosting — 正しく選ぶ必要はある？

短い答えは、そこまで悩む必要はありません。 3つのタイプはすべて有効で、GoogleのガイドはArticle、NewsArticle、BlogPostingを同じ推奨プロパティとともにまとめて扱っています。NewsArticleとBlogPostingはどちらもArticleのサブタイプです。したがって、次のように考えます。

• ニュースサイトのニュースコンテンツには**NewsArticle**を使う。
• ブログ記事には**BlogPosting**を使う。
• どちらにもきれいに当てはまらない場合は、一般的な安全な選択として**Article**を使う。

ページを正直に表す最も具体的なタイプを選びます。ただし、眠れないほど悩む必要はありません。推奨プロパティのセットは同じで、選択によって別のリッチリザルトの見返りが生じるわけでもありません。（schema.org自体には、この3つ以外にもArticleのサブタイプがいくつかあります。Googleのガイドとこの記事は、サポートされるプロパティセットを公開している3つを扱っています。）

必須プロパティなし — 欠落ではなく特徴

GoogleのArticleガイドは、必須プロパティはなく、代わりにコンテンツに当てはまるプロパティを追加すると明確に述べています。 Evidence for this claim Google lists no required Article properties but recommends adding applicable author, date, headline, and image data. Scope: Google Search Article feature requirements; completeness and accuracy still matter. Confidence: high · Verified: 2026-07-14 Google: Article structured data ProductやRecipeのように厳格な必須項目リストに慣れていると、この柔軟さがかえって迷いを生みます。ここで推奨されるのは、次のプロパティを丁寧に埋めることです。

schema.orgが提供するすべてのプロパティを詰め込みたくなりますが、やめてください。Googleの指針は当てはまるものを追加することです。長いリストを埋めてもボーナスはなく、無関係または不正確なプロパティはリスクになります。

よくある実装ミス

• 著者名の不一致。 最も多いのは、実際のbylineと一致するPerson／Organizationではなく、authorに「Admin」、サイト名、執筆していない編集者などの一般的または不一致の値を設定することです。
• 長すぎるheadline。 Googleは表示時に長い見出しを短縮したり書き換えたりするため、肥大したheadlineに利点はなく、見た目も不自然になります。
• 古い、または頻繁に変わるdateModified。 毎回のクロールで変更することも、まったく変更しないことも、誤ったシグナルを送ります。コンテンツが本当に変わったときに更新します。
• 品質の低いimageを1枚だけ使う。 Googleに複数のサイズ／比率を渡してください。小さすぎる画像や切り抜きにくい画像だけでは、表示できる内容が制限されます。
• 存在しないカードを追いかける。 Googleはこの機能を「Article rich result」と呼びますが、特徴的な新しい見た目のスニペットを追うものではありません。既存の結果をよりよく表示するためのものです。

Top Stories、News、Discoverとの関係 — 過大に約束しない

ここは正確に説明する価値があります。Googleは明確に説明しており、2つの面は同じではないからです。Articleマークアップは、Googleが記事の詳細をより明確に理解する助けになります。しかしGoogleは、Top StoriesのようなGoogle Newsの機能に必須ではないと述べ、Discoverの指針は対象コンテンツに特別なタグや構造化データはまったく不要としています。Article schemaはどちらも解放しません。すでに検討対象になっているページをGoogleが理解する助けになるマークアップであって、スイッチではありません。Top StoriesやDiscoverに入る実際の条件は、適格なパブリッシャーであること、コンテンツの品質と新しさ、そしてGoogle自身のシステムが表示に値すると判断することです。

深掘りするより、隣接する2点として触れておく価値があります。

• ペイウォールコンテンツには、別途paywalled-content構造化データを追加してください。これはArticleの一部ではなく、購読ページをGoogleがどう扱うかに関係する独自のマークアップです。
• authorと日付のフィールドを正しく設定する価値があるのは、サイトの別の場所で説明している、実在し一貫した著者IDが広いE-E-A-Tシグナルにとって重要なのと同じ理由です。このマークアップ自体が直接的なE-E-A-T入力だという現在の証拠を知っているわけではありませんが、いずれにしても著者情報を正しくするのはよい実務です。

構造化データは順位要因ではない

ここまでの土台なので、繰り返す価値があります。Articleを含む構造化データは順位要因ではありません。John Muellerが繰り返し述べているように、直接影響するのは順位ではなく、リッチリザルトと表示の適格性です。Article schemaは、Googleがコンテンツを理解し表示する助けにするために追加するものであり、結果を上げるためではありません。特徴的な新しいカードがなくても、記事の表示を改善するので追加する価値はあると私は考えます。証明されていないNewsやDiscoverの適格性の主張に頼らなくても、Google自身の「Article rich result」というラベルが示す、title、画像、日付の改善だけで十分です。

構造化データ全体の中でのArticle

Articleはschema.orgのCreative Worksタイプの1つで、AudioObject、Book、Course、Dataset、Movie、Recipe、VideoObjectなどの兄弟タイプと並びます。この記事が属するCreative Worksのハブは、それらをまとめて扱います。RecipeやVideoObjectには専用のリッチリザルトカードがありますが、だからこそArticleにはないことを明確にしておく価値があります。より広い語彙とJSON-LDの位置付けは、この記事の上位にあるSchema MarkupとStructured Dataのハブを参照してください。

AIによる要約

Advanced版を簡潔にまとめると、次のとおりです。

• 何か： schema.orgのArticleマークアップ（Article、NewsArticle、BlogPostingとして実装できます。すべて有効で、Googleは一緒に文書化しています）。通常はJSON-LDで、記事ページのheadline、author、datePublished／dateModified、imageを示します。
• 必須プロパティはない。 Googleはコンテンツに当てはまるプロパティを追加するよう述べており、必須リストも、長いリストに対するボーナスもありません。
• Googleは「Article rich result」と呼ぶ。 ただしRecipeやVideoObjectとは違い、特徴的な新しい見た目のカードはありません。既存の結果を、よりよいtitleテキスト、画像、日付情報で表示するものです。
• Top StoriesやDiscoverのスイッチではない。 Googleは、Top StoriesのようなGoogle Newsの機能にArticleマークアップは必要ないと述べ、Discoverの指針も対象コンテンツに特別なタグや構造化データは不要としています。ページを理解する助けにはなりますが、どちらも解放しません。
• 無視すべき競合の誇張： Article schemaが「Top Stories／article carousel／rich snippetを解放する」という主張は、Googleの理解を助けるという説明と適格性の保証を混同しています。Articleが与える独立した見た目の形式ではなく、誇張された主張として読んでください。
• AMP要件はない。 Googleの現在のArticleガイドはAMPにまったく言及していません。「Article schemaにはAMPが必要」という広く繰り返される主張は古いものです。
• タイプの選び方： ニュースにはNewsArticle、ブログにはBlogPosting、一般的な代替にはArticleを使います（schema.orgにはさらにサブタイプがありますが、Googleがサポートされるプロパティセットを文書化しているのはこの3つです）。3つの推奨プロパティは同じで、選択によるリッチリザルトの見返りはありません。
• 推奨プロパティを丁寧に設定する： authorは、一致する名前を持つ実在のPerson／Organization。簡潔なheadline（長いものはGoogleが短縮）。正直なdateModified。代表的でクロール可能な、少なくとも50 000ピクセルの複数比率（16x9、4x3、1x1）の画像。
• よくあるミス： 不一致または一般的な著者、長すぎるheadline、頻繁に変わるか古いdateModified、弱い画像1枚、存在しないカードへの期待。
• 隣接する話： ペイウォールコンテンツには別のpaywalled-contentマークアップが必要です。author／日付フィールドを正しく設定するのは、このサイトのより広いE-E-A-T作業と並ぶよい実務ですが、この記録はマークアップ自体が直接的なE-E-A-T入力だとは示していません。
• 適格性は表示ではなく、順位要因でもない： 構造化データはリッチリザルト／表示の適格性に影響しますが、順位には影響しません（Muellerが繰り返し説明）。有効なマークアップは適格性を得るだけで、使うかどうかはGoogleが決めます。

公式ドキュメント

検索エンジンによる一次資料のドキュメントです。

Google — Article構造化データ

• Article (Article, NewsArticle, BlogPosting) structured data — 3つのタイプをすべて扱う単一のガイドです。文書化された機能を「Article rich result」と呼び、必須プロパティなしの方針、推奨プロパティ（author、dateModified、datePublished、headline、image）、最低50 000ピクセルで複数比率の画像に関する指針を示します。また、Google NewsのTop Storiesのような機能にArticleマークアップは必要ないと述べています。AMPには言及していません。
• General structured data guidelines — Articleを含むすべての構造化データに適用されるコンテンツ、技術、品質のポリシー。
• Subscription and paywalled content — 購読／ペイウォール記事に対する別のマークアップ（Articleガイドで触れられていますが、独自に実装します）。
• Rich Results Test — マークアップを検証し、Googleが読み取れる内容を確認します。
• Get on Discover （Google）— Discover独自の適格性指針で、特別なタグや構造化データはまったく不要と述べています。

Bing／Microsoft

• サイトに構造化データを付与する — Bingの一般的な構造化データ対応（schema.org、JSON-LDを推奨）。Bingの一般的なMarkup Validatorで検証します。

出典からの引用

Googleによる記録に残る発言です。出典ページがテキストを公開している場合、リンクは引用箇所へ移動するディープリンクになっています。

Googleのドキュメント — 必須プロパティなし

• “There are no required properties; instead, add the properties that apply to your content.” (翻訳)「必須プロパティはありません。代わりに、コンテンツに当てはまるプロパティを追加してください。」 引用へ移動

構造化データと順位について（変わらない説明）

• 構造化データは順位要因ではありません。John Muellerが繰り返し述べているように、直接影響するのは順位ではなく、リッチリザルトと表示の適格性です。（Search Centralのオフィスアワーやソーシャル投稿で一貫して示されているMuellerの説明を要約したものです。単一の出典付き逐語録ではなく、確立した説明として扱ってください。）

Article schemaで避けるべき神話とミス

神話：「Article schemaにはAMPが必要」 誤りです。古いガイドで今も繰り返されているため、直接訂正する価値があります。Googleの現在のArticleガイドはAMPにまったく言及しておらず、現在のArticleの扱いにAMP要件はありません。ArticleマークアップをAMPと結び付ける資料は古い情報です。

神話：「Article schemaは特徴的な新しい見た目のリッチリザルトカードを与える」 そうではありません。Google自身のドキュメントは文書化した機能を「Article rich result」と呼びますが、RecipeやVideoObjectとは違い、Articleに独自の見た目のスニペットはありません。titleテキスト、画像、日付を改善した既存の結果です。また、Google NewsのTop Storiesに必須ではなく、Discoverの指針でも対象コンテンツに特別なタグや構造化データは不要です。スキーマだけで「article carousel rich result」が得られると約束するガイド（Yoast、Semrush、SEJがこの形式を独立したものとして説明する例を見たことがあります）は、マークアップの機能を誇張しています。形式や適格性の保証ではなく、誇張された適格性の主張として読んでください。

神話：「プロパティは多いほどよい」 Googleは、コンテンツに当てはまるプロパティだけを追加するよう明確に述べています。埋める必須リストも長いリストへのボーナスもなく、無関係または不正確なプロパティはリスクであり、順位や適格性を高めるものではありません。

神話：「構造化データで順位が上がる」 Articleを含む構造化データは順位要因ではありません（Muellerが繰り返し説明）。リッチリザルト／表示の適格性に影響しますが、順位には影響しません。結果を上げるのではなく、Googleがコンテンツを理解し表示する助けにするために追加してください。

ミス：一般的または一致しないauthor。 authorを「Admin」、サイト名、または記事を書いていない編集者に設定すると、目的を損ないます。表示されるbylineと一致する名前を持つ実在のPersonまたはOrganizationを参照してください。

ミス：長すぎるheadline。 Googleは表示時に長い見出しを短縮したり書き換えたりします。肥大したheadlineに利点はなく、間違って見えることもあります。簡潔にし、表示されるtitleと揃えてください。

ミス：頻繁に変わる、または古いdateModified。 新しさを偽るために毎回のクロールでdateModifiedを更新したり、まったく更新しなかったりすると、どちらも誤解を招きます。コンテンツが本当に変わったときに更新してください。

ミス：Article schemaでTop StoriesやDiscoverをオンにしようとする。 GoogleはTop StoriesにArticleマークアップは必要ないと述べ、Discoverの指針も対象コンテンツに特別なタグや構造化データは不要としています。掲載には、適格なパブリッシャーであること、コンテンツの品質と新しさ、Google自身の判断が関係します。きれいなマークアップはGoogleがページを理解する助けになりますが、スイッチを切り替えるものではありません。

ミス：paywalled-contentマークアップを忘れる。 購読／ペイウォール記事には別のpaywalled-content構造化データが必要です。Articleの一部ではなく、これを省くとGoogleによるゲート付きページの扱いに問題が生じる可能性があります。

一般的なArticle JSON-LDと、適切に整えたArticle JSON-LD

Articleには必須プロパティがないため、ここでいう「壊れている」は検証に失敗するという意味ではほとんどありません。薄く役に立たないという意味です。つまり、技術的には解析できてもGoogleが扱える情報が少ないマークアップや、ページと一致しない値です。

薄く一般的なスニペット

解析はできますが、authorが一般的で、低品質な画像が1枚だけあり、公開日と変更情報がありません。

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How To Implement Article Schema Markup For Better Search Visibility And Rich Results In Google Today",
  "author": {
    "@type": "Person",
    "name": "Admin"
  },
  "image": "https://example.com/img/thumb.jpg"
}

弱い点：

• author.name：“Admin” — 一般的で、実在するbylineと一致しません。実際の執筆者を使います。
• 長すぎるheadline — Googleが短縮／書き換えます。表示されるtitleとも一致しません。
• 小さなimage1枚 — Googleが表示できる内容が制限されます。
• datePublished／dateModifiedがない — 日付シグナルを活用できていません。

同じ記事を適切に整える

具体的なBlogPostingタイプ、実在してbylineと一致する著者、複数の画像比率、正直な日付を設定します。

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to implement Article schema markup",
  "author": {
    "@type": "Person",
    "name": "Patrick Stox",
    "url": "https://example.com/author/patrick-stox/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/img/logo.png"
    }
  },
  "datePublished": "2026-07-01T09:00:00-04:00",
  "dateModified": "2026-07-01T09:00:00-04:00",
  "image": [
    "https://example.com/img/article-1x1.jpg",
    "https://example.com/img/article-4x3.jpg",
    "https://example.com/img/article-16x9.jpg"
  ]
}

改善される点：

• @type: "BlogPosting" — ページを正直に表す最も具体的なタイプ（有効なArticleサブタイプ）。
• 実在し一致するauthor — 著者エンティティへのurl付き。
• 簡潔で表示されるtitleと揃ったheadline。
• 両方の日付を設定 — タイムゾーン付きのISO 8601。
• 3つの画像比率（16x9、4x3、1x1）— Googleが表示面に最適な画像を選べます。

ここで満たしている「必須」プロパティはないことに注意してください。すべて推奨です。2つのスニペットの違いは合格／不合格ではなく、渡した情報をGoogleがどれだけ活用できるかです。

確認テスト：Article Schema

Article、NewsArticle、BlogPostingのマークアップ、それがすること（しないこと）、無視すべき神話について問う5つの短い質問です。それぞれ回答を選んでから、確認してください。

Article schemaの継続的なKPI

Article schemaには、RecipeやProductのような独自のリッチリザルトレポートがSearch Consoleにありません。そこで、ここで役立つKPIはマークアップが実際にすること、つまり既存の結果の表示品質の改善を反映するものです。公開後の1つの数字を追いかけるのではなく、四半期ごとに比較して追跡します。

Top Stories／Discoverの検索での表示回数

指標： Search Consoleの検索での表示の内訳に「Top stories」が表示される場合、または別のDiscoverレポートに動きがある場合の表示回数とクリック数。わかること： GoogleがArticleをマークアップしたページをこれらの面に表示しているか。ただし、Articleマークアップはどちらにも必須ではありません（GoogleはTop Storiesにマークアップ不要と述べ、Discoverにも特別なタグや構造化データは不要としています）。そのため、ここが少ないからといってマークアップが壊れているとは限らず、強い数字をマークアップだけの成果とすることもできません。取得方法： Search Console → Performance → 検索での表示フィルター（または、プロパティに表示対象のトラフィックが登録されていれば専用のDiscoverレポート）。ベンチマーク／現実的な範囲： サイト横断の基準値はありません。Top StoriesとDiscoverの適格性は、パブリッシャーの状態、分野、新しさに大きく左右されるため、外部の数字と比べるのではなく、セクションごとに自分の基準値を作って推移を見ます。頻度： 毎月、またはArticleマークアップや公開頻度を変更した後。

記事テンプレート全体の有効な構造化データ率

指標： Articleテンプレートを使うページのうち、推奨フィールドの欠落なしに正常に解析できる割合。わかること： CMSの更新、テーマ変更、テンプレート編集によってサイト全体のマークアップが壊れていないか。テンプレートのバグ1つで、すべての記事からauthorやimageが静かに消えることがあります。取得方法： 構造化データ検証 ツールまたはリッチリザルト適格性 チェッカーでURLのサンプルを確認します。Search Consoleの構造化データ警告も、Googleが解析できなかったページを知らせます。ベンチマーク／現実的な範囲： 曲線ではなく衛生指標です。部分的なカバレッジに利点はないため、推奨フィールドを持つテンプレートページが100%であることを正直な目標にします。頻度： テンプレートやCMSを変更した直後。そうでなければ四半期に一度のサンプル確認で十分です。

表示されたtitle、画像、日付の正確さ

指標： Googleが検索結果で実際に表示するheadline、画像、日付が、headline、image、datePublished／dateModifiedに設定した内容と一致するか。わかること： Article schemaの主な役割である「表示品質の改善」を直接観測できます。Googleが推測したtitleや別の画像に置き換えているなら、そのページではマークアップが役割を果たしていません。取得方法： URL検査ツールのレンダリングプレビュー、Rich Results Test、または記事の対象クエリで手動のSERP確認を使います。ベンチマーク／現実的な範囲： 目標にする割合はありません。確認したページごとの合否として読み、相違があれば著者、headline、画像の値を見直すシグナルとします。頻度： 重要ページは公開直後に確認し、その後は更新した古いコンテンツを時々確認します。

Article schemaを作成・確認するツール

私が提供する3つの無料ツールで、Article schemaの一連の作業をカバーできます。正しく生成し、既存のマークアップを検証し、推奨フィールドのうち何が不足しているかを正確に確認します。

Schema Markup Generatorでマークアップを生成する

Schema Markup Generatorは、手書きではなくフォームからArticle、NewsArticle、BlogPostingのJSON-LDを作成します。間違えやすい部分の入れ子を正しく処理します。たとえば、単なる文字列ではなくPersonまたはOrganizationオブジェクトとしてのauthor、ImageObjectロゴを入れたpublisher、Googleが推奨する16x9／4x3／1x1の比率を指定できるimage配列です。ページへそのまま貼れる6つの形式で出力します。

Schema Markup Validatorで既存のマークアップを検証する

Schema Markup Validatorは、すでにあるJSON-LD（コードまたは完全なHTMLページ）を、schema.org語彙とGoogleがArticleに推奨するプロパティの両方に対して、重大度別の結果で確認します。Advancedタブで扱った著者不一致のミスに特に役立ちます。ブロックをまたぐ@idグラフのチェックにより、ページ上の別の実在するPersonまたはOrganizationエンティティへ解決できないauthor参照を検出します。

Rich-Result Eligibility Checkerでフィールドごとの適格性を確認する

Rich-Result Eligibility Checkerは、Articleマークアップが推奨セット（headline、author、datePublished、dateModified、image）をカバーしているかをフィールドごとに確認する最速の方法です。明確なチェックマーク、不足を示すX、推奨だが任意のフィールドを示す警告が出ます。Articleには必須プロパティがないため、推測ではなく、どの推奨フィールドを追加する価値があるかを判断するツールです。

Google自身の検証ツールでセカンドオピニオンを得る

上のツールを使った後に、GoogleのRich Results Test も実行する価値があります。第三者による仕様の解釈ではなく、Google自身のパーサーがページから何を読み取るかを正確に示すため、テンプレートをサイト全体へ反映する前の最終確認に役立ちます。

時間をかける価値のあるリソース

業界の資料

Article schemaは、Top StoriesやDiscoverでマークアップが得るものを有名なガイドがいくつも誇張しているテーマです。そのため、ここではこの記事が訂正する誇張の例としていくつかを挙げます。Google自身のドキュメントと照らして読んでください。Googleはこれを「Article rich result」と呼びますが、利益を既存の結果の理解と表示の改善として説明しており、独立した新しいカードや適格性の切り替えとは説明していません。

• Article (Article, NewsArticle, BlogPosting) structured data （Google Search Central）— 権威あるリファレンスです。必須プロパティなし、推奨フィールド、最低50 000ピクセルで複数比率の画像、Top Storiesにマークアップ要件がないこと、そしてAMPに言及していないことを説明します。
• Get on Discover （Google）— Discoverの適格性に特別なタグや構造化データは不要と述べています。
• General structured data guidelines （Google）— すべての構造化データに適用されるポリシー。
• 購読コンテンツとペイウォールコンテンツ （Google）— ゲート付き記事の別マークアップ。
• Structured data / schema ultimate guide （Yoast）— 一般的なリファレンスとして有用ですが、Article schemaがTop Storiesやarticle carouselのようなリッチリザルトを可能にすると説明しています。Google自身のドキュメントは、どちらの面にもこのマークアップは必要ないと述べています。
• Schema markup guide （Semrush）— 同様にArticle schemaがページを「eligible for a rich snippet」にすると説明していますが、News／Discoverの適格性とマークアップ自体を混同しています。誇張された適格性の主張として扱ってください。
• What Is Schema Markup? How to Add It & Why It Matters （Ahrefs）— AIエージェント／機械可読性の観点も役立つ、堅実な一般的schemaガイドです。

変更履歴