先に結論

構造化データは、検索順位を上げるための裏技ではありませんが、検索エンジンやAIにサイトの内容を正しく理解してもらうための一つの要素です。画面に書かれている店名、住所、記事、著者などへ、検索エンジンやAIも読める名札を付けます。店舗サイトでは「サイト全体」「運営会社」「各店舗」「記事」を分け、同じものを同じIDでつなぐことが大切です。

ブログ記事では「誰が書いたか」も情報になる

SEOを考えるとき、記事の内容だけでなく、誰がその内容を書いたのかを読者が確認できることも大切です。Googleは、信頼できるコンテンツかを考える手がかりとして、記事に著者名があるか、その著者についてさらに分かるページへ移動できるか、といった点を確認するよう案内しています。

これは、著者名を入れるだけで検索順位が上がるという意味ではありません。Googleも、経験・専門性・権威性・信頼性を表すE-E-A-T自体は単独のランキング要因ではないと説明していますが、コンテンツの有用性や信頼性を考えるうえでの要素の一つです。そして大切なのは、読者が「誰の、どんな経験に基づく情報か」を確かめられる状態にすることです。

01 / BYLINE記事に著者名を表示する誰が書いた記事かを読者が確認できる
02 / PROFILE著者情報へつなぐ経歴や専門分野が分かるページを用意する
03 / ARTICLE DATA機械にも著者を伝えるArticleのauthorからPersonへつなぐ

たとえばこの記事では、Webマーケティングを担当する大和哲を著者として表示し、役員紹介のプロフィールへリンクしています。構造化データでも、記事のauthorから同じ大和哲のPerson情報へつなぎます。画面に見える著者と、検索エンジンが読む著者を一致させるためです。

WordPressでは、管理画面のログイン名がそのまま記事の著者として出力されることがあります。ブログ記事を公開する前に、読者へ見せる著者名、プロフィール、構造化データのauthorが同じ人物を示しているか確認します。

構造化データとは 検索エンジン向けの名札

人がワイルームSpa様の店舗ページを見れば、店名、住所、営業時間、電話番号、予約先を画面から読み取れます。しかし、検索エンジンは、書かれている数字が電話番号なのか、住所なのか、別店舗の情報なのかを必ず正しく理解できるとは限りません。

そこで使うのが構造化データです。ページの中へ「これは店舗名」「これは住所」「この記事を書いたのはこの人」と、決められた形式で情報を入れます。Googleは、ページの内容を理解するための明確な手がかりとして構造化データを利用しています。

画面に見える情報ワイルームSpa蒲田西口店
機械が読む名札name / DaySpa

構造化データが正しくても、検索順位の上昇や特別な検索表示が保証されるわけではありません。まず読者に必要な情報をページへ掲載し、その内容と同じ事実を構造化データで伝えます。

WordPressのプラグインを入れただけでは構造化設定は終わらない

CLIENT CASE温活×マッサージのリラクゼーションサロン ワイルームSpa様

蒲田店と横浜鶴見店、それぞれ異なるサービスと店舗情報を持つWordPressサイトです。

公式サイトを見る
PC表示ワイルームSpa様公式サイトのPC表示
スマートフォン表示ワイルームSpa様公式サイトのスマートフォン表示
ワイルームSpa様公式サイトのPC表示とスマートフォン表示（2026年8月撮影）

ワイルームSpa様のサイトでは、WordPressのSEOプラグインが、サイト全体を表すWebSite、運営者を表すOrganization、ページを表すWebPage、記事を表すBlogPostingなどの基本データを自動で出力しています。

ただし、ワイルームSpa様には蒲田店と横浜鶴見店があり、住所、電話番号、営業時間、提供するサービスが異なります。共通の会社情報を一つ設定するだけでは、検索エンジンへ「どの情報がどちらの店舗のものか」まで伝えられません。

プラグインが自動で作れるのは、サイト全体に共通する構造化データの土台です。複数店舗の違いまでは自動で判断できないため、各店舗の情報は実際の事業に合わせて人が設計します。

店舗ごとのNAPをそろえる

店舗情報で特に大切なのがNAPです。NAPは、Name（店名）、Address（住所）、Phone（電話番号）の頭文字を取った言葉です。検索エンジンが同じ店舗の情報だと判断しやすいように、店舗ごとにこの3つを正しくそろえます。

N / NAME店名店舗名と支店名
A / ADDRESS住所郵便番号・建物名まで
P / PHONE電話番号店舗へつながる番号

ワイルームSpa様の場合、蒲田店と横浜鶴見店のNAPを一つにまとめず、それぞれ別の店舗情報として設定します。公式サイト、Googleビジネスプロフィール、予約ページ、構造化データで同じ店名・住所・電話番号を使い、変更があったときも一緒に更新します。

このように、プラグインを有効にした後で店舗ごとのNAPを整理し、ページに表示している情報と一致させることで、構造化データが実際の店舗構成を正しく表すようになります。

最初に4つの役割へ分ける

いきなりコードを書くと、店舗と会社、記事とページが混ざります。先に、サイトに登場する情報を次の4つへ分けます。

01 / SITE

WebSite

サイト名、URL、運営者など、Webサイト全体に共通する情報です。

02 / OWNER

Organization

店舗ブランドや運営会社の正式名称、ロゴ、公式SNSなどを表します。

