構造化マークアップとは？SEOに効くJSON-LDの書き方とschema.org完全ガイド

構造化マークアップとは

構造化マークアップとは、Webページのコンテンツに意味を付与するためのコードのことです。HTMLだけでは伝えきれない情報、たとえば「これは商品名です」「これは著者の名前です」「これはイベントの開催日です」といった文脈を、検索エンジンが正確に理解できるように記述します。人間がページを見れば何が書かれているか直感的にわかりますが、検索エンジンのクローラーはあくまでテキストとコードを解析しているだけなので、構造化マークアップによって情報の種類や関係性を明示してあげる必要があります。

私は27年にわたってWebプログラミングとSEOに携わってきましたが、構造化マークアップの重要性は年々高まっていると実感しています。Googleをはじめとする検索エンジンが、単なるキーワードマッチングから意味理解へとシフトしている現在、構造化データを正しく実装することはSEO施策の基本となりました。

検索エンジンが構造化データを必要とする理由

検索エンジンは膨大なWebページの中から、ユーザーの検索意図に合致した結果を返すことを目指しています。しかしHTMLの記述だけでは、そのテキストが何を意味するのかを完全に把握することは困難です。たとえば「田中太郎」という文字列があったとして、それが人名なのか店舗名なのか商品名なのか、HTMLだけでは判断できません。構造化マークアップを使えば、このテキストがPersonタイプの名前であることを明示できます。

検索エンジンはこうした構造化データを読み取ることで、ページの内容をより深く理解し、適切な検索結果を表示できるようになります。また、構造化データは検索結果の表示形式にも影響を与え、リッチリザルトとして目立つ形で表示されることがあります。

リッチリザルトと構造化マークアップの関係

リッチリザルトとは、通常の検索結果よりも視覚的に豊かな形式で表示される検索結果のことです。商品の星評価や価格、イベント情報、求人情報、レシピの調理時間などが検索結果に直接表示されることで、ユーザーの目を引き、クリック率の向上につながります。構造化マークアップを正しく実装することで、このリッチリザルトとして表示される可能性が高まります。

ただし、構造化マークアップを実装したからといって必ずリッチリザルトが表示されるわけではありません。Googleはコンテンツの品質やユーザーの検索意図なども考慮して、リッチリザルトを表示するかどうかを判断します。それでも、構造化データがなければリッチリザルトの対象にすらならないので、実装しておくことは非常に重要です。

Googleが公開している事例では、構造化データによるリッチリザルト実装で大きな効果が報告されています。Rotten Tomatoesは10万ページに構造化データを追加した結果、構造化データ付きページで25%高いクリック率を達成しました。Food Networkは80%のページでリッチリザルトを有効化し、35%の訪問増加を記録しています。さらにNestléの計測では、リッチリザルト表示ページは非表示ページと比較して82%高いクリック率を示しました。

出典: Google Search Central（2023年）

構造化マークアップの記述形式を理解する

構造化マークアップには主に3つの記述形式があります。JSON-LD、Microdata、RDFaの3種類で、いずれもschema.orgで定義されたボキャブラリーを使用できます。それぞれに特徴があり、サイトの状況や運用体制によって最適な選択肢は異なります。

WebDataCommonsの2024年調査によると、構造化データを実装しているWebサイトのうち、JSON-LDは約1,150万サイト（70%）で採用されています。Microdataは約760万サイト（46%）、RDFaはわずか約40万サイト（3%）にとどまっています。2019年から2021年にかけてMicrodataの使用はピークを迎えた後減少傾向にある一方、JSON-LDは2020年以降も継続的に成長を続けています。

出典: WebDataCommons, University of Mannheim（2024年）

JSON-LDが推奨される理由

JSON-LDはJavaScript Object Notation for Linked Dataの略で、Googleが公式に推奨している記述形式です。HTMLの本文とは独立してscriptタグ内に記述するため、既存のHTMLを変更することなく構造化データを追加できます。この特徴により、CMSやテンプレートエンジンとの相性が良く、保守性も高いのが魅力です。また、可読性が高いためデバッグもしやすく、実装ミスを発見しやすいというメリットもあります。

Googleは構造化データの記述形式としてJSON-LDを推奨しており、公式ドキュメントで「可能な限りJSON-LDを使用することをお勧めします」と明記しています。JSON-LDはHTMLの本文に影響を与えずに構造化データを追加できるため、実装と保守が容易です。

Microdataの特徴と使いどころ

MicrodataはHTMLの要素に直接属性を追加する形式です。itemscope、itemtype、itempropといった属性を使って、HTMLタグそのものに意味を付与します。コンテンツとマークアップが一体化しているため、動的にコンテンツが変わる場合でも構造化データが自動的に追従するというメリットがあります。ただし、HTMLが複雑になりやすく、既存サイトへの導入には手間がかかることが多いです。

Microdataの実装例は以下のとおりです。

<div itemscope itemtype="https://schema.org/Article">
  <h1 itemprop="headline">記事タイトル</h1>
  <p>公開日: <time itemprop="datePublished" datetime="2024-01-15">2024年1月15日</time></p>
  <div itemprop="author" itemscope itemtype="https://schema.org/Person">
    <span itemprop="name">著者名</span>
  </div>
  <div itemprop="articleBody">
    <p>記事本文がここに入ります...</p>
  </div>
</div>

RDFaという選択肢

RDFaはResource Description Framework in Attributesの略で、Microdataと同様にHTML属性を使って構造化データを記述します。vocabやpropertyといった属性を使用し、より汎用的な記述が可能です。歴史的にはMicrodataより先に存在していましたが、現在ではJSON-LDの普及により採用されることは少なくなっています。既存のシステムがRDFaを前提としている場合を除き、新規実装であればJSON-LDを選択するのが無難です。

RDFaの実装例は以下のとおりです。

<div vocab="https://schema.org/" typeof="Article">
  <h1 property="headline">記事タイトル</h1>
  <p>公開日: <time property="datePublished" content="2024-01-15">2024年1月15日</time></p>
  <div property="author" typeof="Person">
    <span property="name">著者名</span>
  </div>
  <div property="articleBody">
    <p>記事本文がここに入ります...</p>
  </div>
</div>

3つの記述形式を比較すると、それぞれに明確な特徴があります。

記述形式	記述場所	Google推奨	保守性	採用率（2024年）
JSON-LD	scriptタグ内	◎	高い	70%
Microdata	HTML属性	○	中程度	46%
RDFa	HTML属性	○	中程度	3%

Article系構造化データでコンテンツの価値を伝える

Article構造化データは、ブログ記事やニュース記事などのコンテンツに対して使用します。検索エンジンに対して、そのページが記事コンテンツであることを明示し、タイトル、著者、公開日、更新日などの詳細情報を伝えることができます。Articleには派生タイプとしてNewsArticle（ニュース・プレスリリース）、BlogPosting（ブログ記事）があり、さらに記事ではない静的ページにはWebPageを使用します。この4つのコンテンツタイプの使い分けが、構造化データ設計の基本となります。なお、後述するPerson（人）、Organization（組織単位）、Corporation（法人）の使い分けも重要なポイントです。

