Falcon Information — ホームに戻る

Schema.org 構造化データに関するチュートリアル|JSON-LD、検証、および一般的なエラー

Schema.org は、検索エンジンがウェブページの構造を明確な形式で理解できるようにするためのものであり、検索順位の保証や、AI による検索に必要なものではありません。 少ない情報で正確であることが重要であり、マークアップされた内容はウェブページ上で確認できる必要があります。

まず、Schema.org と Google 検索機能の違いを明確にする必要があります。

Schema.org は、エンティティと関係性を記述するための共通の用語を提供します。Google は、これらの用語の一部のみを、特定の検索結果の表示形式の基準として利用しています。ウェブサイトは、有効な Schema.org 属性を使用できますが、これによって Google が必ず豊かな検索結果を表示することを保証するものではありません。実装前に、ウェブページの主要なコンテンツ、Google が対応する機能のサポート状況、および十分な情報が正確に記述されていることを確認することが重要です。

このウェブサイトで実際にどのような種類のコンテンツが利用されていますか?

Falconは、ブランド、ウェブサイト、著者、およびページの内容を、共通のエンティティ識別子で一元的に管理します。

  • 団体名:ブランドのアイデンティティと公開連絡先
  • ウェブサイト:ウェブサイトと発行者の関係
  • サービス:提供されるサービス範囲と提供者
  • 記事:記事の内容(著者、掲載日など)
  • パンくずナビ
  • プロフィールページ/個人:実名による著者と公開されている専門的なつながり
  • 創作物:事例の内容と証拠の開示

JSON-LD はどのように実装・導入すべきでしょうか?

Google は JSON-LD の利用を推奨しており、Microdata や RDFa もサポートしています。Next.js では、サーバーサイドで生成される HTML に `application/ld+json` スクリプトを配置できます。重要なのは、`<head>` または `<body>` の形式の違いではなく、データが検索エンジンによって取得可能であり、JSON が解析可能であること、URL が正式な canonical 形式で指定されていること、そして各フィールドがページの主要なコンテンツまたは明確な関連情報で検証可能であることです。共有エンティティを使用する場合は、一意な `@id` を使用し、同じページで複数の競合するエンティティが生成されないようにする必要があります。

画面の内容に基づいてスキーマを構築する順番

まず、テンプレートを生成するのではなく、まず既存の文章を参考にすることをお勧めします。より安全な手順は以下の通りです:

  • 確認ページの主な目的と、canonical(正規化)ページの実際の表示内容
  • Google がサポートしており、主要なコンテンツと関連性の高いカテゴリを選択してください。
  • 既存の著者、日付、画像、サービス、または事例に関する情報のみを反映する。
  • Google の機能について、Rich Results Test で確認し、一般的な文法については Schema Markup Validator で確認する。
  • 上流で取得したURLを使って、Googleが実際に取得したHTMLを確認する。

よくある間違い

  • 虚偽の集約評価(例:自己評価 4.9 / 50件レビュー)への参加— Googleの高品質検索結果ポリシー違反
  • スキーマの内容と実際のページのコンテンツが一致しない場合、Googleはリッチな検索結果を表示しません。
  • 実店舗を持たない場合に、LocalBusinessの住所や営業時間などの情報を掲載
  • ECサイトでは、FAQページ、HowTo、Speakableを、一般的なリッチコンテンツやAIによる引用のショートカットとして扱っています。

よくある質問、HowTo、Speakable が混在するのはなぜですか?

「よくある質問」のFAQは、依然としてユーザーにとって有用ですが、Googleの「よくある質問」の充実した検索結果は、主に政府や医療機関などの信頼性の高いウェブサイトに限定されています。また、「HowTo」の充実した検索結果は表示されなくなっています。SpeakableのGoogleドキュメントは、特定の報道機関での利用に限定されています。これは、ウェブサイトが質問や手順の内容を使用できないという意味ではなく、一般企業に対して、簡単なタグ付けで充実した検索結果やAIによる引用が得られると約束することは適切ではないということです。

試験に合格したからといって、必ずしもその結果が正しく表示されるとは限らない。

「リッチリザルト」の合格は、技術的な形式と一部の要件を満たしていることを意味しますが、Googleは依然として、検索状況、品質基準、およびページの代表性に基づいて、表示するかどうかを決定します。構造化されたデータが誤解を招く場合、または隠されたコンテンツのマークアップが不適切である場合、またはポリシーに違反する場合、ページは「リッチリザルト」の資格を失う可能性があります。最悪の場合、検索コンソールで構造化データの人工処理が行われることもあります。これは、通常の自然なランキングが必ず低下することを意味するものではありませんが、誤ったマークアップは価値を失う可能性があります。

参考文献

よくある質問

スキーマの誤った記述は、どのような罰則が科せられますか?
構造化されたデータが、ポリシーに違反したり、誤解を招いたりした場合、そのデータは「高品質」の資格を失う可能性があり、人工的に処理される可能性もあります。一般的なリスクとしては、ユーザーが見えないコンテンツを埋め込んだ自己評価、ユーザーが見えない情報をマークするなど、架空の事業者や著者を設定することが挙げられます。
JSON-LD、Microdata、RDFa のうち、どれを選ぶべきか?
Google は、3つの方法での都支援を提供しており、公式推奨のJSON-LDは、以下の利点があります。; 画面のHTMLから分離できるため、メンテナンスが容易; レイアウトが崩れる心配がない ただし、既存のシステムでMicrodataが広く利用されている場合は、新しいプロジェクトでJSON-LDを導入するのではなく、既存のシステムを優先する方が良いでしょう。
構造化された資料には、すべてのページに情報を記載する必要があるのでしょうか?
ページの種類に応じて、以下のいずれかを選択します。; 組織とWebサイト全体で共有; 記事ページには「記事」、サービスページには「サービス」というラベルを付与; 階層構造のあるページには「パンくずリスト」を付与 画面の内容とは関係のない種類のページには、無理にラベルを付与しないこと。ラベルを付与しない方が、誤ったラベルを付与するよりも良い。

関連するご要望はありますか?

お問い合わせ