AI表示のためのSchema.org：現在重要なマークアップ

AIによる表示のためのSchema.org：現在重要なマークアップ

2026年9月5日現在、構造化データは検索エンジンがページ、著者、組織、事実を理解するのに依然として役立っています。しかし、AIによる回答の直接的なランキング要素ではありません。

Googleは、AI概要やAIモードに表示されるために特別なSchema.orgマークアップは必要ないと述べています。ページは主にクロール可能で、インデックス登録され、検索スニペットの対象であり、役立つコンテンツによって裏付けられている必要があります。Googleはまた、構造化データは表示されているページコンテンツと一致するべきだとも述べています。(developers.google.com)

したがって、現在の最善の戦略は次のとおりです。

1. ページを正確に記述するために構造化データを使用する。
2. マークアップをページの真の目的に合わせる。
3. 記事、著者、組織、トピックの間に明確な関係を構築する。
4. 表示されるHTMLで直接的で完全な回答を記述する。
5. AIによる引用を従来のリッチリザルトとは別に測定する。

最終的な見解

広範な調査結果は重要です。汎用的な構造化データを追加するだけでは、AIによる引用の一貫した増加にはつながっていません。Ahrefsが実施した対照研究では、JavaScript Object Notation for Linked Dataを追加した1,885ページと、4,000の対照ページを追跡しました。その結果、Google AIモードまたはChatGPTの引用において意味のある改善は見られませんでした。Google AI概要の引用はわずかに減少しましたが、研究者らはその変化は小さく、マークアップに明確に起因するとは断定できないと警告しています。(ahrefs.com)

2026年の別のプレプリントでは、Article、Organization、BreadcrumbList、WebPageなどの汎用タイプは、検索ランキングとドメイン権威を制御した後では、AIによる引用を単独で予測しないことがわかりました。最も強力な発見は、価格、評価、仕様など具体的な属性が豊富なデータを持つページが、汎用的なページラベルのみを持つページよりも優れたパフォーマンスを示したことです。この発見は主に製品ページとレビューページに焦点を当てているため、この記事のどのタイプも引用上の利点をもたらすという証明として扱うべきではありません。(aixiv.science)

構造化データができること、できないこと

構造化データは、ページの機械可読な記述です。検索エンジンに次のことを伝えることができます。

• どのような種類のページか
• 誰が書いたか
• どの組織が公開したか
• どのような質問に答えているか
• いつ公開または更新されたか
• ページが記述する人物、会社、用語、データセットは何か

Googleは、構造化データがシステムによるページコンテンツの理解を助け、ページをよりリッチな検索機能の対象にできると述べています。また、Google検索は、それらのプロパティが目に見える検索結果を引き起こさない場合でも、理解のために他のSchema.orgプロパティを使用する可能性があるとも述べています。(developers.google.com)

構造化データは次のことを保証しません。

• より高いオーガニックランキング
• AIによる引用
• リッチリザルト
• ナレッジパネル
• AIによる回答への包含
• マークアップ内の正確なテキストの使用

Bingも同様のガイダンスを提供しています。現在のウェブマスター向けガイダンスでは、構造化データはより明確な根拠付けをサポートする可能性があるが、表示や引用トラフィックを保証するものではないと述べています。Bingはまた、公開元に、表示されるページコンテンツで事実と定義を明示するようにアドバイスしています。(bing.com)

主な研究の限界

AIによる回答パネルは通常、ソースページを表示し、そのページに存在する可能性のあるSchema.orgタイプは表示しません。Googleは、例えば、ページがArticleを使用したために引用されたという報告を公開していません。

これにより、3つの異なる疑問が生じます。

1. ページは引用されたか？
2. ページに構造化データが含まれていたか？
3. 構造化データが引用を引き起こしたか？

ほとんどの研究は最初の2つにしか答えられません。3つ目を証明することはできません。

