Googleビジネスプロフィールの属性設定と
絞り込み検索

「属性は余力があれば触るところ」「チェックを入れても順位には関係ない」——ビジネスプロフィールの説明でよく聞く整理ですが、これは実態と合っていません。属性は、店の名前や写真と違ってユーザーが検索側から条件を指定して絞り込むための材料として使われます。つまり、入っているかどうかで「そもそも候補の一覧に残るか」が変わる場面がある。さらに近年は、AI検索が店の条件を読み取るときの手がかりとしても効いてきます。この記事では、ビジネスプロフィールの属性がどういう構造で働いているのか、誰が何を付けているのか、そして実態と違う属性を入れたときに何が起きるのかを整理します。

「属性はおまけ」という前提を先に崩す

ビジネスプロフィールの管理画面を開くと、営業時間や電話番号のような「必ず埋めるもの」の下に、チェックボックスの塊が並んでいます。バリアフリー対応、Wi-Fiあり、駐車場あり、女性経営、支払い方法、屋外席の有無。この部分が属性（attributes）です。

ここが後回しになる理由は分かります。埋めても見た目が派手に変わらないからです。写真を追加すれば一覧の印象が変わり、口コミが増えれば星の数が動く。属性はそういう手応えがありません。

ただし、手応えがないことと効いていないことは別です。属性が働くのは、ユーザーが自分から条件を絞ったときと、検索側が店の条件を機械的に読み取るときの二つの場面です。どちらも、オーナーが管理画面を眺めていても見えません。見えないところで候補から外れているケースがある、というのが実際のところです。

ビジネスプロフィールの属性設定で、実際に決まっていること

ビジネスプロフィールの属性設定は、管理画面の項目にチェックを入れる作業として案内されることがほとんどです。ただ、そこで決まっているのはチェックの数ではありません。決まっているのは、どの条件で探している人の一覧に自店が残るか、という範囲です。

属性の項目は、店の設備や対応の事実を申告する欄として並んでいますが、検索する側から見ると、ひとつひとつが絞り込みの入口になっています。ある項目を空けておくことは、その条件で探す人の画面から自店を外しておくことと同じ意味を持ちます。逆に、実態にない項目を入れることは、来店してから食い違いに気づく人を作ることになります。そして、実態どおりに申告し終えたところで、決まっていないことが残ります。同じ実態でも、隣に並ぶ店の申告の粒度や、探す人が指定する条件の立て方によって、一覧に残るかどうかが変わるからです。申告は作業の終点ではなく、そこから先の残り方は自店の欄の外で決まります。

だからビジネスプロフィールの属性設定は、埋める・埋めないの作業ではなく、自店をどの条件の一覧に置くかを決める設計になります。そして、どの条件の一覧に置かれることが自店にとって効くのかは、同じ商圏で同じ条件を指定したときに誰が並ぶかで変わります。この並びは自店の管理画面には出てきません。

属性を付けているのはオーナーだけではない

ここを誤解している方が多いので、先に切り分けます。ビジネスプロフィールに表示される属性には、出どころが違うものが混ざっています。

つまり、プロフィール上に出ている属性のすべてが自分の申告というわけではありません。「設定した覚えのない項目が出ている」という相談の多くは、後ろ二つが原因です。

そして重要なのは、編集できない属性のほうが、店の実態とずれやすいという点です。利用者の回答は、来店したタイミングの状況を反映します。改装前の話、期間限定で止めていたサービス、たまたま満車だった駐車場。そうした一時点の情報が、そのまま残ることがあります。

この場合、オーナーが管理画面から直接消す操作は用意されていません。実態の側へ寄せる打ち手は別の経路にあり、検索側が読み取っている情報の総量を動かす形になります。どこをどれだけ動かせば寄るのかは、いま何が根拠にされているかで変わりますが、その根拠は店側に開示されません。

カテゴリが変われば、出せる属性も変わる

