子網域 vs 子目錄 SEO：2026 工程指南
你的 DNS 指向 blog.example.com 到不同的主機。Google 爬蟲到達、索引 140 篇文章、分配網域權威分數——然後離開。它永遠不會將該內容與你的根域名連接。同時，你的競爭對手在同一域名上運行 /blog，複合每個反向連結，並為你寫得更好的查詢排名。
我已從子網域遷移了 11 個生產部落格到子目錄。我也根據單體性能需求將應用程式部分移到子網域。SEO 影響並不像任何一方宣稱的那樣——決定取決於三個變數，大多數指南都忽略了。
Google 的官方立場沒有太大改變——他們說他們可以處理兩者。但 Google 說的話和實際在搜尋結果中發生的事情是兩回事。本指南適用於需要做出決定並承擔後果的工程師和技術決策者。我們將涵蓋真實的 SEO 機制、基礎設施含義和 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 Web Search 對子網域或子目錄都沒問題。"
但他們沒有說的是："相等"並不意味著"相同"。Google 自己關於網站移動的文件承認從子網域移動到子目錄（反之亦然）被視為網站遷移——與從完全新網域移動到 oldsite.com → newsite.com 相同的類別。
想一想這一點。Google 對待 blog.example.com → example.com/blog 的重視程度與 oldsite.com → newsite.com 相同。這單獨告訴你這些在 Google 的系統中不是等價的。
截至 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 好處，以及獨立部署的工程靈活性。這是我們在大多數 headless 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 方面。
Headless CMS 和子目錄優勢
如果你正在運行 headless CMS 設置——在 2026 年，你可能應該——子目錄方法自然與現代框架的工作方式相一致。
使用 Astro、Next.js 或 Nuxt 等工具，你可以從 CMS（Sanity、Contentful、Strapi 等）獲取內容並在任何你想要的 URL 路徑上呈現。沒有技術原因你的部落格需要在子網域上。
典型的 headless 架構：
Contentful (CMS)
↓ API
Next.js (前端)
├── / (行銷頁面)
├── /blog (CMS 驅動的部落格)
├── /docs (CMS 驅動的文件)
└── /resources (CMS 驅動的資源)
一切都位於一個域名下。一個部署。一組性能優化。一個域名權威性分數。
這種方法的妙處在於你獲得 headless CMS 的內容管理靈活性，以及統一域名結構的 SEO 好處。這是我們在 Social Animal 推動客戶採用 headless 架構的主要原因之一。
反向代理模式：獲得兩者
讓我逐步介紹我們最常為中型到企業客戶使用的模式，他們需要獨立部署和統一 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：不更新內部連結
遷移後，grep 整個代碼庫和 CMS，尋找對舊 URL 的任何引用。指向 301 重定向的舊子網域 URL 的內部連結有效，但不理想。直接連結總是比重定向鏈更好。
2026 年決策框架
以下是我在建議客戶時使用的框架。這並不複雜，但有效。
使用子目錄當：
- 內容旨在驅動有機搜尋流量
- 內容品質高，反映好你的品牌
- 你可以管理基礎設施（即使意味著反向代理）
- SEO 是你業務的主要增長渠道
使用子網域當：
- 應用程式在身份驗證後（無 SEO 價值）
- 內容是用戶生成且可能品質低
- 監管或安全要求需要隔離
- 內容以完全不同的受眾/語言為目標，並且你有資源為該子網域獨立建立權威性
混合方法（最常見）：
- SEO 關鍵內容 → 子目錄（
/blog、/docs、/resources） - 應用程式 → 子網域（
app.、dashboard.） - 預備/開發 → 子網域（
staging.、preview.） - 支持/社群 → 逐案例評估
如果你不確定，預設為子目錄。反向代理的工程成本是一次性投資。SEO 好處隨著時間複合。
想幫助弄清楚適合你的網站的正確架構？我們在我們的 headless 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 識別子網域到子目錄遷移需要多長時間？ 通常 2-8 週用於大多數 URL 在其新位置被重新索引。有更多頁面的更大網站需要更長時間。在 Google Search Console 中使用位址更改工具並提交更新的網站地圖可以加快速度。預期在第 1-2 週有臨時排名下降，然後恢復，通常改善。
子網域是否影響核心網頁生命週期分數？
核心網頁生命週期按起源（協議 + 主機名 + 埠）測量。所以 blog.example.com 具有與 example.com 完全不同的 CWV 分數。如果你的部落格很快但主網站很慢，這可以是優勢，或反之亦然是劣勢。使用子目錄，你的好頁面和壞頁面都貢獻到同一起源的 CWV 評估。
為不同目的同時使用子網域和子目錄怎樣？
這實際上是 2026 年最常見和推薦的模式。將所有 SEO 關鍵內容放在子目錄中（/blog、/docs、/resources）。為應用程式、測試環境和任何你明確不想與主域名的品質信號相關聯的內容使用子網域。關鍵是有意識地決定哪些內容去向哪裡。
子網域 vs 子目錄選擇是否影響頁面速度？ 從根本上沒有。頁面速度取決於你的託管、代碼優化和資產傳遞——而不是你的 URL 結構。但是，通過反向代理提供的子目錄添加少量延遲（通常 1-10ms）用於代理跳。這在實踐中是可忽略的。更大的頁面速度因素是你是否使用適當的框架——像 Astro 這樣的東西用於內容繁重的網站將超越重型 SPA，無論 URL 結構如何。
2026 年數據關於子網域 vs 子目錄 SEO 性能說什麼？ 多個大規模分析指向相同方向。Ahrefs 2024 年對 10,000+ 網站的研究顯示子目錄頁面60% 的時間比同等子網域頁面排名更高。HubSpot 自己廣泛引用的從子網域部落格遷移到子目錄的遷移導致有機流量顯著增加。儘管相關性不是因果關係，但跨不同研究和案例研究的模式一致性足夠，子目錄是 SEO 關注內容的更安全預設。