Webサイトの情報アーキテクチャとは？サイトマップ・UI・SEOをユーザー目線で設計するには？

Webサイトをリニューアルした、情報も分類したし、ナビゲーションやサイトマップもきれいになったと思う。それなのに、ユーザーからは「知りたいことがどこにあるか分からない」という声を聞く。

こうしたことは珍しくありません。なぜなら、ページを論理的に分類すれば、すなわちそれがユーザーにとっても分かりやすくなるかというと、それは別の話だからです。

今回はこの「情報構造の考え方」「情報アーキテクチャ」について企業のWebサイトに絞ってまとめていきます。

情報を分類してサイトマップへ並べるだけでは、ユーザーが使えるWebサイトにはなりません。

ユーザーが必要な情報を予測して選び、意味や関係を理解し、比較や問い合わせなどの次の行動へ進める状態を作ります。そのために、ページ構成、メニュー、見出し、内部リンク、サイト内検索などを一続きで考え、実際のユーザーの行動で確かめます。この活動が、Webサイトにおける情報アーキテクチャです。

この記事でいうUIは、画面上で情報をどう見せ、どのように選べるようにするかという仕組みとします。また、今時のSEOは検索順位だけを指しません。検索エンジンがページを見つけ、内容とページ同士の関係を理解できるようにする取り組みも含みます。

サイトマップ、UI、SEOは、担当者ごとに分かれた成果物に見えがちですが…ユーザーが情報を探す場面ではセットで考えなくてはいけない物です。

情報アーキテクチャの良し悪しは、構造の美しさでだけでは判断できません。

ユーザーが必要な情報を見つけ、理解し、次へ進めるか。言葉が正しければ、正しく伝わるとは限らない、みたいなことですね。ユーザーの勘違いも許容するようなイメージです。

まず、ユーザーが何を知りたいかから考えよう

サイトを作るとき、最初にページの一覧から考えたくなるかもしれません。しかし、その前に確認したいことがあります。そのサイトを訪れるユーザーは、何を知り、何を判断しようとしているのでしょうか。

ユーザーは、自分の疑問から探し始める。会社の商品分類なんて関係ない

例えば、法人向けの業務支援サービスを探している人を考えてみます。その人が最初から、提供会社の商品名や担当部署を知っているとは限りません。次のような疑問を持って検索するはずです。

• 自社の問題は、このサービスで解決できるのか
• IT担当者がいなくても依頼できるのか
• どこまで作業を任せられるのか
• 費用と期間はどのくらいか
• 同じような会社の事例はあるか
• 相談した後は、どのように進むのか

一方、社内では「導入支援」「運用支援」「プロフェッショナルサービス」のように、提供体制や契約区分でサービスを分けているかもしれません。その分類は、社内の管理には適しています。しかし、初めて訪れたユーザーが、自分の疑問と各区分の関係を理解できるとは限りません。

当社では、ユーザーの状況を仮定して、検索から比較、問い合わせまでを実際に追う作業を「お客さまロールプレイ」と呼んでいます。SEOの進め方をまとめた記事でも、検索語だけを見るのではなく、検索のきっかけ、検討段階、比較条件、検索後に望む行動を一組にして考えることを勧めています。

この作業をするときは、自社名や商品名を知っている前提をできるだけ忘れてください。ユーザーが最初に使いそうな言葉で検索し、競合を含む複数のページを見ながら、どの情報が判断に使われるかを考えていく。

問い合わせまでに必要な情報を、ユーザーの順番で書き出す

ユーザーの疑問が見えたら、問い合わせまでに必要な情報を書き出します。ページ名を決めたくなるかもしれませんが、それはその後です。

法人向けサービスサイトなら、例えば次のような順番が考えられます。

1. 自社が対象に含まれるかを知る
2. 何を解決できるサービスかを理解する
3. 支援範囲と自社で行う作業を確認する
4. 費用、期間、契約条件を確認する
5. 事例や実績から、自社でも任せられるか判断する
6. よくある疑問や例外条件を確認する
7. 相談後の流れを理解して問い合わせる

