site-architecture

site-architecture 技能總覽

site-architecture 技能的用途

site-architecture 技能可協助你規劃或重整網站的頁面階層、導覽、URL 結構與內部連結。它是為資訊架構（IA）工作而設計，不是用來產生技術性的 XML sitemap。若你真正想解決的是「這個網站應該有哪些頁面、彼此該怎麼串接、使用者應該如何在站內移動」，那這個技能就是正確選擇。

哪些人適合使用 site-architecture

這個 site-architecture 技能特別適合：

• 正在規劃新網站或大幅改版的行銷人員
• 需要定義 SaaS 行銷網站架構的創辦人
• 負責導覽與資訊架構的 UI/UX 團隊
• 要決定內容樞紐、分區與頁面關係、且具 SEO 意識的內容團隊
• 需要快速產出第一版 sitemap、URL map 與 nav spec 的代理商

當網站是一路自然長大，現在變得難逛、前後不一致，或層級過深時，這個技能特別有用。

最適合用 site-architecture 解決的工作

當你需要以下成果時，適合使用 site-architecture：

• 把一份粗略的頁面清單整理成合理的網站地圖
• 判斷應採用扁平還是較深的結構
• 定義 header、footer 與各區塊導覽
• 為 /features、/compare、/integrations 這類區段建立 URL 規則
• 改善 hub 頁與細節頁之間的內部連結
• 產出可供審閱的 ASCII 或 Mermaid 視覺 sitemap

site-architecture 與一般 prompt 的差異

一般 prompt 可能只會列出頁面。site-architecture 更強的地方在於，它會把輸出推向更完整的交付內容：

• 先釐清商業與受眾背景
• 明確設計階層結構
• 提供導覽建議
• 規劃 URL 結構模式
• 提供內部連結指引
• 輸出視覺 sitemap
• 附上常見網站類型可重用的模板

這個 repo 也包含 Mermaid 圖表、導覽模式與網站類型模板等實用參考，因此比起從零開始，輸出通常更一致。

重要的適用範圍界線

這個技能主要不處理：

• XML sitemap 檔案
• 完整 SEO 稽核
• schema markup
• 最終 wireframe 或精緻 UI mockup

若是 site-architecture for UI/UX Design，它最有價值的層次是在結構面：頁面分組、尋路邏輯、導覽區域與內容可發現性，適合放在詳細介面設計之前。

如何使用 site-architecture 技能

安裝方式與使用情境

可透過以下指令從 repository 安裝此技能：

npx skills add https://github.com/coreyhaines31/marketingskills --skill site-architecture

實務上，使用者通常會在需要網站地圖、導覽、頁面階層或 URL 規劃協助時觸發 site-architecture。它最適合用在支援 Skills 的 agent 環境中，讓模型能讀取 skill 檔案並依照既定流程執行。

使用 site-architecture 前，先讀這些檔案

如果你想快速判斷這個技能值不值得用，建議先看：

1. skills/site-architecture/SKILL.md
2. skills/site-architecture/references/site-type-templates.md
3. skills/site-architecture/references/navigation-patterns.md
4. skills/site-architecture/references/mermaid-templates.md
5. skills/site-architecture/evals/evals.json

這個閱讀順序可以讓你先掌握 workflow、常見輸出、具體的導覽選項、圖表格式，以及 evaluations 中「什麼算是好的結果」。

site-architecture 最需要的輸入資訊

只要你提供以下資訊，site-architecture 的表現通常會明顯提升：

• 公司是做什麼的
• 主要受眾是誰
• 網站最重要的目標，通常以 2–3 個為上限
• 這是新網站還是重整案
• 若有，現有頁面 inventory
• 目前痛點，例如內容重複、層級太深、難以找到資訊
• 網站類型，例如 SaaS、ecommerce、services、marketplace，或內容量大的網站

如果缺少這些資訊，模型仍然可以先起草架構，但內容會偏泛，也可能選錯導覽模式。

先確認 product-marketing context

這個 repo 有一個很實用的行為設計：skill 會明確要求 agent 在提問前，先檢查 .agents/product-marketing-context.md 或較舊的 .claude/product-marketing-context.md。這很重要，因為許多架構決策都取決於定位、受眾與產品／方案結構。

如果你已經整理好 product marketing context，請直接告訴模型檔案位置。這能減少重複來回釐清，也能讓頁面分組更準確。

把模糊目標轉成高品質的 site-architecture prompt

較弱的 prompt：

Help me make a sitemap.

較強的 prompt：

Use the site-architecture skill to plan a SaaS marketing site for an analytics product aimed at ecommerce teams. Our goals are demo requests, SEO traffic, and partner integrations. We need a homepage, pricing, feature pages, docs, blog, integrations, and competitor comparison pages. Keep top nav to 5-6 primary items. Propose page hierarchy, URL structure, header/footer nav, and internal linking model.

