ページのラベルは、訪問者が見えるページに合わせるべき
Schema.orgマークアップは、ページとその主題の構造化された説明をソフトウェアに提供します。ページがすでに述べていることを説明すべきであり、訪問者が確認できない主張を追加するものではありません。
まず、ページの目的と主要なエンティティを書き出します。次に、最もシンプルで適合するタイプを選びます。プロジェクトの概要ページと製品ページは、同じウェブサイト上にあっても互換性がありません。これにより、AI可視性のためのschema.orgマークアップの最初の実用的なチェックが得られます。人は、マークアップされた各事実の背後にある可視コンテンツを指し示せますか?
| ページまたは主題 | 可能なタイプ | 実用的なチェック |
|---|---|---|
| プロジェクトまたは企業 | Organization | 公開されている名前と詳細は正確ですか? |
| ウェブサイト全体 | WebSite | レコードはサイト自体を説明していますか? |
| 1つのURL | WebPage | 説明されているページを特定していますか? |
| 編集リソース | Article | 著者と公開詳細は表示されていますか? |
| 製品またはソフトウェア | Product または SoftwareApplication | ページはその提供物を実際に説明していますか? |
サポートされていないプロパティが詰め込まれた混雑したレコードよりも、チームが維持できる小さなセットを推奨します。技術的な作業の全体像については、技術的なAEOガイダンスをご覧ください。
人々がすでに尋ねるプロジェクトの詳細から始める
初めてのローンチが静かだった創業者を想像してください。答える人が休暇に入り、新しい訪問者はプロジェクトの明確な詳細を必要としています。
私たちは、大きなマークアップテンプレートではなく、訪問者が必要とするページから始めます。プロジェクト名、製品説明、連絡先詳細がサイトに明確に表示されているかを確認します。次に、表示されている事実だけを適切なschema.orgプロパティにマッピングします。ページが真実の情報源であり、マークアップはそれに従います。
プロジェクトに製品ページと短い説明記事があるとします。製品ページが実際に製品を説明している場合、Productをサポートできます。説明記事は、著者と編集詳細が表示されている場合、Articleに適しています。ページがフィールドをサポートしていない場合は、それを省略し、まずプロジェクトオーナーに情報源を明確にするよう依頼します。
これにより、作業の引き継ぎも容易になります。チームメイトは、各フィールドとページの間の関連性を推測する代わりに、その理由を理解できます。有用な情報源ページの作成については、AIアシスタント向けの引用可能なコンテンツをご覧ください。
プロジェクトサイトの異なる部分に適したスキーマタイプは?
適切なスキーマタイプは、特定のページが何を表すかに依存します。プロジェクトウェブサイトは、各ページが表示されているコンテンツを反映している限り、異なるURLで複数のタイプを使用できます。
サイトとそのページから始める
Organizationは、サイトの背後にあるプロジェクトや企業を説明できます。WebSiteはウェブサイト全体を説明し、WebPageは個々のURLを説明します。これらのタイプは、関係が実際に明確である場合に接続できます。名前と公開詳細は、ページとそのマークアップ全体で一貫させます。
コンテンツ固有のタイプは適合する場合のみ追加
Articleは、著者や公開詳細が表示されている編集リソースに適している場合があります。Productは、実際に製品を提示するページに適合する場合があります。SoftwareApplicationは、ソフトウェアを説明するページに適合する場合があり、マークアップで表現された詳細がそこでサポートされている必要があります。
例えば、ソフトウェア機能を説明するページは、SoftwareApplicationの適合性を検討できます。プロジェクトについて一般的に議論しているだけの場合、そのタイプを追加すると誤った説明になる可能性があります。ページごとの簡単なレビューにより、1つのテンプレートが異なるページにコピーされるのを防ぎます。
JSON-LDオブジェクトは小さく読みやすいものにできます。ここでは、名前と住所は例示であり、あなたのプロジェクトの事実ではありません:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Example Project",
"url": "https://example.org/"
}
サイトの実際の公開詳細を使用し、レンダリングされたページがそれらをサポートしていることを確認します。質問ページについては、FAQ最適化が、マークアップを検討する前に表示される回答を計画するのに役立ちます。
ページリストからチェック済みJSON-LDへの落ち着いた5ステップ
ページリストと短い証拠チェックにより、スキーマの作業がレビューしやすくなります。この手順を使用して、各レコードをそれが説明するページに結び付けます。
- 優先URLを選ぶ。 最初に重要なページをリストアップします。各ページの目的、主要エンティティ、正規アドレスを記録します。
- 適切なタイプを選ぶ。 ページが組織、ウェブサイト、記事、製品、ソフトウェア、または他の適切な主題を説明しているかを判断します。
- 各プロパティを追跡する。 訪問者が事実をどこで確認できるか、またはどの信頼できるプロジェクト情報源がそれを確認するかを書き留めます。明確なサポートがないフィールドは削除します。
- JSON-LDを該当ページに追加する。 URLが意図したページを指し、構文が解析されることを確認します。レコードをレンダリングされたコンテンツと比較します。
- 編集後に再確認する。 ページ、製品詳細、著者、または組織の事実が変更された場合、関連するマークアップをチェックします。
公開前に、編集者またはプロダクトオーナーにIDと製品の主張を確認してもらいます。このレビューにより、名前の不一致や古い説明を、修正が容易なうちに発見できます。チェックリストをページノートと一緒に保管し、将来の編集者が理由を再構築せずに同じチェックを繰り返せるようにします。llms.txtの実装方法も検討している場合は、そのタスクを別に保ちます:ファイルとページマークアップは異なる役割を果たします。
構造化データとAIプラットフォームの間の引き継ぎ
構造化データは、ページに関する詳細をより明示的にできます。しかし、ChatGPT、Perplexity、Google、または他のプラットフォームが情報を選択または表示する方法を指示することはできません。Googleのドキュメントでは、構造化データはコンテンツを理解し、サポートされている検索表示の対象を評価するのに役立つ方法として説明されています。表示が表示されるかどうかはGoogleの判断です。どのスキーマタイプも、引用や特定の回答を約束することはできません。
この境界線は、チームに有用な品質テストを提供します。ページが実際の読者のニーズに答えているか、その主張がサポートされているか、マークアップが表示されているコピーを反映しているかを確認します。データが解析されてもページが曖昧な場合は、より多くのプロパティを追加する前にページを改善します。プロジェクトの説明が変更された場合は、ページを更新し、関連するレコードを確認します。
変更内容とその理由をメモしておきます。そうすれば、次の担当者がフィールドが実際のページ詳細なのか古い仮定なのかを判断できます。ChatGPTとPerplexityが表示する内容を比較するときは、各プラットフォームが実際に表示するものを記録します。マークアップを言及や省略の原因として扱わないでください。AI検索可視性のガイドでは、より広範な公開の全体像をカバーしています。
チームが再確認できる小さな記録を残す
コンパクトなレビュー記録は、チームがページの事実、マークアップチェック、可視性の観察を分けて管理するのに役立ちます。また、次のコンテンツ更新で古い詳細が残る可能性を減らします。
優先URLごとに、意図したタイプ、正規アドレス、最終レビュー日、検証ステータスを記録します。ページが構造化データに影響を与える可能性のある方法で変更された場合は、短いメモを追加します。プラットフォームの観察は別の場所に保管します:確認した質問、プラットフォーム、確認日、表示内容を記録します。これらのメモはチームが見た内容を説明するものであり、プラットフォームが特定の情報源を選んだ理由を確定するものではありません。
実際の訪問者がプロジェクトについて尋ねる可能性のある小さな質問セットを使用します。ページをレビューするときにそれらを繰り返し、回答を公開ページの内容と比較します。回答が重要な詳細を欠いている場合、スキーマを変更する前に文言と情報源を調査します。これにより、作業は人々が検証できるコンテンツに基づいたものになります。
より広範な技術レビューが必要な場合は、llms.txtとAIクローラーの設定でその作業の別の部分を説明しています。独自のレビューを開始するには、優先URL、オーディエンスが尋ねる質問、既存のスキーマエクスポートを集めてください。ページとマークアップの一致を確認し、チームに明確な修正を返すことができます。
仕組み
- 優先ページをリストアップ各URLの目的、主要エンティティ、正規アドレスを記録します。
- ページタイプを選択各ページの表示されている目的を説明するタイプを選びます。
- 事実を追跡各プロパティを表示されているコンテンツまたは信頼できるプロジェクト情報源に結び付けます。
- JSON-LDを追加して確認説明するページに配置し、構文をテストし、事実をレンダリングされたページと比較します。
- 編集後にレビュー関連するページコンテンツやプロジェクト詳細が変更されたときにマークアップを再確認します。
よくある質問
スキーママークアップはChatGPTやPerplexityがプロジェクトに言及するのに役立ちますか?
スキーマはページの詳細を構造化された方法で説明できますが、ChatGPTとPerplexityは表示・引用する内容を決定します。ページが明確な読者の質問に答え、マークアップされた事実が表示されているテキストと一致することを確認してください。結果をレビューするときは、質問とプラットフォームを保存して、チームが観察を繰り返せるようにします。
プロジェクトウェブサイトはどのスキーマタイプから始めるべきですか?
持っているページと各ページが実際に何を言っているかから始めてください。Organizationはプロジェクトを説明し、WebSiteとWebPageはサイトと個々のURLを説明します。Article、Product、またはSoftwareApplicationは、表示されている詳細がそれらのタイプをサポートする場合に特定のページに適合する可能性があります。
llms.txtとschema.orgマークアップの両方は必要ですか?
必ずしも必要ではありません。Schema.orgはページコンテンツとエンティティを構造化データで説明します。llms.txtは、選択したサイトリソースを指すための提案されたテキストファイルの慣習です。それぞれが別々のニーズに役立つかどうかを判断し、チームが維持できる場合にのみ情報を最新に保ってください。
JSON-LDの例を自分のページに対して確認するにはどうすればよいですか?
構文が解析され、タイプがページに適合し、各プロパティに表示可能または信頼できるサポートがあることを確認します。公開前に、名前、URL、説明をレンダリングされたページと比較します。著者や製品情報などの事実が明白でない場合、2人目のレビュー担当者が詳細を確認できます。
質問があるすべてのページでFAQPageマークアップを使用すべきですか?
いいえ。タイプは、ページを正確に説明し、関連するプラットフォームの文書化された要件に従う場合にのみ使用してください。FAQPageマークアップがなくても、ページは一般的な質問に明確に答えることができます。重要なチェックは、訪問者がデータで表現された回答を見つけられるかどうかです。
チームはどのくらいの頻度でスキーママークアップを見直すべきですか?
ページまたはそれが説明する詳細が変更されたときにレビューします。例えば、製品説明や組織名が改訂された場合は、関連するレコードのチェックを促します。URL、意図したタイプ、最終レビュー日を1つの短いメモに保持することで、そのチェックを繰り返しやすくなります。
プロジェクトについて教えてください
4つの簡単な質問に答えると、マネージャーが1時間以内にプラン、スケジュール、価格帯をお送りします。すべて機密情報として扱われます。
フォームを読み込んでいます…