すべてのユーザーが、この順番で読むわけではありません。費用から見る人もいれば、事例から見る人もいます。重要なのは、一本道を強制することではなく、必要な情報同士の関係を先に明らかにすることです。

この段階では、「どの部署が原稿を持っているか」よりも、「ユーザーが一つの判断をするために、どの情報を一緒に使うか」を優先します。

情報を分けるときは、ユーザーがどう捉えるかを基準にしよう

情報を正確に分類することは大切です。ページが増えても分類されてなければ、ユーザーは混乱します。

ただし、論理的に正しい分類は出発点としてとても有用です。

その上で、その分類がユーザーにも伝わるかを確かめて、初めてWebサイトで使える情報構造になるイメージです。

論理的に正しい分類が、ユーザーにも分かるとは限らない

制作側は、商品仕様、契約形態、担当部門、技術分野などを詳しく知っています。そのため、細かな違いを基準にページを分けられます。

しかし、ユーザーが知りたいのは、細かな違いそのものではなく、「自分はどれを選べばよいか」である場合が多いと思いませんか？

例えば、メニューに次の三つが並んでいたとします。

• ソリューション
• プロフェッショナルサービス
• マネージドサービス

提供側が業界内で意味を分けていても、初めて訪れた人は選択後の内容を予測できないかもしれません。「システム導入を相談したい」「運用を任せたい」のように、目的や依頼内容が分かる言葉を補うと選びやすくなります。

専門用語をすべて避ける必要はありません。検索や商談で顧客が実際に使う言葉なら、専門用語が最も分かりやすい場合もあります。社内で正確かどうかだけでなく、ユーザーが次の内容を予測できるかを判断基準にします。

ナビは専門用語ではなく、次の内容を予測できる言葉を使う

メニュー名やリンクの言葉は、単なる短い名称ではありません。ユーザーは、その言葉から移動先を予測します。

例えば、「詳細はこちら」だけでは、何の詳細か分かりません。「料金と支援範囲を見る」「同業種の導入事例を見る」と書けば、移動する理由を判断できます。

短い言葉にすることより、次の三点を優先しましょう。

• 誰向けの情報か分かる
• 何について書かれているか分かる
• 選ぶと何を確認できるか分かる

同じ言葉を、メニュー、ページタイトル、見出し、リンクで極端に違う意味に使わないことも大切です。場所によって呼び方が変わると、ユーザーは別の情報だと受け取る可能性があります。

一緒に置くか分けるかは、何かを判断する際にそれを同時に知りたいだろう情報かどうかで決める

ページやサイトを分けるときも、商品分類だけで決めないようにします。ユーザーが判断するときに、両方の情報を一緒に使うかを考えます。

当社のQ&A「複数の事業で、Webサイトやドメインは分けた方が良いでしょうか」では、もう一方の事業がユーザーにとって役立つ情報になるか、ただのノイズになるかを判断基準にしています。

情報の見せ方には、次のような段階があります。

• 同じ重要度でメニューへ並べる
• 補助的なリンクやバナーで存在を知らせる
• サービス一覧からだけ移動できるようにする
• サイト自体を分ける

どれか一つが常に正しいわけではありません。ユーザーの判断に強く関係する情報ほど近くに置き、関係が薄い情報は露出を弱めます。「会社として扱っているから目立たせる」ではなく、ユーザーが必要とする距離で配置します。

サイトマップをページ一覧で終わらせないようにしよう

サイトマップは、Webサイトの構成を共有するために役立ちます。そのためサイトの構造理解のために「とりあえずSitemaps見てくれるだろう」と投げがちです。

しかし、ページを漏れなくリストアップ・入れただけでは、ユーザーが目的の情報へ進めるかは判断できません。

入口、現在地、次に必要な情報までを線でつなぐ

サイトマップを見るときは、各ページの上下関係に加えて、ユーザーの移動を線でみていきましょう。

