中小企業が公式サイトを制作する際、コンテンツフレームワークは初回公開時にほぼ固定されてしまいます。ナビゲーションが配置され、カテゴリが作成され、ページも埋め尽くされます。しかし本当の問題は半年後に現れます。製品カテゴリを追加したいのにナビゲーションに収まらない、古いカテゴリを統合したいのに外部リンクや検索エンジンの登録が旧アドレスを指している、新しい担当者に更新を引き継ぎたいのに画像ファイル名が「1.jpg」「無題-2.png」ばかり、といった具合です。
つまりコンテンツフレームワークとは「カテゴリを綺麗に並べること」ではなく、将来の更新、追加・削除、リニューアルに備えて構造上の余地を残すことです。以下、保守担当者が実際に直面する順序で説明します。
カテゴリを並べる前に決めておくべき3つのこと
フレームワークが乱れる原因は、多くの場合デザインの問題ではなく、着手前に以下の3点を明確にしていないことです。ナビゲーションを描く前に、一枚の紙に書き出すことをお勧めします。
- 誰が、どのくらいの頻度で保守するか。兼任の運用担当者が一人だけなら、カテゴリを細かく分けすぎない方がよいでしょう。各カテゴリが長期間空欄になると、サイトが更新されていない印象を与えます。複数部門がコンテンツを提供する場合は、「誰がどの部分を担当するか」で区分けし、見た目の良さで区分けしないようにします。
- どのコンテンツが長期的に安定し、どれが頻繁に変わるか。会社概要、連絡先、資格情報などは年に数回しか変更されません。ニュース、事例、イベント、製品価格などは毎月変わる可能性があります。安定したコンテンツは固定カテゴリに適し、変化しやすいコンテンツには「一括追加可能な」構造を用意します。例えば、10件の事例を一つの長いページに並べるのではなく、事例一覧ページと詳細ページを設けます。
- サイトの中心的な役割は何か。連絡先を見つけてもらうことか、製品を見てから問い合わせてもらうことか、営業がリンクを送るためか。役割によってカテゴリの優先順位と階層の深さが変わります。
カテゴリ階層：浅めに、推測に頼らない
中小企業の公式サイトのナビゲーション階層は、経験上2階層以内に抑えるのが最も簡単です。第1階層は直接表示し、第2階層はマウスオーバーや展開で表示します。3階層以上になると、訪問者は迷いやすく、保守担当者も深い階層のページがどこにあるか忘れがちです。
あるカテゴリを独立させるべきかは、次の2つの質問で判断できます。
- 将来的に継続的に新しいコンテンツが生まれるか。生まれるなら独立させる価値があり、たまに説明記事を1つ載せるだけなら親カテゴリに統合します。
- 訪問者が専用に探しに来るか。「採用情報」「お問い合わせ」などはユーザーが直接探すのでナビゲーションに置きます。内部向けの展示だけならフッターや「会社概要」の下に置きます。
カテゴリ名は、内部用語ではなく訪問者が使う言葉を選びます。例えば工業部品を扱う企業が、社内で製品を「非標準品」と呼んでいても、顧客は「カスタム加工」で検索する可能性が高いです。ナビゲーションには後者を使い、前者はページタイトルや本文で補足します。一度命名を決めたら、以降のすべてのページタイトル、パンくずリスト、画像の説明文もこの用語に統一し、チームが素材を検索する際に呼び方がばらばらにならないようにします。
URLと素材の命名が長期的な保守コストの大部分を占める
多くの手戻りは、コンテンツの誤りではなく、アドレスやファイルが乱雑であることが原因です。フレームワーク作成時にいくつかのルールを決めておけば、後々大幅に時間を節約できます。
- URLは短い英語またはピンインを使い、無意味な番号は避ける。例えば、製品カテゴリは
/products/、事例は/cases/、ニュースは/news/とします。カテゴリが公開されたら、アドレスはできるだけ変更しないようにします。変更が必要な場合は、旧アドレスのリダイレクトとサイト内リンクを同時に処理します。 - 画像やドキュメントは「カテゴリ-用途-日付」で命名する。例えば
cases-2024-工場改修-01.jpgのようにし、IMG_2031.jpgは避けます。これにより、管理画面のメディアライブラリで検索する際に、カテゴリと用途で素早く特定できます。 - 各カテゴリに「一覧ページ＋詳細ページ」のテンプレートを用意する。一覧ページは表示と分類を担当し、詳細ページは具体的なコンテンツを担当します。これにより、将来の追加は一覧に1件加えるだけで済み、ページ全体を再レイアウトする必要がありません。
これらのルールに複雑なツールは不要です。チームの共有ドキュメントに記載し、新しい担当者が引き継ぐ際にそれに従えばよいのです。
「将来追加するもの」のための場所を前もって確保する
長期運用するサイトでは、フレームワークに以下のような場所を用意しておくのが望ましいです。
- フッター領域。連絡先、登録情報、リンク集、プライバシーポリシーなどを配置します。ここに後から追加してもメインナビゲーションに影響しません。
- サイドまたは下部の推薦枠。最新事例、関連製品、イベント入口などを配置します。コンテンツ更新時は推薦内容を差し替えるだけで、ページ構造は変えません。
- 拡張可能な分類。製品、事例、ニュースなどのカテゴリは、一度に固定しすぎないようにします。例えば事例は最初は業界別に分類し、後で地域別にも分類できるようにします。ただし、管理画面が複数分類やタグをサポートしていることが前提です。
管理画面が単一分類しかサポートしていない場合は、計画時にどちらを主分類にするか明確にします。業界別が一般的か、サービス種別が一般的か。主分類を一つ選び、他の軸はタイトルや本文に記載し、後で分類が足りなくなり作り直すことを避けます。
公開前の項目別チェックは、後からの修正より安価
フレームワークができたら、正式公開前に一度チェックすることをお勧めします。チェック対象は構造であり、文章の良し悪しではありません。
- 各第1階層カテゴリをクリックしたとき、空白ページや「準備中」ではなく実際のコンテンツがあるか。
- ナビゲーション内の各リンクを一つずつ開き、リンク切れや無関係なページへの遷移がないか。
- パンくずリストで詳細ページから一覧ページ、さらにホームへ戻れるか。
- モバイルでナビゲーションを展開したとき、第2階層カテゴリがクリックできるか。
- 管理画面で各カテゴリにテストコンテンツを正常に追加でき、公開後にフロントエンドに表示されるか。
- 画像ファイル名とカテゴリ命名ルールがチームドキュメントに記載されているか。
このチェックはすべてのコンテンツを一度に完成させる必要はありませんが、構造上の問題はコンテンツを大量に投入する前に解決する必要があります。そうしないと、コンテンツが増えるほどフレームワーク調整のコストが大きくなります。
運用段階でフレームワークを変更すべきか判断する方法
サイト公開後、フレームワークは完全に変更不可ではありませんが、「コンテンツの問題」と「構造の問題」を区別する必要があります。
あるカテゴリのコンテンツが少ないだけなら、まずコンテンツを補充し、カテゴリを急いで削除しないようにします。あるカテゴリに数ヶ月間新規追加がなく、訪問者もナビゲーションからほとんど入らない場合は、親カテゴリへの統合を検討できます。統合時には2つのことを行います。旧ページのコンテンツを新しい場所に移行し、旧アドレスのリダイレクトを処理して、既に配信されたリンクが無効にならないようにします。
訪問者が常に検索から直接ある詳細ページに入り、ホームページをほとんど経由しない場合、そのページのタイトルとコンテンツ自体が機能している証拠であり、フレームワークレベルで大きく変更する必要はありません。むしろ、そのページの関連推薦と連絡先を明確に保つことが重要です。
フレームワーク調整の目標は、保守をより省力化し、訪問者が次のステップを見つけやすくすることであり、一度で完璧を目指すことではありません。中小企業の公式サイトのコンテンツフレームワークは、今後1〜2年の通常の更新と少量の追加・削除を支えられれば、合格と言えます。
