30 サイト中 22 サイトが、AI に自社を推測させている

研究対象の 30 のホームページのうち 22 は、Organization、WebSite、Person、LocalBusiness のエンティティをまったく宣言していません。これはサンプルの 73% に当たり、モデルが名前を確実に知っている企業もいくつか含まれています。名前を知っていることと、その名前をどのドメインが所有しているかを教えられることは、別の問題だからです。

30 のうち 19、つまり 63% は、エンティティノードも sameAs のリストも持っていません。そうしたページでは、あらゆる消費側がブランドを可視テキストから推測しなければならず、推測こそが静かに間違う部分です。モデルはその企業を完璧に知っていても、名前をあなたのドメインに結び付けられないことがあります。

エンティティを宣言するとは何をすることか

解析に成功した 1 つの JSON-LD ブロックに、Organization、WebSite、Person、LocalBusiness のいずれかの @type が含まれていること。ルールはこれだけで、4 点の価値があります。

意図的に浅く定義しています。スキャナーは解析に成功したグラフのどこかに現れる型を、ネストされたものも含めて読み取るため、記事の author プロパティの中にある Person ノードでも、ページのどこにも Organization ノードがなくても条件を満たします。根拠の行には一致した型が表示されるので、合格は「ブランドのエンティティが存在する」という断定ではなく、見たものを述べたものになります。

30 のうちいくつが宣言しているか

エンティティ型を宣言しているのは 8、sameAs を持つのは 9、両方を持つのは 6、どちらも持たないのは 19 です。興味深いのは重なりです。この 2 つのプロパティは一緒に追加されることが多く、片方だけを持つサイトこそ見る価値があります。

合格したページと不合格のページはどう違うか

パターンは人が期待するものではありません。高得点のページのいくつかはエンティティを持ち sameAs を持たず、低めのページのいくつかはエンティティなしで sameAs を持っています。

このうち 2 行が示唆に富みます。Salesforce はサンプル全体で最高スコアでありながら sameAs を持っていません。識別の仕事はエンティティノードがしており、プロフィールへのリンクは一度も追加されていないのです。Shopify はエンティティを宣言せずに sameAs を通しているため、プロフィールはページが一度も名指ししていない何かを指しています。アンカーのない結合です。

モデルはこのマークアップを実際にどう使うか

文字列を 1 つのものに解決するために使います。name、url、sameAs を伴う Organization が、「この名前、このドメイン、これらのプロフィールは同じエンティティだ」と言う形です。

それがなければ、あなたのブランドを解決する消費側はページのテキストと、すでに信じているものだけを使うしかありません。それは何もないことではありません。企業名がはっきり書かれた大きな文書は不可視ではないのです。しかしそれは推測であり、推測には宣言にはない失敗モードがあります。同名の別企業、略称、ブランドの改名、あるいは企業を知っていてドメインを知らないモデルです。

これが 2 つのルールが別のディメンションで採点される理由です。エンティティノードは機械可読性のプロパティです。パーサーが指し示せるものを見られるかどうか。sameAs リストは信頼性のプロパティです。そのものが、他所に存在するアカウントを指しているかどうか。前者はこのページについて、後者は世界の中のあなたのブランドについてです。

このチェックはエンティティが正しいことを証明するか

いいえ。ルールページにもそう書かれています。テストされるのは存在だけです。sameAs のプロフィールを取得するものはなく、宣言された名前をページタイトルと比較するものもありません。

それに最適化する前に、この限界を知っておく価値があります。可視コピーのどこにも名前が出てこない Person ノードを宣言してもページは合格でき、両方を読んだモデルはその不一致に気づきます。ルールは解析可能性の下限であり、身元の証明書ではありません。

両方のルールを通る最小のマークアップは？

Organization ノード 1 つ、それを参照する WebSite ノード 1 つ、そして sameAs 配列です。プレースホルダーは置き換えてください。残さないでください。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://your-domain.com/#organization",
      "name": "Your Brand Name",
      "url": "https://your-domain.com",
      "sameAs": [
        "https://github.com/your-account",
        "https://www.linkedin.com/company/your-brand"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://your-domain.com/#website",
      "url": "https://your-domain.com",
      "name": "Your Brand Name",
      "publisher": { "@id": "https://your-domain.com/#organization" }
    }
  ]
}
</script>

このスニペットには意図的な点が 2 つあります。@id の値は実際のオリジン上のフラグメントなので、各ページはブランドを繰り返し述べるのではなく同じノードを参照できます。そして配列は水増ししていません。存在する 2 つのプロフィールは、存在しない 6 つより価値があります。このプロパティは消費側が検証できる主張だからです。

先にやる価値が高いのはどちらか

エンティティノードです。2 回採点されるからです。1 回は直接、もう 1 回は sameAs を意味のあるものにするアンカーとして。

1. Organization ノードをすべてのページに、またはすべてのページを包むレイアウトに追加します。どちらでも機能しますが、1 つのファイルのほうが正確に保ちやすいです。
2. 実際に維持しているプロフィールで sameAs を追加します。死んだプロフィールは壊れた主張であり、モデルが反証できる主張は、存在しない主張より高いコストになります。
3. ブロックが解析できることを検証します。構文エラーは消費側にとってはマークアップがないのと区別がつかず、追加したと思っている読者にとっては何もないより悪いです。
4. スキャンを再実行します。根拠の行に一致した型が表示されるので、合格は仮定ではなく観察できます。

完全な手順を載せたガイドは Schema.org JSON-LD ガイド、重みの背後にある算術は 方法論のページにあります。