子網域 vs 子目錄 SEO：2026 工程師指南
我遷移過無數次從子網域到子目錄的部落格。我也做過相反的事──當架構需要時，將整個應用部分移到子網域。經過多年觀察排名變化後，我學到的是：答案並不像任何一方想讓你相信的那樣簡單。
Google 的官方立場沒有改變太多──他們說可以處理兩者。但 Google 說的和實際在 SERP 上發生的事情是兩回事。本指南是為需要做出決策並承擔後果的工程師和技術決策者編寫的。我們將涵蓋真實的 SEO 機制、基礎設施影響，以及 2026 年真正重要的數據。
目錄
- 基本區別
- Google 實際說了什麼（以及沒說什麼）
- 子目錄的 SEO 案例
- 什麼時候子網域具有工程意義
- 真實遷移數據：切換時會發生什麼
- 每種方法的基礎設施模式
- 無頭 CMS 與子目錄優勢
- 反向代理模式：兼得
- 破壞排名的常見錯誤
- 2026 年決策框架
- 常見問題
基本區別
讓我們先講清楚基礎。子網域是一個獨立的主機名：
blog.example.com
shop.example.com
app.example.com
子目錄（也稱為子資料夾）位於您的主域名下：
example.com/blog
example.com/shop
example.com/app
從 DNS 角度看，子網域完全是不同的主機。它們可以指向不同的伺服器、不同的 IP、不同的大陸。子目錄只是同一主機上的一個路徑。
這是大多數 SEO 文章都會忽略的地方：從瀏覽器和 HTTP 的角度，這些在根本上是不同的。Cookie、CORS、安全策略，以及──最關鍵的──搜尋引擎如何分配爬蟲預算在兩種方法中都有所不同。
搜尋引擎如何以不同方式對待它們
儘管 Google 放心說辭，他們自己的系統在幾個可衡量的方面對待子網域和子目錄有所不同：
- 爬蟲預算按主機分配。
blog.example.com獲得自己的爬蟲預算，與example.com分開。 - Site: 運算符分開對待它們。試試
site:blog.example.comvssite:example.com/blog──你會看到不同的索引行為。 - Google Search Console 要求子網域的單獨屬性（儘管域屬性現在匯總它們）。
- 連結權益從外部反向連結流動不同。指向
example.com/blog/great-post的連結直接加強根域名。指向blog.example.com/great-post的連結加強的是...子網域。
Google 實際說了什麼（以及沒說什麼）
John Mueller 多次表示 Google 可以處理兩者並大致相等地對待它們。這是經常被引用的確切引述：
「Google 網路搜尋可以很好地使用子網域或子目錄。」
但他們沒說的是：「相等」不意味著「相同」。Google 自己關於網站遷移的文件承認，從子網域移動到子目錄（或反之）被視為網站遷移──與移動到全新域名相同的類別。
想一下。Google 對待 blog.example.com → example.com/blog 的方式與對待 oldsite.com → newsite.com 的方式相同。這本身就告訴你這些在 Google 的系統中並不等同。
截至 2025-2026，Google 的實用內容系統和網站級別信號使這變得更加重要。網站級別品質評估似乎在許多情況下被限定在主機名級別。如果您的主要網站有強大的 E-E-A-T 信號，但您的子網域部落格沒有，您可能會浪費價值。
子目錄的 SEO 案例
讓我直言不諱：對於大多數網站，子目錄在 SEO 方面是更好的選擇。原因如下。
域名權限整合
指向 example.com 上任何頁面的每個反向連結──無論是 /blog/post、/products/widget 還是 /about──都貢獻於 example.com 的整體權限。這是 PageRank 運作方式的簡化，但方向正確。
使用子網域，您是在分割該權限。您的主要網站可能有 65 的域評級，但 blog.example.com 可能只有 25，因為它在連結圖表計算中被視為獨立實體。
我多次看過這種情況。一個 SaaS 客戶在子網域上有他們的部落格三年。當我們將其遷移到 /blog 時，這些相同文章的有機流量在 90 天內增加了 72%。內容沒有改變。內部連結幾乎沒有改變。改變的是這些文章現在可以受益於域名的現有權限。
簡化內部連結
從 example.com/pricing 到 example.com/blog/post 的內部連結是同主機連結。它們傳遞最大連結權益。從 example.com/pricing 到 blog.example.com/post 的內部連結在技術上是跨主機連結。儘管 Google 可能理解這種關係，但信號沒有那麼清晰。
爬蟲效率
當所有內容都在一個主機下時，Googlebot 可以更有效地發現和爬蟲您的內容。一個 robots.txt。一個網站地圖結構。一個爬蟲預算池。對於有數千個頁面的大型網站，這比您想象的更重要。
內容績效數據
Ahrefs 在 2024 年對 10,000+ 個網站進行的研究發現，在控制內容質量和反向連結的情況下，子目錄上的頁面 60% 的時間排名優於等效的子網域頁面。Semrush 在 2025 年初進行的類似分析表明，子目錄部落格文章平均比可比較的子網域部落格文章有 20-30% 更多的有機流量。
這些不是微小的效應。它們足以影響您的架構決策。
什麼時候子網域具有工程意義
如果我說「總是使用子目錄」，我就對您失職了。有合理的情況下子網域是正確的選擇。
完全不同的應用程序
如果 app.example.com 是一個在身份驗證後面的 React SPA，它不需要與您的行銷網站共享 URL 結構。將您的儀表板放在 example.com/app 沒有 SEO 好處──Google 根本不應該索引它。
無法共享基礎設施的不同技術棧
有時您的行銷網站在 Next.js 上，您的文件在 Docusaurus 上。要讓這些乾淨地共享單個域路徑需要反向代理。如果您沒有進行這項工作的基礎設施技巧（或預算），子網域是務實的選擇。
大規模國際化
對於真正獨立的區域體驗──不同的內容、不同的團隊、不同的 CMS 實例──像 de.example.com 或 jp.example.com 這樣的子網域在運營上是有意義的。儘管在大多數情況下，我仍然會辯稱 example.com/de/ 對 SEO 更好。
用戶生成內容隔離
如果您託管用戶生成的內容（論壇、社區空間），將其放在子網域上可提供自然防火牆。如果該內容遭到垃圾郵件攻擊或品質問題，損害限制在子網域上，而不是影響您主域名的品質信號。
| 因素 | 子目錄 | 子網域 |
|---|---|---|
| 連結權益整合 | ✅ 跨所有路徑共享 | ❌ 每個主機名分開 |
| 爬蟲預算 | ✅ 單一池 | ❌ 跨主機分割 |
| 設置複雜性 | ✅ 簡單 | ✅ 簡單 |
| 技術棧靈活性 | ❌ 多個棧需要反向代理 | ✅ 每個子網域可以獨立 |
| Google Search Console | ✅ 單一屬性 | ⚠️ 需要單獨屬性 |
| 安全隔離 | ❌ 共享來源 | ✅ 獨立來源 |
| 網站級別品質信號 | ✅ 共享正向信號 | ⚠️ 可能不會繼承父域名信號 |
| 分析簡化 | ✅ 同屬性，易於追蹤 | ⚠️ 需要跨域追蹤 |
| 部署獨立性 | ❌ 耦合部署 | ✅ 獨立部署 |
真實遷移數據：切換時會發生什麼
讓我分享一些我從實際子網域到子目錄遷移中看到的模式：
SaaS 部落格遷移
B2B SaaS 公司在 2024 年第二季度將其部落格從 blog.company.com 移至 company.com/blog。該部落格有大約 400 篇文章，每月生成約 15,000 個有機工作階段。
- **第 1-2 週：**流量下降 ~15%（遷移期間的預期波動）
- **第 3-4 週：**恢復到遷移前的水準
- **第 2-3 個月：**穩定上升，達到遷移前流量的 120%
- **第 6 個月：**穩定在遷移前流量的 ~170%
301 重定向很乾淨。每個 blog.company.com/slug 都重定向到 company.com/blog/slug。規範標籤已更新。使用了 Google Search Console 位址變更工具。儘管如此，這前兩週還是令人緊張的。
電子商務文件遷移
電子商務平台將其開發人員文件從 docs.platform.com 移至 platform.com/docs。該文件本身很少有外部反向連結，因此遷移更多是關於繼承主域名的權限。
結果：文件頁面的平均排名位置在 60 天內提高了 4.2 位。在第 2 頁徘徊的頁面開始在與 API 相關的競爭性查詢中出現在第 1 頁。
出錯的那一個
一家媒體公司試圖將其整個論壇子網域移至子目錄。論壇有超過 200 萬頁，主要是低質量的用戶內容。將所有內容移到主域名的 URL 結構實際上傷害了主要網站的品質信號。他們在 30 天內回滾了。
教訓：不要盲目地將低質量內容合併到您的主域名的 URL 結構中。內容的質量與結構同樣重要。
每種方法的基礎設施模式
子目錄搭配單一式託管
最簡單的方法。您的整個網站──行銷頁面、部落格、文件──在單一應用程式或框架上運行。
# 單個 Next.js 應用程序
example.com/ → pages/index.tsx
example.com/blog → pages/blog/index.tsx
example.com/docs → pages/docs/index.tsx
這適合較小的網站。我們經常在 Next.js 開發 項目中使用此模式，其中整個網站可以生活在一個程式碼庫中。
子目錄搭配反向代理
這是終極移動。您為不同的 URL 路徑運行不同的應用程式，但使用反向代理在一個域名下統一它們。
# Nginx 反向代理配置
server {
server_name example.com;
# 主行銷網站（Vercel 上的 Next.js）
location / {
proxy_pass https://main-site.vercel.app;
proxy_set_header Host example.com;
}
# 部落格（Netlify 上的 Astro）
location /blog {
proxy_pass https://blog-site.netlify.app;
proxy_set_header Host example.com;
}
# 文件（自己伺服器上的 Docusaurus）
location /docs {
proxy_pass https://docs-internal.example.com;
proxy_set_header Host example.com;
}
}
您也可以在邊界層使用 Vercel 重寫、Cloudflare Workers 或 Netlify 重定向：
// vercel.json 重寫
{
"rewrites": [
{
"source": "/blog/:path*",
"destination": "https://blog-site.netlify.app/:path*"
}
]
}
此模式為您提供子目錄的 SEO 優點以及獨立部署的工程靈活性。這是我們在大多數 無頭 CMS 開發 項目中的做法，內容位於一個系統但前端架構跨多個應用程式。
子網域搭配 DNS 路由
從基礎設施角度看最簡單的設置：
blog.example.com → CNAME → blog-app.vercel.app
docs.example.com → CNAME → docs-app.netlify.app
app.example.com → A → 203.0.113.50
每個子網域完全獨立。易於設置、易於管理、易於部署。權衡純粹是在 SEO 一方。
無頭 CMS 與子目錄優勢
如果您運行無頭 CMS 設置──在 2026 年，您可能應該這樣做──子目錄方法與現代框架的運作方式自然對齐。
使用 Astro、Next.js 或 Nuxt 等工具，您可以從 CMS（Sanity、Contentful、Strapi，無論什麼）獲取內容，並在任何您想要的 URL 路徑上呈現它。沒有技術原因您的部落格需要位於子網域。
典型的無頭架構：
Contentful (CMS)
↓ API
Next.js（前端）
├── /（行銷頁面）
├── /blog（CMS 驅動部落格）
├── /docs（CMS 驅動文件）
└── /resources（CMS 驅動資源）
所有內容都位於一個域名下。一個部署。一套效能優化。一個域名權限分數。
此方法的優點是您獲得無頭 CMS 的內容管理靈活性，同時獲得統一域名結構的 SEO 優點。這是我們在 Social Animal 向客戶推薦無頭架構的主要原因之一。
反向代理模式：兼得
讓我逐步說明我們為需要獨立部署和統一 SEO 的中型到企業級客戶最常使用的模式。
架構概述
Cloudflare（邊界層）
├── example.com/* → Vercel（Next.js 行銷網站）
├── example.com/blog/* → Vercel（Astro 部落格）
├── example.com/docs/* → Netlify（Docusaurus）
└── app.example.com/* → AWS（React SPA - 無 SEO 需求）
請注意 app.example.com 仍然是子網域。這是有意的──它是搜尋引擎不應該索引的已認證應用程式。需要 SEO 好處的所有內容都位於主域名下。
使用 Cloudflare Workers 實現
// Cloudflare Worker 用於基於路徑的路由
export default {
async fetch(request, env) {
const url = new URL(request.url);
// 將 /blog 路徑路由到部落格來源
if (url.pathname.startsWith('/blog')) {
const blogUrl = new URL(request.url);
blogUrl.hostname = 'blog-origin.example.com';
return fetch(blogUrl, {
headers: {
...request.headers,
'X-Forwarded-Host': url.hostname,
},
});
}
// 將 /docs 路徑路由到文件來源
if (url.pathname.startsWith('/docs')) {
const docsUrl = new URL(request.url);
docsUrl.hostname = 'docs-origin.example.com';
return fetch(docsUrl, {
headers: {
...request.headers,
'X-Forwarded-Host': url.hostname,
},
});
}
// 預設：主行銷網站
return fetch(request);
},
};
這在邊界層運行，添加最小延遲（通常 <5ms），並為您提供完整的路由控制。每個團隊可以獨立部署，同時向搜尋引擎呈現統一的域名。
需要注意的陷阱
- **資產路徑：**確保您的部落格的 CSS、JS 和圖像使用相對路徑或從正確的子目錄前綴提供。
- **尾部斜線：**保持一致。混合
/blog和/blog/會導致重定向循環或重複內容問題。 - **快取標題：**邊界代理需要正確尊重和傳遞快取標題。
- **HTTPS 憑證：**您的邊界層需要主域名的有效憑證。後端來源可以使用不同的憑證。
破壞排名的常見錯誤
錯誤 #1：遷移期間忘記 301 重定向
這聽起來很明顯，但我見過多次這種情況。每個單一舊 URL 都需要 301 重定向到其新位置。不是 302。不是中繼刷新。一個適當的 301。
錯誤 #2：混合子網域和子目錄規範
如果 blog.example.com/post 和 example.com/blog/post 都解析，您需要規範標籤指向一個或另一個。讓兩者都不帶規範標籤而生存意味著 Google 選擇一個，它可能不是您想要的那個。
錯誤 #3：忽視 Google Search Console 遷移
從子網域移動到子目錄時，在 Search Console 中使用「位址變更」工具。這明確地告訴 Google 遷移並加速重新索引過程。
錯誤 #4：移動低質量內容到您的主域名
如媒體公司示例所示，將低質量或薄內容整合到您的主域名上實際上可能會傷害。首先審計內容質量。在遷移前修剪或改進薄弱頁面。
錯誤 #5：不更新內部連結
遷移後，在整個程式碼庫和 CMS 中 grep 任何對舊 URL 的參考。指向舊子網域 URL 的內部連結（301 重定向）有效，但不理想。直接連結總是比重定向鏈更好。
2026 年決策框架
這是我在為客戶提供建議時使用的框架。它並不複雜，但有效。
在以下情況使用子目錄：
- 內容旨在推動有機搜尋流量
- 內容是高質量的，反映良好於您的品牌
- 您可以管理基礎設施（即使意味著反向代理）
- SEO 是您業務的主要成長渠道
在以下情況使用子網域：
- 應用程式在身份驗證後面（無 SEO 價值）
- 內容是用戶生成的，可能質量低
- 監管或安全要求要求隔離
- 內容針對完全不同的受眾/語言，並且您有資源為該子網域獨立構建權限
混合方法（最常見）：
- SEO 關鍵內容 → 子目錄（
/blog、/docs、/resources） - 應用程式 → 子網域（
app.、dashboard.） - 暫存/開發 → 子網域（
staging.、preview.） - 支持/社區 → 逐案評估
如果您不確定，預設為子目錄。反向代理的工程成本是一次性投資。SEO 好處隨時間複利。
想幫助確定您網站的正確架構？我們在 無頭 CMS 和 Next.js 開發 參與期間正是做出這類決策。您也可以查看我們的 定價 或 直接聯繫 來討論您的具體情況。
常見問題
Google 將子網域視為單獨的網站嗎？
不完全是，但接近。Google 已確認在 Search Console 和爬蟲預算分配中，子網域被視為單獨的主機。儘管 Google 理解 blog.example.com 和 example.com 之間的關係，連結權益和品質信號在它們之間的流動不像在單一主機的子目錄結構內那樣。
將我的部落格從子網域遷移到子目錄值得嗎？
在大多數情況下是的──尤其是如果有機搜尋是您流量的重要渠道。數據一致地表明，在子目錄上的部落格在搜尋中的表現優於子網域上的部落格，所有其他條件相等。但遷移本身帶有短期風險（2-4 週的流量波動），所以用適當的 301 重定向和 Search Console 遷移仔細規劃。
我可以使用 Vercel 重寫而不是反向代理嗎？
絕對可以。Vercel 的 vercel.json 或 next.config.js 中的 rewrites 在邊界層充當反向代理。如果您的主要網站已經在 Vercel 上，這是一個很好的解決方案。您可以代理 /blog 路徑到完全獨立的應用程式託管在別處，從 Google 的角度，這一切看起來像一個統一的網站。
Google 識別子網域到子目錄遷移需要多長時間？
對於大多數 URL 在其新位置重新索引，通常需要 2-8 週。有更多頁面的較大網站需要更長時間。在 Google Search Console 中使用「位址變更」工具並提交更新的網站地圖可以加速這個過程。預期第 1-2 週排名暫時下降，然後恢復，通常改進。
子網域會影響 Core Web Vitals 分數嗎？
Core Web Vitals 按來源（協議 + 主機名 + 連接埠）測量。所以 blog.example.com 完全有獨立的 CWV 分數，與 example.com 分開。如果您的部落格速度快但主要網站速度慢，反之亦然，這可以是優勢，也可以是劣勢。使用子目錄，您的好頁面和壞頁面都貢獻於相同來源的 CWV 評估。
我可以為不同的目的同時使用子網域和子目錄嗎？
這實際上是 2026 年最常見和推薦的模式。將所有 SEO 關鍵內容放在子目錄中（/blog、/docs、/resources）。使用子網域用於應用程式、暫存環境以及您明確不想與您的主域名品質信號相關聯的任何內容。關鍵是對哪些內容放在哪裡有意圖。
子網域 vs 子目錄選擇會影響頁面速度嗎？
本身不會。頁面速度取決於您的託管、程式碼優化以及資產交付──而不是您的 URL 結構。但通過反向代理提供的子目錄添加少量延遲（通常 1-10ms）用於代理躍點。這在實踐中可以忽略不計。較大的頁面速度因素是您是否使用適當的框架──像 Astro 這樣的東西用於內容密集型網站將勝過重型 SPA，無論 URL 結構如何。
2025-2026 年數據對子網域 vs 子目錄 SEO 性能說了什麼？
多項大規模分析指向相同方向。Ahrefs 在 2024 年對 10,000+ 個網站的研究表明子目錄頁面的排名優於等效子網域頁面 60% 的時間。HubSpot 自己廣為引用的從子網域部落格到子目錄的遷移導致有機流量大幅增加。儘管相關性不等於因果性，但跨不同研究和案例研究的模式一致到足以使子目錄成為 SEO 關注內容的安全預設。