場所フィールドが単なるテキストである場合、イベント構造化データが有効かどうかを判断しようとしていますが、矛盾する答えが見つかりました。
例:
<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "Event",
"startDate": "2013-09-14T21:30",
"name": "Name of the event",
"location" : "Some place"
}
</script>
Googleのリッチスニペットガイド これは許容されることを明示的に述べています(推奨されません):
テキスト文字列は許可されますが、ネストされた場所または組織を使用して場所を表し、会場名とその住所を個別に指定することをお勧めします。
しかし、上記のデータをGoogle独自の構造化データテストツールに貼り付けると、「場所」をオブジェクトとして解釈し、アドレスがないため拒否します。
location [Thing]:
name: Some place
address: missing and required
schema.orgは、有効なタイプはPostalAddressまたはPlaceのみであり、プレーンテキストではないことを示唆しています。
http://linter.structured-data.org/ のリンターは、エラーなしでデータを受け入れます。
明確なルールはありません、ネストされた場所の代わりに文字列を使用してはいけないと言っています。ただし、Googleは最も信頼性の高いデータを提供することを望んでいるため、テストツールにエラーを投稿します。
私の経験では、Googleは適切な場所を使用することを望んでいます。したがって、Googleガイドのように配信される実際の住所が要求されます。
<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "Event",
"startDate": "2013-09-14T21:30",
"name": "Name of the event",
"location" : {
"@type" : "Place",
"sameAs" : "http://www.hi-dive.com",
"name" : "The Hi-Dive",
"address" : "7 S. Broadway, Denver, CO 80209"}
}
</script>
Schema.orgの仕様にもかかわらず、Googleは高品質のデータを受信するためにこの追加要件を採用することを決定しました。彼らのガイドとして 1 は言う:
werecommendネストされたPlaceまたはOrganizationを使用して場所を表し、会場名とその住所を個別に指定することをお勧めします。
「ある場所」のような単純な文字列を配信すると、Googleはデータを受け入れない場合があります。さらに、コード内の実際の場所を認識しない場合、スパムのリッチスニペットに対する手動アクションを提供する場合があります。
Google向けにデータを最適化してテストするときは、テストツールを使用してください。 structure-data.orgのライナーは正常に機能しますが、Googleの要件を尊重しません。
要約すると:
サンプルコードはschema.org仕様と一致するため、有効です。しかし、Googleは、より詳細なデータを提供することをお勧めし、場所の単純な文字列ではなく、ネストされた場所または組織を要求します。