そのため、FAQPageマークアップを持つページがAIによる回答に頻繁に表示されることがあっても、マークアップがその理由ではない可能性があります。そのページは、強力なコンテンツ、高い検索ランキング、多くのリンク、またはよく知られたブランドを持っている可能性があります。

スキーマタイプ別監査

1. Article

何ができるか

Articleは、記事、ニュース記事、ブログ投稿、または類似の編集ページを記述します。GoogleはArticle、NewsArticle、BlogPostingを記事タイプとしてサポートしています。Googleは記事マークアップの必須プロパティをリストしていませんが、ページに適用されるプロパティを追加することを推奨しています。(developers.google.com)

最も重要なプロパティ

これらは、表示されていて正確である場合に使用します。

• headline
• author
• author.name
• author.url または author.sameAs
• datePublished
• dateModified
• image
• publisher
• mainEntityOfPage
• about
• inLanguage

Googleは、著者には実際のPersonまたはOrganizationを使用することを推奨しています。また、構造化データ内の日付と、表示される公開日および更新日を一致させることも推奨しています。(developers.google.com)

AIへの影響

証拠レベル：間接的。

Articleは、ページタイプ、 authorship（著者情報）、鮮度を確立するのに役立ちます。これらは検索システム、特に事実ページや編集コンテンツにとって有用なシグナルです。しかし、現在の証拠では、Article単独の追加がAIによる引用を増加させることは示されていません。

Articleチェックリスト

• ページは真に記事である。
• 見出しが表示されるタイトルと一致する。
• 表示されるすべての著者が含まれている。
• 各著者には個別のPersonまたはOrganizationオブジェクトがある。
• 著者名には名前のみが含まれ、役職や公開元名は含まれない。
• 著者が実際のプロフィールまたは著者ページにリンクしている。
• 公開日と更新日がページに表示されている。
• 時間が含まれる場合、日付は正しいタイムゾーンを使用している。
• 画像が記事を表している。
• 公開元がサイト全体で一貫して識別されている。
• ページが真に両方の目的を果たす場合を除き、HowToのような異なる主要タイプとしてマークアップされていない。

2. WebPage

何ができるか

WebPageは一般的なページタイプです。Schema.orgは、すべてのウェブページが暗黙的にWebPageとして扱われると述べていますが、ページにページレベルのプロパティや関係が含まれる場合、明示的な宣言が役立つことがあります。(schema.org)

有用なプロパティには以下が含まれます。

• url
• name
• description
• inLanguage
• dateModified
• breadcrumb
• mainEntity
• about
• isPartOf
• primaryImageOfPage

AIへの影響

証拠レベル：低く、間接的。

WebPageは、接続されたグラフの外側のページレイヤーとして使用するのが最適です。ページを主要な記事、定義、データセット、人物、または組織に接続することができます。

これを特別なAI最適化タイプとして扱うべきではありません。汎用的なWebPageオブジェクトのみを含むページは、主要エンティティを明確に識別するページよりも、通常、有用な情報が少なくなります。

WebPageチェックリスト

• ページに1つの安定した@idを使用する。
• 正規URLをページURLとして使用する。
• ページの真のmainEntityを識別する。
• mainEntityOfPageで主要エンティティをページにリンクする。
• 既知の場合にinLanguageを追加する。
• ページ名と説明を表示されるコンテンツと一致させる。
• ページが実際には記事、プロフィール、データセット、または質問ページであることを隠すためにWebPageを使用しない。

3. QAPage

何ができるか

QAPageは、1つの質問とその回答に焦点を当てたページ用です。Googleは、QAPageとしてマークされたページからのQuestion構造化データを使用すると述べており、ページにはQAPageと主要なQuestionが1つだけであるべきです。(developers.google.com)

必須プロパティ

現在のGoogleの質疑応答の対象資格の場合：

• QAPage.mainEntity
• ネストされたQuestion
• Question.answerCount
• acceptedAnswerまたはsuggestedAnswerのいずれか
• Answer.text

