# 構造化マークアップとは？SEOに効くJSON-LDの書き方とschema.org完全ガイド > **Canonical:** https://www.tsuyoshikashiwazaki.jp/blog/seo-effects-of-structured-data/ > This Markdown is the AI-optimized parallel version of the canonical HTML page above. Authority, freshness, and canonicalness belong to the canonical page. > **Schema.org/Article** > - headline: 構造化マークアップとは？SEOに効くJSON-LDの書き方とschema.org完全ガイド > - author: 柏崎剛 > - datePublished: 2022-01-04T09:40:34+09:00 > - dateModified: 2026-01-25T09:18:30+09:00 > - inLanguage: ja > - url: https://www.tsuyoshikashiwazaki.jp/blog/seo-effects-of-structured-data/ > > **Schema.org/BreadcrumbList** > - 1: SEO対策研究室 (https://md.tsuyoshikashiwazaki.jp/) > - 2: 柏崎剛のSEOブログアーカイブ (https://md.tsuyoshikashiwazaki.jp/blog/) > - 3: 構造化マークアップとは？SEOに効くJSON-LDの書き方とschema.org完全ガイド (https://md.tsuyoshikashiwazaki.jp/blog/seo-effects-of-structured-data/) 構造化マークアップって聞くと「なんか難しそう」と感じる方も多いんじゃないでしょうか。僕も27年以上Webの世界にいますが、最初はとっつきにくいなと思ってました。ただ、クライアントさんのサイトで何度もJSON-LDを実装してきた経験から言うと、基本を押さえればそこまで複雑なものではありません。この記事では、JSON-LDの書き方からschema.orgの主要タイプ（Article・Person・Organization・FAQなど）の使い分け、WordPressでの実装方法まで、実務で本当に使える内容をまとめました。「リッチリザルトを出したい」「E-E-A-Tを強化したい」「構造化データって何から手をつければいいの？」という方に読んでもらえたらうれしいです。 目次閉じるもっと見る ## 構造化マークアップとは **構造化マークアップ**とは、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の本文に影響を与えずに構造化データを追加できるため、実装と保守が容易です。 JSON-LDの実装例は以下のとおりです。 ``` ``` > [構造化データ マークアップとは | Google 検索セントラル  |  Documentation  |  Google for DevelopersGoogle 検索がページの理解を高める「構造化データ マークアップとは」何か、解説します各機能のマークアップ例は「検索ギャラリー」から確認できます。Google for Developers外部リンク!\[構造化データ マークアップとは | Google 検索セントラル  |  Documentation  |  Google for Developers\]()]() ### Microdataの特徴と使いどころ MicrodataはHTMLの要素に直接属性を追加する形式です。itemscope、itemtype、itempropといった属性を使って、HTMLタグそのものに意味を付与します。コンテンツとマークアップが一体化しているため、動的にコンテンツが変わる場合でも構造化データが自動的に追従するというメリットがあります。ただし、HTMLが複雑になりやすく、既存サイトへの導入には手間がかかることが多いです。 Microdataの実装例は以下のとおりです。 ```

記事タイトル

公開日:

記事本文がここに入ります...

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

記事タイトル

公開日:

著者名

記事本文がここに入ります...

