ホームページのサイトマップの作り方｜ページ構成・メニュー・依頼の準備

ホームページのサイトマップは、ページ名を箱に入れて線でつなぐだけでなく、「どの情報を、どこで伝えるか」を決めるために使います。サービスを知りたい人、依頼できる条件を確かめたい人、会社の所在地を探す人が、それぞれ必要な情報へ進める構成を考えましょう。

この記事は、新しくホームページを作る企業や、リニューアルのページ構成を検討している担当者に向けたガイドです。材料の集め方、分類、ページの役割、メニュー名、制作会社へ渡す構成表、確認方法までを説明します。完成原稿がなくても、必要な情報と未決定の事項を整理するところから始められます。

GOV.UK・W3C・米国のU.S. Web Design System（USWDS）・Googleの一次資料を参照しています。確認日は2026年9月9日です。公開された設計例と、説明のために作った架空の企業例を区別します。ここで扱う中心は制作時のページ構成で、検索エンジンへ送るXMLサイトマップの設定とは役割が異なります。

1. サイトマップで決めることを、最初に揃える

構成図・公開する一覧・検索向けファイルを区別する

打ち合わせで「サイトマップを作る」と言われたら、何を作るのか確認してください。制作前の構成図は、ページの一覧や親子関係、作業範囲を整理する資料です。利用者向けのサイトマップページは、公開サイトの案内としてリンクをまとめるものです。同じ言葉でも、提出物と確認する相手が違います。

Googleのサイトマップ解説で扱われるのは、ページなどの情報を検索エンジンへ伝えるファイルです。検索向けのファイルを用意しても、利用者に分かりやすいメニューが自動的に決まるわけではありません。制作依頼では「ページ構成の検討」「公開メニュー」「検索向けの設定」を分けて担当を確認します。

ページの階層と、読者の読む順番を分ける

サービス詳細がサービス一覧の下に属する、という関係が階層です。一方で、サービス詳細を読み、関連する実績を確かめ、相談するという移動は読者の行動の流れです。構成図に親子関係があっても、実績からサービスへ戻るリンクや相談先が必要な場所まで決まっているとは限りません。

構成を考える際は、階層の線とは別に、代表的な読者がどこから来て何を確認するかを書きます。例えば検索からサービス詳細へ直接来る人に、トップページで説明した前提が伝わっているとは限りません。各ページ単体でも何の情報か分かり、必要な説明を追加で読めるように設計します。

箱の数より、今回の判断と納品範囲を明確にする

ページ数を先に固定すると、必要な説明を無理に詰め込んだり、内容が少ないページへ分けたりしがちです。まず、今回の公開で読者に何を判断してもらいたいかを揃えます。そのうえで一ページにまとめる部分、独立した説明が必要な部分、公開後に追加する部分を検討します。

構成図だけでは、記事一覧の絞り込み、フォームの確認画面、各記事を編集する仕組みなどが見えないこともあります。見積もり用の資料には、画面や機能、入力する原稿の件数も添えましょう。初回の相談材料全体は、初めてのホームページ制作ガイドで整理しています。

2. 掲載する材料を、読者の用事から洗い出す

「会社を知る」の先にある行動を具体化する

誰が、何をするために、どんな情報を必要としているのかを書きます。「会社を知ってほしい」なら、取引を検討する人が対応範囲を確認したいのか、応募する人が仕事内容を調べたいのかで必要なページが変わります。社内の発信したい内容と、読者が判断に必要とする内容を並べて確かめましょう。

GOV.UKの利用者ニーズに関するガイドは、誰が何をしたいのか、その理由を利用者の視点で記述し、問い合わせや既存の調査などを材料にする方法を説明しています。企業サイトなら、営業時の質問、依頼を見送った理由、受付で説明している内容を確認材料にできます。推測だけの案には、その旨を残します。

既存ページ・営業資料・社内の回答を一覧にする

既存サイトがある場合はURLとページ名を集め、本文だけでなくPDF、ブログ、採用情報、別のサービスサイトも確認します。営業資料にしかない仕様や、担当者だけが答えている条件も候補へ加えてください。新規サイトでは、会社案内、提案書、見積もりの説明、よく受ける質問から材料を拾えます。

集めた資料は、そのまま掲載できるものと、内容確認が必要なものを分けます。古い料金表が存在することと、現在もその料金で提供できることは別です。資料を集める担当、事実を確認する担当、掲載を決める担当が違う場合は、一覧に役割を記して確認が止まる場所を見つけます。

