2026年4月27日月曜日

Schema.org(構造化データ)を学ぶ

現在Googleが推奨する構造化データを学んでみた話

タイトル通りですが基本的に一般人は気にする必要はないです。理由は３つほど

  • ・検索のページランク自体には直結しない
  • ・なのに記述を間違えると怒られる
  • ・リッチリザルトは実務系しか強化されていない

リッチリザルトと構造化データの関係

リッチリザルト レポートの概要
「https://support.google.com/webmasters/answer/7552505?hl=ja」

構造化データ自体はだいぶ前から存在しており、情報を構造化して機械が理解しやすい様にすると考えれば基本的には十分です。

リッチリザルトは構造化データの「対象となる一部」から検索結果の見た目を強化する機能です。
これ自体はページランクに影響しないが検索結果が装飾される事でクリック率が上がり結果的にSEOに繋がる。

つまり、「構造化データ」は様々な情報を整理できるがそもそもリッチリザルトは一部しか対応してないので一般人が使うような内容には影響がないというわけです。

Schema.orgってなに？

構造化データを定義（Structured Data）している所です。
構造化データを定義を入れる時にこのサイトに構造情報があるという「"@context": "https://schema.org",」を指定します。
ですが現状ここしか指定出来ません。保証される構造情報を提供してるのがここしかないからです。

元々は Google・Microsoft・Yahoo・Yandex が共同で立ち上げたプロジェクトですが現状はほぼgoogleの影響で決まります。
そのためgoogleが構造化を推奨を強くしているわけです。

余り良くない事もあります。

リッチリザルトが実務ベースが強く、構造化データは多くの情報を定義出来るにお金になるProduct（商品）、JobPosting（求人）、LocalBusiness（店舗）、Recipe（レシピ）と言った所しかリッチリザルトされません。
FQAなども信頼の高いサイト以外は無意味になったし、How-toも廃止。
百歩譲ってリッチリザルトが実利を取るのはいいですが、構造化データ自体10年以上ほぼ変わらない構造化データなどがあります。

例えばVideoGameなどの構造はボードゲームなどの物理ゲームをベースに作られほぼ更新がありません。
ゲームアイテムの説明をするページを作る時にgameitemというプロパティはあるがメインに置くカテゴリが無いです。
存在しないアイテムなどの場合は「"mainEntity": {"@type": "Thing","name": "ゲームのアイテム名",」のようにThingしかないです。
また、同様にその説明に入れる情報は階層としてPropertyValueにするしかありません。

更に2026年今現在のAIに構造化データを作らせるとProductなどとあり得ない提案をして来たりします。
しかしそれらは実際の商品に対するものなのでゲームアイテムがリッチリザルトなどされるとショップを偽装するサイトとして評価が下がります。
ここらへんが最初に書いた通りの「一般人は気にする必要はないです」という事です。
あと記述も厳密でhtmlと違いカンマ一つ違うだけでエラーします。
変に構造化データを入れてページの信頼を落とすより、構造化を入れない方が大半の一般人には正しいです。

当然ある程度は構造化データに更新を求めて提案がされていますが主にgoogleがそれを取り合っていない為、構造化の追加もされてないのが今現在です。閑話休題。

構造化の構造について

さて話を戻して構造データについて。

Thing (最上位：すべての基本)
┃
┣━ Action (動作：検索、購入、予約など)
┃
┣━ CreativeWork (著作物・創作物)
┃   ┣━ Article (記事)
┃   ┃   ┗━ NewsArticle (ニュース記事)
┃   ┣━ Recipe (レシピ)
┃   ┣━ WebPage (ウェブページ)
┃   ┗━ Movie (映画)
┃
┣━ Event (イベント)
┃   ┣━ BusinessEvent (ビジネスイベント)
┃   ┗━ EducationEvent (教育イベント)
┃
┣━ Organization (組織)
┃   ┣━ Corporation (企業)
┃   ┗━ LocalBusiness (地域のお店・施設)
┃       ┣━ FoodEstablishment (飲食店)
┃       ┃   ┗━ Restaurant (レストラン)
┃       ┗━ Store (小売店)
┃
┣━ Person (人物)
┃
┣━ Place (場所)
┃   ┗━ AdministrativeArea (行政区画：市町村など)
┃
┣━ Product (製品・商品)
┃
┗━ Intangible (無形のもの)
    ┣━ ListId (リストの識別)
    ┃   ┗━ ItemList (リスト全般)
    ┃       ┗━ BreadcrumbList (パンくずリスト)
    ┣━ Enumeration (列挙型：在庫状況など)
    ┣━ Language (言語)
    ┗━ StructuredValue (構造化された値：評価、価格など)
        ┣━ AggregateRating (合計評価)
        ┗━ PriceSpecification (価格詳細)

全部ではありませんが主要なツリー構造はこういう感じです。
共通プロパティは「name (名前), url (URL), image (画像), description (説明)」
これらを使ってサイトの構造を定義します。初手は

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  ...内容
</script>

これです。
ページの情報はhtmlのその一つであっても個々に見ようとするので基本的には「"@graph": [...]」が必要になります。
更に言えばgraphで繋いでも情報が分散するのでidが必要になります。
面倒臭そうに見えますか？はい、実際に面倒臭いです。

ページ構造で必要なのは主に

  • パンくずリスト(最低限これだけあればいい)
  • メインコンテンツ(mainEntity)

形式的には

  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@graph": [
      {
        "@type": "BreadcrumbList",
        "itemListElement": [
          {"@type": "ListItem", "position": 1, "name": "top", "item": "url"},
          {"@type": "ListItem", "position": 2, "name": "階層", "item": "url"},
          {"@type": "ListItem", "position": 3, "name": "現在", "item": "現url"},
        ]
      },
      {
        "@type": "コンテンツのタイプ",
        "url": "現url",
        "name": "ページのタイトル",
        "description": "ページの説明",
        "mainEntity": {
          ...内容
        }
      }
    ]
  }
  </script>

