子網域 vs 子目錄全解析：SEO 差異與建立教學

會議室裡，公司決定要開一個部落格、一個電商商城、或一個給海外客戶看的英文站，工程師丟過來一句：「你要放在 blog.你的網域.tw 還是 你的網域.tw/blog？」你盯著螢幕，心裡冒出一個念頭：這兩個東西到底差在哪裡？哪一個對 Google 排名比較有利？

先給你一句話的答案。如果內容跟主站是同一個品牌、服務同一群人，通常可先選子目錄。當內容性質、技術棧、團隊或營運方式需要獨立時，子網域才會是更乾淨的選擇。Google 官方表示，從索引與排名角度並不偏好子網域或子目錄，因此這主要是組織、技術與維護方式的決策。

這篇我會帶你從 Google 真實的爬取與索引機制拆開來看，給你一份能直接拿去跟工程師開會的決策框架，再加一段子網域從 DNS 到 WordPress 上線的實作教學。

先給結論：同品牌內容通常先評估子目錄

我把最常被問到的核心問題，先濃縮成核心重點。你可以把這段直接截圖傳給團隊。

維度	子目錄 /blog	子網域 blog.網域
Google 怎麼看	同一主機名稱下的路徑，管理通常較集中	不同主機名稱，可獨立部署與管理
內部連結效益	站內導覽與連結管理較直接	仍可互相連結，但要額外維護導覽與追蹤
爬取預算	共用一份	各自獨立計算
設定成本	通常不必新增 DNS 或憑證設定	通常要新增 DNS、主機與憑證設定；GSC 是否另建資源視資源類型而定
適合場景	同品牌內容、主題叢集	獨立產品線、不同技術棧、隔離需求

Google 的爬取文件把不同主機名稱視為不同的爬取單位，但官方同時明確表示，從索引與排名角度不偏好子網域或子目錄。因此，同品牌且同一團隊維護的內容可先用子目錄；有部署、權限或營運隔離需求時，再選子網域。

你以為的「子網域」和「子目錄」，長相可能跟你想的不一樣

很多人討論這兩者卻沒先把定義講清楚，結果雞同鴨講。我們把網址拆開。

網址的層級結構

一個完整的網址，例如 https://blog.example.com.tw/marketing/seo-guide，從左到右其實是這樣拆的：

• blog 是子網域（subdomain）
• example.com.tw 是根網域（root domain）
• /marketing 是子目錄，也就是路徑的第一層
• /seo-guide 是更深的子目錄或頁面

關鍵差異在主機名稱與路徑。子網域出現在註冊網域的前面、用小數點隔開；子目錄出現在主機名稱的後面、用斜線隔開。這不只是排版差異，也會影響 DNS、憑證、伺服器、權限與部分工具的設定方式。

一個很多人沒察覺的事實：www 本身就是子網域

這裡有個會讓不少人愣住的冷知識。www.example.com 裡面的 www，技術上就是 example.com 的一個子網域。它當年被發明出來，是為了把網頁服務（World Wide Web）跟 FTP、郵件等其他服務區隔開來。今天大多數網站只是把 www 和裸網域 example.com 用 301 轉址綁在一起，讓兩者指向同一份內容。如果你對 www 與非 www 的處理有興趣，我也寫了一篇 www 與 non-www 網址差異全解析，把自相殘殺的陷阱講得很細。

理解了 www 的本質，你就會明白：子網域不是什麼新奇的東西，你早就天天在用它。差別在於，當你刻意開一個 shop 或 blog 子網域時，你是在告訴 Google「這是一個有點不一樣的區塊」。

子目錄的本質：主站地盤上的一條路

子目錄是主機名稱後方的一段路徑，不代表它一定跟首頁住在同一台伺服器，也不一定由同一套程式產生。不過在常見的 WordPress 架構裡，建立 /blog 通常不必新增 DNS 或另簽 SSL；Google Search Console 是否另建資源，則取決於你使用網域資源還是網址前置字元資源。

換個方式想：子目錄是你在自己家裡多隔一間房間，水電都接現成的；子網域是你去隔壁買一塊地蓋一棟新房，地址是新的、水電要重拉、門牌要重掛。

