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

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

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

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

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

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

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

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

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

網址的層級結構

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

• blog 是子網域（subdomain）
• example.com.tw 是本例的註冊網域；此處不把它與 DNS 根節點混為一談。
• /marketing 是子目錄，也就是路徑的第一層
• /marketing/seo-guide 是 URL 路徑；最後一段通常識別頁面，不一定對應伺服器的實體目錄。

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

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

www.example.com 裡的 www 是 example.com 的子網域名稱，常用來提供網頁服務。網站可選擇有 www 或沒有 www 的版本，並把另一版本永久轉址到主要版本，保持連結與 canonical 一致。設定細節可參考 www 與 non-www 網址差異全解析。

開設 shop 或 blog 會建立不同的主機名稱，方便安排服務與權限；名稱本身不會向 Google 保證這是獨立品牌，也不會自動帶來較高排名。

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

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

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

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

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

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

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

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

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

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

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

第三層：官方排名立場與部署差異

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

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

子目錄的維護優勢：導覽、內容管理與技術一致性

子目錄常見的優勢在於維護與管理。以下三點是架構選擇時可評估的便利性，並非 Google 承諾的排名加分。

優勢一：較容易維護共同導覽

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

優勢二：集中管理相關內容

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

優勢三：技術設定較容易一致

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

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

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

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

子網域和子目錄都能承載不同主題。不能僅靠拆分網址，便推論 Google 會給每個區塊更高的專業評價；也不能用每個區塊的文章數量，直接判定權威太薄。應比較內容是否回答不同需求、分類是否清楚，以及相關頁面之間是否有可爬取的連結。

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

大型品牌可能因團隊、平台、權限或地區營運而採用子網域，但外觀無法證明它們的決策原因，更不能證明子網域帶來排名優勢。小型團隊可先選擇自己容易維護的方式，不必照搬大型網站的架構。

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

子網域可以協助分開部署、權限與審核流程，卻不是 Google 搜尋政策的防火牆。不要把它當成隔離垃圾內容處分的保險，也不能推論跨子網域的正常連結無法傳遞訊號。應直接處理低品質或違規內容。

可以評估子網域的五種情境

下列情境可以評估子網域；最後仍要比較平台支援、管理權限、導覽與長期維護成本，並非只能選這一種結構。

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

WordPress 主站與 Shopify 商城，或靜態行銷頁與獨立應用程式，可能需要不同的部署方式。子網域常能直接接上各平台；子目錄有時也能透過反向代理等方式實作，但要確認平台支援與維護成本。平台選擇可搭配 電商平台比較指南。

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

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

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

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

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

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

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

活動頁可以使用子網域或子目錄。選擇獨立子網域有助於分開部署，但活動結束後仍需處理導覽、舊連結和網址狀態：有相近替代內容時轉址，沒有則保留有用的歷史資訊，或適當回傳 404／410。子網域不會自動消除孤兒頁面。

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

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

第一步：在 DNS 新增記錄

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

• A 記錄：把子網域指向主機的 IPv4 位址，例如文件示意用的 192.0.2.10；IPv6 則使用 AAAA 記錄。請填服務商實際提供的位址，不要照抄範例。
• CNAME 記錄：把子網域指向另一個網域名稱（例如 your-hosting.example.com）。適用於主機商給你網址、而非固定 IP 的情況，或你用的是 CDN 與託管平台的組合。

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

TTL（Time To Live）是 DNS 記錄可被解析器快取的時間，單位為秒。規劃變更時可依服務商限制先調短 TTL，再等舊快取到期；事後才調短，不能立即清掉先前的快取。穩定後可依服務需求調整，沒有所有網站都適用的固定秒數。

可先讀 DNS 網域名稱指向設定教學，了解記錄類型與快取。生效時間會受到舊 TTL、負向快取、託管商設定及是否更換權威名稱伺服器影響。應分別查詢權威 DNS 與常用解析器，確認回應，而不是只等待固定時數。

第二步：處理 SSL 憑證

子網域的主機名稱必須在有效 TLS 憑證的涵蓋範圍內，但不一定要另買一張憑證。可使用包含該名稱的 SAN 憑證，或由主機商透過 Let's Encrypt 簽發。*.example.com 萬用憑證只涵蓋一層子網域，例如 blog.example.com，不涵蓋裸網域 example.com 或 www.blog.example.com，除非憑證另外列出這些名稱。更多說明見 SSL 憑證指南、HTTP 與 HTTPS 差異解析。

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

