「MEO対策はGBPの最適化だけ」と思っていませんか。
実は、自社のWebサイト側でできるMEO施策があります。それが構造化データ(Schema.org)の実装です。
構造化データとは、Webページの内容を検索エンジンが理解しやすい形式で記述する仕組みのことです。 ローカルビジネスにおいては「LocalBusiness」という構造化データタイプを使うことで、Googleに対して店舗の所在地、営業時間、連絡先などの情報を正確に伝えることができます。
構造化データを正しく実装することで、Google検索のリッチリザルト(ナレッジパネルなど)に情報が表示されやすくなり、MEOとSEOの両面で効果が期待できます。 WEBRIESでは、構造化データの実装に加えて、自社運営の業種特化型ポータルサイトがサイテーション源として機能しています。ポータル側にも正確なNAP情報と構造化データを実装しているため、外部からの信頼性シグナルが二重に積み上がる仕組みです。
この記事では、LocalBusinessマークアップの基本知識から具体的な実装方法、テスト手順まで、技術的な内容をわかりやすく解説します。
MEO対策の全体像はMEO対策の完全ガイドで、構造化データ全般の知識は構造化データの完全ガイドで解説しています。
構造化データとは何か — MEOとの関係性
構造化データの基本概念
検索エンジンは、Webページの内容をHTMLのテキストから読み取ります。 しかし、「渋谷区神宮前1-2-3」というテキストが「住所」なのか「記事の一文」なのか、HTMLだけでは正確に判断できません。
構造化データは、このような曖昧さを解消するためのものです。 「これは住所です」「これは電話番号です」「これは営業時間です」と、検索エンジンに対して明示的にデータの意味を伝える仕組みです。
構造化データの標準的なフォーマットとして、Google、Microsoft(Bing)、Yahoo!などが共同で策定した「Schema.org」が広く使われています。
LocalBusinessマークアップとは
Schema.orgには数百種類のデータタイプが定義されていますが、ローカルビジネスにとって最も重要なのが「LocalBusiness」タイプです。
LocalBusinessは、物理的な店舗や事業所を持つビジネスの情報を記述するためのデータタイプです。 以下のような情報を構造化データとして記述できます。
- ビジネス名
- 住所(郵便番号、都道府県、市区町村、番地)
- 電話番号
- 営業時間
- 定休日
- Webサイト URL
- ビジネスの説明
- 価格帯
- 支払い方法
- 地理座標(緯度・経度)
- 写真・ロゴ
なぜMEOに効果があるのか
構造化データが直接MEOのランキング要因になるかどうかについて、Googleは公式には明言していません。 しかし、構造化データがMEO対策に効果的である理由は複数あります。
情報の正確性向上 GBPに登録した情報と、Webサイトの構造化データに記述した情報が一致していることで、Googleはその情報の信頼性を高く評価します。 NAP(Name, Address, Phone)の一貫性は、MEOにおける重要なランキング要因の1つです。
リッチリザルトの表示 構造化データを実装することで、Google検索のリッチリザルト(ナレッジパネル、営業時間の表示など)に情報が表示されやすくなります。 これにより、検索結果でのクリック率(CTR)が向上します。
Googleの理解促進 構造化データによって、Googleはビジネスの業種、所在地、サービス内容をより正確に理解できるようになります。 これは「関連性」の評価向上につながります。
LocalBusinessの主要なサブタイプ
業種に合わせたサブタイプの選択
LocalBusinessには、業種に応じた細かいサブタイプが用意されています。 より具体的なサブタイプを使用することで、Googleに対してビジネスの業種を正確に伝えることができます。
| 業種 | 推奨サブタイプ |
|---|---|
| レストラン・飲食店 | Restaurant, CafeOrCoffeeShop, BarOrPub |
| 美容室・サロン | HairSalon, BeautySalon, NailSalon |
| 歯科医院 | Dentist |
| 医療機関 | MedicalClinic, Physician, Hospital |
| 弁護士事務所 | LegalService, Attorney |
| 不動産業 | RealEstateAgent |
| フィットネス | HealthClub, ExerciseGym |
| 小売店 | Store, ClothingStore, HardwareStore |
| 自動車関連 | AutoDealer, AutoRepair |
| 宿泊施設 | Hotel, Motel, LodgingBusiness |
例えば、歯科医院であれば「LocalBusiness」ではなく「Dentist」を使用することで、Googleはこのビジネスが歯科医院であることをより正確に理解できます。
サブタイプの継承関係
Schema.orgのデータタイプは階層構造になっています。 例えば、Dentistは以下のように継承されています。
Thing → Organization → LocalBusiness → MedicalBusiness → Dentist
サブタイプは親タイプの全てのプロパティを継承します。 つまり、DentistタイプではLocalBusinessのプロパティ(address, openingHoursなど)に加えて、MedicalBusinessやDentist固有のプロパティも使用できます。
具体的な実装方法 — JSON-LDの書き方
JSON-LD形式の推奨
構造化データの記述形式には、JSON-LD、Microdata、RDFaの3種類がありますが、Googleが公式に推奨しているのはJSON-LD形式です。
JSON-LDは、HTMLの<head>または<body>内に<script>タグで記述します。
HTMLのマークアップとは独立しているため、既存のHTMLを変更する必要がなく、実装と保守が容易です。
基本的なLocalBusinessマークアップの例
以下は、飲食店の構造化データの基本的な記述例です。
{
"@context": "https://schema.org",
"@type": "Restaurant",
"name": "イタリアン レストラン サンプル",
"image": "https://example.com/photos/restaurant.jpg",
"url": "https://example.com",
"telephone": "+81-3-1234-5678",
"priceRange": "¥¥",
"address": {
"@type": "PostalAddress",
"streetAddress": "神宮前1-2-3",
"addressLocality": "渋谷区",
"addressRegion": "東京都",
"postalCode": "150-0001",
"addressCountry": "JP"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 35.6695,
"longitude": 139.7025
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "11:00",
"closes": "22:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Saturday", "Sunday"],
"opens": "10:00",
"closes": "23:00"
}
],
"servesCuisine": "Italian",
"acceptsReservations": true
}
この記述をHTMLの<head>内に以下のように配置します。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Restaurant",
...(上記の内容)
}
</script>
複数店舗がある場合の記述
複数の店舗を持つビジネスの場合、各店舗のページにそれぞれのLocalBusinessマークアップを記述します。 加えて、親組織としてOrganizationマークアップを記述し、各店舗との関連を示すことも推奨されます。
各店舗ページには、その店舗固有の住所、電話番号、営業時間を記述してください。 全店舗で共通の情報を使い回すと、NAP情報の混乱を招く恐れがあります。
重要なプロパティの詳細解説
NAP情報(Name, Address, Phone)
NAP情報は構造化データの中で最も重要な要素です。 GBPに登録されている情報と完全に一致させることが鉄則です。
「渋谷区」と「東京都渋谷区」、「03-1234-5678」と「+81-3-1234-5678」のような表記の揺れも、可能な限り統一しましょう。 厳密にはGoogleは表記の揺れをある程度認識できますが、完全に一致させるに越したことはありません。
特に注意すべきなのは電話番号です。 構造化データでは国際電話番号形式(+81-3-1234-5678)が推奨されていますが、GBPでは国内形式(03-1234-5678)で登録していることが多いです。 両方の形式を認識できるよう、Webサイト上でも両方を記載するか、GBPの形式に合わせるのが安全です。
営業時間(openingHoursSpecification)
営業時間の記述は、曜日ごとに細かく設定できます。 祝日や特別営業日についても、specialOpeningHoursSpecificationプロパティを使って記述することが可能です。
"specialOpeningHoursSpecification": {
"@type": "OpeningHoursSpecification",
"validFrom": "2026-12-31",
"validThrough": "2026-12-31",
"opens": "00:00",
"closes": "00:00"
}
上記は12月31日を休業日として設定する例です。 opensとclosesの両方を「00:00」にすることで、その日は営業しないことを示します。
地理座標(geo)
緯度・経度の情報は、Googleがビジネスの所在地を正確に把握するために重要です。 Googleマップで自分の店舗の位置を確認し、正確な緯度・経度を取得してください。
Googleマップ上で店舗の位置を右クリックすると、座標が表示されます。 この値をそのまま構造化データに記述しましょう。
写真・ロゴ(image, logo)
imageプロパティには、ビジネスを代表する写真のURLを記述します。 複数の画像を指定する場合は配列形式で記述できます。
"image": [
"https://example.com/photos/exterior.jpg",
"https://example.com/photos/interior.jpg",
"https://example.com/photos/menu.jpg"
],
"logo": "https://example.com/logo.png"
画像のURLは、実際にアクセス可能な有効なURLである必要があります。 リンク切れの画像URLを指定すると、構造化データの信頼性が低下します。
実装後のテストと検証
Googleのリッチリザルトテスト
構造化データを実装したら、必ずGoogleの「リッチリザルトテスト」ツールで検証しましょう。 https://search.google.com/test/rich-results にアクセスし、URLまたはコードスニペットを入力するだけでテストできます。
テスト結果では、以下の情報が表示されます。
- 検出された構造化データの種類
- エラー(必須プロパティの欠落、構文エラーなど)
- 警告(推奨プロパティの欠落など)
- リッチリザルトのプレビュー
エラーは必ず修正してください。 警告は直接的な問題ではありませんが、可能な限り解消することで、構造化データの効果を最大化できます。
Schema.orgバリデーター
Googleのツールに加えて、Schema.orgの公式バリデーター(https://validator.schema.org/)でも検証することをおすすめします。 こちらはSchema.orgの仕様に準拠しているかどうかをチェックするもので、Googleのツールとは異なる観点で検証できます。
Google Search Consoleでの確認
構造化データの実装後、Google Search Consoleの「拡張」セクションで、Googleがどの構造化データを認識しているかを確認できます。 エラーや警告がある場合はここに表示されるため、定期的にチェックしましょう。
よくある失敗と注意点
GBPとの情報不一致
最も多い失敗が、構造化データの情報とGBPの情報が一致していないことです。 ビジネス名、住所、電話番号、営業時間――全ての情報が完全に一致していることを確認してください。
営業時間の変更やリニューアルによる住所変更があった場合、GBPと構造化データの両方を同時に更新することを忘れないようにしましょう。
隠しコンテンツとしての使用
構造化データに、ページ上には表示されていない情報を記述することは避けてください。 Googleは、構造化データの内容とページ上の可視コンテンツが一致していることを求めています。
構造化データにのみ偽の星評価を記述したり、ページに表示されていない価格情報を追加したりすると、ガイドライン違反として手動ペナルティを受ける可能性があります。
過度な構造化データの使用
必要以上に多くの構造化データを追加することは、かえってマイナスになる場合があります。 ビジネスに関連性のある構造化データだけを正確に記述することが重要です。
よくある質問(FAQ)
Q. 構造化データを実装するだけでMEO順位は上がりますか?
構造化データだけでMEO順位が劇的に上がることは期待しないでください。 構造化データは、GBPの最適化、口コミ対策、NAP統一などのMEO施策を補完するものです。 総合的なMEO対策の中の1ピースとして位置づけてください。
Q. WordPressでLocalBusinessマークアップを追加する方法は?
WordPressの場合、Yoast SEOやRank Mathなどのプラグインで構造化データを簡単に追加できます。 手動で追加する場合は、テーマのheader.phpにJSON-LDスクリプトを直接記述するか、wp_headアクションフックを使って追加します。
Q. 構造化データの更新頻度はどのくらいが適切ですか?
ビジネス情報(住所、電話番号、営業時間など)に変更があった場合は、即座に更新してください。 変更がない場合は、特に更新する必要はありません。 年に1回程度、情報の正確性を確認するレビューを行うとよいでしょう。
Q. 1ページに複数のLocalBusinessマークアップを記述できますか?
技術的には可能ですが、推奨されません。 1ページには1つのビジネスの情報のみを記述してください。 複数店舗がある場合は、各店舗ページにそれぞれのマークアップを記述しましょう。
Q. 構造化データの効果が出るまでどのくらいかかりますか?
Googleが構造化データをクロールして反映するまでに、通常数日から数週間かかります。 リッチリザルトへの表示が始まるまでには、さらに時間がかかる場合があります。 Google Search Consoleで認識状況を定期的に確認してください。
まとめ
構造化データ(LocalBusinessマークアップ)は、WebサイトからMEO対策を強化するための有効な手段です。 GBPの最適化と組み合わせることで、Googleに対してビジネス情報をより正確に伝えることができます。
重要なポイントを振り返ります。
- LocalBusinessまたは業種に適したサブタイプを使用する
- JSON-LD形式で実装する(Google推奨)
- NAP情報はGBPと完全に一致させる
- 営業時間、地理座標、写真など、可能な限り多くのプロパティを記述する
- 実装後はリッチリザルトテストとSearch Consoleで検証する
- GBP情報の変更時は構造化データも同時に更新する
MEO対策の全体戦略についてはMEO対策の完全ガイドで、構造化データ全般については構造化データの完全ガイドで詳しく解説しています。
技術的な作業に思えるかもしれませんが、一度正しく設定してしまえば、長期間にわたってMEO対策の基盤として機能し続けます。
