「サイトマップって、結局何のこと?」
新人ディレクターからよく受ける質問のひとつです。実はこの言葉、現場では3つの異なるものを指して使われています。混同したまま打ち合わせに出ると、クライアントやデザイナーとの間で話が噛み合わなくなることもあります。
この記事では、サイトマップの3つの意味を整理したうえで、Webディレクターとして現場でどう扱えばよいか、実務目線で解説します。
サイトマップとは？まず3つの意味を整理する
「サイトマップ」という言葉は、主に次の3つを指して使われます。
| 種類 | 誰のためのもの | 主な用途 |
|---|---|---|
| ①構成図としてのサイトマップ | 制作チーム・クライアント | サイト全体のページ構成を可視化する |
| ②HTMLサイトマップ | サイト訪問者(ユーザー) | 目的のページを探しやすくする |
| ③XMLサイトマップ | 検索エンジン | クロール・インデックスを促す |
①構成図としての「サイトマップ」
制作の初期段階で作る、ページの一覧と階層関係を示した図です。トップページを頂点に、下層ページをツリー状に並べていきます。要件定義やワイヤーフレーム作成の前段階で、「どんなページが、いくつ、どんな関係で必要か」を関係者間で合意するために使います。
②ユーザー向けの「HTMLサイトマップ」
サイト訪問者が、サイト内のページ一覧を確認できるページです。フッターなどからリンクされることが多く、「求めている情報がこのサイトにあるか」を訪問者が判断する助けになります。
③検索エンジン向けの「XMLサイトマップ」
Googleなどの検索エンジンに、サイトの構造やページのURLを伝えるためのファイルです。訪問者が直接目にすることはありません。WordPressの場合、実は特別な設定をしなくても「/wp-sitemap.xml」という形式で標準機能として自動生成されています。
同じ「サイトマップ」でも役割がまったく違う。ここを最初に分けて理解しておくと、後の話がすっきり整理できます。
なぜWebディレクターが「サイトマップ」を正しく理解すべきなのか
3つの意味を知っているだけでは、実務では足りません。私がディレクターとして特に重要だと感じるのは、①の「構成図としてのサイトマップ」がプロジェクトの土台になるという点です。
構成図は、要件定義・デザイン・コーディングという後工程すべての前提になります。ここが曖昧なまま先に進むと、後になって「このページ、聞いてなかったんですが」「この階層、この位置でいいんでしたっけ」といった手戻りが発生しやすくなります。
私自身、駆け出しの頃に構成図の粒度を粗く作ってしまい、デザイン工程の途中で「お問い合わせページの下に、実は個別の相談フォームが3種類必要だった」と判明したことがあります。デザインをやり直すことになり、スケジュールにも影響が出ました。構成図は「後で直せばいい」ものではなく、この段階でどれだけ具体的に詰められるかが、後工程の手戻りを左右するものだと痛感した経験です。
現場でよく起きるズレは、次のようなパターンです。
- クライアントは「サイトマップ」をページ一覧のExcelだと思っていて、ディレクターは階層構造の図をイメージしている
- 「サイトマップ作成お願いします」と言われて、③のXMLサイトマップ(SEO向けファイル)の話だと勘違いする
- 構成図の段階で決めたページ数が、デザイン工程で「やっぱりこのページも必要」と後から増える
いずれも、言葉の指す範囲を最初にすり合わせておけば防げるズレです。打ち合わせの冒頭で「ここでいうサイトマップは、構成図の意味で使います」と一言添えるだけでも、認識のズレはかなり減らせます。
制作初期に作る「サイトマップ(構成図)」の実務ポイント
誰が・いつ・どこまで作るのか
構成図は、要件定義がある程度固まった段階で、ディレクターが主導して作成することが多いです。私の場合、クライアントへのヒアリングで「必要なコンテンツ」がひと通り出そろった時点で、まず自分でたたき台を作り、その後クライアントとすり合わせる、という流れを取ることが多いです。
いきなり完成形を目指す必要はありません。7〜8割の完成度でクライアントに見せて、フィードバックをもらいながら詰めていくほうが、手戻りが少なく進められる印象があります。
粒度と命名ルールで揉めないための判断基準
構成図でよく迷うのが「どこまで細かく書くか」です。私が現場で意識している判断基準は、次の2つです。
- URL(ディレクトリ構成)に影響する階層は必ず書く(例:サービス配下に個別サービスページがあるかどうか)
- ページ内のセクション単位までは書かない(それはワイヤーフレームの役割)
これを混同すると、構成図が細かくなりすぎて、逆に全体像が見えづらくなります。「このページ、必要ですか?」ではなく「このページ、どの階層に置きますか?」というレベルで議論できる粒度を目安にすると、ちょうどよいバランスになりやすいです。
ワイヤーフレーム・ディレクトリマップとの違い
現場で混同されやすい3つの言葉を整理しておきます。
- サイトマップ(構成図):ページ同士の階層関係を示す図
- ワイヤーフレーム:1ページの中の要素配置を示す図
- ディレクトリマップ:各ページのURL・タイトルなどを一覧化した表
サイトマップは「どんなページがあるか」、ワイヤーフレームは「そのページの中身はどうなっているか」を扱うもの。役割が違うので、混ぜて使わないよう意識しておくと、後工程との連携がスムーズになります。
HTMLサイトマップは作るべきか?の判断基準
HTMLサイトマップ(訪問者向けのページ一覧)は、必ず作らなければいけないものではありません。私の感覚では、次のような基準で判断することが多いです。
- ページ数が多く、グローバルナビだけでは情報を探しにくい大規模サイト → 設置を検討
- コーポレートサイトなど、ページ数が少なく構造がシンプルなサイト → 省略されることも多い
フッターがナビゲーションの役割を兼ねているサイトも増えており、「HTMLサイトマップがない=手抜き」というわけではありません。サイトの規模と情報量に応じて、必要性を判断すればよいものです。
XMLサイトマップでディレクターが確認すべきこと
XMLサイトマップの生成・送信自体は、実装を担当するエンジニアやSEO担当者が対応することがほとんどです。ディレクターがコードを書く必要はありません。ただし、次の点は押さえておくと安心です。
- WordPressであれば、標準機能で「/wp-sitemap.xml」が自動生成されていることが多い(プラグインが必須というわけではない)
- 公開前に、noindexにしたいページ(サンクスページや管理用ページなど)がサイトマップに含まれていないか、エンジニアに確認する
- 公開後、Google Search Consoleへのサイトマップ送信が完了しているかを確認する
「作る担当ではないから知らなくていい」のではなく、関係者に正しく指示・確認できる程度の理解を持っておくことが、ディレクターの役割だと考えています。
サイトマップ作成・管理に役立つツール
構成図としてのサイトマップ作成には、次の2つがよく使われています。
- Googleスプレッドシート:ページ一覧・階層・担当者などを表形式で管理したい場合に扱いやすいツールです。関係者との共同編集もしやすく、進行管理も兼ねられます。
- Figma:階層構造をツリー状に視覚化したい場合に向いています。ワイヤーフレームやデザインへの移行もスムーズに行えます。
どちらが正解というものではなく、プロジェクトの規模やクライアントの読みやすさに応じて選ぶとよいでしょう。表で細かく管理したいなら前者、視覚的に全体像を共有したいなら後者、というのが私の使い分けの目安です。
まとめ
サイトマップには、①構成図、②HTMLサイトマップ、③XMLサイトマップという3つの意味があります。ディレクターにとって特に重要なのは①の構成図で、これはプロジェクト全体の土台になるものです。
粒度や命名ルールを最初に決め、関係者との認識をすり合わせておくことで、後工程での手戻りを減らせます。「サイトマップ」という言葉が出てきたら、まずどの意味で使われているかを確認する。それだけでも、現場でのすれ違いはぐっと減るはずです。
ディレ和尚のひとこと
地図なき航海に、迷いは付き物なり。サイトマップは船出前の羅針盤と心得るべし。