Google 把子網域當「另一個網站」看待嗎？拆解爬取與索引的真實機制

這是整個爭論最核心的問題，也是網路上最多半真半假答案的地方。我把 Google 實際的行為拆成三層來看。

第一層：爬取與爬取預算是分開的

Google 的爬取預算文件以主機名稱為範圍說明限制，因此不同子網域可能有各自的爬取上限。不過，多數小型網站不必把爬取預算當成決策主因；它通常是在網址量大、更新頻繁時才需要特別管理。

當網站有大量、快速變動的網址時，主機層級的爬取限制才可能影響新內容被發現的速度。這時應先查看伺服器紀錄與 Search Console 的主機狀態，再判斷是否需要調整架構，而不能僅憑收錄快慢歸因。如果你想把這塊機制摸得更透，可以讀 爬取預算優化策略。

第二層：索引與排名訊號的累積

子目錄的實務優勢，在於內容與導覽通常更容易共用同一套內部連結。外部連結指向首頁後，仍要靠清楚的導覽與相關內容連結，搜尋引擎才容易發現深層頁面；共用網域本身不代表每一頁都會自動獲得同等效果。

Backlinko 在 2025 年 4 月分析了 1180 萬個 Google 搜尋結果，發現連結到一個網域的獨特網站數量（referring domains）與搜尋排名存在相關性。相關性不能證明子目錄必然優於子網域，但把同一主題的內容、導覽與維護流程集中，通常比較容易形成清楚的內容關係。

第三層：Google 官方的表態與現實落差

Google 的搜尋中心 FAQ 表示，從索引與排名角度看，子網域或子目錄都可以，建議選擇較容易組織與管理的形式。這不代表兩者的部署與分析成本相同，而是沒有官方所稱的固定排名偏好。

因此，真正該比較的是部署、權限、導覽、追蹤與長期維護成本，而不是預設其中一種結構一定排名較好。相關檢查可搭配 技術 SEO 完整指南。

子目錄的 SEO 紅利：連結權重、主題權威與技術一致性

把前面三層機制收攏，子目錄的優勢可以歸納成三個具體的紅利。

紅利一：連結資產一條龍

主站與子目錄通常共用導覽與內容管理流程，因此較容易安排深層頁面的內部連結；但頁面能否獲得自然搜尋流量，仍取決於內容相關性、可索引性與外部訊號。若要檢查連結配置，可以看 反向連結建立指南。

紅利二：主題叢集與主題權威的天然載體

主題叢集（Topic Cluster）的核心，是用支柱頁與支援頁串成清楚的內容關係。子目錄常是順手的載體，因為頁面能共用導覽與管理規則；子網域若設計好跨站導覽，一樣能建立相關性。相關的內部連結配置，可參考 內部連結、外部連結完整解析。

紅利三：技術一致性與維護省力

子目錄通常不必額外設定 DNS、憑證或主機綁定，分析標籤與 Cookie 也較容易沿用。GSC 是否需要新增資源、sitemap 是否拆分，則取決於原有的資源類型與管理需求。這些差異在網站擴大後會反映成維護成本。

三個害人走錯路的常見迷思

這個主題在網路上流傳著好幾個聽起來合理、實際上會誤導判斷的說法。我把最常碰到的三個拆給你看。

迷思一：「子網域對 SEO 比較好，因為可以鎖定不同關鍵字」

這是最普遍的誤解。背後的推理是：把不同主題分到不同子網域，Google 會把每個子網域當成一個專精的網站來排名。聽起來有道理，但實際運作恰恰相反。Google 的主題權威機制看的是一個網域在單一主題領域的累積深度，跟網域數量沒有關係。你把十篇 SEO 文章拆到 seo.網域、十篇網頁設計文章拆到 design.網域，等於把本來可以互相支撐的二十篇文章打散成兩個各只有十篇的微型網站，兩邊的權威訊號都太薄，反而長不起來。子目錄底下用清晰的分類跟內部連結，照樣能讓 Google 辨識出不同主題的邊界，而且還能享受跨主題的連結資產流通。

迷思二：「大品牌都用子網域，所以子網域比較強」

