Yandexのバリデーター用のAPI。 また、なぜマイクロマーキングバリデーターが異なる答えを出すのですか？

少し前に、マイクロマーキングバリデータ用のAPIをリリースしました。 そして今日、APIとバリデーターの両方についてお話ししたいと思います。 たとえば、異なるバリデータの結果が異なる理由を理解するため。

バリデータには多くの種類があり、さまざまな目的のために設計されています。 一般的に、それらは2つのタイプに分けることができます：ユニバーサルとスペシャライズド。 Universal- 検証 ツール 、Googleの構造化データテストツール 、 Validator.nu 、 構造化データリンター 、Bingのマークアップ 検証ツール -いくつかのマークアップ標準を一度にチェックします。 同時に、検索エンジンのバリデーターは、それに基づいた製品のドキュメントへの準拠についてもマークアップをチェックします。 JSON-LD PlaygroundやOpen Graph Object Debuggerなどの特殊なバリデーターは、標準自体の開発者によるツールです。 Open Graph Object Debuggerを使用すると、Open Graphレイアウトが正しいことを確認でき、JSON-LD PlaygroundはロボットがJSON-LDレイアウトをどのように理解するかを示します。



さまざまなマークアップの例を取り上げ、これらのバリデーターの回答を比較して、最適なものを見つけました。

1.メタ以外のタグのコンテンツを使用します。
microdata仕様では、メタタグ以外の属性でコンテンツを使用することは許可されていません。 しかし最近、そのような使用法がますます頻繁に発見されているため、さまざまなバリデーターがそのような例を分析するのを見るのは興味深いです。

レイアウトの例：

<div itemscope itemtype="http://schema.org/Review"> <div itemprop="dateCreated" content="2015-06-07 20:10:47"> :  20:10</div> </div> 

Yandexバリデーターは、メタ以外のタグのコンテンツを無視します（現在、これが一般的になっているため、パーサーとバリデーターの両方でこのデザインを使用する機能を追加しています）。



Google Validatorは製品エラーを生成します。



Validator.nuは、タグでcontent属性を使用できないことを警告し、使用できる属性を確認することを提案します。



Yandexバリデーターのような構造化データリンターは、コンテンツを無視し、間違った時間形式について警告します。



どうですか？ この質問も行っています。 最近まで、マイクロデータ仕様の要件を無視すべきではないと考えていました。 しかし、この動作はSchema.orgのドキュメントの例でよく見られるという事実により、バリデーターでそのようなケースをよりソフトにチェックし、検索でコンテンツ属性からのデータを使用します。

2. Open GraphとApplinksマークアップを含む記事 。

Open Graphは、ソーシャルネットワーク上のリンクの表示をカスタマイズするのに役立つ有名なマークアップであり、 Applinksは、クロスプラットフォームアプリケーション通信の人気が高まっている標準です。 バリデーターがどれだけ精通しているか見てみましょう。

Yandex.Validatorは、見つかったすべての結果を表示します。 同時に、明示的に定義されていないalプレフィックスについて警告します。



Google Validatorは、Applinksマークアップのみを表示し、Open Graphやその他のマークアップは表示しません。 エラーはなく、alプレフィックスはデフォルトプレフィックスとして認識されます。



構造化データリンターはRDFaを展開せず、HTMLエラーおよびog：urlの無効なデータ型を警告します。



Open Graph Object Debuggerはvk：app_idについて警告します。 どうやら、彼は彼の外国の性質のために彼について知らない：



Applinksも認識します。



Validator.nuは、このページをチェックするときに結果を返しません。

どうですか？ 規則により、RDFa仕様で定義されていないすべてのプレフィックスは、prefix属性で明示的に指定する必要があります。 しかし、コンテンツ属性の場合のように、実践は常に理論と一致するとは限りません。 また、Vk.comなどの多くのマークアップコンシューマーは、明示的なプレフィックス参照を必要としません 。 そのため、最近、最も一般的なプレフィックス（vk、fb、twitterなど）の一部をデフォルトのプレフィックスと見なし始め、それらについての警告を停止しました。 その他（たとえば、al）はデフォルトでプレフィックスのリストにまだ追加されていないため、ウェブマスターがそれらを明示的に定義することを期待しています。 いずれにしても、ページで使用するすべてのプレフィックスを明示的に指定することをお勧めします。

3. Schema.org以外のコンテキストを使用したJSON-LDマークアップ。

レイアウト例：

 { "@context": "http://asjsonld.mybluemix.net", "@type": "Post", "actor": { "@type": "Person", "@id": "acct:sally@example.org", "displayName": "Sally" }, "object": { "@type": "Note", "content": "This is a simple note" }, "published": "2015-01-25T12:34:56Z" } 

Yandex.Validatorはコンテキストを拡張します。



Google Validatorは、コンテキストをexample.comに置き換えます。



JSON-LD Playgroundは、Yandex.Validatorと同じ方法で解析します。



残りのバリデーターはそのような例を明らかにしていません。 ここでは、最良のテスト結果が明らかであると思われます。

4. JSON-LDと空のコンテキストの例。

レイアウト例：

 <script type="application/ld+json"> { "@context": { "name": "", "description": "http://schema.org/description", "image": { "@id": "http://schema.org/image", "@type": "@id" } }, "@type": "Article", "author": "John Doe", "interactionCount": [ "UserTweets:1203", "UserComments:78" ], "name": "How to Tie a Reef Knot" } </script> 