一つの材料を、一つの判断単位へ分ける

「会社案内」というファイルの単位のまま分類するより、サービスの対象、依頼の流れ、担当者、所在地など、読者が確認する情報へ分解すると配置を検討しやすくなります。一枚の資料に複数の情報がある場合も、それぞれどのページが最新版を持つかを決めましょう。同じ説明を各ページへ丸ごと複製する必要はありません。

3. 情報をまとめ、読者に伝わる名前を付ける

社内の部署名だけで、大分類を決めない

事業部ごとにページを分けると社内では管理しやすくても、初めて訪れた人には違いが分からない場合があります。「第一事業部」「第二事業部」ではなく、提供するサービスや対象者が想像できる名称を候補にします。社内組織と公開メニューは、必ずしも同じ並びにする必要はありません。

複数のサービスを分類するときは、分類の軸を揃えます。業種別、製品別、目的別が同じ段に混ざると、どこを選べばよいか判断しにくくなります。読者の目的が複数あるなら、基本のサービス分類を保ち、用途別の案内から同じ詳細ページへリンクする方法もあります。入口の追加と説明の重複を分けて考えましょう。

仮の分類を、初めて見る人に確かめる

材料を紙や表へ一項目ずつ書き、関連するものをまとめて名前を付けます。その後、制作に参加していない人にも、どの項目に何が入ると思うかを聞いてください。分類名だけを見せて「点検を頼める設備はどこで調べますか」と確認すると、説明を読んでもらう前の迷いが見えます。

回答が分かれた場合は、人数だけで正解を決めず、選んだ理由を確認します。言葉が分からないのか、複数の分類へ入りそうなのか、探す情報そのものが足りないのかで対応が違います。少人数の確認は全顧客の行動を代表する調査ではありませんが、候補を修正する材料として記録できます。

「その他」へ入れる前に、用途と優先度を見直す

分類しづらい情報を何でも「その他」へ入れると、その中身が増えて探しにくくなります。読者が頻繁に必要とする情報なのか、特定のサービスにだけ関係するのか、公開しなくてもよい社内情報なのかを再確認します。複数のページに関係する内容は、中心となる説明を一か所に置き、各ページから案内できます。

トップのメニューに置く項目数も、固定の正解があると考えないようにします。項目を減らしても、名前が曖昧なら探す負担は残ります。主要な用事へ進めるか、長い項目が小さい画面で読めるか、関連する項目がまとまっているかを見ます。見栄えのために意味の違う内容を一つへ押し込まないことが大切です。

事例を業種や対応サービスで絞り込む場合は、分類名だけでなく、誰が登録時に選ぶかも決めます。「製造」「製造業」のような似た分類が増えないよう、名称の一覧を管理します。まだ事例がない分類を表示するか、複数の分類に属する事例をどう扱うかも確認すると、公開後に一覧が空になる場面や登録の迷いに備えられます。

4. ページの親子関係と、各ページの役割を決める

一覧と詳細を分ける理由を確認する

サービスが複数ある場合、一覧は選ぶためのページ、詳細はそのサービスの条件を確認するページとして役割を分けられます。一覧に詳細の文章をすべて載せる必要はありません。対象や違いが分かる短い説明を付け、どちらを開けばよいか判断できるようにします。

反対に、サービスが一つで説明も短い場合、空に近い一覧を作る必要はないかもしれません。将来増える可能性だけで階層を深くせず、現在必要な情報と追加時の対応を相談します。記事一覧、制作事例一覧、事例詳細など、繰り返し増える部分では、同じ表示形式を使う範囲と個別編集する情報も決めます。

架空例：設備点検会社の構成表を作る

次は、法人向けの定期点検と修理相談を扱う架空の会社の例です。実在の顧客案件や推奨ページ数ではありません。会社が提供できる業務と確認済みの情報をもとに調整してください。「採用情報を作るか」も、募集の有無と掲載担当が決まっているかを確認して判断します。

公開例：USWDSは階層と現在地を併せて示している

米国政府のデザインシステムであるUSWDSのサイドナビゲーションには、親・子・さらに下の階層を表示し、現在の項目を区別する公開例があります。案内では、項目が多すぎたり深すぎたりしないか利用者と確かめることや、自分の実装でも試験することを勧めています。

