網站架構 SEO 是什麼?為什麼會影響排名?
網站架構 SEO 是把分類、導覽、URL、內部連結與索引控制規劃成搜尋引擎和使用者都能理解的結構;SEO 友善的網站架構,會讓重要頁面更容易被發現、理解與使用。
網站架構不只是選單怎麼排。實務上,網站架構問題通常不是單一頁面可以解決,而是分類、內鏈、索引與內容角色一起造成的結果。當搜尋引擎看不懂頁面之間的關係,重要頁面就可能被埋在深層、被重複頁稀釋,或沒有足夠內部連結支援。
- 對搜尋引擎:影響爬取、索引、主題理解與頁面重要性判斷。
- 對使用者:影響找資料、比較方案、進入表單或購買頁的效率。
- 對網站經營:影響未來新增分類、文章、服務頁時是否容易擴充。
網站架構包含哪些元素?
網站架構包含首頁、分類頁、服務頁、商品頁、文章頁、導覽列、Footer、麵包屑、URL 規則、XML sitemap 與內部連結。這些元素一起決定網站的層級、主題與動線。
導覽列、分類頁、內容頁、商業頁、Footer、麵包屑、XML sitemap、URL 規則
導覽列通常放最重要的入口,分類頁負責整理同一主題或同一類產品,內容頁負責回答問題,商業頁負責承接轉換。Footer 適合放輔助入口,例如公司資訊、政策頁、重要分類與聯絡方式;麵包屑則協助使用者與搜尋引擎理解目前頁面在網站中的位置。
XML sitemap 不是排名保證,而是協助搜尋引擎發現可索引頁面的清單。URL 規則則要穩定、可讀、層級一致,避免改版後新舊網址混用。
網站架構如何影響 Google 理解網站?
Google 會透過連結、頁面內容、URL、麵包屑、sitemap 與 canonical 等訊號判斷頁面關係。當重要頁面有清楚入口、相關頁面互相支援,搜尋引擎比較容易理解網站主題與代表頁。
主題關係、頁面重要性、內部連結訊號、點擊深度
如果一個服務頁從首頁、主導覽、相關案例與文章都有連結,它通常比藏在五層分類底下的頁面更容易被視為重要頁面。點擊深度越深,不代表一定無法排名,但越容易出現爬取不足、權重不足與使用者找不到的問題。
網站架構如何影響使用者動線?
好的網站架構會讓使用者知道自己在哪裡、下一步能去哪裡,以及哪個頁面能解決他的問題。這會直接影響停留、比較、詢問與購買行為。
找資訊、比較方案、進入表單或購買頁
例如 B2B 網站不能只有知識文章,還要讓使用者能從文章進入服務頁、案例頁與聯絡頁。電商網站也不能只堆商品頁,分類、篩選、品牌頁與商品頁之間要能支援比較與決策。
SEO 友善網站架構的 6 個核心原則
SEO 友善網站架構的核心,是讓重要頁面容易抵達、分類語意清楚、URL 穩定、導覽可理解、內部連結有目的,並讓搜尋引擎能順利爬取與索引。
重要頁面最好在 3 到 5 次點擊內抵達
原因是重要頁面如果離首頁太遠,搜尋引擎與使用者都更不容易發現。做法是把核心服務頁、主要分類頁、支柱頁放在主導覽、首頁模組或重要分類入口中。
常見錯誤是網站新增很多頁面後,沒有重新整理導覽與分類,導致高價值頁面只能靠站內搜尋或舊文章連到。Kevin Lin 的實務觀察是,很多網站不是內容不夠,而是好頁面被藏得太深。
分類名稱要符合使用者與搜尋引擎都能理解的語意
分類名稱應該描述內容或服務本身,而不是只有內部團隊看得懂的代號。像「解決方案」、「資源中心」可以存在,但底下仍要有清楚的服務、產業、主題或產品分類。
常見錯誤是把分類做得太抽象,例如全部放在「知識專區」底下,卻沒有區分教學、案例、FAQ、工具或產業情境。這會讓網站主題關係變模糊。
導覽列與 Footer 要分工,不要塞滿所有頁面
導覽列應該放核心入口,Footer 則放輔助資訊與次要入口。主導覽塞太多項目,使用者反而更難判斷重點,搜尋引擎也不容易看出頁面優先級。
做法是把首頁、主要服務、產品分類、主題中心、案例、關於與聯絡放在明顯位置,政策頁、次要分類、社群連結與補充資訊放在 Footer。常見錯誤是把所有文章分類、活動頁、標籤頁都塞進導覽。
麵包屑要反映真實層級,而不是只為了放 schema
麵包屑應該呈現使用者所在頁面的實際層級,例如首頁、主題中心、分類、文章。它可以輔助搜尋引擎理解結構,但前提是層級本身合理。
常見錯誤是頁面明明屬於某個服務或分類,麵包屑卻只顯示首頁與文章,或 schema 標記和畫面上的層級不一致。schema 是輔助說明,不應該拿來包裝混亂的架構。
URL 要短、穩定、可讀、規則一致
URL 結構應該讓人看得出頁面類型與主題,例如 /articles/site-structure-seo 比一串參數或日期更容易理解。穩定比花俏更重要,尤其是已經有排名與外部引用的頁面。
常見錯誤是改版時大量更改 URL,卻沒有做好 301 redirect、canonical 與內鏈更新。URL 一旦對 SEO 有歷史價值,就不該因為視覺改版隨意變動。
內部連結要支援重要頁面,不是隨機互連
內部連結的目的,是讓頁面之間的主題關係與重要性更清楚。首頁、分類頁、支柱頁、文章頁與商業頁都應該有不同連結任務。
常見錯誤是每篇文章都塞同樣的熱門文章連結,或全部用「看更多」、「點這裡」當錨文字。內鏈應該優先連到真正能補充脈絡或承接下一步的頁面。
不同網站類型,網站架構 SEO 應該怎麼規劃?
不同網站類型需要不同的網站架構 SEO 規劃;電商重視分類與篩選,B2B 重視服務與案例,內容站重視主題中心,在地服務重視地區意圖與信任資訊。
| 網站類型 | 核心架構 | SEO 重點 | 常見錯誤 |
|---|---|---|---|
| 電商網站 | 首頁 > 商品分類 > 子分類 > 商品頁 / 品牌頁 | 分類頁、篩選頁、canonical、庫存頁管理 | 讓篩選參數頁大量進索引 |
| B2B 服務網站 | 首頁 > 服務頁 > 產業頁 > 案例 / FAQ / 文章 | 服務頁與案例頁互相支援 | 只有文章,沒有能轉換的服務頁 |
| 在地服務網站 | 首頁 > 服務項目 > 地區頁 > 案例 / 評價 | 地區意圖、服務範圍、信任資訊 | 複製大量低差異地區頁 |
| 內容型網站 | 首頁 > 主題中心頁 > 分類頁 > 支援文章 | Topic Cluster、內鏈、內容盤點 | 標籤頁失控、孤兒文章太多 |
| 課程 / 顧問網站 | 首頁 > 解決方案 > 課程 / 顧問服務 > 成果 / FAQ | 決策內容、信任證明、轉換路徑 | 內容很多但使用者不知道下一步 |
電商網站要特別管理分類、篩選與商品頁
電商網站的 SEO 架構重點通常不在商品頁數量,而在分類頁、子分類、篩選頁與代表頁管理。分類頁要能承接搜尋需求,篩選頁則要判斷是否有獨立搜尋價值。
例如「男款慢跑鞋」可能值得有可索引分類頁,但「尺寸 27.5、黑色、折扣排序」這類參數頁不一定適合進索引。處理方向要看搜尋需求、頁面內容差異與庫存穩定性。
B2B 網站要讓服務頁、產業頁與案例頁互相支援
B2B 網站常見問題是文章很多,服務頁卻很弱。正確架構應該讓服務頁說明解決方案,產業頁對應情境,案例頁提供信任證明,文章頁補足搜尋問題。
如果只有知識文章吸引流量,卻沒有清楚的服務頁與案例頁承接,使用者看完後很難判斷下一步。SEO 流量不等於有效轉換,架構要把資訊需求與商業決策接起來。
內容站要用主題中心頁管理文章,而不是只靠分類頁
內容型網站如果只靠分類頁,很容易變成文章列表。主題中心頁應該整理某個大主題下的核心概念、重要文章、進階內容與相關問題。
例如「網站架構 SEO」可以有中心頁,底下再連到 URL 結構、內部連結、canonical、文章更新與網站改版 SEO 等支援內容。這比單純把文章放在「SEO 教學」分類中更清楚。
在地服務網站要避免大量低差異地區頁
在地服務網站可以做地區頁,但不應該大量複製只換地名的頁面。地區頁要有真實服務範圍、案例、評價、交通或服務流程等差異內容。
如果每個地區頁內容幾乎相同,搜尋引擎可能把它們視為薄內容或重複內容。更好的做法是先建立核心服務頁,再針對真的有需求與服務能力的地區製作頁面。
如何用 Topic Cluster 規劃網站架構,而不是只排選單?
Topic Cluster 是用中心頁與支援頁組織主題關係,讓網站架構從選單層級升級為語意網絡;它能幫助搜尋引擎判斷網站對某個主題的完整度。
先定義中心頁,再安排支援頁
中心頁負責回答大問題,支援頁負責回答子問題。中心頁不一定是首頁,也不一定是分類頁,它應該是某個主題最能代表網站觀點與內容深度的頁面。
中心頁回答大問題,支援頁回答子問題
| 頁面角色 | 以網站架構 SEO 為例 | 任務 |
|---|---|---|
| 中心頁 | 網站架構 SEO 完整指南 | 整理定義、原則、檢查、改版與內鏈策略 |
| 支援頁 | URL 結構 SEO | 回答網址規則與改版風險 |
| 支援頁 | 內部連結與錨文字 | 回答頁面如何互相支援 |
| 支援頁 | canonical 標籤教學 | 處理重複內容與代表頁 |
| 商業頁 | SEO 顧問或網站健檢服務頁 | 承接需要專業協助的使用者 |
分類頁、支柱頁、文章頁、服務頁要有不同任務
分類頁負責整理入口,支柱頁負責完整回答主題,文章頁負責處理細分問題,服務頁負責說明解決方案與轉換。這些頁面不該全部寫成同一種內容。
不要讓多個頁面競爭同一個搜尋意圖
如果分類頁、支柱頁與文章頁都想排名「網站架構 SEO」,就容易產生內部競爭。比較好的安排是讓一個代表頁主攻核心詞,其他頁面支援子問題並用內鏈回到代表頁。
內部連結要把語意相近的頁面連成群組
Topic Cluster 的關鍵不是文章彼此隨便互連,而是把語意接近、搜尋意圖相連、決策路徑相關的頁面接起來。這能讓搜尋引擎看出主題範圍,也能讓使用者沿著問題往下讀。
錨文字要描述目的頁,不要全部寫「點我看更多」
錨文字應該讓使用者知道點過去會看到什麼。例如要連到錨文字教學,可以用 錨文字 SEO,不要只寫「點我看更多」。自然描述目的頁,通常比刻意堆關鍵字更穩定。
網站架構 SEO 的內部連結優先級怎麼排?
網站架構 SEO 的內部連結優先級,應先支援核心商業頁,再支援分類與支柱頁,接著讓文章頁補足主題關係,最後清理孤兒頁與深層頁面。
第一優先:首頁與主導覽連到核心商業頁
首頁與主導覽是最強的入口之一,應該優先連到主要服務、主要產品分類、核心解決方案或高價值轉換頁。這些頁面通常和營收、詢問、購買或報名直接相關。
常見錯誤是主導覽放了很多品牌口號、活動頁或次要文章,核心服務頁反而要從多層選單才找得到。這會讓使用者與搜尋引擎都難以判斷網站重點。
第二優先:分類頁連到最重要的支柱頁與子分類
分類頁不應該只是文章列表,它應該把同一主題底下的重要支柱頁、子分類與精選內容整理出來。這對內容站、電商與大型服務網站特別重要。
例如 SEO 分類頁可以優先連到網站架構 SEO、技術 SEO、內容更新、內部連結、canonical 等支柱頁,再讓使用者進入更細的文章。
第三優先:文章頁連到相關支援文與轉換頁
文章頁的內鏈要看使用者當下需求。如果使用者還在學概念,可以連到支援文;如果問題已經接近決策,可以連到服務頁、案例頁、工具頁或 FAQ。
例如一篇談網站架構的文章,可以連到 H1 與 H2 標題架構、canonical 標籤、Core Web Vitals 等相關主題,但每個連結都要有脈絡。
第四優先:找出孤兒頁與深層頁面
孤兒頁是沒有被其他頁面連到,或只有很少入口的頁面。深層頁面則是需要點很多次才到達的頁面。兩者都可能造成爬取與使用者發現問題。
可以用爬蟲工具、GSC、sitemap 與網站後台清單交叉比對,找出有價值但缺少內鏈的頁面。不是每個孤兒頁都要救,重點是先處理有排名、有曝光、有轉換價值或主題必要性的頁面。
錨文字要自然描述頁面主題
錨文字要描述目的頁,而不是把所有關鍵字硬塞進同一句。自然、清楚、符合上下文的錨文字,更能同時服務使用者與搜尋引擎。
可內鏈到已發布文章:anchor-text-seo
需要進一步整理錨文字策略時,可以連到 錨文字 SEO。在網站架構中,錨文字不是裝飾文字,而是頁面關係的語意訊號。
網站架構 SEO 檢查清單:規劃前後都要確認的 12 個項目
網站架構 SEO 檢查清單應同時驗收 URL、轉址、canonical、robots、sitemap、麵包屑、標題階層、手機導覽、速度與結構化資料,避免規劃正確但上線失控。
| 檢查項目 | 要確認什麼 | 常見問題 |
|---|---|---|
| URL 規則 | 是否短、穩定、可讀、層級一致 | 改版後新舊網址混用 |
| 301 redirect | 舊 URL 是否正確導到新 URL | 大量導到首頁 |
| canonical | 重複頁是否指向代表頁 | canonical 指到錯頁 |
| robots.txt | 是否阻擋不該擋的路徑 | 阻擋 CSS、JS 或重要分類 |
| meta robots | noindex 是否只用在必要頁 | 重要頁被 noindex |
| XML sitemap | 是否只放可索引重要頁 | sitemap 放入 404、noindex 頁 |
| HTML sitemap | 使用者與爬蟲是否能找到重要分類 | 只做 XML,沒有使用者入口 |
| 麵包屑 | 是否反映真實層級 | 層級和 URL / 導覽不一致 |
| H1-H3 | 頁面內容架構是否清楚 | 多個 H1、標題跳層 |
| RWD | 手機版導覽是否完整 | 桌機有連結,手機版消失 |
| 速度 / Core Web Vitals | 重要頁是否載入過慢 | 圖片、外掛、JS 太重 |
| 結構化資料 | 是否反映頁面主內容 | schema 與實際內容不符 |
哪些問題要找工程師,哪些問題靠內容優化?
轉址、canonical、robots.txt、sitemap、速度、RWD、JavaScript 渲染通常需要工程或網站管理者協助;分類命名、內部連結、標題階層、內容合併與主題中心則多半可以由 SEO 或內容團隊先處理。
實務上最容易卡住的是責任邊界不清。建議先把問題分成索引控制、網站模板、內容架構與內鏈調整四類,再決定由誰處理。
頁面內容架構:Title、H1、H2 如何支援網站架構
Title、H1、H2 應該反映頁面在網站中的任務。服務頁要清楚說明服務,分類頁要說明分類範圍,文章頁要回答明確問題,支柱頁要承接完整主題。
可內鏈到已發布文章:h1-heading-structure
標題階層需要獨立檢查時,可以參考 H1 與 H2 標題架構。網站架構清楚,但頁面標題混亂,搜尋引擎仍可能難以判斷頁面重點。
canonical、robots、sitemap 是網站架構的索引控制層
canonical 用來協助指定代表頁,robots.txt 用來管理爬取,meta robots 用來控制索引,XML sitemap 則協助搜尋引擎發現重要可索引頁。這些不是獨立技術項目,而是網站架構的索引控制層。
可內鏈到已發布文章:canonical-tag
重複內容、篩選頁或參數網址較多的網站,建議延伸閱讀 canonical 標籤。canonical 設錯時,可能讓真正該排名的頁面失去代表性。
改版或重整網站架構時,怎麼避免 SEO 流量下滑?
網站改版 SEO 的核心,是在改版前盤點重要頁面,建立 URL 對照,上線時同步轉址、canonical、內鏈與 sitemap,上線後用 GSC 監控索引與流量變化。
| 階段 | 要做的事 | 主要風險 | 驗收方式 |
|---|---|---|---|
| 改版前 | 盤點高流量頁、轉換頁、有排名頁 | 漏掉重要舊頁 | 比對 GSC、GA4、後台頁面清單 |
| 改版前 | 建立舊 URL 到新 URL 對照表 | 新舊頁面不對應 | 每個舊 URL 都有處理方式 |
| 上線時 | 確認 301、canonical、內鏈、sitemap | 轉址錯誤、代表頁錯亂 | 抽查重要頁與批次爬取 |
| 上線後 | 用 GSC 追蹤索引、點擊、曝光、錯誤頁 | 問題延後才發現 | 持續追蹤重要頁與錯誤報告 |
改版前:盤點高流量頁、轉換頁與有排名頁
改版前要先知道哪些頁面不能出錯。高流量頁、有詢問或購買的頁面、有自然搜尋曝光的頁面、被外部引用的頁面,都應該列入重點清單。
不要只看網站後台頁面列表,因為後台看不到搜尋價值。GSC 可以看曝光與點擊,GA4 可以看互動與轉換,兩者一起看會比較完整。
改版前:建立舊 URL 到新 URL 的對照表
URL 對照表要列出每個舊網址的新去向。最理想是舊頁導到內容最接近的新頁,而不是全部導回首頁。
如果某些舊頁沒有新版本,要判斷是否合併到相關頁、保留舊頁、重寫內容,或回傳合理的 404 / 410。這一步做得細,改版後的流量波動通常比較可控。
上線時:確認 301、canonical、內鏈、sitemap 同步更新
上線當天要檢查 301 是否正確、canonical 是否指向新代表頁、內部連結是否改成新 URL、XML sitemap 是否只放可索引新頁。
很多改版掉流量不是因為設計變了,而是舊 URL 沒轉好、內鏈還指向舊頁、sitemap 放了錯頁,或 canonical 還停在測試環境。這些問題都應該在上線前後批次檢查。
上線後:用 GSC 監控索引、點擊、曝光與錯誤頁
改版後自然搜尋可能有短期波動,但不應該放著不管。要用 GSC 觀察索引狀態、404、重新導向、曝光、點擊與主要查詢變化。
如果重要頁曝光突然消失,應先檢查是否 noindex、canonical 指錯、robots 阻擋、轉址錯誤或頁面內容大幅改變。不要只用「Google 還在重新認識網站」帶過。
不要把所有舊頁都導回首頁
大量把舊頁導回首頁,通常不是好的 SEO 改版策略。搜尋引擎與使用者期待的是相近內容,而不是被送到一個需要重新找路的入口頁。
舊文章應導到最相關的新文章,舊服務頁應導到對應服務頁,舊分類頁應導到對應分類或上層分類。只有真的沒有相近替代頁時,才考慮其他處理方式。
大型網站常見的網站架構 SEO 問題
大型網站的網站架構 SEO 風險,常來自篩選頁、標籤頁、站內搜尋頁、分頁與重複 URL;判斷核心是哪些頁面值得索引,哪些頁面只該輔助使用者。
| 問題 | 風險 | 處理方向 |
|---|---|---|
| 篩選頁與參數網址 | 產生大量重複或低價值 URL | 判斷搜尋需求,必要時用 canonical、noindex 或爬取控制 |
| 標籤頁過多 | 薄內容、主題稀釋、孤兒頁增加 | 合併重複標籤,保留有搜尋價值的標籤頁 |
| 站內搜尋結果頁 | 索引膨脹與品質不穩 | 多數情境避免大量索引 |
| 分頁、排序、篩選混用 | 代表頁混亂,canonical 難管理 | 制定清楚規則並批次驗收 |
| 孤兒頁 | 搜尋引擎與使用者難以發現 | 用內鏈、分類或主題中心重新納入架構 |
篩選頁與參數網址不一定都該被索引
篩選頁是否該索引,要看它是否有明確搜尋需求、內容是否獨立、商品或資料是否穩定。不是所有篩選頁都該 noindex,也不是所有篩選頁都該開放索引。
電商常見的 faceted navigation 會產生大量組合網址,如果沒有規則,很容易讓搜尋引擎把爬取資源花在低價值頁面上。
標籤頁太多會製造薄內容與主題稀釋
標籤頁如果沒有管理,常會變成只有一兩篇文章的薄內容頁。大量近似標籤也會讓網站主題變得分散。
建議定期檢查標籤頁是否有搜尋價值、文章數量是否足夠、是否和分類頁或主題中心重複。沒有價值的標籤頁可以合併、noindex 或移除入口。
站內搜尋結果頁通常不適合大量進索引
站內搜尋結果頁內容變動大,品質不穩,也容易產生大量低價值 URL。多數網站不適合讓所有站內搜尋結果頁進索引。
如果某些搜尋結果本身有穩定需求,通常更好的做法是建立正式分類頁、主題頁或集合頁,而不是依賴站內搜尋結果頁排名。
分頁、排序、篩選要避免產生代表頁混亂
分頁、排序與篩選混在一起時,canonical、索引與內鏈規則要非常清楚。否則搜尋引擎可能不確定哪個頁面是代表頁。
處理時要先定義主要分類頁,再決定排序頁、分頁、篩選頁與參數頁的索引規則。大型網站最怕規則一半靠模板、一半靠人工,最後批次產生錯誤。
網站架構不是一次性規劃:如何用 GSC 數據持續調整?
網站架構需要用 GSC 持續調整;透過曝光、點擊、CTR、排名與索引狀態,可以判斷頁面該保留、合併、刪除、重寫或增加內部連結。
用曝光與點擊找出有潛力但連結不足的頁面
如果某些頁面有曝光但點擊低,可能需要調整 Title、描述或搜尋意圖對齊;如果有排名與曝光但內鏈很少,可能代表頁面有潛力但架構支援不足。
這類頁面適合優先從相關分類頁、支柱頁或高流量文章補內部連結。先處理已有搜尋訊號的頁面,通常比盲目新增文章更有效率。
用內容盤點決定保留、合併、刪除或重寫
內容盤點不是只看流量高低,而是看頁面是否仍有搜尋需求、是否有轉換價值、是否和其他頁面重複、是否能支援主題群。
可內鏈到已發布文章:article-update-seo
需要建立更新流程時,可以延伸閱讀 文章更新 SEO。內容更新和網站架構是同一個循環,因為保留、合併、刪除或重寫都會改變頁面關係。
成效好的頁面要鞏固排名,成效差的頁面要找原因
成效好的頁面可以補充新段落、更新資料、增加相關內鏈,讓它繼續支援主題群。成效差的頁面則要先判斷問題來自內容、搜尋意圖、內鏈、索引還是競爭強度。
Kevin Lin 常用的判斷方式是先問三件事:這頁是否有明確任務、是否有上層或相關頁支援、是否和其他頁搶同一個意圖。答案不清楚時,通常就是架構需要調整。
不要把剛上線沒效果直接歸因於網站架構錯誤
新頁面剛上線沒有成效,不一定是網站架構錯誤。可能是索引還沒穩定、內容品質不足、關鍵字競爭太強,或頁面需要更多內部連結與時間累積。
比較合理的做法是先確認頁面可被爬取與索引,再觀察曝光、排名與查詢,再決定是否調整內容或內鏈。不要在沒有數據前頻繁改 URL 或刪頁。
網站架構 SEO 規劃範例:從首頁到文章頁怎麼排?
網站架構 SEO 可以用文字樹狀圖先規劃首頁、服務頁、分類頁、支柱頁、文章頁、FAQ 與聯絡頁的關係,再決定導覽、內鏈與索引規則。
B2B 服務網站範例
首頁
服務項目
SEO 顧問服務
技術 SEO 健檢
內容 SEO 規劃
產業解決方案
電商 SEO
B2B SEO
在地服務 SEO
案例
產業案例
成效案例
資源中心
網站架構 SEO
內部連結
canonical 標籤
文章更新 SEO
FAQ
聯絡頁
這種架構的重點是讓服務頁、產業頁、案例頁與文章頁互相支援。文章負責回答問題,服務頁負責承接需求,案例頁負責補信任。
內容型網站範例
首頁
主題中心
SEO 基礎
搜尋引擎如何運作
Google 排名因素
網站架構 SEO
URL 結構
內部連結
麵包屑
canonical
內容更新
文章盤點
合併與重寫
工具與模板
關於作者
聯絡頁
內容型網站要避免所有文章平均鋪開。主題中心頁要承接主題,分類頁整理入口,文章頁回答子問題,內鏈再把相關頁面串成群組。
電商網站範例
首頁
商品分類
跑鞋
男款跑鞋
女款跑鞋
越野跑鞋
運動服飾
上衣
短褲
外套
品牌頁
尺寸指南
購物 FAQ
部落格
跑鞋挑選
運動保養
會員與客服
電商網站要先定義哪些分類與篩選有搜尋價值。商品頁負責商品資訊,分類頁負責承接品類搜尋,指南與部落格則支援比較與購買前問題。
網站架構 SEO 常見錯誤與快速修正方式
常見網站架構 SEO 錯誤包括重要頁面藏太深、分類名稱混亂、缺少主題中心、URL 隨意變動、孤兒頁太多與重複內容失控;修正時要先處理高價值頁面。
| 錯誤 | 影響 | 快速修正方式 |
|---|---|---|
| 重要頁面藏太深 | 爬取不足,使用者找不到 | 從首頁、主導覽、分類頁或支柱頁增加入口 |
| 分類名稱只給內部人看得懂 | 主題語意不清,使用者判斷困難 | 改成符合搜尋意圖與使用者語言的分類 |
| 文章很多但沒有主題中心頁 | 內容分散,主題權威不集中 | 建立支柱頁與主題中心,整理相關文章 |
| 新舊 URL 混用或隨意改網址 | 排名訊號分散,轉址與索引混亂 | 統一 URL 規則,補 301、canonical 與內鏈更新 |
| 網站有很多頁,但搜尋引擎找不到重要頁 | 重要頁曝光不足,孤兒頁增加 | 比對 sitemap、爬蟲資料與內鏈,補上入口 |
重要頁面藏太深
如果核心服務頁、主要分類頁或高價值文章需要點很多次才到,應該優先改善入口。可以從主導覽、首頁區塊、相關文章、分類頁與 Footer 補連結。
分類名稱只給內部人看得懂
分類名稱應該以使用者能理解的詞為主。內部部門名稱、專案代號或太抽象的品牌詞,不適合直接當作主要分類。
文章很多但沒有主題中心頁
文章數量多不代表網站架構好。如果文章彼此沒有共同中心頁,搜尋引擎可能只看到一堆零散內容,而不是完整主題覆蓋。
新舊 URL 混用或隨意改網址
URL 變動要有理由,也要有配套。改 URL 前先確認原頁是否有排名、流量、外部連結或轉換價值,改完後要同步 301、canonical、內鏈與 sitemap。
網站有很多頁,但搜尋引擎找不到重要頁
如果重要頁沒有內部連結、沒有放入 sitemap,或被 robots / noindex 擋住,搜尋引擎就可能找不到或不索引。頁面存在不等於頁面可被發現。
哪些內容不該混進網站架構 SEO 主體?
網站架構 SEO 應聚焦分類、頁面層級、導覽、URL、內部連結、索引控制與改版風險;完整 SEO 入門、廣告投放、網站設計公司比較與程式碼教學不應混進主體。
SEO 入門、關鍵字工具教學、網站設計公司比較、程式碼教學
這些主題可能和網站經營有關,但會稀釋搜尋意圖。讀者搜尋網站架構 SEO 時,通常要的是規劃方法、檢查清單、改版控管與內鏈優先級,不是重新學完整 SEO 或比較設計公司。
比較好的做法是只在必要段落短暫提到工具或相關概念,並把深入內容交給獨立文章。例如 GSC 用於監控,不需要展開完整操作教學;JavaScript 會影響渲染,但不需要寫成完整 JavaScript SEO 技術文。
網站架構 SEO 常見問題
網站架構 SEO 的常見問題,多半圍繞扁平化、URL 變更、sitemap、麵包屑、JavaScript、篩選頁、內部連結與改版風險;回答時要回到頁面角色與索引價值。
網站架構 SEO 是什麼?
網站架構 SEO 是把網站分類、頁面層級、導覽、URL、內部連結與索引控制規劃成搜尋引擎和使用者都能理解的結構。它會影響爬取、索引、頁面重要性、主題關係與使用者動線。
SEO 友善的網站架構一定要扁平化嗎?
不一定要極度扁平,但重要頁面不應該藏太深。SEO 友善網站架構的重點是層級清楚、重要頁面容易抵達、分類語意明確,而不是把所有頁面都硬放在同一層。
重要頁面一定要在 3 次點擊內到達嗎?
3 次點擊是常見參考,不是絕對規則。中小型網站的核心頁面最好在 3 到 5 次點擊內抵達;大型網站則要確保重要分類、支柱頁與商業頁有足夠入口與內部連結支援。
網站架構調整後多久會看到 SEO 效果?
時間沒有固定答案,取決於網站規模、爬取頻率、調整幅度、競爭程度與內容品質。可先用 GSC 觀察索引、曝光、點擊與主要查詢變化,不要只看單日排名波動。
URL 改了會不會掉排名?
URL 改動有風險,尤其是已有排名、流量或外部引用的頁面。若必須更改,應建立舊 URL 到新 URL 的對照表,設定 301 redirect,更新 canonical、內部連結與 sitemap。
小網站需要 XML sitemap 嗎?
小網站也可以有 XML sitemap,尤其是希望搜尋引擎更快發現重要頁面時。不過 sitemap 不是排名保證,仍要確保頁面本身可被爬取、可被索引,並有合理內部連結。
麵包屑對 SEO 有幫助嗎?
麵包屑可以幫助使用者理解所在位置,也能輔助搜尋引擎理解頁面層級。它的前提是網站本身有清楚分類與層級,不應只為了放結構化資料而硬加。
網站架構 SEO 會受到 JavaScript 影響嗎?
會。如果重要導覽、內部連結或內容需要 JavaScript 才能顯示,搜尋引擎可能需要額外渲染才能理解頁面。重要連結與主要內容應盡量穩定、可被爬取與渲染。
電商網站的篩選頁要不要讓 Google 索引?
要看篩選頁是否有搜尋需求、內容是否有差異、商品是否穩定。高價值篩選組合可以規劃成正式分類頁;低價值參數頁則可能需要 canonical、noindex 或爬取控管。
文章頁很多但排名不好,是網站架構問題嗎?
可能是,但不一定。要檢查文章是否有主題中心支援、內部連結是否足夠、是否和其他文章競爭同一搜尋意圖,也要檢查內容品質、搜尋需求與索引狀態。
網站改版前最重要的 SEO 檢查是什麼?
最重要的是盤點高流量頁、轉換頁、有排名頁,並建立舊 URL 到新 URL 的對照表。上線時要同步檢查 301、canonical、內部連結、sitemap、robots 與 noindex 設定。
內部連結要連到文章頁還是服務頁?
要看使用者當下意圖。需要補知識時連到相關文章,需要比較或決策時連到服務頁、案例頁或商品頁。好的內部連結不是只增加連結數,而是支援下一步行動與頁面關係。