屋号と会社名が違うときのサイト表記|どこに何を書くかと、検索側に伝える書き分け
屋号と会社名が違うときのサイト表記|どこに何を書くかと、検索側に伝える書き分け
「お店の名前は◯◯なのですが、会社の登記は別の名前です。ホームページにはどちらを書けばいいですか」
店舗ビジネスのサイト制作では、かなりの割合でこの質問が出ます。個人事業から法人化した、複数業態を1つの会社で運営している、法人名は創業者の名字で店名は別、といった事情はどれも珍しくありません。
先に結論を書きます。どちらかに統一しようとしないでください。屋号(サイトの表示名)を全ページの主役に固定したうえで、登記上の会社名は「書く場所を3か所だけ決めて、そこにだけ書く」のが正解です。
3か所とは、フッターの運営会社表記・会社概要の会社情報表・特定商取引法に基づく表記です。そして機械(検索エンジンとAI)に対しては、構造化データで name(表示名)と legalName(登記商号)を別の項目として渡します。
この形にすると、お客様の目に入るのは常に覚えてもらいたい屋号のままで、取引先や行政が確認したい法人格の情報にもきちんと辿り着けます。以下、置き場所の決め方と、実装で事故が起きやすい箇所を順に見ていきます。
どちらかに統一すると、必ず片方を損する
まず、統一案がなぜ成立しないのかを確認しておきます。
屋号だけにする場合、サイト上のどこにも法人格が出てきません。一般消費者向けだけならしばらく問題は起きませんが、管理会社・不動産会社・工務店といった法人が発注を検討する段になると、「この会社はどこの誰なのか」が確認できないまま見積依頼を出すことになります。請求書に出てくる会社名とサイトの名前が初めて突き合わされるのが契約の直前、という状態は、決裁が絡む取引ほど不利に働きます。
会社名だけにする場合、今度は検索で見つけてもらう入口を失います。店舗ビジネスで実際に検索されるのは、看板やチラシや口コミで見た屋号です。検索した人が求めている名前がサイトのどこにも大きく出ていなければ、それが目的のサイトだと判断されません。
つまりこれは「どちらが正しいか」の問題ではなく、読む相手が2種類いるので、置き場所を分けるという設計の話です。
置き場所を4階層で決める
実務で使っている割り当ては次の通りです。上から下へ行くほど、読む人が限られ、正確さの要求が上がります。
| 場所 | 書くもの | 理由 |
|---|---|---|
| ヘッダー・ファーストビュー・ページタイトル | 屋号のみ | 検索される名前と、覚えてほしい名前を一致させる |
| フッター(全ページ共通) | 屋号+「運営会社:株式会社◯◯」の1行 | どのページから入っても事業者が辿れる |
| 会社概要ページ | 会社情報表に「商号」「屋号」を別の行で記載 | 法人格を正面から示す。BtoBの信用に効く |
| 特定商取引法に基づく表記 | 登記商号・登記上の所在地 | このページに書く事業者名は屋号ではなく登記商号 |
ポイントは2つあります。
ひとつは、フッターの1行を省略しないこと。会社概要ページにだけ書いておけば足りると考えがちですが、検索から入ってきた人はサービスページや事例ページに着地します。フッターは全ページ共通で表示される唯一の場所なので、ここに運営会社を1行入れておくと、どこから読み始めても事業者情報に辿り着けます。制作時に「フッターは全ページ共通」という原則を守っておけば、追加の手間はほぼありません。
もうひとつは、会社概要の表で「商号」と「屋号」を別の行にすること。1行に「株式会社◯◯(◯◯店)」のようにまとめて書くと、どちらが登記名か読み取れません。行を分けて、それぞれにラベルを付けます。
なお、法人しか取得できない co.jp ドメインで運営している場合、それ自体が法人格の裏付けになります。ただしこれをトップページで強調する必要はありません。一般の消費者はドメインの種類を識別しないからです。会社概要の信頼情報ブロックに1行添える程度が適量で、それ以上押し出すと逆に素人っぽく見えます。
構造化データでは3つの項目を使い分ける
検索エンジンとAIに対しては、HTMLの見た目とは別に、構造化データ(JSON-LD)で名前を渡します。ここで使う項目は3つです。
| 項目 | 入れる値 |
|---|---|
name |
サイトの表示名(屋号)=正 |
legalName |
登記商号(株式会社◯◯) |
alternateName |
他媒体での登録名が違う場合の別名 |
legalName は「この事業者の法人としての名称はこれです」を機械に伝える項目で、表示名を屋号のままにしながら法人格を通知できます。実装としては Organization および LocalBusiness に name と legalName を両方入れるだけです。
alternateName は用途が別です。Googleビジネスプロフィールなど外部サービスへの登録名が、サイトの表示名と語順違い・表記違いになっているときに、その別名を吸収するために使います。登記名を alternateName に入れるのは誤りです。登記名には専用の項目があるので、そちらを使います。外部サービス側の登録名との名寄せをどう設計するかは論点が別なので、GBPとサイトの名前が割れている場合の実装は別記事に分けています。
実装で注意したいのは、別名が表示名と同じ値になったときに出力しない条件を書いておくことです。将来、外部サービス側の登録名を揃えたときに、同じ文字列が2つ並んだ状態が残ります。条件を1行入れておけば、揃った時点で自然に消えます。納品後にコードを触らない事業者ほど、こうした「放っておくと正しくなる実装」が効きます。
もう1点、構造化データを自前で書くなら、SEOプラグイン側の同種の出力は止めてください。同じ型の情報が1ページに2つ出ると、どちらが正なのか機械には判断できません。
名前より事故りやすいのは「住所が2つある」ケース
屋号と会社名が違う事業者は、登記上の所在地と、実際に営業している拠点も違うことが非常に多いです。そして表記の混乱としては、名前よりこちらの方が実害が大きくなります。
実例として、関東で排水管洗浄を手がける専門事業者のサイトを制作した際、ヒアリングシートに記載されていた所在地は登記上の住所で、実際に現場へ向かう拠点は別の県にありました。この差は、対応エリアの説明も、地域名を含む検索での見え方も変える性質のものです。
ここで気をつけたいのは、構造化データやフッターに登記住所を書いてしまうと、Googleビジネスプロフィールに登録している営業拠点の住所と食い違うという点です。名称・住所・電話番号の3点は、検索側が同一事業者かどうかを判断する材料になります。ここが割れると、せっかく積んだ情報が別々の事業者のものとして扱われかねません。
割り当てはこうします。
- 構造化データ・フッター・お問い合わせ・会社概要の「所在地」 = 実際の営業拠点(=ビジネスプロフィールの登録住所と一字一句そろえる)
- 登記上の本店所在地 = 会社概要に「本店所在地(登記)」という別ラベルの1行として置き、加えて特定商取引法に基づく表記に記載する。構造化データには入れない
そして、制作を始める前に確認すべき質問がひとつあります。「実際に現場へ出発するのは、どちらの住所ですか」です。ヒアリングシートの「所在地」欄には登記住所が書かれていることが多く、そのまま進めると、商圏の説明ごと組み直す手戻りが発生します。名前と住所は、申告された文字列をそのまま使わず、登記情報・ビジネスプロフィールの実データ・実際の稼働拠点の3つを突き合わせてから確定させてください。
そろえる表記と、そろえなくていい表記
すべてを1文字単位で統一しようとすると、確認作業が終わらなくなります。線引きは次の通りです。
そろえるもの:郵便番号、都道府県、市区町村、町域名、電話番号、そして事業者名の文字列そのもの。
そろえなくていいもの:番地の全角・半角、ハイフンの種類、ビル名の「3階」と「3F」。これらは検索側で正規化される粒度です。ここを合わせるために外部サービスの登録情報を修正依頼するのは、手間に対して得るものがありません。
郵便番号については、同じ市区内でも町域ごとに違います。推測で書かず、日本郵便の町域一覧で引いて、登録済みの住所と突き合わせてから確定してください。
法人化のタイミングで表記を切り替える順番
個人事業から法人化した場合、サイト側の変更は次の順で進めると漏れません。
- 特定商取引法に基づく表記を先に直す(このページを設けているなら最優先。事業者名が個人名のまま残るのが一番まずい)
- 会社概要の会社情報表に「商号」「設立」「代表者」を追加、または更新する
- フッターの運営会社1行を追加する
- 構造化データに
legalNameを追加する - お問い合わせ完了メール・自動返信の署名を更新する
- 請求書・見積書のテンプレートを更新する
ここでヘッダーとページタイトルの屋号は変えません。法人化は社内の事情であって、お客様が検索する名前が変わったわけではないからです。名前そのものを変えるかどうかは、これらの表記整理が終わったあと、別の判断として検討すれば十分です。
5と6は、サイトの表示だけ直して見落としやすい箇所です。特に自動返信メールの署名は、更新後に自分宛てで1通テスト送信して実物を確認してください。
反映後の確認手順
直したら、次の順で確かめます。
- サイト内の全ページを対象に、旧表記の文字列で検索して0件になっているか確認する(目視で1ページずつ見ない)
- 構造化データを取り出し、JSONとして壊れていないか、
nameとlegalNameが意図した値になっているかを確認する - 同じ型の情報が1ページに2つ出ていないか確認する
- 構造化データの検証ツールに通す
1について補足します。ページ数が多いサイトほど、目視での確認は途中で必ず抜けます。公開されているHTMLを取得して旧表記を機械的に検索する方が確実で、しかも速いです。
もうひとつ、多店舗サイトや複数ページを自動生成しているサイトでは、公開ページを直しただけでは戻ります。表記の管理には「公開HTML」「生成の仕組み」「元になっている設定データ」の3層があり、元データを直さないまま公開側だけ修正すると、次の更新で元の表記が復活します。どの層まで直したかを記録してから作業を終えてください。
まとめ
- 屋号と会社名は統一しない。表示名は屋号に固定し、登記商号は3か所(フッター・会社概要・特定商取引法ページ)に置く
- 構造化データは
name=屋号、legalName=登記商号。登記名をalternateNameに入れない - 名前より住所の方が事故りやすい。構造化データとフッターは実際の営業拠点、登記住所は会社概要の別ラベルと特商法ページにのみ書く
- 制作前に「実際に現場へ出発するのはどちらの住所か」を確認する。ヒアリングシートの所在地欄は登記住所であることが多い
- そろえるのは郵便番号・都道府県・市区町村・町域名・電話番号・事業者名まで。番地の全半角は放置してよい
- 法人化時は特商法ページ→会社概要→フッター→構造化データ→メール署名→帳票の順。ヘッダーの屋号は変えない
名前が2つあること自体は、まったく問題ではありません。問題になるのは、どちらをどこに書くかが決まっていない状態です。置き場所さえ先に決めてしまえば、あとは機械的に流し込むだけの作業になります。