這個推論把因果關係搞反了。大型品牌之所以用子網域，是因為他們的規模、團隊架構、技術需求已經到了非切割不可的程度，子網域本身並沒有帶來 SEO 紅利。一家跨國媒體集團把新聞、運動、財經分到不同子網域，是因為每個垂直有自己的編輯團隊、自己的上稿系統、自己的廣告營運，硬塞在同一個目錄裡反而會變成管理災難。你如果是一個五人團隊、用同一套 WordPress、同一群人寫所有內容，去模仿跨國集團的架構，結果只會是把簡單的事做複雜。

迷思三：「子網域的內容不會拖累主站排名」

這句話半對半錯，而那個「半錯」的部分很危險。子網域確實能在一定程度上隔離垃圾內容的負面影響，但這層隔離是雙面的：當子網域上有優質內容、獲得外部連結時，那份正面訊號也很難有效回流到主站。換句話說，你買到的是隔離風險的保險，代價是放棄了正向權重的集中放大。對絕大多數還在成長中的網站來說，你需要的是把每一分連結資產都集中用在刀口上，而不是買一份你還不需要的保險。

非用子網域不可的五種劇本

講了這麼多子目錄的好處，不代表子網域沒有它不可取代的時刻。以下五種情境，我會明確建議你用子網域。

劇本一：完全不同的技術棧與營運節奏

你的主站是用 WordPress 蓋的品牌官網，但你想新增的商城跑在 Shopify 上；或者主站是靜態生成的行銷頁，而你要開一個需要伺服器運算的應用平台。這類技術棧根本不同的情境，硬塞進同一個目錄會帶來無止境的伺服器設定惡夢。子網域讓你各跑各的，乾淨俐落。如果你正在評估電商平台，電商平台比較指南 可以幫你先理出方向。

劇本二：明確的國際化與多語系切割

當海外業務需要獨立的在地化營運（不同定價、物流或法規遵循），用 tw、jp、en 子網域切割市場，是常見做法。若是純語系切換、內容高度共用，子目錄配 hreflang 標記通常較輕量；每個語言版本必須互相回指，並包含指向自己的標記。多語系的完整設定方法，可參考 Hreflang 多語系 SEO 手冊 與 多語系網站架構設計。

劇本三：企業級的產品線或事業體隔離

大型企業底下有不同的產品線，每條線有自己的品牌調性、自己的技術團隊、自己的資安要求。這時用子網域做切割，讓每個事業體獨立部署、獨立擴展，是合理的組織決策。例如一家同時經營雲端服務跟線上學習的公司，把兩者分到不同子網域，各自的工程團隊不會互相踩腳。

劇本四：社群與使用者生成內容的隔離需求

論壇、問答區、使用者上傳的社群平台，內容品質較難完全掌控。子網域可以讓權限、程式與審核流程獨立，但不能保證搜尋品質問題完全與主站隔離；仍應搭配內容審核、垃圾防護與適當的索引控制。

劇本五：暫時性或活動型頁面的獨立生命週期

年度大型活動、募資專案、短期的行銷活動頁，用獨立子網域可以讓它在活動期間集中累積自己的連結與聲量，活動結束後乾淨下架，不會在主站的內容結構裡留下孤兒頁面。這對行銷節奏密集的品牌來說，是一種整潔的內容衛生策略。

子網域建立實作：從 DNS 到 WordPress 上線

如果你評估過前面五種劇本，確認子網域是對的選擇，接下來就是實作。我用最常見的情境示範：在一個已上線的網域底下（還沒申請主網域的話，先從〈網域申請全攻略〉把地基打好），新增一個 blog 子網域，並且讓它跑 WordPress。

第一步：在 DNS 新增記錄

子網域的起點是 DNS。你登入網域註冊商或 DNS 託管商的後台，新增一筆記錄，把 blog 指向你的伺服器或主機。兩種最常見的記錄類型：

• A 記錄：把子網域指向一個 IPv4 位址（例如 123.45.67.89）。適用於你指向一台固定 IP 的主機。
• CNAME 記錄：把子網域指向另一個網域名稱（例如 your-hosting.example.com）。適用於主機商給你網址、而非固定 IP 的情況，或你用的是 CDN 與託管平台的組合。