Articleタイプの主要プロパティ

Articleタイプで設定できるプロパティは多岐にわたります。headlineには記事のタイトルを指定し、authorには著者情報をPersonまたはOrganizationとして記述します。datePublishedで公開日、dateModifiedで更新日を指定することで、コンテンツの鮮度を検索エンジンに伝えられます。imageにはアイキャッチ画像を設定し、publisherには発行元をOrganizationまたはCorporationとして記述します。企業メディアの場合はCorporation、個人ブログやメディア名で発行する場合はOrganizationを使用するのが適切です。descriptionで記事の概要を説明し、articleBodyに本文テキストを、wordCountで文字数を指定することも可能です。keywordsで関連キーワードを、articleSectionでカテゴリを示すこともできます。

Articleタイプの主要プロパティは以下のとおりです。

• headline：記事タイトル
• author：著者（PersonまたはOrganization）
• datePublished：公開日
• dateModified：更新日
• image：アイキャッチ画像
• publisher：発行元（OrganizationまたはCorporation）
• description：記事の説明
• articleBody：記事本文
• wordCount：文字数
• keywords：キーワード
• articleSection：カテゴリ

ArticleタイプのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "記事タイトルをここに記述",
  "author": {
    "@type": "Person",
    "name": "著者名",
    "url": "https://example.com/author/"
  },
  "publisher": {
    "@type": "Corporation",
    "name": "株式会社〇〇",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2024-01-15",
  "dateModified": "2024-01-20",
  "image": "https://example.com/article-image.jpg",
  "description": "記事の説明文を120文字程度で記述"
}
</script>

Articleのheadlineは、ページのtitleタグやh1見出しと一致させるのが基本です。構造化データには「SEOに強い！完全保存版」と書いてあるのにページ見出しは「構造化データ入門」では、Googleに不信感を与えます。また、authorを省略してpublisherだけ記述するサイトを見かけますが、E-E-A-Tの観点からは誰が書いたのかを明示することが重要です。匿名記事であっても「編集部」などのOrganizationで著者を設定し、可能であれば実名のPersonで記述することを推奨します。

NewsArticleとBlogPostingの使い分け

Articleには派生タイプとしてNewsArticleとBlogPostingがあります。NewsArticleはニュース記事やプレスリリースに適しており、datelineプロパティで発信地や日付を追加できます。企業のお知らせページやニュースサイトの記事にはNewsArticleを使うのが適切です。企業ニュースの場合、authorには作成した組織単位（広報部、編集部など）をOrganizationで、publisherには発行元の企業をCorporationで指定すると、組織構造が明確になります。

一方、BlogPostingは個人の日記やブログ記事向けのタイプです。mainEntityOfPageで正規URLを指定できます。ただし正直なところ、現在のGoogleアルゴリズムにおいてBlogPostingを使うSEO上のメリットは限定的だと考えています。E-E-A-Tの観点から見ても、あえて「これは日記です」と宣言することで優遇される可能性は低いからです。通常の記事コンテンツであればArticleタイプを使用し、ニュースやプレスリリースにはNewsArticleを使う、という運用で問題ありません。

NewsArticleのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "headline": "企業ニュースのタイトル",
  "dateline": "東京, 2024年1月15日",
  "author": {
    "@type": "Organization",
    "name": "広報部"
  },
  "publisher": {
    "@type": "Corporation",
    "name": "株式会社〇〇",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2024-01-15",
  "dateModified": "2024-01-20"
}
</script>

BlogPostingは基本的にArticleと同じプロパティを使用しますが、参考までに実装例を示します。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "ブログ記事のタイトル",
  "author": {
    "@type": "Person",
    "name": "著者名"
  },
  "publisher": {
    "@type": "Organization",
    "name": "〇〇ブログ",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2024-01-15",
  "dateModified": "2024-01-20"
}
</script>

WebPageで静的ページを表現する

一方、記事コンテンツではない静的な情報ページにはWebPage構造化データを使用します。Article/NewsArticle/BlogPostingが時系列で更新される「記事」を表現するのに対し、WebPageは会社概要、アクセス、サービス紹介など、時間が経っても内容が大きく変わらない普遍的なページに適しています。WebPageタイプではnameでページタイトル、urlでURL、descriptionで説明を指定します。datePublishedとdateModifiedで公開日と更新日を設定し、inLanguageで言語を明示します。isPartOfでそのページが属するWebSiteを参照できます。

WebPageのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "会社概要 - 株式会社〇〇",
  "url": "https://example.com/about/",
  "description": "株式会社〇〇の会社概要ページです",
  "inLanguage": "ja",
  "datePublished": "2020-04-01",
  "dateModified": "2024-01-20",
  "isPartOf": {
    "@type": "WebSite",
    "name": "株式会社〇〇",
    "url": "https://example.com/"
  }
}
</script>

Person構造化データで著者の信頼性を示す

著者情報を構造化データで明示することは、E-E-A-Tの観点から非常に重要です。Personタイプを使って著者の詳細情報を記述することで、検索エンジンにコンテンツ作成者の専門性や信頼性を伝えることができます。

Personタイプで設定すべきプロパティ

Personタイプではnameで著者名を指定し、urlでプロフィールページへのリンクを設定します。imageには顔写真を設定することで視認性が高まります。sameAsプロパティは配列形式で複数のSNSアカウントURLを指定でき、著者のオンライン上での存在感を示すことができます。jobTitleで職業や役職を、worksForで所属先をOrganizationまたはCorporationとして記述します。企業全体への所属を示す場合はCorporation、特定の部門やチームへの所属を示す場合はOrganizationを使用します。emailやtelephone、addressといった連絡先情報も設定可能です。alumniOfで出身校、awardで受賞歴、knowsAboutで専門分野を明示することで、著者がその分野の専門家であることをアピールできます。

Personタイプで設定できる主要プロパティは以下のとおりです。

• name：著者名
• url：プロフィールページURL
• image：顔写真
• sameAs：SNSアカウントURL（配列）
• jobTitle：職業・役職
• worksFor：所属組織（OrganizationまたはCorporation）
• alumniOf：出身校
• award：受賞歴
• knowsAbout：専門分野

PersonタイプのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "柏崎剛",
  "url": "https://example.com/profile/",
  "image": "https://example.com/author-photo.jpg",
  "jobTitle": "SEOコンサルタント",
  "worksFor": {
    "@type": "Corporation",
    "name": "株式会社○○"
  },
  "sameAs": [
    "https://twitter.com/example",
    "https://www.linkedin.com/in/example/"
  ],
  "knowsAbout": ["SEO", "構造化データ", "Webマーケティング"]
}
</script>

Organization構造化データで組織の実在性を証明する

Organization構造化データは、チーム、事業部、研究室、プロジェクトグループなどの組織単位を検索エンジンに伝えるために使用します。重要なのは、Organizationは法人格を持たない組織にも使用できる点です。法人企業にはCorporationを使用し、組織単位や部門にはOrganizationを使用するという使い分けが推奨されます。組織の実在性と信頼性を示すことで、そのコンテンツ全体の信頼度向上につながります。

Organizationの基本プロパティ