企業サイトへ応用できるのは、階層を作る際に「今どこを見ているか」も示す考え方です。資料が多い事業の案内なら、同じ分類内のページへ移動する手段を検討できます。ただし、この公開例がすべての小規模企業サイトに必要な形というわけではなく、売上が増えたという事例でもありません。ページ数と利用場面に合わせて取り入れます。

5. メニュー・パンくず・本文リンクの役割を分ける

共通メニューには、主な入口を分かる名前で置く

ヘッダーやハンバーガーメニューには、サイトの主な入口を示します。各ページで同じ対象を違う呼び名にせず、表示位置や並び方にも一貫性を持たせます。英語の短い名前を採用する場合も、想定する読者が内容を予測できるか確認し、必要なら日本語の説明を添えましょう。

W3Cのメニュー構造のチュートリアルは、リストやナビゲーションの領域を示すマークアップ、現在の項目の表示などを説明しています。デザイン確認では見た目だけでなく、読み上げ時にもまとまりや現在地が伝わるかを制作担当へ確認します。画面上で同じように見えることと、構造が適切に伝わることは別の確認です。

パンくずで現在地を示し、本文で関連情報へつなぐ

パンくずは、ページがサイトのどこに属するかを示す案内です。USWDSのパンくずの公開例では、上位の項目と現在のページを順に示しています。サイトの階層を示すものとして設計する場合、閲覧者が実際に通ってきた履歴と混同しないようにします。検索から直接来た人も、上位の一覧へ移動できるようにします。

本文のリンクは、その説明を読んだあとに必要な情報へ進むために使います。Googleのリンクに関するガイドは、リンク先の内容が伝わる言葉と文脈を用い、関連する内部ページへつなぐことを説明しています。「こちら」を並べるより、「見積もりに必要な資料」のように、移動先で確認できる内容を示しましょう。

スマートフォンとキーボードの操作を構成段階で考える

PCで横に並べた項目を、スマートフォンではどう開いて選ぶのかを確認します。親の項目を押すとページへ移動するのか、下のメニューを開くのかが曖昧だと、意図した場所へ進めません。開閉する操作とページ移動を分ける案や、一覧ページから詳細を選べる案を制作担当と比べます。

W3Cの展開メニューの説明では、マウスの細かな操作が難しい人への配慮として、親ページなどにも下位ページへの別の移動手段を用意することを挙げています。小さい画面のタップ、キーボードでの移動、開閉、本文へ戻る動きを試験項目へ入れます。メニューが開くだけで操作完了とせず、目的のページまで進めるかを確かめてください。

6. 各ページに、原稿と導線の設計メモを付ける

一ページごとに、読後の判断を短く書く

ページ名が決まったら、「このページで誰が何を判断できるか」を一文にします。定期点検の詳細なら「対象設備と実施条件を確認し、見積もり相談に必要な情報を準備できる」と書けます。会社情報なら、取引する相手の基本情報や連絡先を確認する役割を持たせます。

同じ一文になるページが複数あれば、役割の重複を見直します。読者や条件が違うために分けるのか、内容の一部を共通の説明へまとめるのかを検討してください。役割を分けるために、実際には提供していないサービスを作ったり、地域名だけを変えた同じ説明を増やしたりする必要はありません。

見出し・材料・確認担当を対応させる

次にページ内の見出しを並べ、各見出しに使う原稿や写真、数値の根拠、確認担当を対応させます。「対応範囲」の見出しはあるが、社内で対応条件が決まっていないと分かれば、デザインに入る前に確認できます。写真がない場合も、撮影、既存素材、図解などの準備方法を相談できます。

すべてのページを同じ見出しで埋める必要はありません。サービス詳細は対象や利用条件、事例は担当内容と背景、採用は仕事と応募条件のように、読者の判断に合わせて構成します。写真と原稿の集め方は、ホームページ制作の素材準備ガイドも参考にしてください。

読者の入口と、次に確認する情報を記録する

主要ページには、想定する入口と次の案内を記します。ホームから来る人だけでなく、検索、紹介されたURL、事例のリンクから来る人も考えます。サービス詳細に直接来ても会社名や対象が分かるか、事例だけを見た人が現在のサービス条件を確かめられるかを確認しましょう。

すべての段落に問い合わせボタンを置くより、比較に必要な説明を読めることも大切です。料金の条件、必要な準備、よくある質問などを確認できれば、相談前の迷いを整理しやすくなります。本文の途中と末尾に何を案内するかを、構成表の「次の情報」の欄へ書き、実装時にリンクが抜けないようにします。

