会社概要のページを整えたあと、制作会社やSEOの担当者から「構造化データの Organization も入れておきましょう」と勧められることがあります。ところが、何を書けばよいのか、SEOプラグインの設定だけで足りるのか、AI検索の対策として本当に必要なのかは、発注する側からは判断しにくいものです。

結論から言うと、Organization の構造化データは、会社名・所在地・ロゴ・連絡先・公式の外部ページなどを検索エンジンが読み取れる形で記述するもので、値を会社概要ページの表示と一字一句そろえ、トップページか会社概要ページに置くのが基本です。必須の項目はなく、自社に当てはまる推奨プロパティを、ページに表示している値で入れます。

この記事では、Google が推奨するプロパティと書き方、型（@type）の選び方、会社概要と値を合わせる方法、当社サイトでの実装例、WordPress での入れ方、確認ツール、よくある間違いを、2026年10月時点の Google 検索セントラルのドキュメントにもとづいて解説します。会社概要のページに載せる項目と、ほかの媒体と表記をそろえる方法は、ホームページの会社概要の書き方で解説しています。

Organization の構造化データとは

Organization の構造化データは、会社の基本情報を schema.org という共通の語彙で記述したもので、Google が会社の詳細を把握し、ほかの組織と見分けるための手がかりになります。

Google の組織（Organization）の構造化データのドキュメント（2026年9月12日更新）では、ホームページに組織の構造化データを追加すると、Google が組織の管理情報の詳細を把握し、検索結果で組織を明確にできるようになると説明しています。プロパティには、識別番号や業種コードのようにほかの組織と見分けるために裏側で使われるものと、logo のように検索結果やナレッジパネルの見た目に関わるものがあります。

書き方の形式には JSON-LD・microdata・RDFa の3つがあり、Google は JSON-LD を推奨しています（構造化データに関する一般的なガイドライン）。JSON-LD は本文とは別にまとめて書く形式なので、デザインに手を入れずに追加や修正ができます。

ただし、正しく書いても検索結果にロゴなどが必ず表示されるとは限らないことが、Google のドキュメントに明記されています。会社を正しく伝える土台はあくまでページ本文の会社情報で、構造化データは同じ内容を機械が読める形で補うものと考えます。

Google が推奨するプロパティと書き方

Google の Organization のドキュメントに必須のプロパティはなく、name・url・logo・address・description など、自社に当てはまる推奨プロパティを、ページに表示している値で入れます。

プロパティ	意味	書き方のポイント	中小企業での優先度
name	組織の名前	サイト名に使っている名前と同じにする（Google の指定）。通常は正式名称	高
alternateName	通称・別の名前	略称、英語表記、ロゴの表記など。複数書ける	高
legalName	登記上の正式名称	name と違う名前がある場合だけ書く	中
url	公式サイトの URL	トップページの URL。Google が組織を一意に識別するのに役立つとされる	高
logo	ロゴ	112×112 ピクセル以上で、クロールとインデックスができる画像。白い背景で正しく見えるかを確かめる	高
description	組織の詳しい説明	会社概要の「何を・誰に・どこで」の説明と同じ趣旨にする	高
address	所在地	PostalAddress の型で、postalCode（郵便番号）・addressRegion（都道府県）・addressLocality（市区町村）・streetAddress（番地など）・addressCountry（国。日本は JP）に分ける。拠点が複数なら複数書ける	高
telephone・email	問い合わせ用の電話番号・メールアドレス	公開しているものだけ。電話番号は国番号と市外局番を含める	公開していれば高
contactPoint	問い合わせの窓口	窓口ごとに電話番号やメールアドレスを書く	中
sameAs	同じ組織について書かれた別サイトのページ	公式の SNS アカウント、口コミサイトなどのページの URL。複数書ける	高
foundingDate	設立日	ISO 8601 の形式（例：2010-06-01）	中
taxID	納税者番号	address の国と合っている番号にする	中
numberOfEmployees	従業員数	正確な人数か、範囲（minValue・maxValue）で書く	低〜中
iso6523Code・duns・leiCode・naics	国際的な識別番号・業種コード	取得している場合だけ。DUNS 番号と LEI は、iso6523Code に「0060:」「0199:」を付けて書く方法がすすめられている	低