這樣寫有效，因為它：

• 定義了受眾與商業類型
• 說明了轉換與內容目標
• 列出必備內容類型
• 加入導覽限制
• 直接要求這個技能最擅長產出的具體交付內容

site-architecture 的理想使用方式

建議你依照這個順序要求輸出：

1. 假設與缺漏資訊
2. 建議的階層結構
3. URL map
4. nav spec
5. 內部連結建議
6. ASCII tree 或 Mermaid diagram
7. 取捨點或待確認問題

這個順序剛好貼合技能的實務強項，也能讓你先檢查整體結構，再去討論命名或設計細節。

不要從空白開始，優先用 reference templates

這個技能最容易上手的捷徑就是 reference：

• site-type-templates.md 提供現成的階層模板
• navigation-patterns.md 幫你判斷該用簡單 header、mega menu 或其他 nav 模型
• mermaid-templates.md 可加速建立視覺 sitemap

對多數團隊來說，最佳 workflow 往往是：先挑最接近的網站模板，再調整區段，最後細修導覽與 URL。這通常比自由發揮式 prompting 更快，也更穩。

新網站的建議 workflow

若是從零建立新網站，建議流程如下：

1. 定義商業目標與受眾
2. 挑選最接近的網站類型模板
3. 調整主要區段
4. 設定 URL 慣例
5. 將 header 導覽限制在優先項目
6. 將輔助頁面放到 footer 或區域導覽
7. 視需要加入 hub-and-spoke 內部連結
8. 匯出 ASCII tree 或 Mermaid diagram 供利害關係人審閱

這個方法對 SaaS 尤其有效，因為像 /features、/customers、/resources、/integrations、/compare 這些區段通常都需要清楚切分。

網站重整時的建議 workflow

如果是結構混亂的既有網站，請提供模型以下資訊：

• 目前的 nav
• 頁面數量或 inventory
• 重複的區段
• 流量差或權責不清的頁面
• 使用者抱怨，例如「找不到 docs」或「下拉選單太多」

接著要求它：

• 合併重複區段
• 移除重複入口
• 壓平不必要的層級
• 區分 primary nav 與 utility/footer 項目
• 在可能情況下保留高價值的既有 URL

這也是 site-architecture 比一般腦力激盪 prompt 更有價值的地方：它會把工作框定為「重組網站」，而不只是「列頁面清單」。

給 UI/UX Design 團隊的 site-architecture 用法

對 UI/UX Design 團隊來說，site-architecture 最適合在 wireframe 之前使用，用來釐清：

• 哪些內容應放進 global nav
• 哪些地方需要 section landing page
• breadcrumbs 應如何反映階層
• 哪些頁面值得直接入口，哪些適合間接進入
• 什麼情況下才有必要使用 mega menu

它不會取代互動設計，但能在開始設計元件之前，先提供一個更站得住腳的 IA 基線。

建議要求的實用輸出格式

當你要求以下一種或多種格式時，這個技能通常表現最好：

• 方便快速審閱的 ASCII tree
• 用於文件化的 Mermaid sitemap
• 含優先級的 URL map table
• header/footer nav spec
• 依區段整理的 internal linking model

這些格式都有 repository 內容支撐，因此你的請求會更貼近這個技能原本就擅長處理的輸出。

site-architecture 技能 FAQ

site-architecture 適合初學者嗎？

適合，前提是你已經清楚網站目標與主要內容類型。這個技能能比從零發明 IA 更快地整理出結構。初學者常見的問題通常不是技能太進階，而是提供的背景資訊太少。

什麼時候該用 site-architecture，而不是一般 prompt？

當你需要的是可落地、可審閱的產出時，就該用 site-architecture：例如階層結構、導覽、URL 規則與連結策略。一般 prompt 可以拿來發想頁面，但若你需要能拿去討論的架構成果，這個技能更合適。

site-architecture 會產生 XML sitemaps 嗎？

不會。這個技能用於資訊架構與導覽規劃，不是拿來做 XML sitemap 產生或技術性 crawl 診斷的工具。

site-architecture 只適合新網站嗎？既有網站也有用嗎？

有用。它非常適合網站重整，尤其是當網站頁面過多、分組不一致，或導覽容易讓人混淆時。提供目前現況與痛點，比只描述理想中的未來狀態更重要。

它和人工手動做 IA 相比如何？

人工 IA 仍然很有價值，但這個技能能加速第一版架構產出，並提供可重用模板。它最有幫助的地方在於快速提出方案、攤開取捨，並產出可供團隊審閱的成果。不過，牽涉到組織政治、內容權責與實作限制時，仍需要人類判斷。