基本一般人が使うのはBreadcrumbList (パンくずリスト)とArticle (記事)ぐらいだと思います。
もうちょっと構造を複雑にしてみましょう。

  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@graph": [
      {
        "@type": "WebSite","@id": "サイトのurl#website",
        "url": "サイトのurl",
        "name": "サイトの名前",
        "description": "サイトの説明",
        "inLanguage": "ja-JP"
      },{
        "@type": "BreadcrumbList","@id": "#breadcrumb",
        "itemListElement": [
          {"@type": "ListItem", "position": 1, "name": "top", "item": "url"},
          {"@type": "ListItem", "position": 2, "name": "階層", "item": "url"},
          {"@type": "ListItem", "position": 3, "name": "現在", "item": "現url"},
        ]
      },{
        "@type": "WebPage","@id": "現ページurl#webpage",
        "url": "現ページurl",
        "name": "ページのタイトル",
        "description": "ページの説明",
        "isPartOf": { "@id": "サイトのurl#website" },
        "breadcrumb": { "@id": "#breadcrumb" },
        "about": {関連の情報},
        "mainEntity": {"@id": "現ページurl#main-categories"},
        "hasPart": [ { "@id": "現ページurl#submenu" }]
      },{
        "@type": "ItemList","@id": "現ページurl/#main-categories",
        "name": "攻略主要カテゴリ","description": "攻略主要カテゴリの説明",
        "itemListElement": [
          {"@type": "ListItem","position": 1,"name": "メインリンク１","url": "url"},
          ...略
          {"@type": "ListItem","position": 8,"name": "メインリンク8","url": "url"}
        ]
      },{
        "@type": "ItemList","@id": "現ページurl#submenu",
        "name": "サブ","description": "サブの説明",
        "itemListElement": [
          {"@type": "ListItem","position": 1,"name": "サブリンク１","url": "url"},
          ...略
          {"@type": "ListItem","position": 5,"name": "サブリンク５","url": "url"}
        ]
      }
    ]
  }
  </script>

・トップの指定。url#websiteは各ページ統一が必要

・isPartOfでどれに属するかを指定

・aboutで関連の情報を追加

・mainEntityをidで指定

・hasPartを使い同様にこのページ内に付属するコンテンツを指定

これくらい出来れば基本的には良いんじゃないかなと思います。

投稿者 時刻:
ラベル:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)