回答のない質問はリッチリザルトの対象外です。

重要なコンテンツルール

QAPageを次のような目的で使用しないでください。

• 通常のよくある質問ページ
• 質問に答えるブログ投稿
• ハウツー記事
• 多くの質問を含む商品ページ
• サイト所有者のみが記述した編集回答

Googleは、通常のQAPageの場合、ユーザーが回答を投稿できる必要があると述べています。有効な例には、フォーラムの質問や、ユーザーが回答を提供できるサポートページが含まれます。(developers.google.com)

AIへの影響

証拠レベル：中程度の意味的合致、因果的な向上は証明されていない。

実際の質疑応答ページは、取得システムにとって自然に理解しやすいものです。しかし、QAPageマークアップ自体がAIによる引用を増加させることを証明する強力な公開研究はありません。

QAPageチェックリスト

• ページは1つの質問に焦点を当てている。
• ページが特別な教育的質疑応答エクスペリエンスの対象となる場合を除き、ユーザーが回答を投稿できる。
• 質問全体が表示されている。
• 回答の全文が表示されている。
• answerCountが実際の回答数と一致する。
• 受理された回答と推奨される回答が正しくラベル付けされている。
• コメントは回答ではなくコメントとしてマークされている。
• ページが単なる編集的なよくある質問ページではない。
• ページに複数の無関係な質問が含まれていない。

QAPageの例

html

このパターンは、ページが真に質疑応答のインタラクションをサポートしている場合にのみ使用してください。

4. HowTo

何ができるか

HowToはステップバイステップの手順を記述します。GoogleはかつてHow-toリッチリザルトをサポートしていましたが、2023年9月にその検索機能を非推奨化しました。Googleは、How-toリザルトはデスクトップに表示されなくなり、モバイル検索からはすでに削除されていると述べました。(developers.google.com)

AIへの影響

証拠レベル：Google向けには低い。

表示される手順は、依然としてユーザーと取得システムに役立つ可能性があります。見出し、番号付きステップ、ツール、時間、警告が明確なチュートリアルは、読みやすく、引用しやすいです。しかし、現在の証拠では、HowToマークアップがGoogle AI概要やAIモードで特別な利点をもたらすとは示されていません。

推奨事項

HowToは次の場合にのみ使用してください。

• ページが真にタスクを教えている。
• 手順がページコンテンツに表示されている。
• 別の検索エンジン、プラットフォーム、または内部システムがマークアップから恩恵を受ける。
• チームが競合するデータを作成せずにそれを維持できる。

Google検索の場合、強力なHTML見出し、番号付きリスト、明確な指示、および有用な画像または動画を優先してください。

チュートリアルチェックリスト

• ページが実際のタスクを教えている。
• タスクの結果が明確である。
• 各ステップが表示されており、完全である。
• ステップ名が表示される見出しと一致する。
• ツールと材料が実際のもので、表示されている。
• 時間の見積もりが正確である。
• 必要に応じて安全警告が含まれている。
• 最初のセクションで短い回答または結果が示されている。
• ページが指示を提供するためにマークアップに依存していない。

5. ClaimReview

何ができるか

ClaimReviewはファクトチェックコンテンツのために設計されました。Googleは2025年の検索結果簡素化の取り組みの一環として、検索でのClaim Reviewのサポートを段階的に終了しました。このタイプはSearch Consoleのレポート作成とリッチリザルトテストから削除されました。(developers.google.com)

AIへの影響

証拠レベル：現在のGoogleの利点なし。

高品質なファクトチェックは、次の点を明確に述べているため、依然として引用される可能性があります。

• 主張
• 評価
• 証拠
• 日付
• ファクトチェック組織
• 結論の根拠

これらのメリットは主にコンテンツ自体から得られるものであり、廃止されたGoogle検索機能によるものではありません。

推奨事項

事実ページの場合：