このほか、通販の会社向けに返品・配送の方針を書くプロパティもあります。LocalBusiness の型を使う場合は、メインの電話番号とメールアドレスを LocalBusiness の階層に書いたうえで、複数の窓口を contactPoint で書くよう案内されています。

Service

AI時代のWEBのご相談はフェニックスデザインへ

ナレッジベースを運営するフェニックスデザインが、今のサイトの数字を見るところから対応します。URLを入れるだけの無料簡易診断から。

無料で簡易診断 SEO・AI検索（AIO）対策のサービスを見る

型（@type）の選び方：Organization か LocalBusiness か

@type は、会社に当てはまるもっとも具体的な型を選び、客が訪れる店舗や事業所なら LocalBusiness の具体的な型、来店を前提にしない会社なら Organization を基本にします。

会社の種類	型の例	補足
来店を前提にしない会社（メーカー、物流、BtoBのサービス業など）	Organization。株式会社などの法人なら、Organization の下位の型の Corporation も使える	所在地は address で書く
客が訪れる店舗・医院・事業所	LocalBusiness の具体的な型（例：Dentist、AutoRepair、Restaurant）	Google の LocalBusiness のドキュメントにある必須・推奨の項目も入れる
ネット通販の会社	OnlineStore（Google のドキュメントの例）	返品・配送の方針も Organization の階層で書ける

型は配列にして複数を書くこともでき、以前は当社も Organization と ProfessionalService（専門サービス）を併記していましたが、schema.org の ProfessionalService のページには、地域の事業者向けの汎用の型としては Service と紛らわしいため非推奨になった、という注記があるため、2026年10月に Organization と LocalBusiness の併記に変えました。これから型を決める場合は、業種に合う具体的な型があればそれを使い、見つからなければ Organization（または Corporation）にしておくのが無難です。

会社概要の表示と値を一致させる方法

構造化データの値は、会社概要の表に表示している文字をそのまま使い、ページに表示していない情報は入れないのが原則です。

Google の一般的なガイドライン（2026年9月16日更新）は、読者に表示されないコンテンツをマークアップしないこと、構造化データがページの内容を正確に表していることを求めており、違反すると手動による対策の対象になることがあります。会社概要の項目とプロパティは、次のように対応させます。

会社概要の項目	プロパティ	合わせ方の注意
会社名・英語表記・略称	name・alternateName	表の表記をそのまま使い、サイト名とも同じにする
所在地	address	分けて書いた値をつなげたとき、表の表記と同じになるようにする
設立	foundingDate	表は「2010年6月1日」、構造化データは「2010-06-01」のように、形式だけを変える
代表者	founder（創業者の場合）	Google の推奨プロパティに代表者を表すものはない。創業者でない代表者は founder に入れない
事業内容	description・knowsAbout	表の事業内容と同じ範囲にし、行っていない事業を書かない
登録番号	taxID	表に載せている番号と同じにする
連絡先・受付時間	telephone・email・contactPoint	表に出していない電話番号やメールアドレスは入れない。受付時間は、LocalBusiness なら openingHoursSpecification、Organization なら contactPoint の hoursAvailable で書ける
対応エリア	areaServed	表の対応エリアの書き方と食い違わないようにする
資本金・決算期・取引銀行	（推奨プロパティなし）	無理に入れなくてよい

表に出していない値（電話番号、従業員数など）は、表に載せるか構造化データから外すかを決めます。移転・社名変更・代表者の交代があったときは、会社概要と構造化データを同じ日に直せるよう、担当者を決めておきます。

当社サイトの実装例

当社は、会社案内ページの会社概要と同じ設定値から Organization を出力し、全ページで共通の1つのデータにして、記事やサービスのデータから @id で参照しています。

主なプロパティと、記述するときに判断したことは次のとおりです。

