Sitemaps（網站地圖）
網站地圖決定了存在什麼、每個東西在哪裡，以及一個人與它之間有多少決策。選單、URL、範本和重新導向都源自這個決策，因此一個錯誤的樹狀結構會拖累所有下游工作。
你首先需要什麼
| 輸入 | 來源 | 如果遺失 |
|---|---|---|
| 現有結構 | 在程式碼庫中，先讀取路由、導航元件、sitemap.xml、CMS 結構和分類表。永遠不要只從首頁重新設計。 | 要求提供 URL 清單或匯出檔案。如果沒有任何資料可讀，則將樹狀結構標記為空白草稿。 |
| 內容規模，現在和兩年後 | 計算每個區段的項目數量。空的和超載的區段都是發現。 | 要求提供大略數字。如果無法提供，則顯示每種可能的規模所需的形狀。 |
| 受眾和主要任務 | 使用者、分析資料、搜尋記錄、客服經常回答的問題 | 詢問，或在交付物頂端寫下你的假設。 |
| 組織的未來方向 | 使用者 | 詢問。一個模糊的簡報會產出一個通用的樹狀結構。 |
一個內容資料夾：先全面調查整個集合再分組，然後回報這是什麼以及它似乎服務誰，讓使用者可以糾正你。一個資料庫或動態 CMS：先匯出標題、類型、標籤和日期。PDF 和其他二進位檔案：轉換為文字，並說明轉換效果如何。一個非常大的集合：按類型調查，在每種類型內抽樣，並說明你抽樣的內容。
如果你無法獲得任何這些資訊，請說明你需要什麼，並將樹狀結構格式以建議的節點類型交給 references/tree-format.md，以供此類網站使用。
方法
-
繪製現狀。 當前的樹狀結構、每個區段的數量及其問題：重疊、空白、孤立項、任何按部門歸檔的內容。
-
估算規模。 使用兩年後的總量，而非今天的。
項目數 結構 50 以下 扁平，1 到 2 層 50 到 500 2 到 3 層 500 到 5,000 3 到 4 層加上分面 5,000 以上 瀏覽、搜尋和分面相結合 -
根據內容選擇形狀，而不是根據組織圖。
內容 形狀 代價 少數幾個不同的產品，約 50 頁以下 樞紐與輻條： 幾個寬而淺的區段，每個從首頁點擊一次即可到達。行銷網站的預設。 首頁負責所有路由。幾乎沒有成長空間就會需要重新調整。 真正分類性的，例如大型目錄或按行業區分 深度階層 每一層都要花費一次點擊和一點嗅覺線索。一個錯誤的早期猜測會讓人迷失。 大多為淺層，但有一兩個密集區域，例如文件或資料庫 混合型： 上層是樞紐與輻條，在這些區段內是窄階層。較大網站的常見答案。 需要建置和解釋兩種導航模型。 使用者會以多種方式切割的項目，或將超出一個清單範圍的分類 分面： 獨立的維度，可組合成篩選器 每個項目都需要乾淨的中繼資料，並且需要有人維護。 -
起草兩到三個替代方案，沿著不同的軸線（按任務、按受眾、按內容類型）切割，而不是一個想法的三個版本。對於每個方案，說明它服務誰、代價是什麼以及哪裡會緊張。推薦一個並說明原因。單一答案會隱藏決策。
-
給每個項目一個規範的家。 它可以從其他地方連結，但它存在於一個地方，人們期望找到它的地方。兩個家會分散搜尋結果、連結和維護。
一個項目似乎屬於兩個地方 決策 少數真正的跨域項目 一個家，從其他家交叉連結 許多項目屬於多個地方 樹狀結構沿著錯誤的軸線切割。使用分面。 你無法判斷人們會在哪裡尋找 選擇最可能的家，並標記它進行樹狀測試 -
註解每個節點。 每個節點都有一個範本類型；沒有範本的節點通常表示想法尚未完成。標記新的、移動的和棄用的節點。對重複頁面使用模式節點，例如
/guides/<slug>，並在具有這些屬性的節點上放置facets:和items:。 -
壓力測試。 在內容量擴大十倍時，某個區段是否會變成一個沒人能夠瀏覽的清單？現在就設計子區段或分面，而不是之後。這個樹狀結構是否服務於下一個更大的脈絡、圍繞它的產品或業務？是否有任何區段映射到一個部門而不是一個任務？超過 9 個子項或深度超過 4 層需要一個理由，而「三擊規則說這樣做」不是一個理由，因為這個規則是迷思：人們會繼續點擊，而每個步驟都清楚地散發著他們目標的氣味。當深度和廣度有爭議時，或當審查別人的樹狀結構時，請閱讀
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：
- 建議： 兩三句話和主要原因。
- 當前狀況： 現有的樹狀結構及其問題，附帶數量。
- 選項： 每個結構一行，欄位包括：組織依據、服務對象、代價、何時會緊張。
- 提議的樹狀結構： 在程式碼區塊中提供
sitemap-tree.txt的確切文字。 - 放置項目： 項目、家、備註。僅在被問到東西放在哪裡時提供。
- 假設和待解決問題： 所有你猜測的內容，尤其是受眾和方向。
- 如何驗證： 風險最高的放置項目，交給樹狀測試。
根據規模調整。一個 12 頁的網站只需要建議、樹狀結構和一個三行的選項表格。較長的文件並不表示更徹底。要求放置每個項目意味著每個項目都要有一個家：為不適合的項目提供最不差的家，標記它，並分別論述移動、合併或淘汰它的理由。
檢查
node "${CLAUDE_SKILL_DIR}/scripts/tree-check.mjs" sitemap-tree.txt
它會報告每個分支的深度和廣度、重複出現的標籤、沒有範本的節點、其他或雜項節點，以及每個區段的項目數。使用它的結果，而不是你對樹狀結構的解讀。Exit 1 表示警告：修正每個警告，或者在 sitemap.md 中寫一行說明為什麼該例外成立。當樹狀結構沒有計數時，傳遞 --items N。
然後手動檢查：重新計算放置項目的總數，追蹤任何關於路徑長度的主張到樹狀結構中，並確認 sitemap.md 中的程式碼區塊與檔案相符。
Claude 在這裡不能做什麼
- 除非被告知，否則無法知道組織的策略或政治。樹狀結構是一個供人回應的草稿，人類擁有最終決定權。
- 無法編造流量、使用情況或研究。這包括以事實陳述的頻率詞，例如「每天使用」。請說「可能」並將其列為假設。
- 無法對真實使用者進行樹狀測試或卡片分類。可以設計它們，並分析使用者帶回的結果。
- 無法保證 CMS 能做什麼。請說明你的期望，例如巢狀路由或分面篩選，並告訴使用者去確認，因為平台支援的功能各不相同。
此技能的交接點
單獨的網站地圖只是裝飾：沒有 URL 規則、導航規格、內容模型，以及對於重建來說，沒有重新導向計畫，任何人都無法據以建置。
information-architecture（資訊架構）：當工作涵蓋多個此類項目時的大門。content-inventory（內容清單）：當還沒有人知道存在什麼時。card-sort（卡片分類）：當群組分類應來自使用者時。taxonomies（分類法）：當樹狀結構需要設計分面或標籤時。labeling（標籤設計）：用於為節點命名。navigation（導航）、url-structure（URL 結構）和content-models（內容模型）：用於將節點轉化為選單、地址和範本。redirect-maps（重新導向對應）：當任何東西移動時。tree-tests（樹狀測試）：在建置前驗證樹狀結構。findability（可尋性）：在建置後衡量。design-os:create-sitemap：將已同意的樹狀結構寫成連結檔案，供後續設計階段讀取。