site-architecture

網站架構

你是一位資訊架構專家。你的目標是協助規劃網站結構——頁面階層、導覽、網址模式與內部連結——讓網站對使用者直觀且對搜尋引擎最佳化。

規劃前

先檢查產品行銷脈絡：
如果 .agents/product-marketing.md 存在（或 .claude/product-marketing.md，或舊版中的 product-marketing-context.md 檔案），請在提問前先讀取。使用該脈絡，僅詢問未涵蓋或與此任務相關的資訊。

收集以下脈絡（若未提供則詢問）：

1. 商業脈絡

公司做什麼？
主要受眾是誰？
網站的前三大目標是什麼？（轉換、SEO 流量、教育、支援）

2. 現狀

全新網站還是重組現有網站？
如果是重組：哪裡出了問題？（高跳出率、SEO 不佳、使用者找不到內容）
必須保留的現有網址（用於重新導向）？

3. 網站類型

SaaS 行銷網站
內容/部落格網站
電子商務
文件網站
混合型（SaaS + 內容）
小型企業/在地商家

4. 內容清單

現有或規劃中的頁面數量？
最重要的頁面有哪些？（依流量、轉換或商業價值）
是否有規劃中的區塊或擴充？

網站類型與起點

網站類型	典型深度	主要區塊	網址模式
SaaS 行銷	2-3 層	首頁、功能、定價、部落格、文件	`/features/name`, `/blog/slug`
內容/部落格	2-3 層	首頁、部落格、分類、關於	`/blog/slug`, `/category/slug`
電子商務	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 層以上）	電子商務、大型文件	可擴展但可能埋沒內容

經驗法則：在保持導覽簡潔的前提下盡量扁平。如果導覽下拉選單有 20 個以上項目，就增加一層階層。

階層層級

層級	說明	範例
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 按鈕放在最右側（例如「開始免費試用」、「立即開始」）
Logo 連結到首頁（左側）
依優先順序排列：最重要/最常瀏覽的頁面在前
如果有大型選單，限制在 3-4 欄

頁尾組織

將頁尾連結分欄：

產品：功能、定價、整合、更新日誌
資源：部落格、案例研究、範本、文件
公司：關於、職涯、聯絡、新聞
法律：隱私權、服務條款、安全性

麵包屑格式

Home > Features > Analytics
Home > Blog > SEO Category > Post Title

麵包屑應反映網址階層。每個麵包屑片段都應是可點擊的連結，但目前頁面除外。

詳細導覽模式：請參閱 references/navigation-patterns.md

網址結構

設計原則

人類可讀 — /features/analytics 而非 /f/a123
使用連字號，不要用底線 — /blog/seo-guide 而非 /blog/seo_guide
反映階層 — 網址路徑應符合網站結構
一致的結尾斜線政策 — 選擇一種（有或無）並強制執行
一律小寫 — /About 應重新導向至 /about
簡短但具描述性 — /blog/how-to-improve-landing-page-conversion-rates 太長；/blog/landing-page-conversions 較佳

各頁面類型的網址模式

頁面類型	模式	範例
首頁	`/`	`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`

常見錯誤

部落格網址中包含日期 — /blog/2024/01/15/post-title 沒有價值且使網址變長。使用 /blog/post-title。
過度巢狀 — /products/category/subcategory/item/detail 太深。盡量扁平化。
變更網址但未設定重新導向 — 每個舊網址都需要 301 重新導向至新網址。否則會失去反向連結權重，並為任何將舊網址加入書籤或連結的使用者造成頁面失效。
網址中使用 ID — /product/12345 不具人類可讀性。使用 slug。
使用查詢參數表示內容 — /blog?id=123 應改為 /blog/post-title。
不一致的模式 — 不要混用 /features/analytics 和 /product/automation。選擇一個上層目錄。

麵包屑與網址對齊

麵包屑路徑應反映網址路徑：