JSON-LD Playgroundは空のコンテキストを警告します：



Yandex Validatorは、このようなコンテキストを拡張することは不可能であることも警告しています。



Googleのバリデーターは、コンテキストの代わりにwww.example.comを使用しており、エラーはありません



どうですか？ ここで最も正直に見えるのはJSON-LD Playgroundです。 この記事の執筆中にそれらを確認し、同様の警告を表示し始めました。

さまざまなバリデータを比較することは非常に興味深く有用であることが判明したため、私たち自身はその結果に驚きました。 そして、いくつかの例の後、彼らはバリデータを改善するために逃げました:)一般に、どのサービスが最良であるかを言うことは困難です：各バリデータは独自の方法で同じ問題を解決します。 そのため、バリデーターを選択する際には、これを念頭に置き、マークアップを追加した目標に集中することをお勧めします。

検証の自動化が必要な場合は、多くのAPIユーザーを歓迎します。 すでに、検証APIはさまざまなプロジェクトで使用されています。 まず、これらはAPIを使用して自動的にマークアップをチェックする多数のページを持つ大規模なサイトです（そのほとんどは商品です）。 さらに、APIを使用して最適化の観点からサイトの状態を監視するサービスは、マイクロレイアウトの存在と正確性に関する情報を表示します。

一般に、マイクロマーキング検証APIを使用すると、次のことができます。

• 多数のページでマイクロレイアウト検証を自動化します。
• さまざまなCMSのプラグインを開発します。
• プロジェクトで使用するためにサイトから構造化データを抽出します。

APIには、通常のバリデーターと同じバンがあります：

1. バリデーターは、 Microdata 、 RDFa 、およびJSON-LDの基本標準の仕様にあるすべてのエラーをチェックします。 JSON-LDは2014年5月に最初にテストされ、その後、この標準がどの検索エンジンバリデータでもサポートされなくなりました。
2. バリデータは標準エラーだけでなく、製品エラーも報告します。 ほとんどの場合、ウェブマスターはマークアップを追加して、アフィリエイトプログラムに参加するために使用します。 したがって、検証プログラムは、マークアップがアフィリエイトプログラムのドキュメントと一致しない場合に報告します。
   
3. バリデーターは仕様への準拠を非常に厳密にチェックしますが、どこでも修正が使用されるようになった場合は、厳格さからユーザーに向かっていきます。 たとえば、最近では、schema.orgで広く使用されるようになったため、meta以外のタグでcontent属性を使用しないことにしました。 また、Open Graphでは、明示的な指示なしに、最も一般的なプレフィックスであるfb、og、vkを受け入れ始めました。 上記のような例を調べました。

仕様といえば、APIの開発時に、標準自体が必ずしも標準に対応するとは限らないことを示す興味深い事実を発見しました。

これは、今日RDFa構文で使用されている最も人気のある辞書-Open Graphです。 ソーシャルネットワークの外観を制御するためにリンクを使用することの明白な利点と実装の容易さという2つの主な理由により、非常に人気がありました。 Open Graphが一連のメタタグを使用してヘッドブロックにマークアップを配置することを推奨しているという事実により、実装が容易になっています。 ただし、これには特定の制限があります。 その1つは、ネストと配列の実装です。 古典的なRDFaでは、ネストはHTMLタグの階層に基づいて決定されます。 この場合、RDFaのプロパティの順序は無視されます。 HTMLタグはネストできないため、Open Graphでのネストは通常​​とは異なる方法で実装されます。 ネストされたプロパティを指定する必要がある場合は、親の後ろのコロンの後に示されます。 たとえば、画像のURL（og：image）は、og：image：urlを使用して設定されます。 このようなプロパティは、仕様では構造化と呼ばれます。 構造化されたプロパティの配列を指定する場合は、正しい順序で指定するだけです。 たとえば、次の例では3つの画像があります。 最初のものの幅は300、高さは300で、2番目の寸法については何も言われておらず、3番目の高さは1000です。

 <meta property="og:image" content="http://example.com/rock.jpg" /> <meta property="og:image:width" content="300" /> <meta property="og:image:height" content="300" /> <meta property="og:image" content="http://example.com/rock2.jpg" /> <meta property="og:image" content="http://example.com/rock3.jpg" /> <meta property="og:image:height" content="1000" /> 

APIバージョン1.0では、RDFaパーサーを改良して公式仕様に完全に準拠しました（以前は、一部の複雑なケースは完全に正しく処理されませんでした）。 テスト中に、構造化プロパティが非常に奇妙な方法で処理されることがわかりました。 ポイントは、RDFaのHTMLコード内の位置は絶対に重要ではないということです。 開発者の最初の反応は、Open Graphの間違った構文に反発し、それらを呼び出して注文することでした。 しかし、もちろん、すべてを修正しました。

この例は、マイクロマーキングの世界がいかに複雑で矛盾しているのかをもう一度示しています:)私たちの製品が、それで働く人々の生活を改善することを願っています。

バリデータAPIについて質問がある場合は、コメントで質問するか、 フィードバックフォームを使用してください。 APIの魔法の鍵はここで入手できます 。

サイトをマークアップし、レイアウトを確認し、美しいスニペットを取得します-そしてすべてがうまくいくようにしてください:)