BtoBサイトの情報設計で最初に決めるべきことは、メニューの項目数ではありません。見込み顧客が検討を進める中で抱く疑問に対し、どのページで、どの証拠を見せ、次に何をしてもらうかを決めることです。
サービスページ、課題別ページ、業界別ページ、導入事例、会社情報を増やしても、役割が重複していればユーザーは比較しにくくなります。逆に、検討段階と意思決定者ごとの判断材料を整理できれば、ページ数が多いサイトでも迷いにくい構造にできます。
結論からいうと、BtoBサイトの情報設計は「入口」「理解」「証拠」「行動」の4役を分け、各ページを内部リンクで循環させる設計が実務的です。本記事では、問い合わせ獲得だけでなく、商談前の理解促進や営業資料としての使いやすさまで考慮したサイトマップの作り方を解説します。
BtoBサイトの情報設計とは、ページ一覧ではなく「判断を進める構造」のこと
情報設計（Information Architecture）とは、情報を分類し、名称を付け、ユーザーが必要な情報へ到達できるように構造化することです。サイトマップはその成果物の一つにすぎません。
BtoBでは、検索して最初に訪れる担当者、比較検討する現場責任者、予算やリスクを確認する決裁者など、閲覧者の立場が分かれます。同じサービスでも、担当者は機能や対応範囲を、責任者は導入効果や実績を、決裁者は費用対効果・セキュリティ・導入負荷を確認したい場合があります。
そのため、会社の組織図や社内の商品分類をそのままナビゲーションに移すだけでは不十分です。ユーザーが今いる検討段階と、次に解消したい不安を基準に情報を配置します。
- 入口：検索・広告・営業共有から訪れた人に、対象課題と提供価値を短時間で伝える。
- 理解：サービス内容、対象業務、導入の進め方を示し、「自社に関係がある」と判断してもらう。
- 証拠：導入事例、仕様、体制、セキュリティ、FAQなどで、比較・社内説明に必要な根拠を渡す。
- 行動：相談、見積もり、資料請求、デモなど、検討温度に合う次の行動へつなぐ。
Googleも、ユーザーが移動しやすい論理的なサイト構造と、重要ページへの関連リンクを推奨しています。情報設計はUXのためだけでなく、重要ページの意味や関係性を検索エンジンへ伝える土台にもなります。[1]
BtoBサイトの情報設計を作る7ステップ
1. 先に「どの成果を増やすサイトか」を定義する
サイトマップから始めると、「会社案内」「サービス」「事例」「お知らせ」といった慣習的な構成になりがちです。最初に、サイトが事業へどう貢献するかを言語化してください。
たとえば、同じ問い合わせでも、採用相談・既存顧客の連絡・協業提案・新規商談では価値が異なります。新規商談を増やしたいなら、単純な問い合わせ数ではなく、対象業種・課題・予算感などを満たす相談を主要成果として置くほうが、ページの優先順位を判断しやすくなります。
| 事業上の目的 | サイト上の主要行動 | 情報設計で優先するページ |
|---|---|---|
| 新規商談を増やす | 課題に合うサービスへの相談 | 課題別ページ、サービスページ、事例、相談導線 |
| 商談化率を高める | 営業共有後の理解・比較 | 導入プロセス、実績、FAQ、仕様・体制、資料 |
| 指名検索・信頼を増やす | 会社・専門性の確認 | 強み、専門コンテンツ、メンバー、会社情報 |
| 既存顧客の自己解決を促す | サポート情報の閲覧 | サポート、ドキュメント、問い合わせ窓口 |
成果定義は、公開後の計測設計にも直結します。問い合わせ完了だけをコンバージョンにすると、資料閲覧や事例閲覧が商談化に寄与しているか見えません。BtoBの行動を段階別に設計する方法は、GA4コンバージョン設計のやり方もあわせて確認してください。
2. 既存コンテンツを「ページ名」ではなく「判断材料」で棚卸しする
情報設計では、公開中のURLを一覧化するだけでは足りません。各ページが、顧客のどの判断を助けるのかまで記録します。特にBtoBでは、営業資料・提案書・PDF・FAQに重要情報が閉じていることがあります。
棚卸しシートには、少なくとも次の項目を入れます。
- ページ・資料の名称とURL
- 主な閲覧者（現場担当、責任者、決裁者、既存顧客など）
- 解消する疑問（何ができるか、なぜ選ばれるか、導入できるか）
- 証拠の種類（事例、数値、仕様、認証、担当体制、プロセス）
- 次に遷移させたいページまたはCTA
- 更新責任者と見直し時期
ここで「内容はあるが、どの判断にも使われていない」ページが見つかれば、統合・削除・リンク追加の候補です。反対に、営業が個別送付している資料に繰り返し同じ質問への回答が含まれていれば、Webページ化する優先度が高いと考えられます。
3. グローバルナビゲーションの主軸を1つ決める
迷いやすいBtoBサイトでは、「サービス別」「課題別」「業界別」「職種別」が同じ階層に混在しています。すべて必要に見えますが、主軸が複数あると、ユーザーはどこから探すべきか判断できません。
基本は、最も再現性が高く、事業の提供単位とも一致する分類を主軸に置きます。多くのBtoB企業ではサービス・製品群が主軸になりやすく、課題別・業界別・役割別は入口ページや絞り込み、関連リンクとして使います。
| 分類軸 | 向いているケース | 設計上の注意 |
|---|---|---|
| サービス・製品別 | 提供範囲が明確で、比較対象もサービス単位の場合 | 社内用語だけで名称を付けず、対象業務や提供価値を補う |
| 課題別 | 顧客が製品名より悩みから探す場合 | 同じ説明を量産せず、詳細はサービスの基幹ページへ集約する |
| 業界別 | 業界固有の規制・商習慣・導入要件が強い場合 | ロゴの並びだけにせず、業界特有の課題と対応内容を示す |
| 役割別 | 開発者・管理者・決裁者で必要情報が大きく異なる場合 | ペルソナを細分化しすぎず、実際の利用目的で分ける |
重要なのは、分類を一つに絞り込むことではなく、主従を決めることです。たとえば「課題別ページ」は検索・広告の受け皿として用意し、サービスの詳細や資料請求は共通のサービスページへ集約します。これにより、SEO用の入口と、商談化のための説明ページを両立しやすくなります。
4. ページを4種類に分け、重複ではなく連携で増やす
ページ数が増えるほど、内容の重複と管理コストが増えます。BtoBサイトでは、各ページを次の4種類に分けると役割が明確になります。
| ページ種別 | 主な役割 | 必ず用意したい要素 | 次の導線 |
|---|---|---|---|
| サービスページ | 何を提供し、どこまで対応するかを説明する | 対象課題、提供内容、導入方法、対象顧客、CTA | 事例、料金・導入条件、相談 |
| 課題別ページ | 悩みから自社との関連性を理解してもらう | 課題の背景、放置リスク、解決アプローチ、関連サービス | サービス詳細、関連コンテンツ、資料 |
| 導入事例ページ | 実現性と信頼性を示す | 導入前の課題、実施内容、成果、適用条件、顧客属性 | 類似課題、サービス詳細、相談 |
| 判断支援ページ | 社内比較や稟議で生じる不安を解消する | 導入手順、体制、FAQ、セキュリティ、価格の考え方 | 相談、資料、デモ |
ここでのポイントは、導入事例を「実績一覧」で終わらせないことです。事例は、サービスの信頼を補強するだけでなく、「自社に近い条件でも導入できるか」を判断するためのページです。業種、企業規模、導入前の状況、制約条件を可能な範囲で整理すると、比較検討中の読者が自分ごと化しやすくなります。
5. メニュー名とリンク文言を「社内用語」から「探す言葉」に変える
ナビゲーションの名称は、ユーザーがクリック前に「この先に欲しい情報がありそうだ」と推測する手がかりです。UXでは、この手がかりを情報の匂い（Information Scent）と呼びます。メニューラベルの分かりやすさが、目的情報の発見やサイト構造の理解に影響することは、ResnickとBakerの研究でも扱われています。[3]
たとえば、次のような抽象語は、社内では通じても初訪問者には内容が伝わりません。
- 「ソリューション」→「製造現場向け在庫管理支援」のように、対象や提供内容を補う
- 「強み」→「選ばれる理由」「対応できる業務・業界」のように、読む目的を示す
- 「リソース」→「導入事例」「お役立ち資料」「セミナー」のように、内容を具体化する
- 「お問い合わせ」→検討初期なら「まずは課題を相談する」など、相談内容を想像できる文言にする
ただし、すべてを長い説明文にする必要はありません。ヘッダーメニューは短く保ち、必要に応じてメガメニューの補足文や遷移先ページの見出しで具体性を補います。内部リンクのアンカーテキストも、「詳しくはこちら」ではなく、遷移先で得られる情報を表す言葉にします。
6. すべての重要ページに「前進」と「横移動」の導線を置く
BtoBの検討は一直線には進みません。サービスページを読んだ人が事例を確認し、事例から導入手順へ移り、後日あらためて資料を探すことがあります。そのため、ページごとにCTAを一つだけ置くよりも、検討度に応じた選択肢を設計するほうが実態に合います。
- 理解を深めたい人：課題別ページ・機能詳細・関連コラムへ
- 信頼を確かめたい人：導入事例・対応業界・会社情報へ
- 導入可否を確かめたい人：導入手順・FAQ・セキュリティ・料金の考え方へ
- 相談したい人：課題相談・デモ・見積もり依頼へ
このとき、CTAの数を増やすこと自体が目的ではありません。ページの主目的に対して最も自然な「前進」を一つ決め、その下に比較・確認用の「横移動」を置きます。たとえば、検索から流入する課題別ページの主CTAはサービス詳細、サービスページの主CTAは相談、導入事例ページの主CTAは類似事例または相談、といった分担が考えられます。
また、重要なサービスページがトップページからしか到達できない構造は避けます。関連する課題ページ、事例、コラム、資料ページからも文脈に沿ってリンクし、営業担当者がURLを共有したときにも次の情報を見つけられる状態をつくります。
7. 公開前はツリーテスト、公開後は「到達」と「迷い」を測る
情報設計は、社内レビューで合意しただけでは検証になりません。公開前は、画面デザインを作り込む前に、メニュー階層とラベルだけを使って目的の情報を探せるか確かめるツリーテストが有効です。カードソートはユーザーの分類の仕方を探る方法、ツリーテストは作成した分類・ラベルで目的の情報に到達できるかを確かめる方法として使い分けます。[2]
たとえば、次のようなタスクを用意します。
- 「自社の業界での導入実績を確認してください」
- 「導入までの期間と進め方を確認してください」
- 「既存システムとの連携可否を確認してください」
公開後は、ページビューだけでなく、次のように導線を分解して見ます。
| 見たいこと | 確認する指標・イベント例 | 読み取り方 |
|---|---|---|
| 重要情報に到達しているか | 対象ページの閲覧数、流入元、前ページ | 課題別ページからサービス・事例へ進めているかを見る |
| 判断材料が使われているか | 事例・FAQ・導入手順の閲覧、PDFクリック | 商談前に必要な情報が孤立していないかを確認する |
| CTAが文脈に合うか | ページ別CTAクリック率、フォーム到達率 | クリック率だけでなく、クリック後の離脱も確認する |
| 迷いが生じていないか | 同一セッションでのメニュー再操作、サイト内検索、想定外の往復遷移 | ラベル・階層・関連リンクの不足仮説を立てる |
注意したいのは、CTAクリック率だけを正解にしないことです。事例ページでは、すぐに問い合わせる人よりも、別の事例やサービス詳細を読んでから離脱する人がいるかもしれません。ページ単体のCVRではなく、重要ページを経由した商談化やリード品質まで確認して、構造を評価します。KGIから指標をつなぐ考え方は、WebマーケティングのKPI設計方法で詳しく解説しています。
BtoBサイトの情報設計で起こりやすい失敗
組織図どおりにメニューを作る
事業部や部門の単位は、運営上は重要です。しかし顧客がその区分を理解しているとは限りません。「〇〇事業部」「DX推進室」のような名称だけでは、何を解決できるのか判断しにくくなります。部門をまたぐサービスは、顧客課題や提供内容から入口を作り、運営上の担当分担はCMSや編集フローで管理します。
課題別・業界別・サービス別で同じ説明を繰り返す
SEOや営業要望に対応しようとして、似たページを量産するケースです。重複が増えると、ユーザーはページごとの差を理解できず、更新時には情報の不整合も起きます。
解決策は、詳細説明の基幹ページを決めることです。サービスの機能・対応範囲はサービスページへ集約し、課題別ページでは課題の理解と関連サービスへの接続に集中します。業界別ページでは、業界固有の要件、実績、導入上の論点を中心に扱います。
メガメニューにすべてのページを詰め込む
情報量が多いからといって、メニューで全ページを見せる必要はありません。メガメニューは、分類を補助する手段であり、サイトマップの代替ではありません。最上位では主要な選択肢を絞り、下層ページで関連情報へ移動できるようにしたほうが、閲覧時の認知負荷を抑えやすくなります。
リニューアル時にURL変更を軽く扱う
情報設計を見直すと、カテゴリやURLを変更したくなります。しかし、検索流入や営業資料からの参照があるURLを変更する場合は、旧URLと新URLの対応表、恒久的なリダイレクト、内部リンク更新、計測確認までを制作要件に含める必要があります。構造をきれいにすることと、既存資産を失わないことは別の論点として管理してください。
一歩深く考える：情報設計は「集客導線」と「営業支援」を共通化する仕事
BtoBサイトでは、検索流入を増やす施策と、営業が商談で使える資料を作る施策が分断されがちです。しかし、顧客が検索で知りたいことと、営業が商談前に説明したいことには重なりがあります。
たとえば「導入事例」「導入手順」「費用の考え方」「連携要件」「セキュリティ」は、検索流入後の比較検討にも、営業からURLを送った後の理解促進にも役立ちます。ここをPDFや担当者の説明だけに閉じず、更新可能なページとして整備すると、コンテンツ・営業・サイト運用で同じ情報を再利用できます。
Ad屋の視点では、良い情報設計は見た目の整理ではなく、次の改善を決められる構造です。ページの役割、CTA、計測イベント、更新責任者までをセットで設計しておけば、「どのページを増やすか」ではなく、「どの判断材料が不足し、どの導線を直すか」で改善を進められます。
まとめ：BtoBサイトの情報設計チェックリスト
- サイトの主要成果を、問い合わせ数だけでなく商談につながる行動として定義している
- コンテンツをページ名ではなく、閲覧者・疑問・証拠・次の行動で棚卸ししている
- グローバルナビゲーションの主軸と、課題別・業界別ページの役割を分けている
- サービス、課題、事例、判断支援ページの重複を抑え、相互にリンクしている
- メニュー名やCTAが、社内用語ではなく顧客が探す言葉になっている
- 公開前に到達テストを行い、公開後は重要ページへの遷移とCTA後の行動を測る設計になっている
まずは、問い合わせにつながる主力サービスを一つ選び、「そのサービスを検討する人が、何を確認してから相談するか」を書き出してください。その順番で既存ページを並べ直すだけでも、サイトマップの問題点と不足コンテンツが見えやすくなります。