web-dev-qa-db-ja.com

検索エンジンがrel = "alternate"またはscript srcを介して分離されたエンドポイントとしてJSON-LD + Schema.orgをサポートしないのはなぜですか？

そのため、JSONの概念全体は、単純なテキスト形式で表示されるオブジェクト->配列を中心に展開されます。 LDバリアントも同様です。 Schema.orgと組み合わせると、従来のフィードと非常によく似た、多くのものが消費できる柔軟な表示APIに変わります。ただし、フィードとは異なり、主にページ上のインラインスクリプトデータとして検索エンジンによって消費されるため、独立したAPIや自動化の観点からは面倒で面倒です。

では、なぜ検索エンジンは、サイトにインラインデータを使用するよう強制することに関して、JSON-LD + Schema.orgがAPIに反することを望んでいるのですか？人間が見るためのメインコンテンツなどの重複データを使用してコードをさらに大きくし、JSON-LDスクリプト内で個別に再定義する必要があるのはなぜですか？つまり、LDがセマンティックな消費を目的としている場合、なぜLDオブジェクトを別のページ、ルート、またはファイルに配置できないのでしょうか。ソース内のデータの複製は、特に長いコンテンツの場合、私を夢中にさせます！

現在のところ、検索エンジンのバリデーターは次のユースケースを理解していません。

  • Example.comには、https://www.example.com/this-product-nameのようなURLを持つ各製品の完全なテンプレートページがあります。このページは、すべての付加機能を備えた検証済みのHTMLです。テンプレートビュー内にSchema.orgマークアップは含まれません。

  • Example.comには、コントローラーから直接提供されるJSON-LD生成関数もあり、各製品のAPIエンドポイントを作成します。返されるのは、JSON形式のLDオブジェクト->配列だけです。テンプレートはありません。これはすぐに使用でき、アグリゲーターでXMLフィードが機能する方法に似ています。 /jsonをURLに追加すると、完全なテンプレートページではなく、この種のLD AP​​Iオブジェクトレスポンスがレンダリングされます。ルートは次のようになります：https://www.example.com/this-product-name/json

  • 各製品の完全なテンプレートページには、上記のalternate LDエンドポイントを指す<link />の<head>が含まれています。これはATOMフィードが動作するのと同じ方法で、訪問者にフィードリーダーが使用する「データの代替形式」を指定します。したがって、LDの代替は次のようになります。<link rel="alternate" type="application/ld+json" title="This Products Consumption API (JSON-LD + Schema.org)" href="https://www.example.com/this-product-name/json"/>

  • JSON-LDレスポンスには、sameAsおよびpotentialActionのようなものが含まれ、ページの完全なテンプレートバージョン（上記の最初の箇条書き）を指し示します。これは、ATOMがalternateがどのように動作するかに似ています...代替の輪を作ります。

  • ATOMフィードにはこれらの代替も含まれ、/jsonエンドポイントを公開します。基本的に、テンプレートページ、JSON-LDエンドポイント、ATOMフィードなどの間で3つ（またはそれ以上）の方法があります。すべてのデータは同じで、目的に応じて消費形式を表示する方法が異なります。 。

  • スニペットテストで https://www.example.com/this-product-name を実行すると、<script type="application/ld+json" src="https://www.example.com/this-product-name/json"></script>などのスクリプトsrcへのパスを含めても、「構造化データが見つかりません」という結果になります。 。消費エンドポイント https://www.example.com/this-product-name/json を実行すると、正しい検証が行われます。

それは単なる検証ツールですか、それともボットに代替同化を理解させる方法は本当にありませんか？ そこに任意のJSON仕様自体がそうであるように、テンプレートページからJSON-LDを取得して別のAPIルートに入れる方法があります検索エンジンが健全なエンドポイント能力を許可する代わりにインラインで排他的に配置するLDを必要とする大きな理由を見逃していますか？

schema.orgstructured-datajson-ldrel-alternateknowledge-graph
6
dhaupin

その答えは実際には非常に簡単です。スパイダーはページを取得し、そのページとそのページのみを処理します。他のリソースへのリンクは、別のスパイダーがアクセスするためにキューに入れられます。検索エンジンは、ソースを持つスクリプトタグを無視します。設計上のJavascriptにはではなくが含まれており、検索エンジンはデータに飢えています。

Itemscopeおよびitempropよりもjson-ldを使用することの主な利点は、マークアップ自体がmicrodataで乱雑にならないことです。

「生の」データをページに含めたくない場合は、RFDaスキーマの使用を検討する必要があります。スキーマをリンクに指定できますか。

個人的には、可能な場合はMicroFormatsを使用します。これは、これらのプロパティがCSSクラスとして偽装されているため、すべてのmicrodata形式の中で最も邪魔にならないことがわかるからです。実際にスタイリングを割り当てるクラス。

2
Swordfish