1. ページが編集的な場合はArticleまたはNewsArticleを使用する。
2. 表示されるテキストで主張を明確に述べる。
3. 主要な証拠を引用する。
4. 著者とレビュー組織を特定する。
5. 公開日とレビュー日を追加する。
6. 他のプラットフォームまたはデータシステムが特別に要求する場合にのみClaimReviewを使用する。

Google AIによる回答がそれを好むと期待するからといって、ClaimReviewだけを追加するべきではありません。

6. FAQPage

何ができるか

FAQPageは、質問と公式の回答を含むページを記述します。Googleは2026年5月7日から検索でのFAQリッチリザルトの表示を停止し、関連するドキュメントを2026年6月に削除しました。(developers.google.com)

AIへの影響

証拠レベル：弱く、混在。

90日間のベンダー調査では、120ページにFAQPageマークアップが追加されました。ChatGPT、Gemini、またはGoogle AI概要の引用に信頼できる改善は見られませんでした。Perplexityではわずかな増加が見られましたが、調査自体は結果がプラットフォーム固有であり、因果関係を証明するものではないと述べています。(authorityradar.com)

すでに引用されている615ページを対象とした別の調査では、FAQマークアップが頻繁に引用されているページでより多く出現することがわかりました。この関係は、同じ公開元からの繰り返しのページを制御した後で消滅しました。研究者らは、証拠がマークアップ自体からの効果を確立していないと結論付けました。(getintel.ai)

推奨事項

読者にとってページを改善する場合にのみ、よくある質問を使用してください。AIによる回答を狙うためだけに、一般的な質問の大きなブロックを追加しないでください。

他の検索エンジンまたはコンテンツシステムのためにFAQPageマークアップを保持する場合：

• すべての質問を表示する。
• すべての回答を完全にする。
• マークアップをページと同一にする。
• 複数のスキーマブロックで同じ質問を繰り返さない。
• GoogleのFAQリッチリザルトを期待しない。

Google以外の消費者向けのFAQPageの例

html

これは意味的な記述であり、Google検索機能の約束ではありません。

7. Organization

何ができるか

Organizationは、Googleが会社、非営利団体、公開元、学校、その他の組織を理解し、曖昧性を排除するのに役立ちます。Googleは、組織マークアップが検索に表示されるロゴや一部のナレッジパネル情報などの視覚要素に影響を与える可能性があると述べています。Googleの現在の組織ガイドには必須プロパティはリストされていません。(developers.google.com)

推奨プロパティ

真実であり、表示されているプロパティを使用してください。

• name
• alternateName
• url
• logo
• sameAs
• description
• telephone
• email
• address
• identifier
• foundingDate
• parentOrganization

AIへの影響

証拠レベル：間接的だが有用。

Organizationは次を接続できます。

• 公開元と記事
• 会社とその製品またはサービス
• ブランドとその公式プロフィール
• 組織と既知のウェブID

これはエンティティの曖昧性排除に役立ちます。AIシステムがページを引用することを証明するものではありません。

Organizationチェックリスト

• 完全な組織オブジェクトをホームページまたは組織ページに配置する。
• https://www.example.com/#organizationのような安定した@idを使用する。
• 正確な公開組織名を使用する。
• sameAsで実際の公式プロフィールにリンクする。
• 適切な場合は正しい組織サブタイプを使用する。
• 組織を表す実際のロゴを使用する。
• 連絡先情報を最新の状態に保つ。
• 記事から組織を参照し、すべてのページで競合するバージョンを再作成しない。

8. Person

何ができるか

Personは、ページを記述、レビュー、所有、管理、または表示する人物を特定します。通常、次と接続されている場合に最も有用です。

• Article.author
• QAPageの質問または回答の著者
• ProfilePage.mainEntity
• Organization.employee
• Review.author