サービス概要の下に費用ページがあるだけでは不十分です。サービス概要を読んだ人が費用も確認したくなるなら、本文中に理由の分かるリンクを置きます。事例を読んだ人が支援範囲を知りたくなるなら、事例ページから支援範囲へ進めるようにします。

このように、サイトマップを「ページが存在する場所」だけでなく、「ユーザーが次に必要とする情報との関係」を確認する図として使います。

※ここでいうサイトマップは、制作時にページ構成を示す図です。検索エンジンへURLを知らせるXMLサイトマップとは役割が違います。XMLサイトマップを送信しても、ユーザー向けのメニューや内部リンクが分かりやすくなるわけではありません。

階層の浅さより、一つ一つの選択が分かることを優先する

「すべてのページへ少ないクリック数で到達できる方がよい」と言われることがあります。クリック数は確認したい指標の一つですが、少なければ必ず分かりやすいとは限りません。

一つの画面に多くの選択肢を並べても、それぞれの違いが分からなければユーザーは迷ってしまいます。

反対に、「目的を選ぶ」「条件を選ぶ」「詳しい情報を見る」と意味の分かる段階を進む方が、確信を持って選べる場合があります。

階層を見るときは、深さだけでなく次の点を確認しましょう。

• 各段階で何を選ぶのかが分かるか
• 選択肢同士の違いを説明できるか
• 現在地と戻り先が分かるか
• 別の探し方も選べるか
• 途中で判断に必要な情報が欠けていないか

階層を浅くすることは手段です。ユーザーが一つ一つの選択に確信を持てるかを優先します。

メニュー、見出し、内部リンクはどう考えれば良い？

メニュー、見出し、内部リンク、サイト内検索は、別々の機能に見えます。しかし、ユーザーにとっては、一つの情報探索を支える入口と道しるべです。

メニューは、”自分向け”の入口を選べるようにする

グローバルメニューへ、すべてのページを並べる必要はありません。

ユーザーがサイト全体を見渡し、自分向けの入口を選ぶために重要な項目を置きます。

項目数だけで良し悪しを決めず、次の点を見ます。

• 違いが分かる言葉になっているか
• 同じ基準で並んでいるか
• よく使う入口が見つけやすいか
• 選ばなかった情報が邪魔になっていないか

例えば、「サービス」「製品」「ソリューション」が同じ階層に並んでいても、ユーザーが違いを説明できなければ、分類基準を見直す余地があります。

見出しは、ページの途中から読んでも内容を理解できるようにする

ユーザーが必ずページの先頭から読むとは限りません。検索結果や内部リンクから、ページの途中へ来ることがあります。AIによる回答が、ページの一部分を参照する場面もあります。

「特徴」「詳細」「その他」だけでは、見出しだけを読んだときに内容が分かりません。「IT担当者がいない企業も依頼できる支援範囲」「料金に含まれる作業と含まれない作業」のように、その節だけでも主題が分かる見出しにします。

W3Cのページ構造に関する資料は、見出しをページ内の関係と重要度に合わせて付けることや、構造化された内容が移動と理解を助けることを示しています。明確な見出しや領域は、視覚的な手掛かりになります。スクリーンリーダーやキーボードを使う人も、必要な場所へ移動しやすくなります。

内部リンクは、比較や次の判断に必要なページへつなぐ

内部リンクは、ページ間の回遊を増やすためだけの仕組みではありません。現在のページと、次に読むページの関係を示すものです。

Googleのリンクに関する案内でも、リンクに表示する言葉は、ユーザーとGoogleへリンク先の情報を伝えると説明されています。

リンクを置くときは、「このページも読ませたい」ではなく、「今の疑問を理解した人は、次に何を判断するか」から考えます。

• 対象者を読んだ後に、支援範囲へつなぐ
• 費用を読んだ後に、含まれる作業と契約条件へつなぐ
• 事例を読んだ後に、同じ条件のサービスへつなぐ
• FAQを読んだ後に、相談後の流れへつなぐ