属性の話がややこしくなる最大の理由がここです。表示できる属性の種類は、選んでいるカテゴリによって決まります。すべての店に共通の一覧があるわけではありません。

飲食店なら「テイクアウト」「デリバリー」「席の予約」といった項目が出ますが、これらは士業事務所のプロフィールには出てきません。逆に美容室では施術メニュー系の属性が並び、宿泊施設では設備系の属性が細かく分かれます。

この構造から、メインカテゴリを変えると使える属性が丸ごと入れ替わることがある、という事実が導かれます。カテゴリ変更は属性の設計変更でもある、という理解が要ります。入れたい項目が現れない理由も、チェックボックスの側とは別のところで決まっていることがあり、何が主業態として認識されているかを外から確かめないと切り分けられません。

ここで安易に「その属性が出るカテゴリに変えればいい」と考えると、事故になります。カテゴリは店の主業態を示すもので、属性を得るために選ぶものではありません。実態と離れたカテゴリを選ぶと、絞り込み以前に「そもそも別の業種として扱われる」状態になります。

カテゴリと属性のどちらを優先して整えるかは、店の業態と、同じ商圏に並んでいる競合がどちらの軸で比較されているかによって変わります。一律の正解がない領域です。※このカテゴリと属性の整合をとる設計は、当社FACTORが運用の中で引き受けている部分です。整合をとるとき見ているのは自店の管理画面だけではなく、同じ商圏で近い業種がどう名乗っていて、その並びのなかで自店がどう浮くかまで突き合わせて逆算しています。この比較材料は自店側からは取得できないため、社内では組み立てにくい部分です。

自店の場合にどちらから触るべきかは、実際のプロフィールの状態と競合の並びを見ないと判断できません。無料のAI診断では、GoogleマップのURLを入力すれば、要点はその場で表示されます。

絞り込み検索とAI検索が属性を読むとき

属性が実際に働く場面を、具体的に見ていきます。

マップ側の絞り込みフィルタ

Googleマップで「近くのカフェ」のように検索すると、結果の上部に条件のチップが並びます。営業中、評価、価格帯、そして業種によっては「Wi-Fiあり」「屋外席」「バリアフリー対応」のような条件です。ユーザーがここを押した瞬間、条件を満たさない店は一覧から外れます。

この挙動が厄介なのは、外れたことがオーナー側から観測できない点です。インサイトの表示回数は減りますが、「絞り込みで落ちた」という内訳は出ません。順位の数字と、条件を指定されたときに一覧へ残っているかどうかは、別々に見ないと揃いません。

条件を指定するユーザーは意思が強い

もう一点。フィルタを押す人は、押さない人より条件がはっきりしています。「車で行くから駐車場は必須」「ベビーカーで入れるか」「カードが使えるか」。この層は候補を比較する段階を飛ばして来店に近いところにいます。条件を指定した時点で来店の意思が固まっている層であり、ここで一覧から外れた分は、数字に痕跡を残さないまま失われます。

AI検索が店の条件を読むとき

ChatGPTやAI Overviewのような生成型の回答では、「駐車場があって個室のある店」のように条件を文章で指定されます。このとき、条件に合う店を選ぶための構造化された手がかりが必要になります。属性は、まさにその形をした情報です。文章のどこかに書いてある説明より、項目として整理された情報のほうが機械には扱いやすい。

どの条件文で自店が拾われるかは商圏と業態で入れ替わり、拾われた事実も落ちた事実も、店側の管理画面には一切残りません。ウェブサイト側の記述とプロフィール側の属性のどちらを基準に読まれているかも同じで、外から条件付きで検索した結果を並べないと決まりません。

実態と違う属性を入れたときに起きること

絞り込みに引っかかりたいからといって、実態にない属性を入れる。これが一番やってはいけない操作です。跳ね返りは、来店した人の側からも、掲載そのものの側からも返ってきます。