Organizationタイプではnameで組織名を、urlで公式サイトURLやページURLを指定します。logoで組織のロゴやアイコンを設定し、sameAsで公式SNSアカウントや関連ページを配列として複数登録できます。memberOfで所属先の組織、parentOrganizationで親組織をそれぞれOrganizationまたはCorporationとして指定できます。departmentで配下の部署や下位組織を設定することも可能です。

OrganizationタイプのJSON-LD実装例は以下のとおりです。ここでは企業内の研究部門を例にしています。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "AI研究開発部",
  "url": "https://example.com/research/ai/",
  "description": "人工知能技術の研究開発を行う組織",
  "parentOrganization": {
    "@type": "Corporation",
    "name": "株式会社サンプル",
    "url": "https://example.com/"
  },
  "member": [
    {
      "@type": "Person",
      "name": "研究責任者名",
      "jobTitle": "部長"
    }
  ]
}
</script>

LocalBusinessで店舗情報を充実させる

LocalBusinessはOrganizationのサブタイプで、実店舗を持つビジネスに特化した構造化データです。Organizationのすべてのプロパティに加え、openingHoursで営業時間、priceRangeで価格帯を設定できます。geoプロパティにGeoCoordinatesで緯度経度を指定すれば、地図検索との連携も強化されます。areaServedでサービス提供地域、paymentAcceptedで対応決済方法、currenciesAcceptedで対応通貨を明示することもできます。ローカルSEOを強化したい場合、LocalBusinessの実装は必須と言えるでしょう。

WebDataCommonsの調査では、LocalBusiness構造化データの採用は2020年の約38.6万サイトから2024年には約130万サイトへと337%の成長を記録しています。この急速な普及は、ローカル検索におけるリッチリザルト表示の重要性が認識された結果と言えます。

LocalBusinessのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "店舗名",
  "image": "https://example.com/shop-image.jpg",
  "url": "https://example.com/",
  "telephone": "+81-3-1234-5678",
  "priceRange": "¥¥",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "○○ビル1階",
    "addressLocality": "渋谷区",
    "addressRegion": "東京都",
    "postalCode": "150-0001",
    "addressCountry": "JP"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 35.6595,
    "longitude": 139.7004
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00",
      "closes": "18:00"
    }
  ]
}
</script>

geoプロパティに緯度経度を設定することで、Googleマップとの連携が強化され、ローカル検索での表示が有利になります。緯度経度の値はGoogleマップで取得できますが、小数点以下の桁数が多すぎても問題ないため、そのままコピーして使用して構いません。

LocalBusinessで特に重要なのは、Googleビジネスプロフィールに登録している情報との一貫性です。店舗名、住所、電話番号（NAP情報）が構造化データとビジネスプロフィールで異なると、Googleが同一店舗として認識できず、ローカル検索での評価が分散します。「株式会社〇〇 渋谷店」と「〇〇渋谷店」のような表記ゆれ、ビル名の有無、電話番号のハイフンの有無なども統一してください。

WebSiteでサイト全体の情報を伝える

WebSiteタイプはサイト全体を表現する構造化データです。nameでサイト名、urlでサイトURL、publisherで運営者、inLanguageで言語を指定します。potentialActionにSearchActionを設定すれば、サイト内検索機能を検索エンジンに認識させることができます。なお、かつて検索結果に表示されていたサイトリンク検索ボックスは2024年11月21日に廃止されており、現在はSearchActionを実装してもボックスは表示されません。ただし、サイト内検索機能の存在を検索エンジンに伝えるという意味では、引き続き実装する価値があります。

WebSite + SearchActionのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "サイト名",
  "url": "https://example.com/",
  "publisher": {
    "@type": "Corporation",
    "name": "株式会社〇〇"
  },
  "potentialAction": {
    "@type": "SearchAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://example.com/?s={search_term_string}"
    },
    "query-input": "required name=search_term_string"
  }
}
</script>

urlTemplateの{search_term_string}部分は、ユーザーが入力した検索キーワードに置き換えられます。WordPressの場合は?s=パラメータを使用するのが一般的です。

BreadcrumbListでサイト構造を伝える

BreadcrumbList構造化データは、パンくずリストの情報を検索エンジンに伝えます。サイトの階層構造を明示することで、ユーザーと検索エンジンの両方にとってナビゲーションがわかりやすくなります。

パンくずリストの実装方法

BreadcrumbListにはitemListElementプロパティでListItemの配列を設定します。各ListItemにはpositionで順番を1から連番で指定し、nameで表示名、itemでリンク先URLを設定します。トップページから現在のページまでの階層を順に記述することで、サイト構造が検索エンジンに正確に伝わります。なお、2024年9月以降、Googleはデスクトップ検索結果からパンくずリストの表示を削除しました（モバイルは2025年8月）。しかしBreadcrumbList構造化データは引き続きGoogleに認識されており、サイト構造の理解やSearch Consoleでのレポートに活用されるため、実装する価値は残っています。

BreadcrumbListのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "ホーム",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "SEO対策",
      "item": "https://example.com/seo/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "構造化マークアップとは"
    }
  ]
}
</script>

FAQPage構造化データの設計と実装

FAQPage構造化データは、よくある質問ページに対して使用します。質問と回答のペアを構造化することで、検索エンジンがQ&A形式のコンテンツを正確に理解できるようになります。

WebDataCommonsのデータによると、FAQPageスキーマは2018年のschema.orgリリース時にはわずか19サイトでしか使用されていませんでしたが、2024年には30.8万サイトにまで急拡大しています。かつてFAQリッチリザルトが検索結果で大きな表示面積を占めていたことが普及の要因でしたが、2023年8月以降は一般サイトでのリッチリザルト表示が制限されています。

出典: WebDataCommons, University of Mannheim（2024年）

FAQPageの記述方法

FAQPageタイプのmainEntityプロパティには、Questionの配列を設定します。各Questionではnameに質問文を記述し、acceptedAnswerにAnswerタイプで回答を設定します。Answerのtextプロパティに回答文を入れることで、質問と回答のペアが完成します。複数の質問がある場合は、mainEntityに複数のQuestionを配列として格納します。

なお、2023年8月にGoogleはFAQリッチリザルトの表示を大幅に制限しました。現在、FAQリッチリザルトは政府機関や医療機関など、権威性の高いサイトに限定して表示されるようになっています。一般のサイトではFAQリッチリザルトが表示されなくなりましたが、構造化データ自体は検索エンジンのコンテンツ理解を助けるため、実装しておく価値はあります。また、ChatGPTやPerplexityなどのAI検索ではFAQPage構造化データを持つコンテンツが引用されやすい傾向が報告されています。

FAQPageのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "構造化マークアップとは何ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "構造化マークアップとは、Webページのコンテンツに意味を付与するためのコードです。検索エンジンがページの内容を正確に理解できるようになります。"
      }
    },
    {
      "@type": "Question",
      "name": "JSON-LDとMicrodataの違いは何ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "JSON-LDはscriptタグ内に記述し、MicrodataはHTML属性として記述します。GoogleはJSON-LDを推奨しています。"
      }
    }
  ]
}
</script>