関連性が薄いページを大量に並べると、次の選択が難しくなります。リンクの数より、移動先と読む理由が分かることを重視します。

サイト内検索は、ユーザーの言葉を知る手掛かりでもある

メニューだけで、すべての探し方へ対応するのは困難です。W3Cのナビゲーションに関する資料も、階層メニューに加えて、サイトマップや検索など複数の方法を用意する考え方を示しています。

サイト内検索は、メニューの補欠ではありません。ユーザーが自分の言葉で情報を探せる、別の入口です。

検索された言葉を見ると、サイト側の言葉とのずれも分かります。例えば、サイトでは「伴走支援」と呼んでいるのに、「運用代行」「更新を任せたい」という検索が多ければ、ユーザーの疑問を現在の分類や言葉で受け止められているかを確認できます。

検索結果が一件も出なかった語句を、ゼロ件検索と呼びます。ゼロ件検索には、情報自体がない場合と、別の言葉で掲載しているため見つからない場合があります。検索語をそのまま新しいメニュー名にせず、検索した人が何を知ろうとしたかを確かめます。

サイト内検索の利用が多いだけで、メニューが失敗しているとも断定できません。検索を好むユーザーもいます。具体的なページを素早く探すために、検索を使う人もいるからです。検索後に目的のページへ進めたか、同じ語で何度も検索していないかも併せて見ます。

画面の分かりやすさとSEOを、同じ情報構造から考えよう

UIとSEOを別々に進めると、画面では分かりやすく見えても重要な条件が画像にしか書かれていない、検索向けの文章はあるが次のページへ進めない、といった分断が起こります。

ユーザーと検索エンジンは同じではありません。それでも、ページの主題や情報同士の関係を明確にするという土台は共通します。

UIでは、情報の関係を見て分かる形にする

UIは、色や装飾だけを指しません。情報のまとまり、順序、違い、選択肢、次の行動を画面上で判別できるようにする仕組みです。

法人向けサービスページなら、例えば次の関係を見て分かる形にします。

• 冒頭で、誰のどの問題を扱うサービスかを示す
• 支援内容と対象外の作業を分けて示す
• 費用、期間、事例、FAQを見つけられるようにする
• 問い合わせ前に確認したい条件を近くに置く
• 問い合わせ後に何が起きるかをボタンの近くで示す

目立つ問い合わせボタンを置くだけでは、ユーザーが次へ進めるとは限りません。対象条件や費用が分からないままでは、ボタンを押す判断ができないからです。

SEOでは、同じ関係を見出し、本文、HTML、リンクで示す

SEOでは、画面に見える関係を、文章とHTMLでも明確にします。HTMLは、見出しや段落、表、リンクなど、ページの各部分の役割を示す記述です。

当社は2012年の記事「Googleが『セマンティック検索』に変わる？そして今やるべきことは？」でも、カテゴリー分けと関連記事へのリンクによって、情報の位置付けを示す考え方を扱いました。当時の検索予測を現在のルールとして使うことはできません。ただし、ページを孤立させず、関係を分類とリンクで示すという考え方は、現在にもつながります。

現在のSEOについては、当社の中小企業向けSEOガイドで、発見、理解、比較、次の行動を支える流れとして扱っています。内部リンクも、ユーザーと検索エンジンへページ同士の関係を伝える手段として位置付けています。

構造化データやAI対策を、分かりにくさの補強材料にしないほうがいい

構造化データは、ページの内容を決められた形式で検索エンジンへ伝える記述です。役立つ場面はありますが、ユーザーが読む本文や導線の代わりにはなりません。

Googleの構造化データに関するガイドラインは、ページ上でユーザーに見えない内容を構造化データだけに書かないよう求めています。正しく実装しても、検索結果に特別な形式で表示される保証はありません。

AI検索についても同じです。GoogleのAI検索機能に関する案内では、従来からのSEOの基本が引き続き関係すると説明されています。重要な内容をテキストで読めるようにすること、内部リンクで見つけられるようにすること、構造化データを画面上の内容と一致させることなどです。AI検索のためだけに、特別なAI用ファイルや専用の構造化データを追加する必要はないとも案内されています。

