企業や人々のためにSchema.org構造化データを使用する方法
公開: 2020-02-26この記事では、Schema.orgの構造化データとは何か、EATを構築するためにそれが不可欠である理由、およびその膨大な範囲のタイプと属性を活用して明確で正確なデータを検索エンジンに伝達する方法について説明します。
EATとは何ですか？
Expertise、Authority and Trust、またはEATは、検索エンジンが特定の検索クエリに対して表示するのに最適なサイトを決定するために使用する主要な基準の1つです。 構造化データを使用すると、あなたが誰で何をしているのかが非常に正確にわかり、サイトへの信頼が高まります。 専門知識と権限を示す追加データを含めると、信頼が高まり、サイトのランクが上がります。
「YMYL」、またはあなたのお金、あなたの人生として知られているさらなるレベルがあります。これには、特に金融と健康を扱っているすべてのサイトが含まれます。 このカテゴリの場合、Googleは非常に厳格であり、これらの主題について話す資格があり、有能であることを示す情報を必ず含める必要があります。
あなたは疑問に思うかもしれません：
構造化データとは何ですか？
構造化データは、機械が理解できる標準化された形式で提示される情報です。
インターネットが存在するには、構造化データが必要です。 構成するすべてのマシンが相互に通信できるようにするために、そのすべてのプロトコルと言語（HTTP、TCP、TLS / SSL、PHP、Javascriptなど）は、厳密に合意された構造を持っています。
これに対する大きな例外は、Webサイトページの表示可能なテキストコンテンツに入力する情報です。 データのレイアウト方法を管理するルールはありません。 検索エンジンはそのコンテンツを見ると、テキストのチャンクを分析して、特定の種類のデータとして識別できるものを探します。 しかし、それは常にある程度の不確実性を伴います。 たとえば、次のような標準アドレスを使用します。
Amazing Stuff Inc、39 Main Street、34000 Newtown、France
この特定の住所形式を使用する場所の人間は、これが住所であることを即座に確認できます。 しかし、あなたが別の住所形式を使用している世界の別の地域の誰かであると想像してください。 住所のすべての部分が何であるかを理解できますか？ これが機械の場合です。
検索エンジンの人工知能は、これがおそらく住所のように見えることを認識し、さまざまな要素を抽出できるようになりましたが、それでも100％確実ではなく、他の多くのソースからの確証が必要です。推測した。 ただし、構造化データは、「streetAddress」などの標準化された名前とそれに割り当てられた値（この場合は「39、Main Street」）で構成されるペアで構成され、検索エンジンはhtmlコードをスキャンしてこのタイプを探します名前付きデータの。
オンクロールデータ³
もっと詳しく知るしたがって、問題は、Webページの情報が人間の目には構造化されているように見えるかもしれませんが、マシンではまったく構造化されていないことです。 彼らは推測しなければなりません！
実際には、これについて何ができるでしょうか。
Schema.orgは、構造化データをWebサイトでマークアップできるようにするユニバーサルスキーマのシステムを提供するために、Google、Bing、およびYahooによって2011年に開始されたイニシアチブの一部です。 検索エンジンが「 @context」：「http://schema.org/ 」という行を見つけると、認識できる名前付きのSchema.orgデータペアの検索を開始します。
次のように、スキーマ構造化データをhtmlの<head>セクションに挿入できます。
JSON-LD形式の構造化データ
そして、これは検索エンジンがページを分析するときにそれをどのように見るかです：
Googleの構造化データテストツールの構造化データ
そんなにはっきりしていませんか？ 検索エンジンのアルゴリズムは、構造化データの各ビットのIDと役割について100％確実になりました。 これは彼らの生活をはるかに楽にし、あなたが誰であるか、あなたが何をするかについて彼らが持っている信頼のレベルを高め、あなたのEATを高め、あなたのランキングを向上させます。
組織の基本的なスキーママークアップ
最も基本的なスキーマから始めて、次にいくつかの追加の最適化を見ていきます。
まず、組織の種類を定義する必要があります。 Schema.orgシステムはタイプと呼ばれるものの階層であるため（ここで確認できます）、最も一般的なタイプから始めて、タイプが見つかるまで階層を深く掘り下げることができます。 最も一般的なタイプはThingであり、多数の幅広いサブタイプが含まれ、そのうちの1つがOrganizationです。 図3に示すように、組織には、 Corporation 、 LocalBusiness 、 EducationalOrganizationなどの他のタイプが含まれています。
タイプ階層の一部
LocalBusinessには多数のサブタイプがあるので、さらに深く掘り下げることができますが、ローカルビジネスでない場合は、おそらく企業であるため、それを確認できます。 株式会社のページを見るにはここをクリックしてください。
Schemaブロックは次のようになります。
法人タイプ
これは素晴らしいことであり、構造化データテストツールでエラーが発生することはありませんが、会社について何も教えてくれないため、いくつかの属性またはそれを説明するデータを提供する必要があります。
Corporationページでは、受け入れられた属性がいくつかあることがわかります。 検索エンジンがタイプを確認すると、そのタイプで受け入れられている特定の属性を検索するため、属性名のスペルを正しく設定することが重要です。 属性名は小文字で始まり、タイプ名は大文字で始まります。
[ケーススタディ]リンクを最適化して、ROIが最大のページを改善します
ケーススタディを読む一部のタイプには1つ以上の必須属性があります。LocalBusinessタイプ（またはLocalBusinessのサブタイプ）を選択すると、少なくとも名前と画像のURLが必要なため、テストツールにエラーが表示される場合があります。
欠測データのエラー
これが発生した場合は、マークアップの誤りを避けるために、少なくとも下の図6のように必要なデータを提供してください。そうすれば、追加のデータを追加できます。
エラーは修正されました
この記事の残りの部分では、私が過去にマークアップした会社であるsunfimmo.comの例を取り上げます。 これはフランスの会社ですが、検索エンジンが認識できるように、属性名は常に標準化された英語の形式になっていることを忘れないでください。
同社は不動産会社ですが、実際に訪問できる不動産会社がないため、 LocalBusinessタイプの1つになることはできません。 RealEstateAgentを使用する代わりに、それらのタイプはCorporationである必要があります。 基本的なマークアップは次のようになります。
企業向けの基本的なSchema.org
これで、会社に関するいくつかの優れた基本データが得られました。 リーガル名は取引に使用される名前と同じではないことに注意してください。これは重要です。後で公式の会社登録リストへのリンクを追加し、正確性に自信を持たせるにはデータを同じにする必要があるためです。データ。 住所と電話番号についても同じことが言えます。 彼らはどこでも同じである必要があります！
連絡先
会社に複数の連絡先がある場合（異なる町、地域、または国に）、それらもマークアップできます。 この会社には2つのオフィスがありますが、同じ電話番号を共有しているため、次のようにグループ化されています。
ContactPointの基本的なSchema.org
タイプ（ここではContactPoint ）が属性の値として使用される場合、中括弧で囲まれたブロックとしてマークアップされることに注意してください。 これは構造化されたデータです！ 属性に複数の値がある場合は、コンマで区切って角かっこで囲むことができます。
組織の追加のスキーママークアップ
追加タイプ
以前の記事で、会社がローカルビジネスではないため、 RealEstateAgentとしてマークアップできないことを確認しましたが、 Productontologyシステムを使用することで、構造化データ形式の特定のタイプの不動産エージェントがあることを示すことができます。 ここでは詳しく説明しませんが（手順はここにあります）、これを行うことができます。
productontologyを使用する
また、ウィキペディアへのリンクをsameAsブロックに配置することもできます。
sameAsを使用する
信頼性を高めるための公式ページへのリンク
現在、会社の基本的な詳細をマークアップし、より具体的なタイプを提供しています。 しかし、私たちは信頼と信頼を高め、会社が本物であることを示したいとも思っていることを忘れないでください。 これを行うために、自分で変更できないデータを含む公式ページにリンクすることができます。これにより、たとえば、基本的に誰もが欲しいものを主張できるソーシャルネットワークアカウントよりもはるかに信頼性が高くなります。
ここフランスでは、すべての企業が正式な登録番号（ "SIRET"）と、事業を行っているセクターのコード（ "CODE NAF"）を持っています。 したがって、実際には次のようなカスタムブロックを作成できます。
「これは公式の識別子です。これはいわゆるものです。これはその価値です。これはそれを説明するウィキペディアのページです。これはリストのある公式の管理ページです」：
Schema.org識別子を使用する
さらに「公式」情報を裏付けるために、次のようなsameAsブロックで、関連するアクティブなソーシャルアカウントとともに、会社情報リストページへのリンクを提供できます。
もっとsameAsリンク
専門知識と権限を高めるために個人のスキーマデータを追加する
Corporationのスキーママークアップのメインブロックを作成し、その信頼性と信頼性を高めるために多数のデータを追加しました。 権限と専門知識を高める良い方法（これはすべてEATに関することです）は、1人以上の人とその資格情報を含めることです。 これを行うには、次のようにPersonブロックを含めることができます。
人のためのSchema.org
ここでは、創設者がJean-Bernard Huetという人物であると言っています。次に、彼のLinkedInアカウントを提供し、彼が2つのEducationalOrganizationの卒業生であり、取得した特定の卒業証書のページへのリンクがあることを示します。 1つは不動産法です。 彼の専門的な信頼性を高めるために、会社のように識別子ブロックを含めることができますが、今回は彼の不動産業者のライセンス番号を定義し、それが何であるかを説明する公式ページと、公式の商工会議所のリストページにリンクします。
人のSchema.org識別子
そのため、マシンが簡単に理解できるように特別に設計された形式で、非常に正確な大量のデータをGoogleに提供しました。
1つの問題は、ブロックが巨大になり、すべてのページのすべてのスキーマブロックですべてが必要なわけではないエンティティ内にエンティティが含まれていることです。 Personとそのすべての情報を含めたいが、 Personブロック全体を毎回含める必要はない、 founders属性のSchemaマークアップブロックの例を見てみましょう。 これが@idの出番です。@idを使用してPersonブロックを定義したら、その@idをfoundersブロックに含めることができます…
エンティティのSchema.org@id
…そしてGoogleは、構造化データツールツールで確認できるように、 @idを介してエンティティをリンクします。
グーグルがこのブロックをどのように見るか
同じページに複数の異なるスキーマブロックを含めるにはどうすればよいですか？
ブロックの管理をより体系的にするために、ブロックを個別のブロックとして@graphのようなコンテナ要素に配置し、次のように@idを使用してそれらをリンクすることができます。
複数のブロックに@graphを使用する
@id属性を介してリンクされた明確で正確なデータの構造化されたブロックがあり、Googleや他の検索エンジンに、あなたが誰であるか、何をしているのか、ページを適切に機能させるために必要な専門知識と権限がある理由を正確に伝えます。検索結果でランク付けされました。 検索エンジンがあなたのサイトを理解し、彼らの作業負荷を減らすのを助けるためにあなたがすることができることは何でもあなたのサイトに利益をもたらします。
最後の言葉
スキーマのマークアップは広大なテーマであり、EATを高めるために構造化データのレビューと評価をマークアップする方法は言うまでもなく、製品/サービスやブログ記事のマークアップも検討していませんが、これらは今後の記事で扱われる予定です。 。
構造化データを楽しんでください。必ず構造化データテストツールを使用してください。