来店した人の側から返ってくるもの。「駐車場ありと書いてあったのに無かった」という体験は、低評価と結びつきやすい書き方をされます。しかも内容が具体的なので、後から返信で挽回しにくい。加えて、申告と実態がずれていれば、その差は利用者側の回答としても情報に積み上がっていきます。

掲載そのものの側から返ってくるもの。ビジネスプロフィールに載せる情報は、実在する事業の正確な情報であることが前提になっています。誤った情報の掲載は、修正要求や、程度によっては掲載自体の扱いに関わります。絞り込み一つのために背負うリスクとして、割に合いません。

厄介なのは、前者は日々の運用で受け止められるのに対し、後者は入れた時点で取り返しの効き方が変わることです。線の引かれ方は文言の外形からは決まらず、ほかにも判断の要る線があります。自店の申告がその線の手前にあるのかどうかは、書いてある文言だけを眺めても決まりません。

逆のパターンもあります。実態としては満たしているのに、申告していないケースです。設備としては対応しているのに該当の欄が空いたまま、という状態は珍しくありません。ただし、空いている欄のどれが取りこぼしになっているかは欄単体では決まらず、その条件で探す人が商圏にどれだけいて、同じ条件で並ぶ他店がどう申告しているかで変わります。どの空欄が効いているかは、外から並べないと自覚できません。

どこから効くかは、業態と商圏で変わる

ここまでの話を踏まえても、「この順で全項目を埋める」という手順にはなりません。属性は業種ごとに項目が違い、優先すべき軸も違うからです。

優先順位を分ける向きは、ひとつではありません。無いと来店そのものが成立しない条件かどうか、という向き。その業種で実際に絞り込みの入口として使われている条件かどうか、という向き。この二つは必ずしも一致しません。来店の可否を左右するのに絞り込みには出てこない条件もあれば、その逆もあります。どちらを先に埋めるかで、取りこぼしの起き方が変わります。

さらに、同じ条件でも商圏の中での相対で意味が変わります。同じ項目でも、同じ条件で並ぶ他店がどう申告しているかによって、埋めたときの効き方が入れ替わります。どの項目がどちらに当たっているかは、複数の条件と複数の地点で検索した結果を並べないと形にならず、単店の画面を見ただけでは再現できません。

どれを重く見るかは、業態と商圏の競合状況で変わります。立地条件が変われば、最優先になる項目そのものが入れ替わります。だからこそ、他店で効いた設定をそのまま持ち込んでも噛み合いません。

あわせて、カテゴリ選定と口コミ運用は同時に積むものです。属性を整えたうえで、順位の面でも競合と並べる状態をつくる。どちらを先に厚くするかは商圏の並びで決まるので、その順番自体が判断の対象になります。

よくある質問

まとめ

ビジネスプロフィールの属性は、プロフィールの見た目を整えるための付属情報ではありません。マップの絞り込みフィルタで条件を指定されたとき、候補の一覧に残るかどうかを分ける情報であり、AI検索が店の条件を読み取るときの機械可読な手がかりでもあります。しかも、絞り込みで落ちたことはオーナー側から観測できません。順位の数字とは別の層で、取りこぼしが静かに起きている可能性があります。しかも落ちているのは、条件を指定してまで探していた層、つまりもっとも来店に近かった人たちです。その人たちは一覧に載らないまま隣の店に流れ、こちらの数字には何も残りません。失っていることに気づけないまま、月ごとの売上だけが伸び悩む形になります。どの属性を優先するかは業態と商圏で変わるため、他店の設定をそのまま持ち込んでも噛み合いません。そして、条件を指定されたときに自店が一覧に残っているかどうかは、外から検索した側にしか見えない出方であって、店の中からは再現できません。その見え方を外から取り、カテゴリと属性の整合を設計し、商圏の並びが変わるたびに組み直すところまでを、FACTORは一続きの運用として引き受けています。