AI検索に店舗サイトを拾わせるために書くこと｜構造化データと一問一答の置き場所と、順位対策と分けて考える範囲
AI検索に店舗サイトを拾わせるために書くこと｜構造化データと一問一答の置き場所と、順位対策と分けて考える範囲
ChatGPTやGoogleのAIによる回答から店舗サイトへ人が来る。この経路は、もう無視できない大きさになっています。当社サイトの実測では、直近28日のAIアシスタント経由のセッションは20件で、その前の28日は5件でした。全体972セッションのうちの20件なので主役ではありませんが、4倍という伸び方は他のどの経路にもありません。
では店舗サイト側は何をすればよいか。先に結論を書きます。
結論：やることは3つ。どれも「AIに読める場所に、事実を置く」作業
AI検索向けの対策は、特別な申請や新しいツールの導入ではありません。次の3つです。
- 本文がHTMLそのものに入っている状態にする（JavaScriptが動いた後にしか文字が出ないサイトは、AIのクローラーには白紙に見える）
- 店舗情報を構造化データで「1つの実体」として宣言する（店名・住所・電話・営業時間・メニューと価格を、サイト全体で同じ1つのIDに結びつける）
- お客様が実際に聞く質問と答えを、開いた状態のテキストで置く（折りたたみの中や画像の中ではなく、最初から見えている文字として）
そして大事な前提がひとつあります。この3つは検索順位を上げる作業とは別の箱で管理します。順位対策は「どのキーワードで何位か」を追う仕事、AI検索向けは「聞かれたときに正しく答えられる材料が置いてあるか」を整える仕事です。混ぜると、順位が動かないことを理由にAI向けの整備が後回しになります。
以下、実際に店舗サイトへ実装した内容をもとに、置き場所を順に説明します。
1. まず確かめる：AIのクローラーにサイトの本文が見えているか
構造化データより先に確認することがあります。クローラーが受け取るHTMLに、本文が入っているかです。
名古屋の美容サロンFC（25店）の店舗サイトを点検したとき、AIクローラーのユーザーエージェントでトップページを取得すると、<body>の中身は <div id="root"></div> の1行だけでした。ブラウザで開けば料金も口コミも強みも表示される、見た目には何の問題もないサイトです。しかし画面の文字はすべてJavaScriptが後から描画しており、JavaScriptを実行しない取得者には1文字も渡っていませんでした。
Googleの検索クローラーはJavaScriptを実行してから読みますが、AIサービスのクローラーの多くは配信されたHTMLをそのまま読みます。つまり、検索では普通に出ているのに、AIからは白紙という状態が起こります。
確認方法
ターミナルで次を実行し、返ってきたHTMLに料金や住所の文字があるかを見ます。
curl -s -A "GPTBot" https://example.com/ | grep -c "営業時間"0が返るなら、AIには読めていません。ブラウザの「ページのソースを表示」で本文の文字を検索する方法でも同じ確認ができます（開発者ツールの「要素」タブは描画後の状態なので確認に使えません）。
対処
このFCでは、本番のページをヘッドレスブラウザで描画し、本文入りのHTMLを生成して配置する方式（プリレンダリング）を全25店に入れました。URLは変えず、サーバー内部で本文入りのHTMLを返します。結果、HTML上の本文は0字から2,000〜4,700字になりました。
WordPressや静的HTMLで作られたサイトは最初から本文がHTMLに入っているので、この項目は確認だけで通過できます。ReactやVueで作ったサイト、ノーコードツールの一部が該当しやすいところです。
運用上の注意：本文入りHTMLは「戻っても誰も気づかない」
プリレンダリングしたHTMLは、通常のデプロイ手順で素のHTMLに上書きされることがあります。このとき、サイトは正常に表示され、HTTPステータスも200のままです。利用者にも担当者にも異常は見えません。壊れているのはクローラーが読むHTMLだけです。
そのため、デプロイ後に本番の<title>とHTMLのサイズを機械的に確かめる手順を用意しておきます。このFCでは、全店のtitleの形・本文の長さ・主要ページの応答を一括で確認するスクリプトを用意し、店舗サイトを触ったら最後に必ず実行する運用にしています。素のHTMLは約5KB、本文入りは50〜150KBなので、サイズだけでも判別できます。料金や口コミを焼き込む方式なので、月1回の再生成も必要です。
2. 構造化データは「種類を増やす」より「1つの実体に束ねる」
構造化データ（JSON-LD）は、ページの内容を機械が読める形で宣言するものです。店舗サイトなら HairSalon や LocalBusiness が基本になります。
愛知県内の美容室の新サイトに実装したとき、着手前の実測はこうでした。トップページには HairSalon が1つあるだけ。併設のWordPressブログにはtitle以外、description・canonical・構造化データのいずれもありませんでした。robots.txtとsitemap.xmlは404です。
ここで行ったのは、種類を並べることではなく、次の設計です。
店舗に固定のIDを付け、全ページから参照する
トップページの HairSalon に @id（例：https://example.com/#salon）を付けます。ブログ記事の BlogPosting では、発行者（publisher）も著者（author）もこのIDを参照させます。パンくずやWebSiteも同じです。
こうすると、機械から見て「トップの店舗」と「ブログを書いている主体」が同じ1つの実体になります。ページごとに店名や住所を書き直すと、表記が1文字違うだけで別物として扱われる余地が生まれます。IDで束ねればその余地がなくなります。
実装上は、複数の<script>に分けず @graph で1本にまとめました。ID参照を確実に解決させるためです。
メニューと価格は、画面のHTMLから機械的に生成する
全28メニューを hasOfferCatalog としてカテゴリ別に入れました。ここで守ったのは、画面に表示しているメニュー表から構造化データを生成することです。手で二重に書くと、値上げのときに片方だけ直して食い違います。「〜」付きの価格は下限として宣言しました。
逆の例もあります。前述のFCには、価格をあえてサイトに載せていない店舗があります。にもかかわらず、meta descriptionには「根元染め¥2,750〜」が入っていました。画面に出していない価格は、descriptionにも構造化データにも出さないというルールを生成側に入れて直しています。AIは宣言された値をそのまま答えに使うので、表示と宣言のズレは誤案内に直結します。
入れないものを決める
- 評価・レビュー（aggregateRating / review）：実データの裏付けがないものは入れません。自店で作った評価を自店のページに宣言する形は、Googleのガイドラインで認められていません。口コミの実データをAPIで持っているFCでは入れ、持っていない新サイトでは入れませんでした
- 従業員数など未確認の値：確認できていない値は宣言しません
構造化データは「多く書くほど有利」ではなく、「確認できた事実だけを、表示と一致させて書く」ものです。
3. 一問一答は、開いた状態のテキストで本文に置く
AIの回答は、質問文に対する答えの形をしています。だから、サイト側にも質問と答えの対があると引用されやすくなります。
置き場所
愛知の美容室サイトでは、トップページのギャラリーとメニューの間にFAQセクションを新設しました。ポイントは2つです。
<details>などの折りたたみを使わず、最初から開いた状態で置く。折りたたみの中身を読まない取得者がいても確実に渡すためです- 画面のFAQと
FAQPageの構造化データを、同じ定義から生成する。1文字単位で一致していることを検証しました
何を質問にするか
「よくある質問」を想像で作るのではなく、AIに聞かれそうな、その店にしか答えられないことを選びます。この美容室は屋号を変更した直後だったため、1問目に「以前の店名から変わったのか」を置き、旧店名を明記しました。当初は旧店名をサイトに出さない方針でしたが、ブログで公式に告知済みであり、旧店名で探す既存客を拾える利益のほうが大きいと判断して方針を変えています。
ほかに向いているのは、駐車場の有無と台数、予約方法、支払い方法、得意な施術、所要時間の目安などです。
FAQを置かない判断もある
25店のFCのほうでは、FAQの新設は見送りました。GoogleはFAQのリッチリザルト表示を2023年に大きく絞っており、検索結果上の見返りは期待できません。加えて、25店分の質問と答えを店ごとに正しく用意するにはコンテンツ制作が必要で、実装だけでは済みません。このときは本文のプリレンダリングと後述の要約ファイルで足りると判断しました。
判断基準は単純です。その店固有の答えを、正確に書ける体制があるならFAQを置く。無いなら、本文と店舗情報を正しく読める状態にするほうを先にやる。どの店にも当てはまる一般論のFAQを量産しても、引用される理由になりません。
4. サイトのルートに置くファイル
robots.txt：AIクローラーを止めていないか確認する
テンプレートやセキュリティ系のプラグインによっては、GPTBotなどのAIクローラーを一括で拒否する設定が入っていることがあります。AIに読ませることが目的なら、ここで止めていては何も始まりません。実装時はrobots.txtを新規に置き、サイトマップの場所を宣言し、AIクローラーは拒否しない内容にしました。
学習に使われたくないという方針の会社もあるはずです。その場合は拒否が正解です。どちらにせよ、意図せず止まっている状態だけは避けます。robots.txtとnoindexの役割の違いはrobots.txtとnoindexの違いで整理しています。
llms.txt：サイトの要約を1枚で渡す
llms.txtは、AI向けにサイトの要点をテキストでまとめて置くファイルです。愛知の美容室では74行で、店舗概要・屋号変更の経緯・営業時間・得意な施術3つ・全メニューと価格・主要URL、そして未公表の項目は未公表と明記しました。
正直に書くと、llms.txtは提案段階の仕様で、主要なAIサービスが必ず参照すると公表しているわけではありません。効果を数字で示せる段階にもありません。それでも置いているのは、作成コストが小さく、置いて困ることがなく、店舗情報を1枚に整理する作業そのものが構造化データやFAQの点検になるからです。優先順位は1〜3より下です。
順位対策と分けて考える範囲
最後に、冒頭で触れた「別の箱」の話です。
共通の土台（どちらにも効く）
- ページごとに固有のtitle・description・canonical
- サイトマップとSearch Consoleへの登録
- 店名・住所・電話番号の表記をサイト、Googleビジネスプロフィール、ポータルで一致させる
これが無い状態でAI向けの施策だけを足しても意味がありません。公開から2か月たってもGoogleに1ページも載っていなかった美容室サイトを調べたときは、原因はSearch Console未登録・サイトマップなし・Googleビジネスプロフィールのリンク先が旧サイトのまま、でした。AI以前の話です。同じ状況ならホームページを新しくしたのに検索で出てこないときを先に確認してください。
順位対策の箱
キーワードごとの順位とクリック率を見て、記事を足すか直すかを決める仕事です。当社サイトでは同じ期間に表示回数が84%増えた一方、全体のクリック率は2.02%から1.43%に下がりました。ただし上位クエリのクリック率は2.8〜11.1%で健全で、下がった理由は15〜30位の表示が大量に増えて薄まっただけでした。こうした読み解きは順位対策の箱の中の話で、AI向けの整備とは指標が違います。
AI検索の箱
こちらの指標は順位ではありません。
- アクセス解析で、AIアシスタント経由のセッションを月次で見る
- 主要なAIサービスに、自店について実際に質問してみる（店名、地域＋業種、駐車場、料金など）。答えが間違っていたら、サイト側にその事実が読める形で置かれているかを確認する
- デプロイのたびに、HTMLに本文が残っているかを確認する
AIの回答が間違っているとき、原因の多くは「AIが悪い」ではなく「正しい情報がどこにも機械に読める形で置かれていない」か「古い情報が別の場所に残っている」かのどちらかです。
まとめ
- AI検索向けの対策は、①HTMLに本文がある、②店舗情報を1つのIDに束ねた構造化データ、③開いた状態の一問一答、の3点
- 最初の確認は
curlでHTMLを取り、本文の文字があるかを見ること。JavaScript描画のサイトは白紙になっていることがある - 構造化データは画面表示から生成し、表示していない価格や裏付けのない評価は入れない
- FAQは、その店固有の答えを正確に書けるときだけ置く
- robots.txtでAIクローラーを意図せず止めていないか確認する。llms.txtは優先度低めの補助
- 順位対策とは指標が違う。title・サイトマップ・表記統一という共通の土台を先に済ませ、その上で別の箱として管理する
店舗サイトの構造化データの点検や、JavaScript描画サイトの本文対応についてのご相談は、お問い合わせフォームまたはLINEから受け付けています。