DNS 後台對「名稱」欄位的處理方式不完全相同：有些要求填 blog，有些接受完整主機名稱。送出前先看服務商的欄位提示與預覽，避免系統再次附加根網域，產生錯誤的雙層名稱。

TTL（Time To Live）的設定也值得一提。TTL 決定了這筆 DNS 記錄在全球 DNS 伺服器上的快取時長，單位是秒。剛開通子網域時，建議把 TTL 設短一點（例如 300 或 600 秒），萬一設定需要修改，傳播速度會快很多；等子網域穩定運作之後，再把 TTL 拉長到 3600 秒以上，減少 DNS 查詢的延遲。這是個小細節，但在你頻繁調整設定的階段，能省下不少等待時間。

如果你對 DNS 的底層邏輯還不熟，建議先讀過 DNS 網域名稱指向設定教學，把記錄類型跟傳播時間的觀念建立好，才不會設完等了半天不知道為什麼沒生效。DNS 記錄的傳播通常需要幾分鐘到幾小時不等，取決於 TTL（Time To Live）的設定。

第二步：處理 SSL 憑證

子網域需要自己的 SSL 憑證，否則瀏覽器會跳出「不安全」警告，而 Google 也把 HTTPS 列為排名訊號之一。最省事的做法是申請一張涵蓋所有子網域的萬用憑證（Wildcard SSL），一張搞定 *.你的網域.tw；如果你的主機商有提供免費的 Let's Encrypt 自動簽發，那就直接在主機後台為新子網域啟用即可。SSL 的完整觀念整理在 SSL 憑證指南 跟 HTTP 與 HTTPS 差異解析 兩篇裡。

第三步：在主機端綁定子網域

DNS 指過去之後，你還要在伺服器或主機後台「迎接」這個子網域。這一步叫法因主機商而異：cPanel 通常是「Addon Domains」或「Subdomains」、Cloud Panel 叫「新增網站」、Cloudways 則是在應用程式設定裡追加網域。不管介面怎麼設計，本質都是告訴伺服器：當有人從 blog.你的網域.tw 連進來，請把流量導到某個指定的資料夾，並用那個資料夾裡的網站程式來回應。如果你用的是虛擬主機，這份主機指南 會幫你搞懂這層對應關係。

第四步：安裝 WordPress 並完成上線檢查

子網域的資料夾準備好之後，安裝 WordPress 的流程跟主站一模一樣。裝完之後，別忘了跑這幾項上線檢查：

1. 確認 blog.你的網域.tw 可以正常開啟、憑證是綠色有效。
2. 設定 WordPress 的網址與站點網址欄位，兩者都要填入完整的子網域路徑。
3. 調整永久連結結構，建議用文章名稱格式，這部分在 WordPress 永久連結設定 有詳細示範。
4. 安裝基本的 SEO 外掛（Rank Math 或 Yoast），把標題、中繼描述、結構化資料的基礎打好。
5. 在 GSC 新增子網域資源、完成驗證、提交 sitemap，讓 Google 盡早開始爬取。

如果你是剛起步、連主機都還沒選，可以從 WordPress 主機推薦 或 WordPress 快速架站指南 開始把基礎打好。

子網域踩坑指南：www、重複內容、GSC 驗證與爬取預算

子網域的麻煩不是在建立的那一刻，而是在營運過程裡慢慢浮上來。我把最常見的四個地雷整理出來。

地雷一：www 與子網域打架

你開了 blog.example.com，結果有人輸入 www.blog.example.com，這時如果你的主機沒有正確處理，可能會出現 404、或者跑到一個空白頁。技術上 www 會變成子網域的子網域，多了一層。解法是在主機或 CDN 層設定好 www.blog 301 轉址到 blog，或者反過來統一。301 與 302 轉址教學 把這類網址統一的邏輯講得很清楚。

地雷二：主站與子網域之間的重複內容