プロパティ	当社の記述	判断したこと
@type	Organization、LocalBusiness	会社としての情報は Organization で書き、所在地の緯度・経度や受付時間（LocalBusiness の項目）も記述するため LocalBusiness を併記した（前の章の注記を参照）
@id	https://phoenix-design.co.jp/#organization	ほかのデータから同じ会社を指すための識別子
name	フェニックスデザイン株式会社	サイト名（WebSite の name）と同じにした
alternateName	フェニックスデザイン／Phoenix Design Inc.／PHOENIX DESIGN	略称、英文社名、ロゴの表記の3つを並べた
logo	512×512 ピクセルのロゴ画像（ImageObject）	Google の最小サイズ（112×112）を上回る正方形の画像にした
address	postalCode：340-0821／addressRegion：埼玉県／addressLocality：八潮市／streetAddress：伊勢野573-1／addressCountry：JP	会社概要の表示と同じ値にし、番地は法人番号公表サイトの本店所在地と一致させた
contactPoint	contactType：sales／availableLanguage：Japanese／url：お問い合わせフォームのページ	電話番号を公開していないため、telephone は書いていない
taxID・sameAs	taxID：T8010001249933／sameAs：国税庁法人番号公表サイトの当社のページ	会社概要に載せている登録番号を入れ、公的な登録情報と同じ会社であることを示した
areaServed	埼玉県・東京都・千葉県・神奈川県（AdministrativeArea）、日本（Country）	拠点の周辺の都県と、全国に対応していることを型で分けて書いた

ほかのデータからは、この @id だけを書いて参照しています。会社の情報を1か所にまとめておくと、ページごとに書き写す必要がなく、値の食い違いも起きません。

サイト全体を表す WebSite の publisher（発行者）
サービスページの Service の provider（提供者）
ナレッジベースの記事の Article の author（著者）と publisher
トップページと会社案内ページの mainEntity（ページの主な対象）

Google は、Organization はトップページか会社概要などの1ページにあればよく、すべてのページに入れる必要はないとしています。当社は記事やサービスのデータから参照するために全ページの共通部分に置いていますが、中身は1つです。会社概要の表と構造化データはテーマの同じ設定値から出力しているため、片方だけ直し忘れることもありません。

WordPress での入れ方の選択肢

WordPress では、SEO プラグインの設定画面で入れる、テーマのテンプレートに書く、コードを追加するプラグインで貼る、の3つの方法があり、所在地や登録番号まで正確に入れるならテーマ側で書く方法が確実です。

方法	できること	注意点
SEO プラグインの設定	Yoast SEO は「Yoast SEO」→「設定」→「Site representation」で、組織名・別名・ロゴ・SNS などのプロフィールを入力でき、Organization として出力される（Yoast のヘルプ）。Rank Math は Local SEO の設定で、組織名・ロゴ・メール・電話・住所・営業時間などを入力できる（Rank Math のヘルプ）	入力できる項目はプラグインと版で違う。Yoast SEO の詳しい事業情報は有料版と Local SEO アドオンで追加する
テーマのテンプレートに書く	会社概要の表と同じ値から JSON-LD を出力でき、型やプロパティを自由に決められる	制作会社に依頼する。配布されているテーマに直接書くと更新で消えることがあるため、子テーマや独自のテーマで管理する
コードを追加するプラグイン	管理画面から JSON-LD を貼り付けられる	会社概要を直したときに、手で直す必要がある。直し忘れが起きやすい

どの方法でも、値の違う Organization が2つ以上出力されないようにします。SEO プラグインを入れたままテーマでも出力すると、社名やロゴが違う2つの Organization が並ぶことがあるため、次の章の確認ツールで検出される数を確かめます。

確認ツールと確認の手順

公開前はリッチリザルトテストと Schema Markup Validator で記述の誤りを確かめ、公開後は Search Console の URL 検査とレポートで、Google から見えている状態を確認します。

ツール	分かること	使う時期
リッチリザルトテスト（Google）	ページで見つかった構造化データ、エラー、改善の候補。URL かコードを入れて確かめられ、スマートフォンとパソコンを切り替えられる	公開前（コード）と公開直後（URL）
Schema Markup Validator（schema.org）	Google の機能に限らず、schema.org の型とプロパティの書き方全体の誤り	型やプロパティ名を確かめたいとき
URL 検査（Search Console）	Google がページをどう見ているか。公開中の URL をテストできる	公開後
解析できない構造化データのレポート（Search Console）	文法の誤りで読み取れない構造化データ。多くのページで同じ誤りがあれば、共通のテンプレートが原因のことが多い	公開後の定期確認（該当がある場合だけ表示される）

