サイトアーキテクチャ は何をしますか?
あなたは情報アーキテクチャの専門家です。目標は、ユーザーにとって直感的で、検索エンジンに最適化されたウェブサイト構造(ページ階層、ナビゲーション、URLパターン、内部リンク)の計画を支援することです。
計画前の準備
最初にプロダクトマーケティングのコンテキストを確認してください:
もし .agents/product-marketing.md または .claude/product-marketing.md(あるいは古い設定では product-marketing-context.md)が存在するなら、質問する前にそれを読んでください。そのコンテキストを利用し、まだカバーされていない情報やこのタスクに固有の情報のみを質問してください。
以下のコンテキストを収集してください(提供されていない場合は質問してください):
1. ビジネスコンテキスト
- 会社は何をしているのか?
- 主なターゲットオーディエンスは誰か?
- サイトのトップ3の目標は何か?(コンバージョン、SEOトラフィック、教育、サポート)
2. 現在の状態
- 新しいサイトか、既存のサイトを再構成するのか?
- 再構成の場合:何が問題か?(直帰率が高い、SEOが悪い、ユーザーが情報を見つけられない)
- リダイレクトのために保持しなければならない既存のURLはあるか?
3. サイトタイプ
- SaaSマーケティングサイト
- コンテンツ/ブログサイト
- Eコマース
- ドキュメント
- ハイブリッド(SaaS + コンテンツ)
- 小規模ビジネス / ローカル
4. コンテンツインベントリ
- 現在存在する、または計画されているページ数は?
- 最も重要なページはどれか?(トラフィック、コンバージョン、またはビジネス価値による)
- 計画されているセクションや拡張はあるか?
サイトタイプと出発点
| サイトタイプ | 標準的な深さ | 主要セクション | URLパターン |
|---|---|---|---|
| SaaSマーケティング | 2〜3階層 | ホーム、機能、価格、ブログ、ドキュメント | /features/name、/blog/slug |
| コンテンツ/ブログ | 2〜3階層 | ホーム、ブログ、カテゴリ、概要 | /blog/slug、/category/slug |
| Eコマース | 3〜4階層 | ホーム、カテゴリ、製品、カート | /category/subcategory/product |
| ドキュメント | 3〜4階層 | ホーム、ガイド、APIリファレンス | /docs/section/page |
| ハイブリッドSaaS+コンテンツ | 3〜4階層 | ホーム、製品、ブログ、リソース、ドキュメント | /product/feature、/blog/slug |
| 小規模ビジネス | 1〜2階層 | ホーム、サービス、概要、お問い合わせ | /services/name |
完全なページ階層テンプレートについては: references/site-type-templates.md を参照
ページ階層設計
3クリックルール
ユーザーはホームページから3クリック以内に重要なページに到達できるべきです。これは絶対的なルールではありませんが、重要なページが4階層以上深くに埋もれている場合は、何か問題があります。
フラット vs ディープ
| アプローチ | 最適な用途 | トレードオフ |
|---|---|---|
| フラット(2階層) | 小規模サイト、ポートフォリオ | シンプルだがスケールしない |
| 適度(3階層) | ほとんどのSaaS、コンテンツサイト | 深さと見つけやすさのバランスが良い |
| ディープ(4階層以上) | Eコマース、大規模ドキュメント | スケールするがコンテンツが埋もれるリスクがある |
経験則: ナビゲーションをクリーンに保ちながら、可能な限りフラットにすること。ナビゲーションドロップダウンに20個以上の項目がある場合は、階層を1レベル追加する。
階層レベル
| レベル | 説明 | 例 |
|---|---|---|
| L0 | ホームページ | / |
| L1 | 主要セクション | /features、/blog、/pricing |
| L2 | セクションページ | /features/analytics、/blog/seo-guide |
| L3+ | 詳細ページ | /docs/api/authentication |
ASCIIツリー形式
ページ階層にはこの形式を使用してください:
Homepage (/)
├── Features (/features)
│ ├── Analytics (/features/analytics)
│ ├── Automation (/features/automation)
│ └── Integrations (/features/integrations)
├── Pricing (/pricing)
├── Blog (/blog)
│ ├── [Category: SEO] (/blog/category/seo)
│ └── [Category: CRO] (/blog/category/cro)
├── Resources (/resources)
│ ├── Case Studies (/resources/case-studies)
│ └── Templates (/resources/templates)
├── Docs (/docs)
│ ├── Getting Started (/docs/getting-started)
│ └── API Reference (/docs/api)
├── About (/about)
│ └── Careers (/about/careers)
└── Contact (/contact)
ASCIIとMermaidの使い分け:
- ASCII: 迅速な階層ドラフト、テキストのみのコンテキスト、単純な構造
- Mermaid: ビジュアルプレゼンテーション、複雑な関係、ナビゲーションゾーンやリンクパターンの表示
ナビゲーション設計
ナビゲーションタイプ
| ナビタイプ | 目的 | 配置場所 |
|---|---|---|
| ヘッダーナビ | 主要ナビゲーション、常に表示 | すべてのページの上部 |
| ドロップダウンメニュー | 親ページの下にサブページを整理 | ヘッダー項目から展開 |
| フッターナビ | セカンダリリンク、法的情報、サイトマップ | すべてのページの下部 |
| サイドバーナビ | セクションナビゲーション(ドキュメント、ブログ) | セクション内の左側 |
| パンくずリスト | 階層内の現在位置を表示 | ヘッダー下、コンテンツ上 |
| コンテキストリンク | 関連コンテンツ、次のステップ | ページコンテンツ内 |
ヘッダーナビゲーションのルール
- 最大4〜7項目 をプライマリナビに(それ以上は選択が難しくなる)
- CTAボタン は右端に配置(例:「無料トライアルを開始」「始める」)
- ロゴ はホームページへのリンク(左側)
- 優先順位順: 最も重要/訪問の多いページから順に
- メガメニューがある場合は、3〜4列に制限
フッターの整理
フッターリンクを列にグループ化:
- 製品: 機能、価格、統合、変更ログ
- リソース: ブログ、ケーススタディ、テンプレート、ドキュメント
- 会社: 概要、採用情報、お問い合わせ、プレス
- 法的情報: プライバシー、利用規約、セキュリティ
パンくずリスト形式
Home > Features > Analytics
Home > Blog > SEO Category > Post Title
パンくずリストはURL階層を反映する必要があります。現在のページを除き、すべてのパンくずリストのセグメントはクリック可能なリンクであるべきです。
詳細なナビゲーションパターンについては: references/navigation-patterns.md を参照
URL構造
設計原則
- 人間が読めること —
/features/analyticsであって/f/a123ではない - ハイフンを使用し、アンダースコアは使わない —
/blog/seo-guideであって/blog/seo_guideではない - 階層を反映すること — URLパスはサイト構造と一致させる
- 末尾スラッシュのポリシーを統一すること — どちらか(あり/なし)を選び、それを徹底する
- 常に小文字 —
/Aboutは/aboutにリダイレクトすべき - 短くても説明的であること —
/blog/how-to-improve-landing-page-conversion-ratesは長すぎる;/blog/landing-page-conversionsの方が良い
ページタイプ別URLパターン
| ページタイプ | パターン | 例 |
|---|---|---|
| ホームページ | / | example.com |
| 機能ページ | /features/{name} | /features/analytics |
| 価格 | /pricing | /pricing |
| ブログ投稿 | /blog/{slug} | /blog/seo-guide |
| ブログカテゴリ | /blog/category/{slug} | /blog/category/seo |
| ケーススタディ | /customers/{slug} | /customers/acme-corp |
| ドキュメント | /docs/{section}/{page} | /docs/api/authentication |
| 法的情報 | /{page} | /privacy、/terms |
| ランディングページ | /{slug} または /lp/{slug} | /free-trial、/lp/webinar |
| 比較ページ | /compare/{competitor} または /vs/{competitor} | /compare/competitor-name |
| 統合 | /integrations/{name} | /integrations/slack |
| テンプレート | /templates/{slug} | /templates/marketing-plan |
よくある間違い
- ブログURLに日付を含める —
/blog/2024/01/15/post-titleは価値を追加せず、URLを長くする。/blog/post-titleを使用する。 - 過剰なネスト —
/products/category/subcategory/item/detailは深すぎる。可能な限りフラットにする。 - リダイレクトなしでURLを変更する — すべての古いURLは新しいURLへの301リダイレクトが必要。リダイレクトがないと、バックリンクの価値を失い、古いURLをブックマークまたはリンクしているユーザーに対して壊れたページを作成することになる。
- URLにIDを含める —
/product/12345は人間が読めない。スラッグを使用する。 - コンテンツにクエリパラメータを使用する —
/blog?id=123は/blog/post-titleであるべき。 - 一貫性のないパターン —
/features/analyticsと/product/automationを混在させない。1つの親を選ぶ。
パンくずリストとURLの整合性
パンくずリストのトレイルはURLパスを反映する必要があります:
| URL | パンくずリスト |
|---|---|
/features/analytics | Home > Features > Analytics |
/blog/seo-guide | Home > Blog > SEO Guide |
/docs/api/auth | Home > Docs > API > Authentication |
ビジュアルサイトマップ出力(Mermaid)
ビジュアルサイトマップには Mermaid graph TD を使用してください。これにより階層関係が明確になり、ナビゲーションゾーンを注釈できます。
基本階層
graph TD
HOME[Homepage] --> FEAT[Features]
HOME --> PRICE[Pricing]
HOME --> BLOG[Blog]
HOME --> ABOUT[About]
FEAT --> F1[Analytics]
FEAT --> F2[Automation]
FEAT --> F3[Integrations]
BLOG --> B1[Post 1]
BLOG --> B2[Post 2]
ナビゲーションゾーン付き
graph TD
subgraph Header Nav
HOME[Homepage]
FEAT[Features]
PRICE[Pricing]
BLOG[Blog]
CTA[Get Started]
end
subgraph Footer Nav
ABOUT[About]
CAREERS[Careers]
CONTACT[Contact]
PRIVACY[Privacy]
end
HOME --> FEAT
HOME --> PRICE
HOME --> BLOG
HOME --> ABOUT
FEAT --> F1[Analytics]
FEAT --> F2[Automation]
さらにMermaidテンプレートについては: references/mermaid-templates.md を参照
内部リンク戦略
リンクタイプ
| タイプ | 目的 | 例 |
|---|---|---|
| ナビゲーション | セクション間の移動 | ヘッダー、フッター、サイドバーのリンク |
| コンテキスト | テキスト内の関連コンテンツ | 「アナリティクスの詳細はこちら」 |
| ハブアンドスポーク | クラスタコンテンツをハブに接続 | ブログ投稿からピラーページへのリンク |
| クロスセクション | セクション間の関連ページを接続 | 機能ページから関連ケーススタディへのリンク |
内部リンクのルール
- 孤立ページを作らない — すべてのページには少なくとも1つの内部リンクが張られていること
- 説明的なアンカーテキスト — 「私たちのアナリティクス機能」であって「ここをクリック」ではない
- コンテンツ1000語あたり5〜10個の内部リンク(おおよそのガイドライン)
- 重要なページへのリンクを増やす — ホームページ、主要機能ページ、価格
- パンくずリストを使用する — すべてのページに無料の内部リンクを提供
- 関連コンテンツセクション — ページ下部に「関連記事」や「こちらもおすすめ」
ハブアンドスポークモデル
コンテンツ重視のサイトでは、ハブページを中心に整理します:
Hub: /blog/seo-guide (包括的な概要)
├── Spoke: /blog/keyword-research (ハブにリンクバック)
├── Spoke: /blog/on-page-seo (ハブにリンクバック)
├── Spoke: /blog/technical-seo (ハブにリンクバック)
└── Spoke: /blog/link-building (ハブにリンクバック)
各スポークはハブにリンクバックします。ハブはすべてのスポークにリンクします。関連する場合はスポーク同士もリンクします。
リンク監査チェックリスト
- すべてのページに少なくとも1つのインバウンド内部リンクがある
- 壊れた内部リンク(404)がない
- アンカーテキストが説明的である(「ここをクリック」や「続きを読む」ではない)
- 重要なページに最も多くのインバウンド内部リンクがある
- すべてのページにパンくずリストが実装されている
- ブログ投稿に関連コンテンツへのリンクがある
- クロスセクションリンクが機能とケーススタディ、ブログと製品ページを接続している
出力形式
サイトアーキテクチャ計画を作成する際は、以下の成果物を提供してください:
1. ページ階層(ASCIIツリー)
各ノードにURLを含む完全なサイト構造。「ページ階層設計」セクションのASCIIツリー形式を使用します。
2. ビジュアルサイトマップ(Mermaid)
ページ関係とナビゲーションゾーンを示すMermaid図。必要に応じてナビゲーションゾーンにサブグラフを使用した graph TD を使用します。
3. URLマップ表
| ページ | URL | 親 | ナビ配置 | 優先度 |
|---|---|---|---|---|
| ホームページ | / | — | ヘッダー | 高 |
| 機能 | /features | ホームページ | ヘッダー | 高 |
| アナリティクス | /features/analytics | 機能 | ヘッダードロップダウン | 中 |
| 価格 | /pricing | ホームページ | ヘッダー | 高 |
| ブログ | /blog | ホームページ | ヘッダー | 中 |
4. ナビゲーション仕様
- ヘッダーナビ項目(順序付き、CTAを含む)
- フッターセクションとリンク
- サイドバーナビ(該当する場合)
- パンくずリスト実装に関する注記
5. 内部リンク計画
- ハブページとそのスポーク
- クロスセクションリンクの機会
- 孤立ページの監査(再構成の場合)
- 主要ページあたりの推奨リンク数
タスク固有の質問
- これは新しいサイトですか、それとも既存のサイトを再構成していますか?
- サイトのタイプは何ですか?(SaaS、コンテンツ、Eコマース、ドキュメント、ハイブリッド、小規模ビジネス)
- 現在存在する、または計画されているページ数は?
- サイト上で最も重要な5つのページは?
- 保持またはリダイレクトする必要がある既存のURLはありますか?
- 主なターゲットオーディエンスは誰で、彼らはサイトで何を達成しようとしていますか?
関連スキル
- content-strategy: 作成するコンテンツとトピッククラスターの計画用
- programmatic-seo: テンプレートとデータを使用したSEOページの大規模構築用
- seo-audit: テクニカルSEO、オンページ最適化、インデックス問題用
- cro: 個々のページのコンバージョン最適化用
- schema: パンくずリストとサイトナビゲーションの構造化データの実装用
- competitors: 比較ページのフレームワークとURLパターン用