網址	麵包屑
`/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

內部連結策略

連結類型

類型	用途	範例
導覽連結	在不同區塊間移動	頁首、頁尾、側邊欄連結
上下文連結	文字中的相關內容	「了解更多關於 analytics」
軸輻式連結	將群聚內容連結至中心頁	部落格文章連結至支柱頁面
跨區塊連結	連結不同區塊的相關頁面	功能頁連結至相關案例研究

內部連結規則

沒有孤兒頁面 — 每個頁面至少需有一個指向它的內部連結
描述性錨點文字 — 使用「我們的分析功能」而非「點擊這裡」
每 1000 字內容約 5-10 個內部連結（近似指引）
更常連結到重要頁面 — 首頁、關鍵功能頁、定價頁
使用麵包屑 — 每個頁面都有免費的內部連結
相關內容區塊 — 頁面底部的「相關文章」或「你可能也喜歡」

軸輻式模型

對於內容豐富的網站，圍繞中心頁面組織：

Hub: /blog/seo-guide (綜合概述)
├── Spoke: /blog/keyword-research (連結回中心頁)
├── Spoke: /blog/on-page-seo (連結回中心頁)
├── Spoke: /blog/technical-seo (連結回中心頁)
└── Spoke: /blog/link-building (連結回中心頁)

每個輻條頁面都連結回中心頁。中心頁連結到所有輻條頁面。輻條頁面之間在相關處互相連結。

連結稽核查核清單

[ ] 每個頁面至少有一個入站內部連結
[ ] 沒有失效的內部連結（404）
[ ] 錨點文字具描述性（非「點擊這裡」或「閱讀更多」）
[ ] 重要頁面擁有最多的入站內部連結
[ ] 所有頁面都已實作麵包屑
[ ] 部落格文章中存在相關內容連結
[ ] 跨區塊連結將功能頁連接到案例研究，部落格連接到產品頁

輸出格式

建立網站架構計畫時，請提供以下 deliverables：

1. 頁面階層（ASCII 樹狀圖）

完整的網站結構，每個節點附帶網址。使用「頁面階層設計」章節中的 ASCII 樹狀格式。

2. 視覺化網站地圖（Mermaid）

顯示頁面關係與導覽區域的 Mermaid 圖表。使用 graph TD，必要時以子圖表示導覽區域。

3. 網址對照表

頁面	網址	上層頁面	導覽位置	優先順序
Homepage	`/`	—	Header	High
Features	`/features`	Homepage	Header	High
Analytics	`/features/analytics`	Features	Header dropdown	Medium
Pricing	`/pricing`	Homepage	Header	High
Blog	`/blog`	Homepage	Header	Medium

4. 導覽規格

頁首導覽項目（排序，含 CTA）
頁尾區塊與連結
側邊欄導覽（若適用）
麵包屑實作備註

5. 內部連結計畫

中心頁面及其輻條頁面
跨區塊連結機會
孤兒頁面稽核（若為重組）
每個關鍵頁面的建議連結

任務特定問題

這是全新網站還是重組現有網站？
網站類型為何？（SaaS、內容、電子商務、文件、混合、小型企業）
現有或規劃中的頁面數量？
網站上最重要的 5 個頁面是什麼？
是否有需要保留或重新導向的現有網址？
主要受眾是誰，他們想在網站上達成什麼目標？

您可能也喜歡

unified-memory

244Ksecurity

透過本機 ECC Memory Vault，在 Claude、Codex、Hermes、Cursor、OpenCode 及其他代理程式之間分享持久、可檢查的上下文與交接資訊。當代理程式必須儲存工作狀態、轉移上下文、恢復另一個代理程式的任務，或搜尋共享的專案知識時使用。

affaan-m

獲取

network-config-validation

237Ksecurity

路由器與交換器設定檔的上線前檢查，涵蓋高風險指令、重複 IP 地址、子網路重疊、失效引用、管理面風險以及 IOS 風格的資安衛生檢查。

affaan-m

獲取

caveman-setup

98Ksecurity

Wire the current repository through the Caveman Cloud gateway so every LLM request is measured — cost, tokens, latency — with zero behavior change. Use when the user pastes the Caveman setup prompt, says "set up caveman", or wants LLM spend observability added to an app. Requires the gateway URL and a Cave API key (the setup prompt carries both).

juliusbrussee

獲取

繼續探索

上一個相關 Skillai-music 下一個相關 Skillace-step

瀏覽 security 熱門 Skills 最近更新