Perplexity schema.org 設定：マークアップの種類と実装例

Perplexity において schema.org はサイトに何をもたらすのか？

Schema.org は共通の語彙であり、サイトがページ上に何が提示されているか（組織、記事、製品など）を明示するために使います。このような構造は、情報処理システムがエンティティとそのプロパティを区別するのに役立つ可能性があります。ただし、マークアップはページを Perplexity が必ず選択または引用するソースに変えるわけではありません。

実用的な意味は、訪問者がすでに利用できる事実（プロジェクトの正式名称、そのサイト、著者、公開日、ページのトピック）を明示的かつ一貫して記述することです。マークアップはコンテンツを補完するものであり、置き換えるものではありません。JSON-LD で宣言された内容とページに書かれた内容が異なる場合、明確さではなく曖昧さを生み出します。

作業を始める前に、どのページが重要で、それらについてどの事実を明確にすべきかを決定します。

• トップページはサイトと組織を記述します。
• 製品ページは製品自体とその目的を記述します。
• 公開記事は素材、著者、日付を記述します。
• 手順セクションは個々のページとサイト構造内での位置を記述します。

より広範な技術的最適化計画については、AI検索向け schema マークアップガイド を参照してください。

Perplexity のためにどの schema.org マークアップを追加すべきか？

ページのコンテンツに正確に対応する schema.org タイプを追加します。ほとんどのコーポレートサイトでは、Organization、WebSite、WebPage が基本となります。編集記事の場合は Article、または素材に合ったより具体的なタイプが適しています。利用可能なすべてのタイプをマークアップする必要はありません。いくつかの適切なエンティティの完全性と正確性の方が重要です。

タイプは AI検索での望ましい結果ではなく、ページの目的に基づいて選択します。例えば、商業ページを編集素材でないのに Article としてマークアップしてはいけません。タイプとプロパティのリファレンスは schema.org 公式サイト に公開されています。

暗号プロジェクトの場合、製品、ネットワーク、公式アドレスの説明がページ間で一貫していることを確認します。チームが確認または維持できないプロパティは追加しないでください。

Perplexity 向け schema.org の JSON-LD 形式の例

JSON-LD を使用すると、構造化情報をページの個別ブロックに配置でき、各可視 HTML 要素にプロパティを埋め込む必要がありません。これは、ブロックが最新データから生成され、ページのコンテンツと一致する場合、編集者や開発者にとって便利な形式です。

記事の例は適応させる必要があります。条件付きの値を実際の値に置き換え、ページ自体で確認できないプロパティは削除します。

JSON-LD ブロックでは、schema.org コンテキストとタイプ Article を指定します。次に、公開の見出しの値を持つ headline、タイプ Organization と著者名を持つ author、実際の日付を持つ datePublished と dateModified、そして記事の正規URLを持つ mainEntityOfPage を追加します。完成した JSON-LD では、キーと文字列値は二重引用符で記述します。

指定された値は実際のページと一致する必要があります。実際の公開日や更新日と一致しないデモ日付は使用しないでください。組織ページの場合は、Organization を個別に使用し、確認可能な情報と公式アドレスのみを指定します。可視コンテンツになく、確認済みのソースがないレビュー、評価、価格、その他の「完全性のための」フィールドは追加しないでください。

JSON の構文、URL の正確性、名称の一致を確認します。CMS が自動的にマークアップを生成する場合は、重複ブロックを作成していないか確認します。

サイトにマークアップを実装し検証するには？

Schema.org の実装が役立ち、矛盾を生まないようにするには、まず事実を確定し、それらをページと照合し、その後に JSON-LD を公開します。これにより、間違ったオブジェクトをマークアップしたり、古いデータを残したりするリスクが減ります。

実践的な作業手順：

• 主要ページのリストを作成します：トップページ、製品、ドキュメント、ブログ、お問い合わせ。
• 各ページについて、主要オブジェクトと適切な schema.org タイプを決定します。
• プロジェクト名、ページアドレス、著者、日付が可視コンテンツと一致することを確認します。
• JSON-LD を適切なテンプレートに一度追加し、重複しないことを確認します。
• 公開後、構文とページのアクセス可能性を確認し、大きな変更後は再度確認します。