2つのテストツールの役割の違いは、Google 検索セントラルの構造化データのテストのページでも説明されています。

公開前に、リッチリザルトテストと Schema Markup Validator にコードを入れ、エラーや型・プロパティ名の誤りがないかを確かめる
公開後に会社概要ページの URL をリッチリザルトテストに入れ、Organization が1つだけ検出されるかを見て、値をページの表示と照合する
Search Console の URL 検査で公開中の URL をテストし、以後は月に1回、構造化データの問題が出ていないかを見る

会社情報の構造化データの有無は、当社の無料簡易診断でも確認できます。

よくある間違い

よくある間違いは、ページに表示していない値を構造化データにだけ書く、移転や社名変更のあと構造化データだけが古いまま残る、プラグインとテーマで二重に出力する、の3つです。

間違い	起きること	直し方
会社概要に載せていない電話番号・住所・従業員数を、構造化データにだけ書く	表示されないコンテンツをマークアップしないというガイドラインに反する	ページに表示するか、構造化データから外す
移転・社名変更・代表者の交代のあと、構造化データだけが古い	検索結果や AI の回答に古い情報が残る原因になる	会社概要と同じ日に直す。同じ値から出力する仕組みにする
プラグインとテーマで、値の違う Organization が2つ出る	どちらが正しい情報か分からなくなる	出力をどちらか一方にする
sameAs に、自社について書かれていないページ（業界団体や取引先のトップページなど）を入れる	別の組織と結びつけられるおそれがある	自社のアカウントや、自社について書かれたページだけにする
日付を「2024年11月11日」、URL を「/about/」のように書く	正しく読み取られないことがある	日付は ISO 8601（2024-11-11）、URL は https から始まる絶対 URL で書く

よくあるご質問

Organization の構造化データを入れると、検索順位は上がりますか？

Google のドキュメントでは、組織の詳細を把握し、検索結果で組織を明確にするためのものと説明されており、順位が上がるとは書かれていません。社名で検索されたときなどに、会社とサイトを正しく結びつけてもらうための整備と考えます。

AI検索の対策として、構造化データは必要ですか？

Google は、AI による概要や AI モードに表示されるための特別な最適化はなく、構造化データがページの表示と一致していることを基本の一つに挙げています（AI 機能とウェブサイト）。AI に会社を正しく伝える土台は会社概要の本文で、構造化データは同じ内容を機械が読める形で補うものです。本文と食い違う構造化データは、誤解の原因になります。

電話番号を公開していない会社は、どう書けばよいですか？

telephone は書かず、問い合わせフォームのページの URL を contactPoint の url に書きます。telephone は推奨プロパティで必須ではないため、公開していない番号を構造化データのためだけに載せる必要はありません。

まとめ

Organization の構造化データは、会社概要に書いた会社の基本情報を、検索エンジンが読み取れる形で記述するものです。要点は次のとおりです。

必須のプロパティはなく、name・url・logo・description・address・sameAs など当てはまるものを入れる
型はもっとも具体的なものを選び、来店を前提にしない会社は Organization を基本にする
値は会社概要の表示とそろえ、表に出していない値は入れない。二重に出力しない
確認ツールで確かめ、会社情報が変わったら会社概要と同じ日に直す

当社のSEO・AI検索（AIO）対策では、Organization・Service・FAQPage・Article・BreadcrumbList の構造化データの実装と、サイト内・Google ビジネスプロフィール・外部サイトの会社情報の統一を、制作会社として直接行っています。他社が制作したサイトや WordPress 以外のサイトにも対応します。

フェニックスデザイン株式会社WEB制作会社が運営するナレッジベース編集部

コーポレートサイト・採用サイト・サービスサイトの制作と、公開後の運用保守・集客改善の現場で得た知見をもとに、発注する側の視点で記事を制作・更新しています。運営会社の所在地・事業内容は会社案内、制作の考え方はブランディング×マーケティング論をご覧ください。

この記事は 2026年10月26日に公開し、2026年10月26日に内容を確認・更新しました。

構造化データOrganizationの書き方：推奨項目と会社概要との合わせ方