HowTo構造化データで手順を明確に伝える

HowTo構造化データは、何かの手順やプロセスを説明するコンテンツに使用します。料理のレシピ、DIYの手順、設定方法など、ステップバイステップで解説するコンテンツに最適です。ただし、2023年9月13日以降、GoogleはHowToリッチリザルトの表示を完全に廃止しました。デスクトップ・モバイルともにHowToリッチリザルトは表示されなくなっています。それでも、HowTo構造化データは検索エンジンのコンテンツ理解を助けるため、実装自体に害はありません。

HowToの詳細なプロパティ設定

HowToタイプではnameでタイトル、descriptionで概要を設定し、imageで画像を指定できます。totalTimeで所要時間をISO 8601形式で、estimatedCostで費用を記述します。supplyにはHowToSupplyの配列で必要な材料を、toolにはHowToToolの配列で必要な道具を列挙します。stepプロパティにはHowToStepの配列で各手順を記述し、それぞれにnameでステップ名、textで説明、imageで画像、urlでアンカーリンクを設定できます。リッチリザルトとしての表示は廃止されましたが、構造化データとして手順を明示することで、検索エンジンがコンテンツの構造を理解しやすくなります。

HowToタイプのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "WordPressに構造化データを実装する方法",
  "description": "WordPressサイトにJSON-LD形式で構造化データを追加する手順",
  "totalTime": "PT30M",
  "step": [
    {
      "@type": "HowToStep",
      "name": "テーマファイルを開く",
      "text": "子テーマのfunctions.phpファイルを開きます"
    },
    {
      "@type": "HowToStep",
      "name": "コードを追加",
      "text": "wp_headフックを使用してJSON-LDを出力するコードを追加します"
    },
    {
      "@type": "HowToStep",
      "name": "動作確認",
      "text": "リッチリザルトテストで構造化データが正しく認識されるか確認します"
    }
  ]
}
</script>

HowToのstepプロパティに記述する手順は、ページ上に実際に存在する見出しや段落と対応させてください。構造化データにだけ詳細な手順を書いてページ本文には概要しかない、という状態はクローキングとみなされるリスクがあります。Googleのリッチリザルトは廃止されましたが、ChatGPTやPerplexityなどのAI検索では手順コンテンツが引用されやすい傾向があり、HowTo構造化データがその精度を高める可能性があります。

Product構造化データで商品情報を最適化する

Product構造化データは、ECサイトや商品紹介ページで使用します。商品の詳細情報を構造化することで、検索結果に価格や在庫状況、レビュー評価などが表示されるようになります。

WebDataCommonsの調査では、Product構造化データの採用は2020年の約59.4万サイトから2024年には約282万サイトへと475%もの成長を遂げています。ECサイトにとって、商品リッチリザルトは購買意欲の高いユーザーを獲得するための重要な手段となっています。

Productタイプの主要プロパティ

Productタイプではnameで商品名、imageで商品画像、descriptionで商品説明を設定します。skuでSKU、mpnで型番、brandでブランド情報をBrandタイプとして記述します。offersプロパティにはOfferタイプで価格情報を設定し、aggregateRatingでAggregateRatingタイプとして評価情報を、reviewでReviewの配列としてレビュー情報を記述できます。

Offerで価格情報を詳細に記述する

OfferタイプではpriceでPrice、priceCurrencyで通貨コード（日本円ならJPY）を指定します。availabilityで在庫状況を、urlで商品ページURLを設定します。priceValidUntilで価格の有効期限、itemConditionで商品状態（新品か中古かなど）、sellerで販売者情報を記述することもできます。これらの情報が検索結果に表示されることで、ユーザーは検索結果の段階で商品の概要を把握でき、購買意欲の高いユーザーがサイトに訪れやすくなります。

ProductタイプのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "商品名",
  "image": "https://example.com/product.jpg",
  "description": "商品の説明文",
  "brand": {
    "@type": "Brand",
    "name": "ブランド名"
  },
  "offers": {
    "@type": "Offer",
    "price": "9800",
    "priceCurrency": "JPY",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/product/"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "reviewCount": "120"
  }
}
</script>

Productのpriceとavailabilityは、ページ上に表示されている実際の価格・在庫状況と完全に一致させる必要があります。セール価格への更新忘れ、在庫切れ商品のInStock表記などは「スパム構造化データ」として手動対策の対象となります。特にアフィリエイトサイトでは、リンク先ECサイトの価格と自サイトの構造化データが乖離しやすいため注意が必要です。価格が頻繁に変動する商品は、APIやスクレイピングで動的に値を取得する仕組みを検討してください。

Review構造化データでユーザー評価を活用する

Review構造化データは、商品やサービスに対するレビュー情報を構造化します。ユーザーレビューを適切にマークアップすることで、検索結果に星評価やレビュー数が表示され、信頼性とクリック率の向上につながります。

ReviewとRatingの関係

Reviewタイプではauthorでレビュー投稿者をPersonとして、datePublishedで投稿日、reviewBodyでレビュー本文を記述します。reviewRatingにはRatingタイプで評価を設定し、itemReviewedでレビュー対象を指定します。RatingタイプではratingValueで評価値、bestRatingで最高評価値、worstRatingで最低評価値を設定します。

AggregateRatingで評価を集約する

複数のレビューがある場合、AggregateRatingタイプで評価を集約できます。ratingValueで平均評価、reviewCountでレビュー数、ratingCountで評価数、bestRatingで最高評価値、worstRatingで最低評価値を設定します。この集約された評価情報が検索結果の星評価として表示されることで、ユーザーの目を引く効果があります。

ReviewタイプのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Review",
  "itemReviewed": {
    "@type": "Product",
    "name": "レビュー対象の商品名"
  },
  "author": {
    "@type": "Person",
    "name": "レビュー投稿者名"
  },
  "datePublished": "2024-01-15",
  "reviewBody": "この商品は非常に使いやすく、品質も良かったです。",
  "reviewRating": {
    "@type": "Rating",
    "ratingValue": "4",
    "bestRating": "5",
    "worstRating": "1"
  }
}
</script>

Reviewで最も注意すべきは「ページ上にレビューが表示されていること」です。構造化データにだけレビューを記述してページには星マークしか表示しない、といった実装はGoogleから「虚偽のレビュー」と判断されます。aggregateRatingを使用する場合は、同一ページに最低でも数件の実際のレビューテキストを表示することが推奨されています。また、自社製品を自分でレビューする「自己レビュー」はガイドライン違反です。reviewCountの数値はページ上のレビュー件数と正確に一致させてください。

Event構造化データでイベント情報を発信する

Event構造化データは、セミナー、コンサート、展示会などのイベント情報に使用します。イベントの詳細を構造化することで、検索結果にイベント情報が目立つ形で表示されます。

Eventの必須プロパティと推奨プロパティ

Eventタイプではnameでイベント名、startDateで開始日時、endDateで終了日時を設定します。locationには開催場所をPlaceまたはVirtualLocationとして記述します。descriptionで説明、imageで画像、offersでチケット情報をOfferとして設定できます。performerで出演者をPersonまたはOrganizationとして、organizerで主催者を指定します。eventStatusで開催状況（予定、中止、延期など）、eventAttendanceModeで参加形式（オンライン、オフライン、ハイブリッド）を明示することも重要です。

EventタイプのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "SEO対策セミナー2024",
  "startDate": "2024-03-15T14:00:00+09:00",
  "endDate": "2024-03-15T17:00:00+09:00",
  "eventStatus": "https://schema.org/EventScheduled",
  "eventAttendanceMode": "https://schema.org/OfflineEventAttendanceMode",
  "location": {
    "@type": "Place",
    "name": "東京コンベンションホール",
    "address": {
      "@type": "PostalAddress",
      "addressLocality": "千代田区",
      "addressRegion": "東京都"
    }
  },
  "organizer": {
    "@type": "Organization",
    "name": "SEO研究会"
  },
  "offers": {
    "@type": "Offer",
    "price": "5000",
    "priceCurrency": "JPY",
    "availability": "https://schema.org/InStock"
  }
}
</script>

Eventで見落としがちなのがeventStatusの更新です。イベントが中止になった場合はEventCancelled、延期の場合はEventPostponedに変更し、ページ本文にもその旨を明記してください。構造化データでは「開催予定」なのにページには「中止」と書いてある状態は、ユーザー体験を著しく損ないます。また、startDateにはタイムゾーン（+09:00など）を必ず含めてください。開催日が過ぎたイベントページは、構造化データを削除するか、過去イベントのアーカイブであることをページ上で明確にすることが望ましいです。

VideoObject構造化データで動画コンテンツを最適化する

VideoObject構造化データは、動画コンテンツに対して使用します。YouTubeなど外部プラットフォームの埋め込み動画や、自社ホストの動画に対して構造化データを設定することで、動画検索結果に表示されやすくなります。

VideoObjectで設定すべき情報

VideoObjectタイプではnameでタイトル、descriptionで説明、thumbnailUrlでサムネイル画像URLを設定します。uploadDateで公開日、durationで再生時間をISO 8601形式で指定します。contentUrlで動画ファイルのURL、embedUrlで埋め込みURLを記述します。interactionStatisticで視聴回数などのインタラクション情報を設定することもできます。動画リッチリザルトが表示されると、検索結果でサムネイルが目立ち、クリック率が向上する可能性があります。なお、2024年4月以降、動画コレクションやカルーセル表示は廃止されており、学習動画のリッチ機能も2025年に終了しました。

VideoObjectタイプのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "VideoObject",
  "name": "構造化データの実装方法を解説",
  "description": "JSON-LD形式で構造化データを実装する手順を解説します",
  "thumbnailUrl": "https://example.com/video-thumbnail.jpg",
  "uploadDate": "2024-01-15",
  "duration": "PT10M30S",
  "contentUrl": "https://example.com/video.mp4",
  "embedUrl": "https://www.youtube.com/embed/xxxxxxxxx"
}
</script>

VideoObjectの重要な要件は「そのページで動画を視聴できること」です。動画へのリンクだけがあってページ上では再生できない、という構成では動画リッチリザルトの対象外となります。また、動画は最低30秒以上の再生時間が必要です。contentUrlに指定する動画ファイルURLはGooglebotがアクセス可能で、robots.txtでブロックされていない必要があります。YouTubeの埋め込み動画を使用する場合はembedUrlのみでも構いませんが、自社ホストの動画ではcontentUrlの指定が推奨されます。

ImageObject構造化データで画像情報を充実させる

ImageObject構造化データは、重要な画像に対して詳細情報を付与するために使用します。特にオリジナル画像や著作権情報を明示したい場合に有効です。

ImageObjectのプロパティ詳細

ImageObjectタイプではnameで画像名、contentUrlで画像URL、urlで掲載ページURLを設定します。widthとheightで画像サイズを、captionでキャプションを記述できます。authorで撮影者、copyrightHolderで著作権者、licenseでライセンス情報を明示することで、画像の出典や権利関係を検索エンジンに伝えることができます。

ImageObjectタイプのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ImageObject",
  "name": "構造化データの概念図",
  "contentUrl": "https://example.com/images/structured-data.jpg",
  "url": "https://example.com/structured-data-guide/",
  "width": "1200",
  "height": "630",
  "caption": "構造化データの仕組みを図解したイメージ",
  "author": {
    "@type": "Person",
    "name": "著者名"
  },
  "copyrightHolder": {
    "@type": "Organization",
    "name": "株式会社〇〇"
  }
}
</script>

ImageObjectはリッチリザルトには直接影響しませんが、Google画像検索でのクレジット表示やライセンス情報の明示に役立ちます。オリジナルの図解やインフォグラフィックを制作しているサイトでは、copyrightHolderとlicenseを設定することで、画像の無断転載時に出典元として認識されやすくなる効果が期待できます。ストックフォトやフリー素材を使用している場合は、元の著作権者の情報を正確に記述するか、ImageObject自体の使用を控えるのが無難です。

SoftwareApplication構造化データでアプリ情報を伝える

SoftwareApplication構造化データは、Webアプリやモバイルアプリなどのソフトウェア情報に使用します。アプリの検索結果にレビュー評価や価格が表示されるようになります。

アプリ情報の構造化

SoftwareApplicationタイプではnameでアプリ名、operatingSystemで対応OS、applicationCategoryでカテゴリを設定します。offersで価格情報をOfferとして、aggregateRatingで評価情報を記述できます。downloadUrlでダウンロードURL、screenshotでスクリーンショット、softwareVersionでバージョン情報を設定することも可能です。

SoftwareApplicationタイプのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "SEO分析ツール",
  "operatingSystem": "iOS, Android",
  "applicationCategory": "BusinessApplication",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "JPY"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "reviewCount": "500"
  }
}
</script>

SoftwareApplicationでaggregateRatingを使用する場合、App StoreやGoogle Playの実際の評価と一致させることが重要です。ストアでの評価が3.8なのに構造化データで4.5と記述するのは明らかなガイドライン違反です。また、アプリ紹介ページ（ランディングページ）にSoftwareApplicationを設置する場合、そのページ自体にユーザーレビューを掲載していなければaggregateRatingは使用すべきではありません。無料アプリはprice: “0”と明記し、フリーミアムモデルの場合はアプリ内課金があることをページ上で説明してください。

Course構造化データで教育コンテンツを最適化する

Course構造化データは、オンライン講座や教育コースに対して使用します。学習コンテンツの検索結果に詳細情報が表示されるようになります。

Courseで設定する情報

Courseタイプではnameでコース名、descriptionで説明、providerで提供者をOrganizationとして設定します。offersで価格情報、hasCourseInstanceで開催情報をCourseInstanceとして記述できます。coursePrerequisitesで前提条件、educationalLevelで難易度、teachesで学べる内容を明示することで、ユーザーが適切なコースを見つけやすくなります。

CourseタイプのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Course",
  "name": "SEO実践講座",
  "description": "構造化データの実装からコンテンツ最適化まで学べるオンライン講座",
  "provider": {
    "@type": "Organization",
    "name": "SEOスクール"
  },
  "offers": {
    "@type": "Offer",
    "price": "29800",
    "priceCurrency": "JPY"
  },
  "hasCourseInstance": {
    "@type": "CourseInstance",
    "courseMode": "online"
  }
}
</script>