Googleのプロフィールに関するガイダンスでは、プロフィールページは1人の人物または組織に焦点を当てる必要があると述べられています。ProfilePageオブジェクトにはmainEntityが必要であり、そのエンティティはPersonまたはOrganizationである必要があります。人物または組織はname、または名前がない場合はalternateNameを持つ必要があります。(developers.google.com)

推奨プロパティ

• name
• url
• sameAs
• image
• description
• jobTitle
• worksFor
• knowsAbout
• affiliation
• identifier

AIへの影響

証拠レベル：間接的。

人物のマークアップは、著者の名前を次と接続するのに役立ちます。

• 略歴
• 役職または役割
• 組織
• 公開された記事
• 外部プロフィール
• 専門分野

これは、ページがサポートしていない専門知識を主張するためではなく、身元を明確にするために使用してください。

Personチェックリスト

• Personは実際の人物にのみ使用する。
• 会社または出版物にはOrganizationを使用する。
• 人物を表示される著者ページにリンクする。
• sameAsは正確で公式なプロフィールにのみ使用する。
• 役職と資格を最新の状態に保つ。
• 主著者だけでなく、表示されるすべての著者を追加する。
• 記事とプロフィールページ全体で同じ人物の@idを使用する。

必須プロパティマトリックス

Googleの一般的なガイダンスでは、不完全なマークアップを大量に使用するよりも、完全で正確なデータが推奨されています。また、構造化データは表示されるコンテンツを表す必要があり、正しいマークアップでもリッチリザルトが保証されるわけではないと警告しています。(developers.google.com)

ユースケース実装チェックリスト

事実ページ

最適な組み合わせ：

• WebPage
• Article または NewsArticle
• Person
• Organization
• 別のサポートされている消費者向けの場合のみオプションでClaimReview

チェックリスト：

• ページの冒頭付近で主要な事実を述べる。
• 事実の出典を明記する。
• 主要な証拠にリンクする。
• 公開日と最終レビュー日を含める。
• 著者とレビュアーを特定する。
• 事実と意見を区別する。
• ページが編集的な場合はArticleを使用する。
• ClaimReviewを現在のGoogle検索戦略として使用しない。

定義ページ

最適な組み合わせ：

• WebPage
• DefinedTerm
• ページが長い編集的な説明である場合はオプションでArticle
• 専門家または公開元が責任を負う場合はOrganizationまたはPerson

DefinedTermは、正式な定義を持つ単語、フレーズ、コード、または概念を対象としています。その主要プロパティには、name、description、termCode、inDefinedTermSet、sameAsが含まれます。(schema.org)

チェックリスト：

• 最初の段落で定義を与える。
• 主要エンティティとして1つの明確な用語を使用する。
• 実際の代替名がある場合にのみ追加する。
• 適切な場合に信頼できる外部定義にリンクする。
• 平易な言葉で用語を説明する。
• 例と境界線を含める。
• 無関係な用語のリストを1つのDefinedTermとしてマークしない。

チュートリアル

最適な組み合わせ：

• WebPage
• 他の消費者に必要な場合のみHowTo
• チュートリアルが編集記事でもある場合はArticle
• 著者情報についてはPersonとOrganization

チェックリスト：

• 手順の前に結果を述べる。
• 番号付きの表示される見出しを使用する。
• 各ステップを1つのアクションに集中させる。
• 必要に応じてツール、材料、時間、警告を含める。
• 役立つ場合は画像または動画を追加する。
• 手順をJSON-LD内だけに隠さない。
• Google検索でのHow-toリッチリザルトを期待しない。

データカタログ

最適な組み合わせ：

• WebPage
• DataCatalog
• Dataset
• DataDownload
• Organization

Schema.orgはDatasetを構造化情報の本体と定義し、includedInDataCatalogやdistributionなどの関係をサポートしています。(schema.org)

Googleは2025年後半に、Dataset構造化データはDataset Searchで使用されるものであり、一般的なGoogle検索結果機能ではないと明確にしました。したがって、これはAIによる引用のショートカットではなく、データ発見と相互運用性のレイヤーとして扱うべきです。(developers.google.com)

