サイトマップ
サイトマップは、何が存在するか、各要素がどこに属するか、そしてユーザーがそこに到達するまでにいくつの判断を要するかを決定します。メニュー、URL、テンプレート、リダイレクトはすべてこの決定から導き出されるため、誤ったツリーは下流のすべてに負担をかけます。
最初に必要なもの
| 入力 | 入手先 | 不足している場合 |
|---|---|---|
| 現在の構造 | コードベースがある場合は、まずルート、ナビゲーションコンポーネント、sitemap.xml、CMSスキーマ、カテゴリテーブルを読み取ってください。トップページだけから再設計しないでください。 | URLリストまたはエクスポートを依頼してください。読み取るものが何もない場合は、ツリーを白紙のドラフトとしてラベル付けしてください。 |
| コンテンツサイズ（現在と2年後） | セクションごとのアイテム数を数えてください。空のセクションや過負荷のセクションは発見事項です。 | おおよその数字を依頼してください。それができない場合は、考えられる各サイズがどの形状を必要とするかを示してください。 |
| オーディエンスと主要タスク | ユーザー、アナリティクス、検索ログ、サポートが対応している質問 | 依頼するか、または成果物の先頭にあなたの仮定を書いてください。 |
| 組織の方向性 | ユーザー | 質問してください。一般的な概要は一般的なツリーを生み出します。 |
コンテンツのフォルダがある場合：グループ化する前にセット全体を調査し、それが何であり、誰に役立つかをフィードバックして、ユーザーが修正できるようにしてください。データベースや動的CMSの場合：最初にタイトル、タイプ、タグ、日付をエクスポートしてください。PDFやその他のバイナリの場合：テキストに変換し、変換の品質を報告してください。非常に大規模なセットの場合：タイプごとに調査し、各タイプ内でサンプリングし、何をサンプリングしたかを報告してください。
これらがまったく入手できない場合は、何が必要かを伝え、references/tree-format.mdにあるツリー形式を、この種のサイトに推奨されるノードタイプとともに提供してください。
方法
-
既存のものを描く。 現在のツリー、各セクションのカウント、およびその問題点（重複、空欄、孤立、部門ごとに分類されたもの）を特定します。
-
規模を見積もる。 今日の数ではなく、2年後の総数を使用します。
アイテム数 構造 50未満 フラット、1〜2レベル 50〜500 2〜3レベル 500〜5,000 3〜4レベル＋ファセット 5,000超 ブラウズ、検索、ファセットの組み合わせ -
組織図ではなく、コンテンツから形状を選ぶ。
コンテンツ 形状 コスト 少数の明確なオファー、約50ページ未満 ハブ＆スポーク： 少数の広く浅いセクション。それぞれがホームから1クリック。マーケティングサイトのデフォルト。 ホームがすべてのルーティングを担う。再編成する前に成長する余地はほとんどない。 真にカテゴリカル（大規模なカタログや業界ごとなど） 深い階層 各レベルは1クリックとわずかな手がかりを消費する。初期の誤った推測はユーザーを迷子にする。 ほとんどが浅く、ドキュメントやライブラリなどの1〜2の密集エリアがある ハイブリッド： 上部はハブ＆スポーク、それらのセクション内は狭い階層。大規模サイトの一般的な解決策。 2つのナビゲーションモデルを構築し説明する必要がある。 ユーザーが複数の方法でスライスするアイテム、または1つのリストを超えて成長するカテゴリ ファセット： フィルターとして組み合わせる独立した次元 すべてのアイテムにクリーンなメタデータと、それを維持する担当者が必要。 -
2つまたは3つの代替案を起草する。 1つのアイデアの3つのバージョンではなく、異なる軸（タスク別、オーディエンス別、コンテンツタイプ別）でカットします。それぞれについて、誰に役立つか、コストはいくらか、どこに負担がかかるかを述べます。1つを推奨し、その理由を説明します。単一の回答は意思決定を隠してしまいます。
-
各アイテムに1つの正規のホームを設定する。 他の場所からリンクすることはできますが、人々が期待する1つの場所に存在します。2つのホームは検索結果、リンク、メンテナンスを分割します。
アイテムが2つの場所に属するように見える場合 決定 ごく少数の真のクロスカッター 1つのホーム、他からのクロスリンク 多くのアイテムが複数の場所に属する ツリーが間違った軸でカットされている。ファセットを使用する。 ユーザーがどこを探すか判断できない 最も可能性の高いホームを選び、ツリーテスト用にマークする -
すべてのノードに注釈を付ける。 各ノードにはテンプレートタイプを割り当てます。テンプレートのないノードは、通常、アイデアが完成していないことを意味します。新しいノード、移動されたノード、廃止されたノードをマークします。繰り返しページには
/guides/<slug>などのパターンノードを使用し、facets:とitems:を該当するノードに記述します。 -
ストレステストを実施する。 コンテンツが10倍になった場合、セクションが誰もスキャンできないリストになるでしょうか？ 後ではなく今、サブセクションやファセットを設計してください。ツリーは、その周囲のより大きなコンテキスト（製品やビジネス）に役立っていますか？ どのセクションもタスクではなく部門にマッピングされていませんか？ 1レベルあたり9つ以上、または深さ4を超える場合は理由が必要です。「3クリックルールがそう言っているから」は理由になりません。そのルールは神話であり、各ステップが目標に明確につながっている場合、人々はさらにクリックするからです。深さと幅が議論されている場合、または他人のツリーをレビューする場合は、
references/depth-and-shape.mdを参照してください。
成果物
sitemap-tree.txtを作成します。提案されたツリーのみを含め、それ以外は含めません。チェックがこれを読み取るためです：
/ home
├── /guides section-hub items: 40
│ └── /guides/<slug> guide
├── /products listing items: 120 facets: use, price
│ └── /products/<slug> product
├── /pricing marketing (new)
└── /about marketing (moved from /company)
次に、sitemap.mdを次の順序で作成します：
- 推奨事項： 2〜3文と主な理由。
- 現状： 現在のツリーとその問題点（カウント付き）。
- オプション： 構造ごとに1行、列には「整理基準」「対象」「コスト」「負担がかかるタイミング」を記載。
- 提案ツリー：
sitemap-tree.txtの正確なテキストをコードブロックで。 - 配置： アイテム、ホーム、備考。物がどこに配置されるか尋ねられた場合のみ。
- 前提と未解決の質問： あなたが推測したすべてのこと（特にオーディエンスと方向性）。
- 検証方法： 最もリスクの高い配置をツリーテストに委ねます。
規模に応じて縮小してください。12ページのサイトには、推奨事項、ツリー、および3行のオプションテーブルで十分です。長いドキュメントがより徹底したドキュメントとは限りません。すべてのアイテムを配置するよう要求された場合は、すべてのアイテムにホームを割り当てます。不適切なアイテムには最もマシなホームを与え、フラグを立て、移動、統合、廃止について個別に議論してください。
チェック
node "${CLAUDE_SKILL_DIR}/scripts/tree-check.mjs" sitemap-tree.txt
ブランチごとの深さと幅、2回出現するラベル、テンプレートのないノード、「その他」や「その他」のノード、セクションごとのアイテム数を報告します。ツリーの解釈ではなく、その結果を使用してください。終了コード1は警告を意味します。それぞれを修正するか、sitemap.mdに1行、例外が成立する理由を書いてください。ツリーにカウントがない場合は、--items Nを渡してください。
次に手動で：配置を合計に対して再カウントし、パス長に関する主張をツリーでトレースし、sitemap.mdのコードブロックがファイルと一致することを確認してください。
Claudeがここでできないこと
- 指示がない限り、組織の戦略や政治を知ること。ツリーは反応を引き出すためのドラフトであり、決定権は人間にあります。
- トラフィック、使用状況、調査結果を invent すること。これには「毎日使用される」などの頻度を事実として述べることを含みます。「おそらく」と述べ、それを前提としてリストしてください。
- 実際のユーザーによるツリーテストやカードソートを実行すること。これらを設計し、ユーザーが持ち帰った結果を分析することは可能です。
- CMSの機能を約束すること。ネストされたルートやファセットフィルタリングなど、期待することを述べ、ユーザーに確認するよう伝えてください。プラットフォームのサポートは異なるためです。
引き継ぎ先
サイトマップだけでは装飾に過ぎません。URLルール、ナビゲーション仕様、コンテンツモデル、そしてリビルドの場合はリダイレクト計画がなければ、誰も構築できません。
情報アーキテクチャ：仕事がこれらのいくつかにまたがる場合の玄関口。コンテンツインベントリ：誰も何が存在するか知らない場合。カードソート：グループ化をユーザーから得るべき場合。タクソノミ：ツリーにファセットやタグの設計が必要な場合。ラベリング：ノード名を言葉にするため。ナビゲーション、URL構造、コンテンツモデル：ノードをメニュー、アドレス、テンプレートに変換するため。リダイレクトマップ：何かが移動した場合。ツリーテスト：構築前にツリーを検証するため。ファインダビリティ：構築後に測定するため。design-os:create-sitemap：合意されたツリーを、後の設計段階で読み取るリンクファイルとして書き出すため。