Courseでは、providerに指定する組織の信頼性が重要です。実在しない架空のスクール名を記述したり、有名教育機関を偽って記載したりすることは厳禁です。hasCourseInstanceは開講スケジュールがある講座に使用し、オンデマンド型の講座では省略しても構いません。offersで価格を記述する際、講座ページ上に表示されている価格と完全に一致させてください。キャンペーン価格や分割払い価格など複数の価格がある場合は、ページ上で最も目立つ通常価格を記述するのが安全です。

JobPosting構造化データで求人情報を最適化する

JobPosting構造化データは、求人ページに対して使用します。Google しごと検索に表示されるためには、JobPosting構造化データの実装が必須となります。

Googleしごと検索の普及により、求人サイトにとってJobPosting構造化データの実装は事実上の必須要件となっています。正しく実装された求人情報は検索結果で目立つ形で表示され、求職者の目に留まりやすくなります。

求人情報の詳細な構造化

JobPostingタイプではtitleで職種名、descriptionで募集内容を設定します。hiringOrganizationで採用企業をOrganizationとして、jobLocationで勤務地をPlaceとして記述します。baseSalaryで給与をMonetaryAmountとして、employmentTypeで雇用形態を指定します。datePostedで掲載日、validThroughで掲載期限、experienceRequirementsで必要経験、educationRequirementsで必要学歴を設定することで、求職者に必要な情報を漏れなく伝えることができます。

JobPostingタイプのJSON-LD実装例は以下のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "JobPosting",
  "title": "Webマーケター",
  "description": "SEO施策の企画・実行を担当していただきます",
  "datePosted": "2024-01-15",
  "validThrough": "2024-03-31",
  "employmentType": "FULL_TIME",
  "hiringOrganization": {
    "@type": "Organization",
    "name": "株式会社〇〇"
  },
  "jobLocation": {
    "@type": "Place",
    "address": {
      "@type": "PostalAddress",
      "addressLocality": "渋谷区",
      "addressRegion": "東京都",
      "addressCountry": "JP"
    }
  },
  "baseSalary": {
    "@type": "MonetaryAmount",
    "currency": "JPY",
    "value": {
      "@type": "QuantitativeValue",
      "minValue": "4000000",
      "maxValue": "6000000",
      "unitText": "YEAR"
    }
  }
}
</script>

JobPostingはGoogleが最も厳格に審査する構造化データの一つです。validThroughの期限が過ぎた求人が掲載されたままだと、Googleしごと検索から除外されるだけでなく、サイト全体の求人情報の信頼性が低下します。募集が終了した求人ページは、構造化データを削除するか、ページ自体を非公開にしてください。baseSalaryは実際に提示する年収・月収の範囲を正確に記述する必要があり、「経験により優遇」のような曖昧な表現を数値化する際は保守的な値を使用してください。hiringOrganizationには実際の雇用主を記載し、人材紹介会社が代理で掲載する場合はその旨をページ上に明記することが求められます。

Corporation構造化データで企業情報を詳細に記述する

Corporation構造化データは、Organizationのサブタイプとして法人格を持つ企業に特化した情報を記述します。私は構造化データの設計において、Person（人）、Organization（チーム・事業部・研究室などの組織単位）、Corporation（株式会社などの法人）を明確に分けることを推奨しています。法人にはlegalName（登記名）やfoundingDate（設立日）などの法人特有のプロパティを設定でき、組織単位よりも詳細な企業情報を構造化できます。

Corporationの基本プロパティ

Corporationタイプでは、Organizationよりも詳細な企業情報を記述できます。nameは一般的に使われる会社名、legalNameは登記簿に記載される正式名称を指定します。例えば「ソニー」がnameで「ソニーグループ株式会社」がlegalNameです。alternateNameには略称や旧社名を設定できます。

カテゴリ	プロパティ	説明
名称	name / alternateName / legalName	会社名 / 略称・別名 / 登記上の正式名称
基本情報	url / logo / image / description	公式サイト / ロゴ画像 / 企業イメージ / 説明文
SNS・外部	sameAs	公式SNSや外部プロフィールURL（配列）
沿革	foundingDate / foundingLocation / dissolutionDate	設立日 / 設立地 / 解散日
人員	founder / employee / numberOfEmployees	創業者 / 従業員 / 従業員数
ブランディング	slogan / tickerSymbol	スローガン / 証券コード

sameAsプロパティは、企業の公式SNSアカウントやWikipediaページなど、同一エンティティを指す外部URLを配列で指定します。これによりGoogleはナレッジパネルに各種リンクを表示でき、企業の公式情報源を明確に認識できます。foundingDateは設立日をISO 8601形式（例：2010-04-01）で記述し、企業の歴史や信頼性を示す要素となります。

グローバル企業や上場企業では、各種識別コードを記述することで、より正確なエンティティ識別が可能になります。

• naics：北米産業分類コード
• isicV4：国際標準産業分類コード
• duns：DUNS番号（企業識別番号）
• leiCode：LEIコード（法人識別子）
• taxID / vatID：納税者番号 / 付加価値税番号

これらの識別コードは必須ではありませんが、同名の企業が複数存在する場合や、B2B取引で企業の正確な識別が求められる場合に有効です。特にDUNS番号は米国企業との取引で、LEIコードは金融機関や上場企業で広く使われています。

住所・連絡先・拠点の設定

addressプロパティでは、PostalAddressタイプを使って本社や事業所の住所を構造化します。日本の住所を記述する場合、addressRegionに都道府県、addressLocalityに市区町村を指定します。streetAddressには番地以降の詳細住所を記述します。

プロパティ	内容	例
streetAddress	番地・建物名	〇〇ビル5階
addressLocality	市区町村	渋谷区
addressRegion	都道府県	東京都
postalCode	郵便番号	150-0001
addressCountry	国コード	JP

contactPointで問い合わせ窓口を複数設定できます。contactTypeにはcustomer service、technical support、salesなどを指定し、telephone、email、対応言語（availableLanguage）、対応時間（hoursAvailable）を記述します。

locationでは複数拠点の情報をPlace配列として記述できます。各拠点にname、address、geo（緯度経度）、営業時間を設定します。

組織構造・ブランド・実績

企業グループの構造やブランド展開を表現するプロパティも充実しています。ホールディングス体制の企業では、parentOrganizationで持株会社を、subOrganizationで事業子会社を明示することで、グループ全体の関係性をGoogleに伝えられます。

• 組織階層：parentOrganization（親会社）、subOrganization（子会社）、department（部門）
• 関係性：memberOf（加盟団体）、owns（所有資産）、sponsor / funder（出資先）
• ブランド：brand（ブランド配列）、makesOffer（提供サービス）、hasOfferCatalog（商品カタログ）
• 実績・信頼性：award（受賞歴）、hasCredential（資格・認定）、knowsAbout（専門分野）、publishingPrinciples（編集方針URL）

