為什麼這個技術決策影響 GEO ROI
「我們的部落格要放在 blog.company.com 還是 company.com/blog/？」
這個看似純技術問題，直接影響 GEO 訊號集中度。多年累積的部落格內容、媒體連結、外部背書——這些是計入主站還是分散到子網域，最終差距可能是主站權威分數的 30–50%。
業界常見的失誤：企業十年累積的部落格放在 blog.company.com，跟主站幾乎沒互通——導致 AI 評估「公司內容深度」時看不到部落格的累積。
下面拆 4 種架構與決策依據。
架構 1：子目錄 — 訊號集中度最高（推薦預設）
結構
example.com/
├── /blog/ ← 部落格
├── /docs/ ← 文件
├── /pricing/ ← 定價
├── /about/ ← 關於
└── /zh/ ← 多語版
為什麼 GEO 訊號集中度高
對搜尋引擎與 AI 而言，整個站是一個實體：
- 域名年資 被所有路徑共享（
/blog/從第一天就繼承主站的 5 年年資） - 外部連結 直接灌到主域名，所有路徑享受連結權威
- 內部連結 在同域名內最自然（
/blog/post-1連到/products/abc是同站連結，AI 視為「主題網狀」） - schema.org
Organization一份就涵蓋全站
對 GEO 的具體影響
- 內容可引用性 / E-E-A-T：部落格的作者署名直接灌注到整站 E-E-A-T 評估
- 站外能見度：媒體報導
example.com/blog/post與報導example.com/products/abc都加分到同一個 domain - Wikipedia 對齊：Wikipedia 條目中的官網連結指向
example.com，所有路徑都受惠
適合場景
95% 的網站應該用這個。除非有具體強烈理由（見下面其他架構），預設就走子目錄。
工程考量
技術實作可能比子網域稍麻煩：
- 需要反向代理（Nginx / Apache）路由
/blog/到部落格服務 - CDN 設定要小心快取規則
- 同源政策下部分跨子路徑的權限管理
但這些都是可解決的工程問題，不該成為架構決策的理由。
架構 2：子網域 — 訊號分散，特殊需求才用
結構
example.com ← 主站（產品 / about / pricing）
blog.example.com ← 部落格
docs.example.com ← 文件
support.example.com ← 客服
zh.example.com ← 中文版
Google / AI 怎麼看子網域
歷史上 Google 對子網域的態度不一致：
- 2007–2015：子網域獨立計算 PageRank（基本上等同獨立站）
- 2016 後：Google 偏向把子網域視為同站的一部分（Matt Cutts 多次澄清）
- AI 引用時代：訓練爬蟲（GPTBot / CCBot）對子網域的處理仍偏獨立——因為它們以 registered domain 為單位做主機級評估
結論：對 GEO，子網域比 Google 想像的更獨立。blog.example.com 累積的權威，不會完整傳遞到 example.com。
適合用子網域的特殊情境
情境 A：子站有獨立法律 / 業務實體
- 集團下不同子公司各有獨立 brand
- 各 brand 有獨立合約 / 客戶 / 收入結構
- Wikipedia 上各 brand 各有條目
→ 此時用子網域反映「真的是獨立實體」是對的。
情境 B：技術上分散部署不可避免
- 主站用 Cloudflare，文件用 ReadTheDocs（自動 host 在 ReadTheDocs 子網域）
- Status page 用第三方服務（必須用該服務的子網域）
→ 工程現實，可接受。
情境 C：地理 / 語言獨立經營
us.example.com由美國團隊獨立營運，內容、定價、服務都跟主站不同- 不只是翻譯，是完全不同的市場 entity
→ 子網域反映實際情況。
不適合用子網域的情境
最常見的誤判：
❌ 「部落格獨立子網域比較專業」 — 純粹形象想像，沒有實際 GEO 好處
❌ 「文件用子網域比較好分團隊管理」 — 內部組織問題不該寫進對外架構
❌ 「我看大公司都用 blog.company.com」 — 大公司可以承擔訊號分散，你不一定可以
❌ 「多語版用語系子網域才正規」 — 子目錄 + hreflang 對 GEO 更好
架構 3：多站獨立 — 真有不同實體才用
結構
brand-a.com ← 完全獨立的 A 品牌
brand-b.com ← 完全獨立的 B 品牌
company.com ← 控股公司（如有）
適合場景
- 集團經營多個完全不同的 brand（如：寶僑經營汰漬、佳潔士、海倫仙度絲，三者完全獨立網域）
- 各 brand 的目標客戶、產品線、市場定位都不重疊
- 各 brand 都有獨立 Wikipedia 條目 / 媒體報導歷史
GEO 的處理
每個獨立站都需要完整 GEO 路線：
- 各自的 Organization schema
- 各自的權威累積
- 各自的 Wikipedia notability 評估
→ 工程量是子目錄方案的 N 倍（N = 獨立站數量）。
不適合的情境
❌ 同一公司開不同小品牌玩試水溫 — 預算與時間根本不夠 ❌ 產品線多樣 — 應該在同一域名下用 /products/ 子目錄 ❌ 跨地區市場 — 多數情況用子目錄 + hreflang 比較好
架構 4：混合模式 — 建議避免
反例
example.com ← 主站
blog.example.com ← 部落格在子網域
example.com/products/ ← 但產品在子目錄
zh.example.com ← 中文在子網域
example.com/en/ ← 但英文在子目錄
shop.example.com ← 但購物又是子網域
為什麼這是最差的
這種混合通常源於：
- 不同時期不同團隊各做各的決定
- 收購其他公司後沒整合
- 「先這樣做，以後再說」的技術債累積
對 GEO 的傷害：
- 訊號分散到無法收斂：主站的權威傳遞路徑不可預測
- AI 對「整站架構」評估降權：偵測到混亂架構通常代表組織問題
- 跨平台對齊困難：Wikipedia / LinkedIn / 媒體該指哪個域名變模糊
修法
把所有架構收斂到一致——選擇一條路（子目錄為主）然後遷移。
遷移成本（短期 SEO/GEO 跌幅 + 工程重整）通常比長期混亂的成本低。
多語版的特殊決策
多語網站有額外考量。三種選擇：
選擇 1：子目錄（推薦）
example.com/zh/page
example.com/en/page
example.com/ja/page
- 配
<link rel="alternate" hreflang="..."> - 主站權威集中在
example.com - 適合大多數場景
選擇 2：語系子網域
zh.example.com/page
en.example.com/page
ja.example.com/page
- 配 hreflang
- 各語系獨立爬取頻率
- 適合各語系團隊獨立營運、內容差異大
選擇 3：國家獨立網域
example.com ← 全球 / 美國
example.com.tw ← 台灣
example.co.jp ← 日本
example.de ← 德國
- 配 hreflang
- 適合真的有國家本地化業務、各國有獨立法律 / 公司主體
決定關鍵
| 你的情況 | 建議 |
|---|---|
| 不同語系內容大致翻譯一致 | 子目錄 |
| 不同語系有獨立團隊與獨立內容策略 | 語系子網域 |
| 不同國家有獨立法律 / 業務實體 | 國家獨立網域 |
| 全部都符合最後一項但你只有 5 個人 | 子目錄（量力而為） |
4 個常見決策錯誤
錯誤 1：根據「看大公司怎麼做」決定
「Google 用 blog.google 子網域，我們也用」——你不是 Google。Google 有資源養多個獨立網域的權威，你可能沒有。
錯誤 2：依「現在後端方便」決定
「Wordpress 在這個 server，主站在另一個 server，分子網域好部署」——這是工程便利凌駕 GEO 訊號的典型錯誤。寧可工程稍麻煩也要架構正確。
錯誤 3：怕子目錄影響部落格獨立性
「部落格內容跟主站業務不同，分子網域比較不會混淆使用者」——這是心理錯覺。使用者進到 example.com/blog/ 不會困惑，AI 也不會。反而 blog.example.com 讓 AI 把部落格與主站視為弱相關。
錯誤 4：先做了混合架構才發現需要遷移
最痛的時機是：營運 5 年後，累積了 1000+ 篇文章，發現架構錯了。
→ 預防方法：架構決定要在前期 1–2 年內定型。架構決定要審慎，但決定後就堅持，避免演進成混合模式。
子網域到子目錄的遷移技術細節
如果你已經是子網域，要遷移到子目錄：
步驟 1：建好新路徑（不刪舊）
- 主站開
/blog/路徑，內容跟blog.example.com同步 - 兩邊並存，先確認內容對應正確
步驟 2：301 永久重定向
blog.example.com/post-1 → 301 → example.com/blog/post-1
blog.example.com/post-2 → 301 → example.com/blog/post-2
每個舊 URL 必須一一對應——不能批量導到首頁。
步驟 3：通知 Google / Bing
- Google Search Console 提交 Change of Address
- Bing Webmaster Tools 同樣動作
- 更新 sitemap.xml
步驟 4：等待索引重建
- 通常需要 3–6 個月看到完整效果
- 過渡期 SEO 流量會有 10–30% 跌幅，要先告知老闆心理準備
- AI 訓練語料更新需要等下一代模型（6–18 個月）
步驟 5：保留 301 至少 1 年
- 不要急著關掉舊子網域 DNS
- 至少維持 12 個月給長尾流量導向新位置
第一步：盤點你目前的架構
跑下面三個檢查：
- 你網站有幾個子網域 / 跨網域資產？ 全部列出來
- 它們之間的內容互通嗎？ 主站 footer 有連到子網域嗎？反向呢？
- 媒體 / Wikipedia / LinkedIn 上你的官網是哪個？ 一致嗎？
如果你發現「混合模式」狀況，架構整理應該排在內容生產之前。
👉 跑 GeoWeb 健檢看單頁分數 — 健檢看單頁訊號，但整站架構問題需要全站盤點才能評估。
如果你想做完整的網站架構診斷與遷移路線圖（含子網域整併、多語架構選型、301 重定向策略、索引遷移計畫），這是 GEO 顧問服務的範圍：[email protected]
GEO 深度系列。前一篇：「SSR / SSG / SPA — 你的渲染方式正在決定 AI 能不能引用你」