site-architecture 適合用在 UI/UX Design 嗎？

適合，尤其是作為前期規劃工具。它能幫 UI/UX Design 團隊在詳細版面設計之前，先定義頁面關係、導覽深度與尋路邏輯；但對於元件層級的設計決策就沒那麼適用。

什麼情況下 site-architecture 不適合？

如果你的真正需求是以下任一項，建議不要用它：

• 技術 SEO 稽核
• schema 規劃
• 內容撰寫
• 高保真頁面 wireframing
• 遠超出行銷網站模式的 app 資訊架構

另外，如果你無法提供基本的商業背景，這個技能的效果也會明顯受限。

如何改善 site-architecture 技能的使用效果

提供更明確的商業限制條件

想要快速提升 site-architecture 輸出品質，最有效的方法就是把限制說清楚：

• 主要轉換動作
• 核心受眾區隔
• header nav 的最大數量
• 必須包含的區段
• 不應放進 main nav 的區段
• 是否以 SEO landing pages 為優先

如果沒有明確限制，模型通常會傾向塞進過多頁面，卻沒有把導覽優先順序排好。

網站重整時提供 page inventory

針對既有網站，請直接貼上粗略的 page inventory 或目前 nav。即使清單很亂也沒關係，這就足以幫助 site-architecture 找出可合併的地方、重複結構，以及原本可能被忽略的孤兒區段。

不要只要一個答案，要它交代取捨

一個很有效的改善方式是這樣問：

Give me a recommended architecture plus one simpler option and one SEO-expansion option.

這能把真正的決策點攤開來，例如：

• 簡單 nav vs 可擴充 nav
• 較少頂層區段 vs 獨立 landing page hubs
• 較扁平的階層 vs 更清楚的分類

這會讓技能在利害關係人對齊時更有用。

用具體交付內容逼出更清楚的輸出

如果第一版輸出太空泛，請直接要求：

• 完整的 ASCII tree
• 精確的 URL patterns
• 含項目數量的 nav labels
• breadcrumbs 範例
• section-level internal links

具體格式能減少空話，讓這份 site-architecture 指引更接近可實作狀態。

site-architecture 常見失敗模式

檢查第一版輸出時，請特別留意以下問題：

• 頂層 nav 項目太多
• 分類名稱彼此重疊
• 內容 hub 與轉換頁混在一起，優先順序不清
• 層級很深，但對使用者沒有明顯好處
• blog/resources/docs 分組不一致
• 加了 SEO landing pages，卻沒有對應的連結規劃

這些都是常見 IA 問題；如果你的 prompt 太寬或太模糊，這個技能也可能做出這些問題。

改善內部連結建議的品質

不要只接受「add internal links」這種程度的建議。請要求模型明確說出：

• 哪些 hub 頁要連到哪些 detail pages
• 哪些 detail pages 要回連 hubs
• 哪些跨區連結合理，例如 features 連到 integrations，或 comparisons 連到 pricing
• 哪些頁面不應做過多 cross-linking

這能讓 site-architecture 從概念層次真正變成可執行方案。

善用 repo references 修正偏弱的初稿

如果輸出看起來太泛，請直接要求模型套用：

• references/navigation-patterns.md 來做 nav 判斷
• references/site-type-templates.md 來補齊 section coverage
• references/mermaid-templates.md 來產出更清楚的 diagrams

這是在不修改技能本身的前提下，提升 site-architecture 結果最簡單的方法之一。

site-architecture 第一版後要再迭代

最佳做法通常是在第一輪架構後追加第二輪 prompt，例如：

Revise this site architecture to reduce header nav to 5 items, move low-priority pages to footer, preserve our existing /blog structure, and create a clearer hub model for integrations and comparison pages.

這類有明確調整方向的修訂，往往才是這個技能真正變得可投入正式工作使用的關鍵。

用真實使用者旅程驗證架構

在正式採用輸出前，請先測試關鍵旅程是否順暢：

• 首次訪客是否能快速理解產品
• 比較型訪客是否能順利到達決策頁
• 從文章進站的 SEO 訪客是否能被導向產品意圖
• 既有客戶是否能快速找到 docs 或 support
• 合作夥伴潛在對象是否能找到 integrations 細節

如果這些旅程走起來很卡，即使 sitemap 看起來很整齊，site-architecture 仍需要再迭代。

透過縮小受眾範圍來改善 site-architecture

受眾過於廣泛，通常會讓架構變得混濁。如果第一版輸出看起來像想同時服務所有人，請把優先級拆開：

• buyer vs user
• SMB vs enterprise
• prospect vs customer
• educational content vs conversion content

當受眾優先順序清楚時，site-architecture 的表現通常會明顯變好，因為導覽與頁面分組也會更容易成立。