公司網站架構應先按客戶搜尋意圖和查詢路徑分層，再決定服務頁、URL、XML Sitemap 和內部連結。小型服務網站可由首頁、服務總覽、個別服務頁、案例、資源、關於我們和聯絡頁開始；Sitemap 協助搜尋引擎發現 URL，但不能取代導覽和內鏈，也不保證收錄。
網站頁面越加越多，客戶卻找不到真正想看的服務；管理員也說不清哪一頁應該連去哪裡。改版時再多加幾個選單，只會令問題更難拆。
LetsGetWeb 編輯團隊整理這份指南時，先把幾個常被混用的概念分開：網站架構（website architecture）、資訊架構（information architecture）、XML Sitemap、HTML Sitemap 和內部連結（internal linking）。混在一起規劃，通常會造成頁面重複、服務分類混亂，或重要頁面變成孤兒頁面。
下文用一個小型香港服務網站的示例，示範頁面層級、服務 cluster、Sitemap 類型和內鏈規則，最後附上改版前的檢查清單。
網站架構、資訊架構、Sitemap 其實有咩分別？
架構圖是策略地圖，Sitemap 只是其中一份機器可讀的交付物。先把這幾個詞分開，後面的規劃才不會亂。
網站架構是頁面和關係
網站架構是整個網站的頁面、層級、導覽、URL 和連結關係，說明哪一頁是父頁、哪一頁是子頁、誰連向誰。資訊架構則是背後的分類邏輯，決定客戶會用甚麼詞語和路徑找到內容。
Google 的 BreadcrumbList 官方說明 提到，Breadcrumb 可協助標示頁面在網站階層中的位置。
XML Sitemap 是提交給搜尋引擎的 URL 清單
XML Sitemap 是向搜尋引擎提供頁面、影片和其他檔案資訊的檔案。根據 Google 的 Sitemap 概覽，它不保證所有 URL 都會被抓取或收錄，所以不能寫成「做了 Sitemap 就會升排名」。
HTML Sitemap 是給使用者和導覽補充的頁面
HTML Sitemap 是使用者看得見的頁面，列出主要頁面連結，作為導覽補充。頁面不多的網站，不必為了 SEO 硬加一頁。
| 概念 | 主要用途 | 限制 |
|---|---|---|
| 網站架構 | 規劃頁面層級、導覽、URL 和連結關係 | 是策略和結構，不是單一檔案 |
| 資訊架構 | 按客戶用語和決策路徑分類內容 | 要先理解客戶真正的問題 |
| XML Sitemap | 向搜尋引擎提供需要處理的 URL | 不保證抓取、收錄或排名 |
| HTML Sitemap | 補充使用者導覽 | 小型網站未必需要 |
小型公司網站應該有幾多層？先畫一份可用 Sitemap
直接答案：沒有適用所有網站的固定層數。以客戶能否經導覽或內鏈到達重要頁面為準，再按內容規模調整；「三層內一定最好」並不是官方規則。
網站 sitemap 規劃的重點，是每一頁都有任務，而不是為了填滿清單而建薄內容頁。
香港 SME 服務網站的示例 Sitemap
以下是編輯設計的假設示例，並非 LetsGetWeb 客戶案例：
每一頁可再補三個欄位：主要意圖、頁面任務和下一步。例如首頁的意圖是了解你做甚麼，任務是分流，下一步是服務總覽或聯絡頁；個別服務頁的意圖是比較方案，任務是講清範圍和流程，下一步是案例、FAQ 或 WhatsApp 查詢。
先分核心服務、支援內容和信任頁
核心服務頁負責承接查詢，支援內容（文章、FAQ）負責回答前期問題，信任頁（案例、關於我們）負責消除疑慮。分好三類，公司網站結構就不會變成一堆平行的選單項目。
XML Sitemap 和 HTML Sitemap 應該點分工？
XML Sitemap 放所有希望出現在搜尋結果的 canonical URL；HTML Sitemap 只放對使用者有用的主要入口。按 Google 的 Sitemap 建立指引，單一 Sitemap 檔案上限為 50,000 個 URL 或 50MB（未壓縮），而且 URL 須使用絕對路徑。
服務頁應該點分類，先唔會搶同一個關鍵字？
服務頁分類要按客戶需要，而不是公司部門圖。客戶搜尋時，不會按你的組織圖思考。
一個主要搜尋意圖對應一個主要 URL
每個主要服務意圖配一個主要 URL；服務總覽頁負責比較和選擇，個別服務頁負責解釋範圍、流程、適用對象、證明和 CTA。「SEO 公司」、「SEO 顧問」和「SEO 審計」不要直接各建一頁，除非它們有不同受眾和交付物。
判斷一頁值不值得獨立存在，可以問五件事：
- 搜尋意圖是否不同？
- 交付範圍是否不同？
- 客戶的決策問題是否不同？
- 能否提供不同的證明或例子？
- 下一步 CTA 是否不同？
大部分答案是「否」，就合併。這是減少意圖重疊和薄內容的方法，並不保證某一頁排第一。
甚麼情況值得建立服務總覽頁？
當你有三項或以上服務，而客戶需要先比較再選擇時，服務總覽頁就有價值。只有一項服務的話，直接用個別服務頁更清楚。
甚麼情況不應建立獨立行業頁或地區頁？
- 不應建立：只是把行業名或地區名換上去，內容、流程和證明幾乎一樣。
- 不應建立：沒有真實案例，也沒有人持續維護。
- 值得建立：該行業有獨立問題、不同交付內容和可核實的證明。
SEO silo structure 適合公司網站嗎？
適合，但要修正理解：silo 是組織原則，不是互相封鎖的牆。把相關內容歸入同一主題，能令服務與實體關係更清楚，但不代表頁面之間不能互連。
用主題 cluster 組織內容，不要把相關頁面鎖死
以 SEO 為一個 service cluster：服務頁是父頁，案例、FAQ 和文章是支援頁。語意上的隔離，和使用者不能跨頁是兩回事。
跨 cluster 的連結只要有上下文就合理，例如網站設計文章提到 SEO 基礎時，連到相關服務頁。Google 的 連結最佳做法文件 強調相關、可抓取和有描述性的連結，並沒有要求頁面互相封閉。
服務頁、案例頁、Blog 和 FAQ 的上下文關係
服務頁連到相關案例、FAQ 和聯絡頁；文章只在內容相關時連回服務頁。每個 cluster 這樣運作，搜尋引擎和 AI 都較容易理解服務之間的關係。
內部連結應該點樣由首頁指向服務頁？
路徑可以這樣走：首頁連到服務總覽或核心服務，服務總覽連到個別服務頁，個別服務頁再連到案例、流程、FAQ 和聯絡頁。每條內部連結都應回答讀者下一個合理問題。
首頁、服務總覽、服務頁和文章頁的連結規則
用內鏈矩陣管理，比憑感覺加連結可靠。以下是示例：
| 來源頁 | 目標頁 | 連結原因 | 錨文字 | CTA 是否重複 |
|---|---|---|---|---|
| 首頁 | 服務總覽 | 讓客戶先比較服務 | 查看全部服務 | 否 |
| 服務總覽 | 個別服務頁 | 進入完整服務說明 | SEO 服務範圍 | 否 |
| 個別服務頁 | 案例或 FAQ | 提供證明和解答疑慮 | 相關案例 | 否 |
| 文章頁 | 相關服務頁 | 讀者已有明確需求 | 服務頁分類方法 | 只放一次 |
錨文字應該描述目標頁面，不要全部寫「了解更多」
錨文字要讓人未點擊就知道去哪裡。Google 建議使用有描述性的錨文字，而且沒有神奇的固定內鏈數量，所以應按內容需要和使用者路徑決定。
如何檢查孤兒頁面和不自然的連結？
Google 建議重要頁面至少由其他站內頁面連入。用爬蟲工具或 CMS 頁面清單，對照 Sitemap 中的 URL，沒有任何內部連結的就是孤兒頁面。同一段文字連到五個意思相近的頁面，亦屬不自然，應合併或刪減。
上線前要檢查 URL、Breadcrumb 和 Google Search Console 甚麼？
分開檢查兩件事：頁面架構是否清楚，以及 Sitemap 檔案是否正確。提交了 Sitemap，並不代表 SEO QA 已完成。
URL、canonical 和 Sitemap 必須指向同一個主要版本
- Sitemap 只放希望出現在搜尋結果的 canonical URL。
- 內部連結、canonical 和 Sitemap 使用同一版本（https、有無 www、結尾斜線）。
- 重要頁面沒有被 noindex 或 robots 設定意外阻擋。
- URL 使用描述性命名，例如示例中的 /services/seo。
- 改版後舊 URL 已檢查 404 和 301。
- Breadcrumb 顯示的階層與實際架構一致。
用 Search Console 檢查 Sitemap 讀取狀態和索引問題
在 Google Search Console 提交 Sitemap 後，可在 Sitemaps 報告說明 所述的報告中，追蹤讀取狀態和錯誤。這只是建議訊號，不代表所有 URL 會立即被收錄。
如果想把這些檢查放進整體 SEO foundation，可參考 SEO 優化服務 的服務範圍。
發佈後如何用資料檢查架構是否真的可用？
上線後每隔一段時間（例如 14、30、60、90 天）檢查四項：Sitemap 讀取狀態、頁面索引問題、非品牌查詢與頁面是否對應，以及服務頁和 WhatsApp 或聯絡頁的點擊。數據不如預期時，先查 noindex、canonical 和孤兒頁面，再考慮重新分類。
網站架構點樣連接到查詢、SEO 和營收？
本文由 LetsGetWeb 發布。品牌服務、方案和功能以官方頁面及正式報價為準；本文示例 Sitemap 並非客戶案例。
LetsGetWeb 的官方定位，是把網站設計、SEO、GEO、AIO 和營收增長諮詢放在同一個整合式數位增長框架內。LetsGetWeb 服務總覽 亦將網站建置、流量獲取和轉化承接排列為連續階段。
LetsGetWeb 可以放在哪一個架構階段？
架構規劃位於設計前策略、SEO foundation 和查詢承接的交界。在 網頁設計服務 開始前先定好頁面關係，設計和內容才有依據。
之後每個核心服務頁都要有清楚的下一步，並配合查詢承接和成效檢查，這部分可與 營收增長諮詢 連接。重點是轉換路徑，而不是頁面數量。
甚麼情況不應只靠重新分類頁面？
以下情況，應先做需求、流程和技術可行性評估，而不是直接做網站架構規劃：
- 需求尚未定義，或服務本身未經驗證。
- 沒有人手承接網站帶來的查詢。
- 涉及複雜 CRM、ERP、會員權限、醫療或金融流程，而未有正式技術規格。
常見問題：公司網站架構、Sitemap 和內部連結
XML Sitemap 同 HTML Sitemap 有咩分別？ XML Sitemap 主要給搜尋引擎處理 URL，HTML Sitemap 是使用者可見的導覽補充，兩者不能互相取代。
小型公司網站一定要有 XML Sitemap 嗎？ 不一定。若頁面少而且重要頁面都有內部連結，需要程度較低；仍應按網站規模和更新方式判斷。
公司網站應該有幾多層？ 沒有固定層數。以使用者和搜尋引擎能否輕易到達重要頁面為準。
服務總覽頁和個別服務頁是否都需要？ 兩者可並存：總覽頁負責比較和選擇，個別服務頁有獨立意圖和完整交付內容。
服務頁分類應按公司部門還是客戶需要？ 應按客戶搜尋意圖和決策路徑，再映射到內部團隊。
SEO silo structure 是否代表相關頁面不能互相連結？ 不是。Silo 是內容組織模型，相關頁面仍應自然互連。
內部連結幾多條先夠？ 沒有固定理想數量，應按頁面內容和使用者下一步決定。
Sitemap 提交後是否一定會收錄？ 不一定。Sitemap 協助 Google 發現和處理 URL，不保證抓取、收錄或排名。
改版時應否重新設計所有 URL？ 不應。先評估現有流量、外部連結、索引狀態和轉址成本。
HTML Sitemap 對 SEO 有沒有必然好處？ 沒有必然好處。只在改善導覽或大型網站管理時才加入。
最後決策：用一張頁面關係表開始網站規劃
- 列出業務服務和對應的搜尋意圖。
- 為每個主要意圖指定一個主要 URL。
- 畫出首頁、服務頁、支援內容和 CTA 的連結關係。
- 上線前檢查 canonical、Sitemap、Search Console 和孤兒頁面。
先整理現有 Sitemap、頁面清單或改版需求，再 預約網站架構諮詢，讓團隊檢視服務分類、內部連結和 SEO foundation。