awardプロパティには受賞歴を、hasCredentialにはISO認証やプライバシーマークなどの取得資格を記述できます。publishingPrinciplesはメディア企業や情報発信を行う企業で編集ポリシーページのURLを指定し、情報源としての信頼性を示すのに有効です。

以下は、これらのプロパティを活用したCorporationタイプのJSON-LD実装例です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Corporation",
  "name": "株式会社サンプル",
  "legalName": "株式会社サンプル",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "description": "○○サービスを提供する企業",
  "foundingDate": "2010-04-01",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "○○ビル5階",
    "addressLocality": "渋谷区",
    "addressRegion": "東京都",
    "postalCode": "150-0001",
    "addressCountry": "JP"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+81-3-1234-5678",
    "contactType": "customer service",
    "email": "[email protected]"
  },
  "sameAs": [
    "https://twitter.com/example",
    "https://www.facebook.com/example"
  ]
}
</script>

構造化データの記述形式を選ぶ際のポイント

構造化データの記述形式にはJSON-LD、Microdata、RDFaの3種類がありますが、新規にサイトを構築する場合や、これから構造化データを導入する場合は、JSON-LDを選択することを強く推奨します。

JSON-LDを選ぶべき具体的な理由

JSON-LDはHTMLの本文から独立しているため、コンテンツ管理システムやテンプレートエンジンとの連携が容易です。WordPressなどのCMSを使っている場合、テーマファイルのヘッダーやフッターに一度scriptタグを追加すれば、PHPやJavaScriptで動的にデータを生成できます。また、JSON形式は多くのプログラミング言語で扱いやすいため、APIからデータを取得して自動的に構造化データを生成するといった処理も実装しやすいです。さらに、HTMLを変更せずに構造化データだけを修正できるため、デザイナーとエンジニアの作業分担もしやすくなります。

MicrodataやRDFaを使う場面

既存のシステムがMicrodataやRDFaを前提としている場合は、無理に変更する必要はありません。また、サーバーサイドでの処理が難しい静的サイトで、かつコンテンツとマークアップを一体化させたい場合は、Microdataも選択肢になります。RDFaは現在ではあまり使われませんが、特定の業界やプラットフォームで標準となっている場合は採用を検討してください。

構造化データを検証するためのツール

構造化データを実装したら、必ず検証ツールを使ってエラーがないか確認することが重要です。Googleが提供する公式ツールを活用することで、実装ミスを早期に発見できます。

リッチリザルトテストの使い方

Googleのリッチリザルトテストは、特定のURLまたはコードスニペットに対して構造化データを検証し、リッチリザルトの対象となるかどうかを判定するツールです。URLを入力してテストを実行すると、検出された構造化データの種類、エラー、警告が表示されます。エラーがある場合はリッチリザルトが表示されない可能性が高いため、必ず修正してください。警告は必須ではありませんが、可能な限り対応することでより良い結果が期待できます。

スキーママークアップ検証ツールの活用

schema.orgが提供するスキーママークアップ検証ツールは、より詳細な構文チェックが可能です。リッチリザルトテストがGoogleのリッチリザルト対応に特化しているのに対し、スキーママークアップ検証ツールはschema.org仕様への準拠を幅広くチェックします。両方のツールを併用することで、より正確な構造化データを実装できます。

Google Search Consoleでの継続監視

構造化データを実装した後は、Google Search Consoleで継続的に監視することが重要です。拡張機能レポートで、各構造化データタイプごとにエラーや警告の発生状況を確認できます。新たなエラーが検出された場合は通知が届くため、問題を早期に発見して対処できます。

WordPressで構造化データを設定する方法

WordPressサイトで構造化データを実装する方法は主に2つあります。プラグインを使う方法と、テーマファイルに直接コードを記述する方法です。

プラグインを使った簡単な実装

WordPressには構造化データを自動生成するプラグインが多数存在します。代表的なものとしてYoast SEO、Rank Math、All in One SEOなどがあり、これらは記事情報から自動的にArticleやBreadcrumbListなどの構造化データを生成します。プラグインを使えばコーディングの知識がなくても基本的な構造化データを実装できますが、カスタマイズの自由度は限られます。

主要なWordPress構造化データプラグインの特徴は以下のとおりです。

プラグイン名	自動生成	カスタマイズ性	対応スキーマ数
Yoast SEO	○	中程度	基本的なタイプ
Rank Math	○	高い	多数対応
All in One SEO	○	中程度	基本的なタイプ
Schema Pro	○	非常に高い	多数対応

テーマファイルへの直接実装

より細かい制御が必要な場合は、テーマファイルにJSON-LDを直接記述します。functions.phpにフックを追加してwp_headやwp_footerでscriptタグを出力する方法が一般的です。WordPressの各種関数を使って投稿タイトル、公開日、著者情報などを取得し、JSON-LD形式で出力することで、サイト固有の要件に合わせた構造化データを実装できます。

functions.phpでArticle構造化データを自動出力するコード例は以下のとおりです。

function output_article_jsonld() {
  if ( !is_single() ) return;

  $post_id = get_the_ID();
  $author = get_the_author();
  $title = get_the_title();
  $published = get_the_date('c');
  $modified = get_the_modified_date('c');
  $thumbnail = get_the_post_thumbnail_url($post_id, 'full');
  $excerpt = get_the_excerpt();

  $jsonld = array(
    '@context' => 'https://schema.org',
    '@type' => 'Article',
    'headline' => $title,
    'author' => array(
      '@type' => 'Person',
      'name' => $author
    ),
    'datePublished' => $published,
    'dateModified' => $modified,
    'image' => $thumbnail,
    'description' => $excerpt
  );

  echo '<script type="application/ld+json">' . "\n";
  echo json_encode($jsonld, JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT);
  echo "\n" . '</script>' . "\n";
}
add_action('wp_head', 'output_article_jsonld');

このコードを子テーマのfunctions.phpに追加すると、投稿ページでArticle構造化データが自動的に出力されます。is_single()で投稿ページのみに限定し、WordPressの関数でタイトルや日付を取得してJSON-LD形式に変換しています。

構造化データが反映されない原因と対処法

構造化データを実装しても検索結果に反映されない場合、いくつかの原因が考えられます。焦らずに一つずつ確認していくことが重要です。

主な原因として以下の3つが挙げられます。

• 構文エラー（JSON-LDの記述ミス、括弧の対応不備など）
• クロール・インデックスの問題（robots.txtのブロック、noindexタグなど）
• コンテンツ品質の問題（構造化データとページ内容の不一致など）

構文エラーによる問題

最も多い原因は構文エラーです。JSON-LDの場合、カンマの位置、引用符の閉じ忘れ、配列やオブジェクトの括弧の対応などをチェックしてください。リッチリザルトテストで構文エラーが検出されれば、該当箇所を修正します。Microdataの場合は、itemscope、itemtype、itempropの属性が正しく記述されているか確認してください。

クロールとインデックスの問題

構造化データ自体は正しくても、Googleがページをクロールしていない、またはインデックスしていない場合はリッチリザルトは表示されません。Google Search ConsoleでURLがインデックスされているか確認し、問題があればURL検査ツールでインデックス登録をリクエストしてください。robots.txtやnoindexタグでクロールやインデックスがブロックされていないかも確認が必要です。