チェックリスト：

• 各データセットに安定した識別子を与える。
• 主題と範囲を述べる。
• 公開元または作成者を含める。
• データがカバーする日付範囲を追加する。
• 関連する場合、地理的範囲を述べる。
• ライセンスとアクセス条件を記述する。
• ダウンロード可能な各ファイルをDataDownloadとして追加する。
• ファイル形式とダウンロードURLを含める。
• カタログメタデータを実際のファイルと同期させる。
• 更新頻度と最終更新日を文書化する。

JSON-LDの例：事実ページ

この例は、ページ、記事、著者、公開元、トピックを接続します。すべての値を実際のページに表示される情報に置き換えてください。

html

JSON-LDの例：定義ページ

html

定義は通常のページテキストとしても表示される必要があります。定義を構造化データ内だけに配置しないでください。

JSON-LDの例：チュートリアル

GoogleのHow-toリッチリザルトは非推奨化されているため、これは他のシステム向けのオプションのマークアップとして扱ってください。表示されるページには、完全な手順が含まれている必要があります。

html

JSON-LDの例：データカタログ

html

一般的な実装上の落とし穴

不一致のスキーマ

最も深刻な間違いは、ユーザーが見ることができないコンテンツをマークアップすることです。Googleは、構造化データはページの真の表現である必要があり、誤解を招くコンテンツや非表示のコンテンツは、ページをリッチリザルトの対象外にする可能性があると述べています。(developers.google.com)

一般的な例：

• 実際の手順を含まない記事をHowToとしてマークアップする
• 記事が個人によって書かれたものであるにもかかわらず、会社を著者としてマークアップする
• ページに表示されないFAQの回答を追加する
• 将来の公開日を使用する
• 一般的なブログ投稿をQAPageとしてマークアップする
• 意見記事にClaimReviewを追加する

薄い回答

構造化データは空のページを埋めることはできません。

Answer.textまたはacceptedAnswer内の短く漠然とした回答は、強力な情報源にはなりません。表示されるコンテンツは次のとおりであるべきです。

• 質問に直接答える
• 重要な制限と例外を説明する
• 情報源を明記する
• 必要に応じて日付、例、または測定値を含める
• コンテキストから切り離されても単独で意味をなす

GoogleのAIガイダンスでは、理想的なページ長はなく、AIシステムのためにコンテンツを細分化する必要もないと述べています。より良い目標は、有用で完全な、人間中心のコンテンツです。(developers.google.com)

重複するエンティティ

同じ組織、著者、またはページの競合する複数のバージョンを公開することは避けてください。

不適切な実装：

• ホームページに1つの名前を持つ1つのOrganizationオブジェクト
• すべての記事に異なる名前を持つ2つ目のオブジェクト
• 著者ページに@idがない3つ目のオブジェクト

より良い実装：

• 組織に1つの安定した@idを与える
• 各著者に1つの安定した@idを与える
• 記事、プロフィール、質疑応答ページからそれらのオブジェクトを参照する
• 名前、ロゴ、URL、外部IDリンクを一貫して維持する

重複する質問

同じ質問を次の中で繰り返さないでください。

• FAQPage
• QAPage
• 記事のマークアップ
• 複数の表示されるページセクション
• 複数のJSON-LDブロック

ページの主要な目的に合致するスキーマタイプを使用してください。複数の重複するマークアップブロックよりも、単一の明確な回答の方が優れています。

不正確な日付

Googleは、公開日と更新日を推定するためにいくつかの情報源を使用します。表示される日付と構造化された日付が一致することを推奨しており、記事で議論されているイベントに関連する日付ではなく、ページ自体に関連する将来の日付や日付を使用しないよう警告しています。(developers.google.com)

sameAsの乱用

sameAsリンクは、同じ実世界の人物または組織を識別するべきです。次のようなものにはリンクしないでください。