7. 制作会社へ、構成表と未決定事項を渡す

ページ数・表示形式・入力件数を分けて伝える

同じ「10ページ」でも、すべて違うデザインを作る場合と、共通の記事形式へ原稿を入れる場合では作業内容が違います。固定ページ、一覧、詳細、フォームなどの表示形式と、それぞれに用意する原稿の件数を分けます。CMSで自社が追加する予定の項目も、どこまで制作会社が初回入力するかを決めてください。

確認画面や送信完了画面、検索結果、該当する記事がない状態など、通常の構成図に描きにくい表示も一覧にします。必要な機能によっては追加の設計と試験が発生します。構成表を見積もりの共通資料にすることで、ページ数だけが同じで作業範囲が異なる提案を比較しやすくなります。

リニューアルでは、既存URLとの対応を残す

新しい構成図で階層を変えたからといって、公開済みのURLも一律に変える必要があるとは限りません。まず既存URLと新しいページの対応を表にし、内容を維持するのか、統合するのか、終了するのかを個別に検討します。外部で紹介されたURL、配布資料やQRコードのリンクも確認材料です。

転送や公開終了の処理は、画面上の分類変更とは別の実装作業です。制作担当へ対象と方針を確認し、公開後に元のURLからどう案内されるかも点検します。移行全体の段取りはホームページリニューアルの進め方に整理しています。図を整えるためだけに既存の公開先を変える判断は避けましょう。

追加要望は、理由と影響を確認して構成へ反映する

制作中に「このページもほしい」という要望が出たら、まず対象読者と目的を確認します。既存ページへの追記で足りるのか、独立した原稿や機能が必要なのかを検討し、制作費、材料、確認日程、更新担当への影響を整理します。必要な追加を受け付けつつ、誰も原稿を用意できない箱だけが増える状態を防ぎます。

合意した構成には日付や版を付け、変更理由と承認した担当者を残します。メールごとに別の図が添付されると、どれが最新版か分からなくなるため、保管先を一つ決めましょう。制作会社だけでなく、原稿を確認する社内担当にも変更を共有し、用意する材料と公開範囲を揃えます。

8. 構成案から公開後まで、探せるかを確かめる

色や写真を付ける前に、名前と分類を試す

構成段階では、文字だけのページ一覧でも確認できます。想定読者に近い人へ具体的な用事を伝え、どの分類を開くか、何を探すかを説明してもらいます。最初から正しい項目名を含む質問をせず、「依頼に必要な資料を準備したい」のように目的を伝えると、名称から行き先を予測できるかを見やすくなります。

迷った場所、別の分類を選んだ理由、見つからなかった情報を記録し、名前・分類・不足情報のどこを直すか考えます。クリック数だけを減らすことを目標にすると、一画面の選択肢が増えて迷う場合もあります。目的を達成できたかと、その途中で理解できなかった点を一緒に確認しましょう。

実装後は、図と公開ページを照合する

ページが完成したら、構成表の各項目が実際に開けるか、タイトルと内容が対応するかを確認します。ヘッダー、ハンバーガー、フッター、パンくず、本文の案内は別々に点検してください。PCで表示されているリンクがスマートフォンでは見つからない、一覧にあるページへ本文からは進めない、といった違いも確認対象です。

公開前の確認表には、主な入口から目的の情報と相談先へ進む経路を記します。検索結果を再現するための確認では、対象ページのURLを直接開いて前提が分かるかを確かめられます。フォームの操作や送信の試験を含める場合は、実際の顧客へ通知しない確認環境と担当を先に決めます。サイト全体の利用しやすさは、アクセシビリティ改善の確認項目も併せて点検できます。

記事やサービスが増えたときの見直し役を決める

公開後にページを追加したら、メニューへ入れるか、どの一覧に表示するか、関連する説明からリンクするかを確認します。掲載数が増えてから分類を作り直す場合も、既存URLや外部リンクへの影響を分けて考えます。内容の更新担当に加え、サイト全体の分類と案内を見直す担当を決めておきましょう。

サイトマップは、制作時に一度描いて終わる資料ではなく、情報の置き場所と管理を確認するために使えます。Acquaのホームページ制作のサービス案内では対応内容を確認できます。ページ構成について相談する際は、現在のURL、伝えたいサービス、読者が困っていること、使える資料をお知らせください。必要なページと、その中で伝える内容を整理する材料になります。