DNS 設好後，還要讓主機識別新名稱並提供正確的網站。新版 cPanel 使用 Domains 介面建立及管理網域；其他平台依各自的網域綁定流程操作。網站可能對應文件目錄、應用程式或反向代理，不能只靠 DNS 完成部署。可搭配 這份主機指南 理解這層對應關係。

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

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

1. 確認子網域透過 HTTPS 正常開啟、憑證名稱與效期正確，而且沒有憑證或混合內容錯誤；不要以特定顏色的鎖頭作判準。
2. 確認 WordPress Address 與 Site Address 符合實際安裝位置及對外網址；WordPress 核心裝在子目錄時，兩欄不一定相同。
3. 調整永久連結結構，建議用文章名稱格式，這部分在 WordPress 永久連結設定 有詳細示範。
4. 安裝基本的 SEO 外掛（Rank Math 或 Yoast），把標題、中繼描述、結構化資料的基礎打好。
5. 確認 GSC 資源涵蓋子網域：網域資源通常已包含旗下子網域；需要獨立報表時可增設網址前置字元資源，並提交或檢查 sitemap。新增資源不會保證收錄。

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

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

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

地雷一：www 與子網域打架

www.blog.example.com 比 blog.example.com 多一層子網域。若前者確實被使用，可在 DNS、主機和有效憑證都配置完成後，永久轉址到主要版本；HTTPS 連線必須先通過憑證檢查才能收到轉址。未使用的別名不必為了 SEO 一律建立。網址統一方法見 301 與 302 轉址教學。

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

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

地雷三：GSC 資源的碎片化

GSC 的資料範圍取決於資源類型。example.com 網域資源涵蓋旗下子網域及不同通訊協定；https://example.com/ 網址前置字元資源則不包含 blog.example.com。可用網域資源看整體，再按需要新增網址前置字元資源或使用頁面篩選。操作見 Google Search Console 教學。

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

Google 建議採用響應式設計，因為通常較容易實作及維護；但仍支援動態提供內容與獨立的行動版網址。既有 m. 網站不必只因網址形式就搬家，應先確認手機版有主要內容、正確的 canonical／alternate 關係與可爬取資源。若決定整併，再規劃完整轉址。

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

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 或 308；各舊頁導向最相關的替代頁。合併內容可合理多對一；沒有替代內容的頁面則回傳 404／410，不要全部轉到首頁。
2. 更新內部連結：全站的內部連結裡，所有指向舊結構的網址都要更新成新路徑，不要依賴轉址鏈。
3. 更新 sitemap 並重新提交：新結構的 sitemap 產生後，立刻到 GSC 提交；舊結構的 sitemap 可以暫時保留一段時間，等索引轉換完成再移除。完整流程見 Sitemap 產生與提交教學。
4. 持續監控 GSC 與流量：檢查轉址、索引、伺服器錯誤與搜尋成效。重新處理網址所需時間依規模和爬取速度而異，不限於兩到四週；上線初期提高檢查頻率，直到主要網址轉換穩定。
5. 更新重要外部連結：可聯絡重要連結來源更新目的網址，減少等待與對舊系統的依賴；不要把每次轉址都視為固定比例的 PageRank 損失。

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

遷移最常見的失誤

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

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

第二種是忘了更新站內的選單與麵包屑。應把導覽、頁尾與相關文章中的舊網址更新成新網址，避免不必要的轉址請求，也讓內部連結與 sitemap、canonical 所指的版本保持一致。

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

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

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

五項行動清單

1. 釐清一個問題：這批新內容，是給現在這群讀者看的、還是一群完全不同的人？答案如果是前者，預設就走子目錄。
2. 盤點技術棧：新內容能否與主站共用部署？平台直接支援子網域時通常較容易設定；子目錄方案則需另外評估代理、路由與維護成本。
3. 檢查主站現況：比較現有內容、導覽與維護流程是否適合共用。不能以網站年齡或 DA 分數，保證放入子目錄就會成長更快。評估第三方分數時可參考 網站權重 DA 攻略。
4. 預估維護成本：把 DNS、SSL、GSC、sitemap、內部連結這些子網域會多出來的設定，列成一張清單，誠實估一下你的團隊扛不扛得住。
5. 留好遷移資料：保留網址清單、內容識別碼與可回復的設定，方便未來建立舊新 URL 對照。清楚且穩定的 URL 有助於管理，但不是必須多層目錄才能轉址。設計原則見 SEO 網址優化指南、網站架構規劃全攻略。

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

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