``` 3つの記述形式を比較すると、それぞれに明確な特徴があります。 記述形式記述場所Google推奨保守性採用率（2024年）JSON-LDscriptタグ内◎高い70%MicrodataHTML属性○中程度46%RDFaHTML属性○中程度3%SEO専門家[!\[柏崎剛\]()]()[柏崎剛]()実務でずっとJSON-LD推しでやってきてるんですけど、やっぱりHTMLをいじらずに構造化データを足したり直したりできるのは、運用フェーズでめちゃくちゃ楽なんですよね。クライアントさんのサイトでMicrodataからJSON-LDに切り替えた時、メンテナンスの手間が一気に減って「もっと早くやればよかった」って言われたこと、何回もあります。 ## 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実装例は以下のとおりです。 ``` ``` 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実装例は以下のとおりです。 ``` ``` BlogPostingは基本的にArticleと同じプロパティを使用しますが、参考までに実装例を示します。 ``` ``` ### WebPageで静的ページを表現する 一方、記事コンテンツではない静的な情報ページには**WebPage構造化データ**を使用します。Article/NewsArticle/BlogPostingが時系列で更新される「記事」を表現するのに対し、WebPageは会社概要、アクセス、サービス紹介など、時間が経っても内容が大きく変わらない普遍的なページに適しています。WebPageタイプではnameでページタイトル、urlでURL、descriptionで説明を指定します。datePublishedとdateModifiedで公開日と更新日を設定し、inLanguageで言語を明示します。isPartOfでそのページが属するWebSiteを参照できます。 WebPageのJSON-LD実装例は以下のとおりです。 ``` ``` ## 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実装例は以下のとおりです。 ``` ``` ![PersonタイプのJSON-LD構造を示す図解]() SEO専門家[!\[柏崎剛\]()]()[柏崎剛]()今のSEOってE-E-A-Tがかなり効いてくるので、Person構造化データはわりと優先度高めでやったほうがいいですよ。sameAsプロパティでSNSとか外部メディアの執筆実績を紐付けてあげると、Googleが著者の専門性をちゃんと拾ってくれるようになります。特にYMYLジャンルだと、著者情報の構造化で順位が動いたケースを僕も何回か見てきてるので、やらない手はないかなと。 ## Organization構造化データで組織の実在性を証明する Organization構造化データは、チーム、事業部、研究室、プロジェクトグループなどの組織単位を検索エンジンに伝えるために使用します。重要なのは、Organizationは法人格を持たない組織にも使用できる点です。法人企業にはCorporationを使用し、組織単位や部門にはOrganizationを使用するという使い分けが推奨されます。組織の実在性と信頼性を示すことで、そのコンテンツ全体の信頼度向上につながります。 ### Organizationの基本プロパティ Organizationタイプではnameで組織名を、urlで公式サイトURLやページURLを指定します。logoで組織のロゴやアイコンを設定し、sameAsで公式SNSアカウントや関連ページを配列として複数登録できます。memberOfで所属先の組織、parentOrganizationで親組織をそれぞれOrganizationまたはCorporationとして指定できます。departmentで配下の部署や下位組織を設定することも可能です。 OrganizationタイプのJSON-LD実装例は以下のとおりです。ここでは企業内の研究部門を例にしています。 ``` ``` ### LocalBusinessで店舗情報を充実させる LocalBusinessはOrganizationのサブタイプで、実店舗を持つビジネスに特化した構造化データです。Organizationのすべてのプロパティに加え、openingHoursで営業時間、priceRangeで価格帯を設定できます。geoプロパティにGeoCoordinatesで緯度経度を指定すれば、地図検索との連携も強化されます。areaServedでサービス提供地域、paymentAcceptedで対応決済方法、currenciesAcceptedで対応通貨を明示することもできます。ローカルSEOを強化したい場合、LocalBusinessの実装は必須と言えるでしょう。 WebDataCommonsの調査では、LocalBusiness構造化データの採用は2020年の約38.6万サイトから2024年には約130万サイトへと337%の成長を記録しています。この急速な普及は、ローカル検索におけるリッチリザルト表示の重要性が認識された結果と言えます。 LocalBusinessのJSON-LD実装例は以下のとおりです。 ``` ``` `geo`プロパティに緯度経度を設定することで、Googleマップとの連携が強化され、ローカル検索での表示が有利になります。緯度経度の値はGoogleマップで取得できますが、小数点以下の桁数が多すぎても問題ないため、そのままコピーして使用して構いません。 LocalBusinessで特に重要なのは、Googleビジネスプロフィールに登録している情報との一貫性です。店舗名、住所、電話番号（NAP情報）が構造化データとビジネスプロフィールで異なると、Googleが同一店舗として認識できず、ローカル検索での評価が分散します。「株式会社〇〇 渋谷店」と「〇〇渋谷店」のような表記ゆれ、ビル名の有無、電話番号のハイフンの有無なども統一してください。 ## WebSiteでサイト全体の情報を伝える WebSiteタイプはサイト全体を表現する構造化データです。nameでサイト名、urlでサイトURL、publisherで運営者、inLanguageで言語を指定します。potentialActionにSearchActionを設定すれば、サイト内検索機能を検索エンジンに認識させることができます。なお、かつて検索結果に表示されていたサイトリンク検索ボックスは2024年11月21日に廃止されており、現在はSearchActionを実装してもボックスは表示されません。ただし、サイト内検索機能の存在を検索エンジンに伝えるという意味では、引き続き実装する価値があります。 WebSite + SearchActionのJSON-LD実装例は以下のとおりです。 ``` ``` `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実装例は以下のとおりです。 ``` ``` BreadcrumbListの実装で課題となるのは、WordPressのカテゴリ構造とURL構造が一致しないケースです。私が開発したパンくずプラグインは、カテゴリではなく実際のURLパスを解析して階層を自動構築するアルゴリズムを採用しています。各階層のタイトルはスクレイピングで取得し、404エラー検出やリダイレクト追跡機能も備えているため、検索エンジンがクロールするパス構造に忠実なBreadcrumbList JSON-LDを生成できます。 > [GitHub - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-breadcrumbs: Advanced SEO breadcrumbs plugin with URL status checking to avoid 404 errors and automatic hierarchy generation from URL structure.Advanced SEO breadcrumbs plugin with URL status checking to avoid 404 errors and automatic hierarchy generation from URL structure. - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-breadcrumbsGitHub外部リンク!\[GitHub - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-breadcrumbs: Advanced SEO breadcrumbs plugin with URL status checking to avoid 404 errors and automatic hierarchy generation from URL structure.\]()]() ## 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実装例は以下のとおりです。 ``` ``` ## 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実装例は以下のとおりです。 ``` ``` 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実装例は以下のとおりです。 ``` ``` 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実装例は以下のとおりです。 ``` ``` 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実装例は以下のとおりです。 ``` ``` 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実装例は以下のとおりです。 ``` ``` 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実装例は以下のとおりです。 ``` ``` ImageObjectはリッチリザルトには直接影響しませんが、Google画像検索でのクレジット表示やライセンス情報の明示に役立ちます。オリジナルの図解やインフォグラフィックを制作しているサイトでは、copyrightHolderとlicenseを設定することで、画像の無断転載時に出典元として認識されやすくなる効果が期待できます。ストックフォトやフリー素材を使用している場合は、元の著作権者の情報を正確に記述するか、ImageObject自体の使用を控えるのが無難です。 ## SoftwareApplication構造化データでアプリ情報を伝える SoftwareApplication構造化データは、Webアプリやモバイルアプリなどのソフトウェア情報に使用します。アプリの検索結果にレビュー評価や価格が表示されるようになります。 ### アプリ情報の構造化 SoftwareApplicationタイプではnameでアプリ名、operatingSystemで対応OS、applicationCategoryでカテゴリを設定します。offersで価格情報をOfferとして、aggregateRatingで評価情報を記述できます。downloadUrlでダウンロードURL、screenshotでスクリーンショット、softwareVersionでバージョン情報を設定することも可能です。 SoftwareApplicationタイプのJSON-LD実装例は以下のとおりです。 ``` ``` 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実装例は以下のとおりです。 ``` ``` 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実装例は以下のとおりです。 ``` ``` JobPostingはGoogleが最も厳格に審査する構造化データの一つです。validThroughの期限が過ぎた求人が掲載されたままだと、Googleしごと検索から除外されるだけでなく、サイト全体の求人情報の信頼性が低下します。募集が終了した求人ページは、構造化データを削除するか、ページ自体を非公開にしてください。baseSalaryは実際に提示する年収・月収の範囲を正確に記述する必要があり、「経験により優遇」のような曖昧な表現を数値化する際は保守的な値を使用してください。hiringOrganizationには実際の雇用主を記載し、人材紹介会社が代理で掲載する場合はその旨をページ上に明記することが求められます。 ## Corporation構造化データで企業情報を詳細に記述する Corporation構造化データは、Organizationのサブタイプとして**法人格を持つ企業**に特化した情報を記述します。私は構造化データの設計において、Person（人）、Organization（チーム・事業部・研究室などの組織単位）、Corporation（株式会社などの法人）を明確に分けることを推奨しています。法人にはlegalName（登記名）やfoundingDate（設立日）などの法人特有のプロパティを設定でき、組織単位よりも詳細な企業情報を構造化できます。 ![Person、Organization、Corporationの使い分けを示す図解]() ### 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-0001addressCountry国コード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実装例です。 ``` ``` ## 構造化データの記述形式を選ぶ際のポイント 構造化データの記述形式には**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を入力してテストを実行すると、検出された構造化データの種類、エラー、警告が表示されます。エラーがある場合はリッチリザルトが表示されない可能性が高いため、必ず修正してください。警告は必須ではありませんが、可能な限り対応することでより良い結果が期待できます。 ![Googleリッチリザルトテストの実行画面]() ### スキーママークアップ検証ツールの活用 schema.orgが提供するスキーママークアップ検証ツールは、より詳細な構文チェックが可能です。リッチリザルトテストがGoogleのリッチリザルト対応に特化しているのに対し、スキーママークアップ検証ツールはschema.org仕様への準拠を幅広くチェックします。両方のツールを併用することで、より正確な構造化データを実装できます。 ![schema.orgのスキーママークアップ検証ツール画面]() ### Google Search Consoleでの継続監視 構造化データを実装した後は、Google Search Consoleで継続的に監視することが重要です。拡張機能レポートで、各構造化データタイプごとにエラーや警告の発生状況を確認できます。新たなエラーが検出された場合は通知が届くため、問題を早期に発見して対処できます。 ![Google Search Consoleの拡張機能レポート画面]() SEO専門家[!\[柏崎剛\]()]()[柏崎剛]()構造化データって、実装して終わりじゃないんですよね。schema.orgの仕様が変わったり、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○非常に高い多数対応 汎用SEOプラグインは多くのスキーマタイプに対応しようとするため、設定項目が増えて複雑になりがちです。記事コンテンツに特化したい場合は、Article/NewsArticle/BlogPosting/WebPageの4タイプに絞った専門プラグインも選択肢になります。**私が開発したプラグイン**では、投稿タイプごとにスキーマタイプを設定でき、タイトル・公開日・更新日・著者情報・アイキャッチ画像などをWordPressから自動取得してJSON-LDを出力します。本記事で解説した「NewsArticleとBlogPostingの使い分け」を投稿タイプレベルで管理できます。 > [GitHub - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-schema-content-type-builder: An SEO plugin that automatically generates structured data (JSON-LD) based on content type. It supports the Article, NewsArticle, BlogPosting, and WebPage schemas, and outputs comprehensive structured data that also includes breadcrumbs.An SEO plugin that automatically generates structured data (JSON-LD) based on content type. It supports the Article, NewsArticle, BlogPosting, and WebPage schemas, and outputs comprehensive structured data that also includes breadcrumbs. - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-schema-content-type-builderGitHub外部リンク!\[GitHub - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-schema-content-type-builder: An SEO plugin that automatically generates structured data (JSON-LD) based on content type. It supports the Article, NewsArticle, BlogPosting, and WebPage schemas, and outputs comprehensive structured data that also includes breadcrumbs.\]()]() ### テーマファイルへの直接実装 より細かい制御が必要な場合は、テーマファイルに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 '' . "\n"; } add_action('wp_head', 'output_article_jsonld'); ``` このコードを子テーマの`functions.php`に追加すると、投稿ページでArticle構造化データが自動的に出力されます。`is_single()`で投稿ページのみに限定し、WordPressの関数でタイトルや日付を取得してJSON-LD形式に変換しています。 ![WordPressのfunctions.phpにJSON-LD出力用のコードを追加している画面]() *WordPressのfunctions.phpに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専門家[!\[柏崎剛\]()]()[柏崎剛]()構造化データで一番こだわってるポイントが、Person・Organization・Corporationの使い分けなんです。正直、Googleのガイドライン的にはこの3つを厳密に分けなくても怒られないし、全部Organizationでまとめてもエラーにはなりません。でも「人」と「組織」と「法人」ってやっぱり別物じゃないですか。Googleのナレッジグラフって実世界のエンティティを識別・分類しようとしてるので、曖昧に書くと情報が混同されるリスクがあるんですよね。リッチリザルトに直接響く話ではないんですけど、検索エンジンにエンティティを正確に伝えることが、長い目で見たSEOの土台になると思ってます。 ## 構造化マークアップとSEOの関係を正しく理解する 構造化マークアップはSEOに直接的なランキング要因として作用するわけではありません。しかし、間接的に検索パフォーマンスを向上させる効果があります。 ### クリック率への影響 リッチリザルトが表示されることで、検索結果での視認性が向上し、クリック率が上がる可能性があります。同じ順位でも、通常の検索結果よりもリッチリザルトの方がユーザーの目を引くためです。商品の価格や在庫、レビュー評価が表示されるProductリッチリザルトや、イベント情報が表示されるEventリッチリザルトなどが代表例です。 ### 検索エンジンの理解向上 構造化データによってコンテンツの意味が明確になることで、検索エンジンがページの内容をより正確に理解できるようになります。これにより、適切な検索クエリに対してページが表示されやすくなり、結果として検索トラフィックの向上につながる可能性があります。 ### E-E-A-Tのシグナルとして 著者情報や組織情報を構造化データで明示することは、E-E-A-T（経験、専門性、権威性、信頼性）のシグナルとして機能する可能性があります。PersonやOrganizationの構造化データで専門家の経歴や組織の実績を示すことで、コンテンツの信頼性をアピールできます。 本記事で繰り返し強調したPerson・Organization・Corporationの使い分けは、Googleのナレッジグラフでエンティティが混同されるリスクを防ぐ上で不可欠です。私が開発したWordPressプラグインでは、この3種類の著者タイプを管理画面から選択するだけで、Article/NewsArticle/BlogPosting/WebPageスキーマと連携したJSON-LDを自動出力できます。コーディング不要でエンティティ分類設計を実装できる点が特徴です。 > [GitHub - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-author-sd: WordPress plugin for SEO author schema display with social links and JSON-LD generationWordPress plugin for SEO author schema display with social links and JSON-LD generation - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-author-sdGitHub外部リンク!\[GitHub - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-author-sd: WordPress plugin for SEO author schema display with social links and JSON-LD generation\]()]() ## 構造化マークアップに注目しましょう 構造化マークアップの重要性は今後さらに高まると予想されます。検索エンジンがより高度な意味理解を目指す中で、構造化データは欠かせない要素となっています。 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対策チャンネル ## 独自調査と集計結果 構造化データを実装していますか？集計データを拡大[このデータセットの詳細ページを見る]() ## よくある質問 ❓構造化マークアップを実装すれば必ずリッチリザルトが表示されますか？▼✅残念ながら、実装したからといって必ず表示されるわけじゃないんですよ。Googleはコンテンツの品質とか、検索意図との関連性なんかも見たうえで表示するかどうか決めてます。ただ、構造化データが入ってないとそもそもリッチリザルトの候補にすらならないので、実装しておくのは大事です。❓JSON-LDとMicrodataのどちらを使うべきですか？▼✅新しく入れるならJSON-LD一択でいいと思います。Google自身が公式に推奨してますし、HTMLに手を入れずに構造化データを足せるのが何より楽です。保守性も高いし、デバッグもしやすい。ただ、すでにMicrodataで動いてるサイトをわざわざ全部書き換える必要はないですよ。❓構造化データのエラーはどうやって確認できますか？▼✅Googleのリッチリザルトテストが一番手っ取り早いです。URLを入れるだけでエラーや警告が出てきます。もう少し細かくチェックしたい場合は、schema.orgのスキーママークアップ検証ツールも使ってみてください。あと、実装した後はGoogle Search Consoleの拡張機能レポートで定期的にウォッチしておくと、いつの間にかエラーが出てたなんて事態を防げます。 ## 関連する記事 [!\[サジェストキーワードとは？と記載された画像\]()]()[サジェストキーワードとは？SEOで成果を生む調べ方とおすすめツールを解説]()サジェストキーワードとは、検索エンジンの自動提案機能で表示さ…[!\[自分でSEO対策 サイトの状況を理解し最適な対策を考えようと記載された画像\]()]()[【2026年版】自分でできるSEO対策！初心者向け実践ガイド]()初心者でも自分でできるSEO対策の基本と実践ステップを解説。…[!\[トピッククラスターモデルとはと記載された画像\]()]()[トピッククラスターとは？SEO効果を最大化するメリットと構築ステップをわかりやす...]()トピッククラスターとは、コアトピックとサブトピックを内部リン…[!\[コアウェブバイタル改善方法を解説する記事のアイキャッチ画像 オレンジ色の背景に最新情報！コアウェブバイタル改善方法というテキストと笑顔の柏崎剛と頭を抱える人のイラストが配置されている\]()]()[コアウェブバイタルとは？3つの指標とSEOを高めるための対策方法を徹底解説]()コアウェブバイタルはGoogle検索ランキングに影響するペー…[!\[LSIキーワードを解説することを強調した画像 オレンジと黄色の背景と説明する男性が表示されている\]()]()[LSIキーワードとは？SEO効果を高める調べ方と使い方]()LSIキーワードとは、メインキーワードの意味的関連語を自然に…[!\[SEOにおけるHTMLタグとは？基本の役割を解説\]()]()[SEOにおけるHTMLタグとは？基本の役割を解説]()HTMLタグの正しい設定はSEOの基本であり、ページの構造化…‹› ## 記事が気に入ったらシェアをお願いします！ []()[]()[]()[]()[]()[]()[]()記事は参考になりましたか？ （[ご意見・ご感想はこちら]()） はいいいえ --- > **Schema.org/Person** (author) > - name: 柏崎剛 > - url: https://www.tsuyoshikashiwazaki.jp/profile/ > > **Schema.org/Organization** (site owner) > - name: SEO対策研究室 > - url: https://www.tsuyoshikashiwazaki.jp/ > - logo: https://www.tsuyoshikashiwazaki.jp/wp-content/uploads/2025/07/cropped-20250722-114641-3bfe11f1.jpg