私はJSON-LDマークアップを持っています(Googleのガイドラインに従って):
Website
ロゴ付きLocalBusiness
とAggregateRating
およびReviews
Breadcrumbs
突然、私はすべてのスキーマがウェブサイトが翻訳されているすべての言語の翻訳されたコピーを持っていることに気付きました。 Breadcrumbs
では問題ありませんが、LocalBusiness
ではそうではありません。これは、評価が重複する重複があるためです。
複数の言語でマークアップを処理する方法に関するGoogleの公式ドキュメントはあまり見つかりませんでした(見つけたのはマークアップではなく、ページとコンテンツに関連するものでした; hreflang
とサイトマップを使用して翻訳済みページについてGoogleに伝えることは、 LocalBusiness
json-ld、それらは異なる方法で処理されます)。
翻訳されたスキーマに最適な戦略は何ですか?
LocalBusiness
スキーマを1つの言語で保持し、翻訳されたコピーを削除しますか?@SameAs
を使用して、翻訳済みのLocalBusiness
スキーマを保持しますか?もしそうなら、Googleはそれらが翻訳であることを理解できますか?LocalBusiness
ごとに異なる@id
を作成しますか?localBusinessはどこでも1つの言語で維持しますが、サイトの異なる言語バージョンでは、次のように言語定義を追加します。
<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "LocalBusiness",
"mainEntityOfPage": {
"@type": "WebPage",
"url": "http://example.com/de/",
"inLanguage": "de"
}
}
</script>
Hreflang属性で使用するURLをurlとして使用してください。これにより、矛盾は生じません。
(私が知る限り、Google Searchはそのような場合のガイドラインを公開していません。)
翻訳されたページから構造化データを削除することは有益ではないと思います。
構造化データに関心がある消費者(人間でもボットでも)は、必ずしも他の言語でページをクロールする必要はありません。これらの消費者は、構造化されたデータを提供していることすら気付かないでしょう。
ページに豊富な結果を表示することを決定した検索エンジンは、翻訳されたページにも表示することに興味があるかもしれません。そして、これを実行し、リッチ結果に作成者が提供したテキストが含まれる場合、データがページの言語でもある場合、検索エンジンは翻訳ページにリッチ結果のみを表示する可能性があります。
@id
同じ組織であるため、@id
も同じである必要があります。
これは、主要な @id
の目的 の1つであり、異なるノード(異なるサイト/ページ、異なる言語など)がほぼ同じエンティティであることを伝えます。
@language
JSON-LDでは、 文字列値の言語を指定@language
を使用できます。 (これにより、すべての言語のデータを含む1つのノードを持つこともできます。)
ただし、少なくともGoogleのSDTTは@language
をサポートしていないようです。 Google検索自体にも当てはまるかどうかは明らかではありません。 Google検索が@language
をサポートしていないと仮定すると、とにかくそのような言語の注釈を提供しても問題ありません。おそらく無視されます。
inLanguage
Evgeniyのメモとして 、Schema.orgは inLanguage
プロパティを定義します。これにより、(LocalBusiness
自体ではなく)クリエイティブな作品の言語を指定できます。
このプロパティは、すべてのWebPage
および/または各言語のWebSite
アイテムに指定できます。
workTranslation
/translationOfWork
WebPage
(および場合によってはWebSite
)アイテムが翻訳されていることを伝えるには、Schema.orgのbib拡張の workTranslation
/ translationOfWork
プロパティを使用できます。