當主站與子網域有高度重疊的內容（例如兩邊都有近似的產品介紹），Google 可能自行選擇其中一版作為標準網址；這是版本整併，不等於對重複內容施加處罰。可用 canonical 標記表達偏好，或合併不必要的重複頁。設定細節可看 Canonical URL 完全指南，完整處理原則則在 重複內容處理準則。

地雷三：GSC 資源的碎片化

這是子網域最被低估的隱性成本。子目錄跟主站共用同一個 GSC 資源，你在一份報表裡就能看到所有頁面的索引狀態、搜尋流量、覆蓋範圍問題。子網域則需要個別驗證一個獨立資源（或者改用網域層級的 Domain 資源，一次涵蓋所有子網域）。如果你同時經營三四個子網域，要在多份報表之間切換，索引問題跟排名波動很容易被忽略。完整的 GSC 操作手冊在 Google Search Console 教學 裡。

地雷四：行動版子網域的歷史包袱

早年很流行用 m.網域 子網域來服務手機版頁面。這個做法在今天已經過時，Google 採用的是行動優先索引（Mobile-First Indexing），你應該用響應式設計（RWD）讓同一組網址同時服務桌面與手機。Statista 的數據（2026 年 4 月）顯示，全球網站流量中行動裝置的佔比長年維持在高檔，這代表行動體驗已經是基本款，不再是附加題。維護一份獨立的 m. 子網域，等於把一份內容維護兩次、還要擔心兩版的內容一致性與 canonical 指向，完全不符合效益。

數據追蹤與使用者體驗：子網域的隱形稅

SEO 之外，子網域還會在兩個你容易看漏的地方收稅：數據追蹤的設定成本，以及使用者跨子網域時的體驗摩擦。

分析工具的跨網域設定

同一個 GA4 網頁資料串流與一致的 Cookie 設定，通常可以跨同一根網域的子網域辨識使用者；跨網域設定主要用於不同根網域。若各子網域使用不同標籤、資料串流或 Cookie 網域設定，仍可能產生自我參照或工作階段斷裂，應在 DebugView 與即時報表實測。子目錄通常較少碰到這類設定差異。

Cookie 能否跨子網域使用，取決於 Domain、Path、SameSite、Secure 等屬性與應用程式設計，不能一概而論。若登入或購物車要跨子網域延續，應由工程團隊明確設計並測試。

Core Web Vitals 與效能追蹤的碎片化

Core Web Vitals（CWV）是 Google 排名系統考量的頁面體驗訊號之一，但良好分數不保證排名。CrUX 欄位資料可能依網址或來源層級彙整，不能推論改善單一子目錄頁面就會讓整站評分同步上升。監控時應依 GSC 與 CrUX 實際提供的分組查看。完整優化方法可參考 Core Web Vitals SEO 指南，並搭配 CDN 網站加速 與 網站快取設定指南。

從子目錄遷到子網域（或反過來）：什麼時候該動、怎麼動才不掉流量

架構不是一次定終身的決定。隨著網站長大，你可能會需要從子目錄遷到子網域，或反過來把表現不佳的子網域收編回主站。這是一個高風險動作，做錯了流量會直接跳水。

什麼時候該認真考慮遷移

符合下面任何一種訊號，就值得坐下來重新評估：

• 子網域的內容已經長出自己的營運團隊、技術需求跟主站完全分道揚鑣，硬綁在一起反而互相拖累。
• 子目錄的內容量膨脹到一個程度，開始出現關鍵字自相殘殺（你自己兩個頁面在搶同一個搜尋詞的排名）。這個問題的判斷與處理，我整理在 關鍵字自相殘殺修復指南。
• 子網域長期沒有自然流量時，先檢查搜尋需求、內容品質、索引與內部連結；若管理分散確實是問題，再評估整併，不要把搬遷當成排名保證。

遷移的關鍵動作清單

不管方向是哪一邊，這幾個動作都不能漏：