コンテンツ品質の問題

Googleは構造化データの内容とページのコンテンツが一致しているかを評価します。構造化データで記述した情報がページ上に実際に存在しない場合、リッチリザルトが表示されないことがあります。また、薄いコンテンツやスパム的なページには、構造化データを実装してもリッチリザルトが表示されない傾向があります。

構造化データでよくあるエラーと修正方法

構造化データの実装でよく発生するエラーとその修正方法を知っておくことで、トラブルシューティングがスムーズになります。

必須プロパティの欠落

各構造化データタイプには必須プロパティがあります。たとえばProductタイプではnameとimageが必須であり、これらが欠けているとエラーになります。リッチリザルトテストでエラーメッセージを確認し、必須プロパティを追加してください。Googleのドキュメントで各タイプの必須プロパティと推奨プロパティを確認することをお勧めします。

不正な値の形式

日付はISO 8601形式（2024-01-15など）、URLは完全なURL（https://から始まる）、価格は数値として記述する必要があります。形式が不正な場合はエラーとなるため、各プロパティの期待される形式を確認してください。

参照の解決エラー

PersonやOrganizationを別の場所で定義して参照する場合、idプロパティを使って参照関係を明示します。参照先が存在しない場合や、idの記述が間違っている場合はエラーとなります。参照関係を使う場合は、idの値が正確に一致しているか確認してください。

構造化データ実装のベストプラクティス

構造化データは、プロパティの1つ1つに明確な意味があり、記述する順番や値の形式にも厳密なルールがあります。JSON-LDはHTMLと異なり、カンマ1つの位置、引用符の有無、日付のフォーマットなど構文に非常にデリケートです。うっかりミスで意図しない情報を検索エンジンに伝えてしまったり、気づかないうちにエラーが発生していることも珍しくありません。以下のポイントを押さえることで、そうしたトラブルを防げます。

実際のコンテンツと一致させる

構造化データはページの実際のコンテンツを正確に反映している必要があります。ページに表示されていない情報を構造化データに含めたり、実際と異なる価格や評価を記述したりすることは、Googleのガイドライン違反となります。ユーザーが目にする情報と構造化データの内容が一致していることを常に確認してください。

適切なタイプを選択する

同じ情報でも、文脈によって適切なタイプは異なります。ニュース記事にはNewsArticle、一般的な記事にはArticle、会社概要のような固定ページにはWebPageを使うといった使い分けが重要です。先述したように、Person、Organization、Corporationの使い分けも意識してください。

構造化データ実装で守るべき基本原則は以下のとおりです。

• 実際のページコンテンツと構造化データの内容を一致させる
• 適切なスキーマタイプを選択する
• 必須プロパティを漏れなく記述する
• 推奨プロパティも可能な限り追加する
• 定期的にエラーチェックを実施する

継続的なメンテナンス

構造化データは一度実装すれば終わりではありません。schema.orgの仕様更新、Googleのリッチリザルト対応変更、サイトのコンテンツ変更などに応じて、定期的な見直しとメンテナンスが必要です。Google Search Consoleの拡張機能レポートを定期的にチェックし、新たなエラーが発生していないか確認する習慣をつけてください。

構造化マークアップとSEOの関係を正しく理解する

構造化マークアップはSEOに直接的なランキング要因として作用するわけではありません。しかし、間接的に検索パフォーマンスを向上させる効果があります。

クリック率への影響

リッチリザルトが表示されることで、検索結果での視認性が向上し、クリック率が上がる可能性があります。同じ順位でも、通常の検索結果よりもリッチリザルトの方がユーザーの目を引くためです。商品の価格や在庫、レビュー評価が表示されるProductリッチリザルトや、イベント情報が表示されるEventリッチリザルトなどが代表例です。

検索エンジンの理解向上

構造化データによってコンテンツの意味が明確になることで、検索エンジンがページの内容をより正確に理解できるようになります。これにより、適切な検索クエリに対してページが表示されやすくなり、結果として検索トラフィックの向上につながる可能性があります。

E-E-A-Tのシグナルとして

著者情報や組織情報を構造化データで明示することは、E-E-A-T（経験、専門性、権威性、信頼性）のシグナルとして機能する可能性があります。PersonやOrganizationの構造化データで専門家の経歴や組織の実績を示すことで、コンテンツの信頼性をアピールできます。

構造化マークアップに注目しましょう

構造化マークアップの重要性は今後さらに高まると予想されます。検索エンジンがより高度な意味理解を目指す中で、構造化データは欠かせない要素となっています。

WebDataCommonsの長期調査によると、構造化データを含むWebページの割合は2010年のわずか5.7%から2024年には51.25%にまで成長しています。この10年以上にわたる普及の加速は、構造化データがWeb標準として定着したことを示しています。

AIと構造化データの関係

生成AIの発展により、検索体験は大きく変化しつつあります。AIが回答を生成する際に、構造化データで整理された情報は参照されやすくなる可能性があります。正確で詳細な構造化データを持つサイトは、AI検索時代においても優位に立てるかもしれません。

新しいスキーマタイプの登場

schema.orgには定期的に新しいタイプやプロパティが追加されています。業界の変化やユーザーニーズに応じて、新しい構造化データタイプがGoogleのリッチリザルトに対応することもあります。最新の仕様変更を追跡し、自サイトに関係する新機能があれば積極的に取り入れることをお勧めします。

まとめ

構造化マークアップは、Webページのコンテンツに意味を付与し、検索エンジンの理解を助けるための重要な技術です。JSON-LD形式を使った実装が推奨されており、Article、Person、Organization、Product、FAQPage、HowToなど様々なタイプが用意されています。

実装にあたっては、Googleのリッチリザルトテストやスキーママークアップ検証ツールでエラーをチェックし、実際のコンテンツと一致した情報を記述することが重要です。構造化データは直接的なランキング要因ではありませんが、リッチリザルトによるクリック率向上やE-E-A-Tシグナルとしての効果が期待できます。

Person（人）、Organization（チーム・事業部・研究室などの組織単位）、Corporation（法人企業）を明確に使い分け、記事にはArticle、ニュースにはNewsArticle、ブログにはBlogPosting、固定ページにはWebPageを使用するなど、適切なタイプ選択を心がけてください。継続的なメンテナンスとモニタリングにより、構造化マークアップの効果を最大限に引き出すことができます。

YouTube動画 – 柏崎剛SEO対策チャンネル

独自調査と集計結果

よくある質問

SEO Professional

柏崎 剛 (かしわざき つよし)

株式会社コンテンシャル

SEO対策研究室の室長、株式会社コンテンシャルの代表取締役を務める。長年WEB業界に携わった経験をもとに、SEO対策とAI活用を具体的かつ実践的に解説。SEOの技術的な部分だけでなく、コンテンツ戦略、内部設計、ページ速度の改善など、広く現場で活用できるノウハウを提供。実際の検証データや豊富な成功事例・失敗談も交えながら、すぐに役立つ施策をお伝えします。

執筆者