03 / SHOP

DaySpa

蒲田店と横浜鶴見店を別々に作り、各店舗の住所、電話、営業時間を持たせます。

04 / CONTENT

BlogPosting

記事タイトル、公開日、画像、著者を表し、PersonやOrganizationへつなぎます。

Googleは、実店舗にはできるだけ具体的なLocalBusinessの種類を使うよう案内しています。リラクゼーションサロンのワイルームSpa様では、LocalBusinessの一種であるDaySpaを候補にできます。

店舗ページの構造化データを設定する4ステップ

  1. STEP 01
    画面にある事実を一覧にする

    店舗ごとのNAPを中心に、営業時間、予約URL、写真、公式SNSを、店舗ページに実際に表示されている内容から拾います。

  2. STEP 02
    ページに合う種類を選ぶ

    店舗ならDaySpa、記事ならBlogPostingのように、ページの中心となるものへ最も近い種類を選びます。

  3. STEP 03
    店舗ごとに変わらないIDを付ける

    蒲田店は`/shops/kamata/#business`のように、同じ店舗を他のページからも指せる固有のIDを決めます。

  4. STEP 04
    画面とデータを照合する

    コードが正しいだけで合格にせず、住所や営業時間がページ表示、予約先、店舗情報と一致するか確認します。

蒲田店を例にすると

次は、説明のために項目を絞ったJSON-LDの例です。JSON-LDは、ページの見た目を変えずに構造化データを記述でき、Googleも多くの場合に推奨している形式です。

{
  "@context": "https://schema.org",
  "@type": "DaySpa",
  "@id": "https://wairoom-spa.com/shops/kamata/#business",
  "name": "よもぎ蒸し＆タイ古式マッサージ ワイルームSpa蒲田西口店",
  "url": "https://wairoom-spa.com/shops/kamata/",
  "telephone": "+81-3-6424-5950",
  "address": {
    "@type": "PostalAddress",
    "postalCode": "144-0051",
    "addressRegion": "東京都",
    "addressLocality": "大田区",
    "streetAddress": "西蒲田7-43-7 ユニパリス蒲田201",
    "addressCountry": "JP"
  }
}

実際の設定では、通常営業時間を表すopeningHoursSpecification、店舗写真、地図の緯度経度なども、確認できた情報だけ追加します。項目を増やすことより、少ない項目でも正しく、更新を続けられることを優先します。

記事はBlogPosting 著者はPersonとしてつなぐ

ワイルームSpa様には、よもぎ蒸し、サウナ、タイ古式マッサージなどを解説する記事があります。店舗情報とは別に、記事ページにはBlogPostingを設定します。

ARTICLEBlogPosting見出し・公開日・画像
WRITERPerson著者名・プロフィール
OWNEROrganization運営者・ロゴ

記事にはheadline、image、datePublished、dateModifiedを設定し、authorから著者のPersonへ、publisherから運営者のOrganizationへつなぎます。管理画面のログイン名をそのまま著者名にせず、読者がページで確認できる名前とプロフィールを使います。

同じ著者や運営者には毎回同じIDを使います。これにより、記事ごとに別人・別会社のようなデータが増えるのを防ぎ、「この記事を誰が書き、誰が公開しているか」という関係を一つのまとまりとして伝えられます。

公開前後に確認する8項目

  • ページとの一致構造化データの店名、住所、営業時間、著者が画面にも表示されている
  • 店舗の分離住所や電話番号が異なる店舗を、一つの店舗データへ混ぜていない
  • NAPの一致店名、住所、電話番号が、公式サイト、Googleビジネスプロフィール、予約先でそろっている
  • IDの統一同じ店舗、著者、運営者をページごとに違うIDで作っていない
  • URLの統一canonical URL、構造化データ、パンくずのURLが一致している
  • 作っていない評価を入れない自社に都合のよいレビューや評価点を、画面にないまま追加していない
  • 公開前の検査Googleのリッチリザルトテストでエラーを確認している
  • 公開後の確認URL検査とSearch Consoleで、Googleが取得した結果を継続して確認する

Googleは、構造化データがページの主な内容を正しく表し、利用者に見える情報と一致することを求めています。検索結果へ出したい情報を後からコードだけで足すのではなく、まずページ自体を正しく整えます。

SEOにもAIにも 大切なのはNAPと情報の一貫性

構造化データを入れただけで、検索順位が上がったり、AIの回答へ必ず採用されたりするわけではありません。それでも、店名、店舗、運営者、記事、著者の関係を標準的な形式で示すことは、サイトの内容を機械が理解するための土台になります。

重要なのは、SEO用の別情報を作ることではありません。店舗ページ、Googleビジネスプロフィール、予約先、構造化データで、名称、住所、電話番号、営業時間をそろえ、変更時に同じ場所を更新できる運用を作ることです。

まとめ 設定より先に誰の何を伝えるか決める

構造化データの設定は、難しいコードを書くことから始まりません。サイトに何が登場し、どの情報が共通で、どの情報が店舗ごとに違うのかを整理することから始まります。

ワイルームSpa様のように複数店舗と多くの記事があるサイトでは、WebSite、Organization、DaySpa、BlogPosting、Personを役割ごとに分け、同じIDでつなぎます。そのうえで、画面に見える事実と一致しているかを公開前後に確認します。

参考にした公式資料