当社も2024年のPodcast「AI Overview・AI検索時代の対策・準備のためのWebサイトの『情報の構造化』」で、見出し、リスト、表、サイト全体の情報構造を扱いました。同時に、HTMLを100点にすること自体は目的ではないと述べています。

先に行うべきことは、ユーザーが読める本文の中で、対象、条件、違い、関連情報を明確にすることです。その関係を見出し、リンク、HTMLでも示します。検索エンジンやAIへの情報伝達は、人に分かりやすい情報構造の延長として考えましょう。

作った情報構造を、実際のユーザーで確かめよう

社内や制作会社の会議だけで、情報構造の正解を決めることはできません。作り手は商品やサービスを詳しく知っているため、初めて見る人がどこで迷うかを想像しきれないからです。

当社は2013年の記事「ユーザにとって魅力的なWebサイトを作るための『制作の6ステップ』」で、制作の各段階にユーザーからの反応を取り入れる考え方を紹介しました。完成後だけでなく、分類やデザインを決める途中でも確かめることが重要です。

「分かりやすいですか」ではなく、目的の情報を探してもらう

ユーザーへ「このサイトは分かりやすいですか」と聞くと、好みや遠慮を含む回答になりやすく、修正箇所を決めにくくなります。

代わりに、具体的な状況を渡します。

あなたの会社には専任のIT担当者がいません。業務システムの導入を相談できるか、料金の考え方と相談後の流れまで確認してください。

そのうえで、次の行動を観察します。

• 最初にどの言葉やメニューを選んだか
• 選んだ先に何があると予測したか
• どこで止まり、どこへ戻ったか
• 必要な情報へたどり着けたか
• 内容を正しく理解できたか
• 次に何をすればよいか判断できたか

たどり着けたかだけでなく、途中の迷いと選んだ理由を聞くことが大切です。

カードソートやツリーテストで、分類と名前の伝わり方を確かめる

画面を作る前にも、分類と言葉を確かめられます。

カードソートは、ページや情報項目を書いたカードを参加者に分けてもらい、どの情報を同じまとまりとして捉えるかを見る方法です。ツリーテストは、デザインを外した文字だけの階層を見せ、目的の情報をどこで探すかを確認します。

2008年の研究「Automated semantic elaboration of web site information architecture」でも、意味の近さから作った分類案を、利用者によるカードソートの結果と比較しています。この研究だけでWebサイトの分類方法が決まるわけではありません。しかし、言葉やデータから作った分類を、利用者の捉え方と比較する必要性を考える参考になります。

詳しい調査設計を最初から行わなくても、対象に近い人に具体的な探索を依頼すれば、社内だけでは気付けなかった問題が見つかります。必要な人数は、検証の目的や段階で変わります。「まず何人」と固定せず、同じ迷いが繰り返されるかを見ます。

迷った場所と選んだ理由を、修正箇所の判断に使う

一人の意見を、そのままメニュー名やページ構成へ反映する必要はありません。発言の背景を見ます。

例えば、「この言葉は嫌い」という感想だけでは修正理由が分かりません。「運用支援を探していたが、『マネージドサービス』の中にあると予測できなかった」という行動と理由が分かれば、ラベル、補足説明、入口の位置を検討できます。

複数人が同じ場所で迷った場合は、構造上の問題である可能性が高まります。一人だけが迷った場合も、その人の状況が重要な顧客層に当てはまるなら、無視はできません。人数だけでなく、誰が、どの目的で、なぜ迷ったかを確認しましょう。

公開した後も、検索語や問い合わせをもとに見直そう

情報アーキテクチャは、サイト公開時に完了する作業ではありません。新しいサービスや事例が増えれば、以前は分かりやすかった分類が使いにくくなることもあります。

公開後は、ユーザーの行動と現場で得た声を確認し、分類、言葉、導線を修正します。