• 無関係なソーシャルプロフィール
• 検索結果ページ
• 汎用的なディレクトリリスト
• スペルまたはIDが異なるページ
• 組織が管理していないプロフィール

JavaScriptのみのマークアップ

Googleはレンダリングされたページに追加された構造化データを処理できますが、JavaScriptのみの実装は、他のクローラーや監査ツールでは検出が難しい場合があります。サーバーでレンダリングされたJSON-LDブロックは、通常、テストと保守が容易です。(developers.google.com)

実践的なテスト計画

マークアップに段階的な効果があるかどうかを測定するには、いくつかの手動検索に頼るのではなく、対照実験を使用してください。

変更前

以下を記録してください。

• ターゲットクエリ
• 現在のオーガニックランキング
• AIによる回答が表示されるかどうか
• どのページが引用されるか
• 利用可能な場合、引用の位置
• 検索トラフィック
• コンバージョン
• 現在の構造化データ
• テスト期間中に行われたコンテンツの変更

テスト中

• 一度に1つの主要なマークアップ変更を追加する。
• コンテンツ、内部リンク、タイトル、バックリンクを安定させる。
• 変更を受けない類似の対照ページを使用する。
• 変更の正確な公開日を記録する。
• クロールと再処理に十分な期間待つ。

Ahrefsは、マッチした対照群と前後差分法を使用しました。そのアプローチは、相関関係が因果関係を証明すると仮定するのではなく、構造化データをテストしたい組織にとって有用なモデルです。(ahrefs.com)

変更後

以下を追跡してください。

• Google Search ConsoleのAIパフォーマンスデータ
• Google AI概要の引用
• Google AIモードの引用
• Bing Webmaster ToolsのAI引用
• 関連する場合、ChatGPT、Gemini、またはPerplexityの引用
• オーガニックランキング
• 検索クリック数
• アシストされたコンバージョン

Googleは、Search Consoleのパフォーマンスレポートを通じてAI検索トラフィックを報告します。BingのAIパフォーマンスレポートは、引用されたページと根拠となったクエリを表示しますが、ページが選択された理由や回答内での重要度は示しません。(developers.google.com)

推奨される実装順序

ほとんどの公開元にとって、最適な順序は次のとおりです。

1. まず表示されるコンテンツを修正する。
2. クロールとインデックス登録を信頼できるようにする。
3. 実際の編集ページにArticleを実装する。
4. Personとプロフィールページで著者を接続する。
5. Organizationで公開元を接続する。
6. WebPageをクリーンなページレベルのグラフレイヤーとして使用する。
7. QAPageは真のコミュニティの質問にのみ使用する。
8. 用語集と定義ページにはDefinedTermを使用する。
9. データリソースにはDatasetとDataCatalogを使用する。
10. FAQPage、HowTo、ClaimReviewは、Google検索機能が削除または非推奨化されているため、二次的なマークアップまたはGoogle以外のマークアップとして扱う。

結論

現在の最も強力な教訓はシンプルです。Schema.orgマークアップは機械がコンテンツを理解するのを助けますが、AIによる回答への保証された道ではありません。

最も持続可能な実装は、大量のスキーマタイプのコレクションではありません。それは、小さく正確なエンティティグラフです。

• Articleが編集ページを記述する。
• Personが著者を特定する。
• Organizationが公開元を特定する。
• WebPageがページを主要エンティティに接続する。
• QAPageが真のユーザーの質問とその回答を記述する。
• DefinedTermが定義を明確にする。
• DatasetとDataCatalogが構造化データリソースを記述する。

明確な意味を追加する場所に構造化データを使用してください。薄いコンテンツを偽装したり、表示されているテキストを複製したり、Googleがもはやサポートしていない検索機能を模倣したりするために使用しないでください。AIによる表示にとって最も価値の高い作業は、明確な回答、強力な証拠、正確なエンティティ、最新の情報、そして単独で意味をなすコンテンツです。