コードのテストだけに限定しないでください。ユーザーとしてページを開き、重要な事実が実際に公開され、リンクが正規アドレスにリンクしていることを確認します。多言語サイトの場合は、各言語バージョンが正しい見出し、URL、テキストを指定し、別のバージョンの情報をコピーしないようにします。

構文的に正しいマークアップは、ブロックが解析可能であることのみを確認します。プロジェクトの説明の正確性を証明するものではなく、特定の検索エンジンがすでに更新を処理したことを意味するものでもありません。

構造化データをコンテンツやソースとどのように結びつけるか？

マークアップはページの説明として機能するため、まず事実自体を明確でアクセス可能にします。プロジェクト名、製品の目的、ネットワーク、著者、ドキュメントへのリンクは、読者がそれらを期待する場所にプレーンテキストで記載する必要があります。JSON-LD はこの説明を補完しますが、重要な主張が利用可能な唯一の場所であってはなりません。

各エンティティに対して1つの正規ページを割り当て、名前とアドレスの一貫性を維持します。製品名が変更された場合は、見出し、メタデータ、JSON-LD、ドキュメント内のリンクを確認します。技術仕様については、プロジェクトチームが責任を持つソースを使用し、確認できるものだけを指定します。また、キー情報を読むためにログインが必要ないこと、重要な資料が通常のリンクでアクセス可能であることを確認します。

事実、それがユーザーにどこで見えるか、構造化データでどこに指定されているか、誰が更新を担当するかという短いレジストリを維持すると便利です。このような管理は、コントラクトアドレス、ネットワーク、製品ステータスが変更される可能性があるトークンや Web3 製品にとって特に重要です。

目標がマークアップよりも広い場合は、Perplexity 向けサイト最適化 がコンテンツとソースもカバーします。一般的な技術的タスクは Technical AEO ページにまとめられています。

Schema.org が Perplexity で保証できないことは何か？

Schema.org はコンテンツの記述に役立ちますが、回答にどのページを使用し、どのソースを表示するかの決定は Perplexity に委ねられています。選択には、ソースの可用性とコンテンツ、クエリの表現、サービス自身の処理プロセスが影響します。JSON-LD の存在自体がページの順位を固定したり、引用を保証したりするものではありません。

したがって、実装は制御可能なものに基づいて評価します。マークアップが可視テキストと一致しているか、JSON-LD が検証に合格しているか、ページが技術的な障害なくアクセス可能か、主要な主張が明確なソースによって裏付けられているか。引用がないことをコードの誤りの証拠と見なさないでください。まずページ自体と構造化情報の正確性を個別に確認します。

構文と機能のサポートを区別することも重要です。有効な JSON-LD は、すべてのタイプやプロパティが Perplexity によって均等に使用されることを意味しません。架空のレビューをマークアップしたり、想定される利点のためにのみプロパティを追加したりしないでください。サービスのルールと回答生成方法は変更される可能性があり、ソースの更新頻度はサイト所有者が設定するものではありません。

技術的確認の後に体系的な作業が必要な場合は、マークアップを Perplexity での可視性最適化 のタスクや Technical AEO の一般的な資料と照合します。

いつ監査とサイト開発を依頼すべきか？

マークアップが複数のテンプレートで生成されている場合、製品に関する事実がページ間で食い違っている場合、またはサイトの変更が定期的に JSON-LD を壊す場合は、専門家に依頼します。そのような状況では、より多くのタイプを追加するよりも、データの所有者、真実のソース、リリース後の確認プロセスを定義することが重要です。

自己準備のために、重要なページの URL、最新の名前と説明、著者情報、ドキュメントやプロジェクトの公式プロフィールへのリンクを収集します。次に、ページ、適切なタイプ、主要プロパティ、各事実のソース、更新責任者をまとめた表を作成します。これにより、開発者は適切なテンプレートにマークアップを実装でき、編集者は公開テキストとの一致を確認できます。

MediaHype は、技術的マークアップと AI検索での全体的な可視性を結びつけるのに役立ちます。構造監査からコンテンツ確認、ページのアクセス可能性まで対応します。サイト実装の作業が必要な場合は、Web3 向けサイト・LP 開発サービス をご覧ください。構造化データやその他の技術的シグナルの計画には Technical AEO が適しており、一般的なアプローチは AI search visibility セクションにまとめられています。

重要なページ1つから始め、結果を確認し、更新ルールを確定します。その後、同じエンティティタイプが実際に適切な他のページにテンプレートを拡張します。