サイト内検索の語句とゼロ件検索から、足りない入口を見つける

サイト内検索では、ユーザーがサイト側の言葉へ合わせず、自分の言葉を入力します。次のような記録を確認します。

• よく検索される言葉
• 結果が一件も出なかった言葉
• 一回の訪問中に言い換えて再検索された言葉
• 検索後に開かれたページ
• 検索後も離脱や再検索が続いた言葉

よく検索されるのに該当ページがないなら、情報不足かもしれません。該当ページがあるのに見つからないなら、タイトル、本文、検索機能、サイト側の呼び方に問題がある可能性があります。

検索語をそのまま新しいページ名にするのではなく、検索の目的を考えます。「価格」で検索した人が知りたいのは料金表とは限らず、最低金額、追加費用、見積もり方法かもしれません。

問い合わせや商談から、判断に足りなかった情報を見つける

問い合わせや商談で繰り返し聞かれる質問は、サイトに足りない情報を知る手掛かりです。

ただし、ページが存在しないとは限りません。書いてあるが見つからない、言葉が難しくて自社に当てはめられない、例外条件が分からないという場合もあります。

繰り返し質問を受けたら、次の順で確認します。

1. その質問に答えるページがあるか
2. ユーザーが使う言葉で書かれているか
3. 必要になるページからリンクされているか
4. 回答を読めば、自社の場合を判断できるか
5. 例外や相談が必要な条件を示しているか

ページを追加する前に、現在のページの言葉や導線で解決できないかも見ます。似たページを増やすと、かえって選択が難しくなる場合があるためです。

数字だけで理由を決めつけず、ユーザーの声と組み合わせる

アクセス解析からは、閲覧数、移動、離脱などを確認できます。しかし、離脱した理由までは分かりません。必要な情報を得て満足したのか、見つからずに諦めたのかは、同じ離脱として記録される場合があります。

数字から問題の候補を見つけ、ユーザーテスト、問い合わせ、商談で理由を確かめます。反対に、現場で聞いた声がどの程度起きているかを、アクセスや検索語で確認することもできます。

きれいな図ではなく、ユーザーが次へ進めるWebサイトを作ろう

情報を論理的に分類することや、言葉の意味を正確に分けることは、情報アーキテクチャの大切な土台です。しかし、制作側にとって正しい分類が、そのままユーザーに伝わるとは限りません。

Webサイトでは、次の順番で考えましょう。

1. ユーザーが何を知り、何を判断したいかを書き出す
2. ユーザーが理解し、次を予測できる分類と言葉を選ぶ
3. 入口、現在地、比較材料、次の行動をサイトマップでつなぐ
4. 同じ関係をメニュー、見出し、内部リンク、UI、SEOで示す
5. 実際のユーザーに目的の情報を探してもらう
6. 公開後の検索語、問い合わせ、行動から見直す

最後に、自社のサイトマップや画面案を次の五つの質問で確認してみてください。

1. ユーザーは、自分向けの入口を自分の言葉で選べるか
2. ページの途中から読んでも、誰向けの何の情報か分かるか
3. 比較や判断に必要な関連情報へ、理由の分かるリンクで進めるか
4. 一つの探し方で迷っても、メニューや検索など別の方法を選べるか
5. 公開後の検索語、行動、問い合わせを使って構造を見直しているか

この五つに答えられない箇所があれば、ページを増やす前に、分類、言葉、導線を見直す余地があります。

情報アーキテクチャの良し悪しを、サイトマップや階層図の完成で判断しないようにしましょう。ユーザーが必要な情報を見つけ、意味を理解し、次へ進める状態になったかを見ます。

検索エンジンやAIへ情報の関係を伝えることも重要です。ただし、それは人に分かりにくいWebサイトを別の記述で補う話ではありません。まず人に伝わる情報構造を作り、その関係を本文、見出し、リンク、HTMLでも判別できるようにする。この順番が、変化の速い検索環境でも長く使えるWebサイトの土台になります。