1. 逐頁 301 轉址：舊網址到新網址必須一對一對應，不要只把首頁轉過去、然後讓所有子頁面都 404。
2. 更新內部連結：全站的內部連結裡，所有指向舊結構的網址都要更新成新路徑，不要依賴轉址鏈。
3. 更新 sitemap 並重新提交：新結構的 sitemap 產生後，立刻到 GSC 提交；舊結構的 sitemap 可以暫時保留一段時間，等索引轉換完成再移除。完整流程見 Sitemap 產生與提交教學。
4. 搬完後密集監控 GSC 與流量：遷移後的兩到四週是危險期，每天看一次 GSC 的覆蓋範圍報表跟搜尋成效，一旦發現大量網址掉出索引或點擊驟降，馬上回頭排查轉址鏈有沒有漏。
5. 通知已知的反向連結來源：如果有幾個重要的外部網站連到你的舊結構，禮貌性地寫封信請對方更新連結，能少一層轉址折損就少一層。

如果你遷移的同時還涉及更換主機或更換網域，動作會更複雜，建議參考 WordPress 搬家到新網域完整指南 跟 WordPress 換主機教學 兩篇，把每一步的檢查點都走過。

遷移最常見的失誤

架構遷移的風險往往出在執行疏漏，而非單純「選錯方向」。以下是三種常見失誤：

第一種是轉址沒有做到一對一對應。若把所有舊網址統一轉到新首頁，使用者會抵達不相關的頁面，Google 也可能把這類轉址視為軟性 404。這會妨礙網址訊號轉移，但不能簡化成所有訊號必然歸零。

第二種是忘了更新站內的選單與麵包屑。301 轉址能救外部連結，但你自己網站上的導覽列、頁尾連結、相關文章區塊，如果還是指向舊網址，等於讓每一個訪客都先跳一層轉址才到達目的地。這不但拖慢載入速度，還會讓 Google 覺得你的站內結構混亂。

第三種是急著拆掉舊的 sitemap 跟轉址規則。Google 建議轉址至少保留一年，從使用者與既有外部連結角度看，能長期保留更好。太早移除會讓尚未更新的舊連結失效。如果你想確認 Google 目前索引了哪些頁面，Google 網頁收錄查詢教學 提供了查證方法。

你的下一步：一張決策表加五項行動清單

我設計一張三分鐘決策表，幫你把前面的討論收斂成可以立刻用的判斷。

你的情境	建議結構	理由
同品牌部落格、內容行銷	子目錄	主題叢集中、連結資產共用
電商商城與主站同品牌	子目錄（若同技術棧）	一致體驗、集中權重
商城跑在不同平台上	子網域	技術棧隔離、各自部署
多國市場、各自獨立營運	子網域（國別）	營運隔離、在地化彈性
純多語系、內容共用	子目錄配 hreflang	輕量、權重集中
論壇、使用者生成內容	子網域	風險隔離
活動頁、募資專案	子網域	獨立生命週期、易下架
企業內獨立產品線	子網域	團隊與資安隔離

五項行動清單

1. 釐清一個問題：這批新內容，是給現在這群讀者看的、還是一群完全不同的人？答案如果是前者，預設就走子目錄。
2. 盤點技術棧：新內容跑在跟主站同一套系統上嗎？如果不同，子網域幾乎是唯一的乾淨解。
3. 檢查主站現況：主站的連結資產健康嗎？如果主站本身還很年輕、外部連結薄弱，把新內容塞進子目錄、一起累積，會比為子網域另起爐灶成長得更快。網域權重的評估方法見 網站權重 DA 攻略。
4. 預估維護成本：把 DNS、SSL、GSC、sitemap、內部連結這些子網域會多出來的設定，列成一張清單，誠實估一下你的團隊扛不扛得住。
5. 留好退路：不管你今天選哪邊，都要確保未來可以用 301 轉址乾淨地搬過去。這代表你的網址結構要有清楚的層級邏輯，避免把所有東西塞在同一層。網址結構的設計原則我在 SEO 網址優化指南 跟 網站架構規劃全攻略 裡有展開。

架構選擇看似是技術問題，其實也牽涉品牌與營運：這批內容是否服務同一群讀者、由同一團隊管理、共用同一套產品體驗？把這些問題釐清，通常就能縮小選項。架構是地基，前期多做一次盤點，能減少日後搬遷成本。

如果你正在規劃整體網站結構，可以從 網域與子網域基礎認識 開始，再依部署、追蹤與內容管理需求做決策。