URL 結構設計指南：六個原則、子目錄決策與改版流程

URL 結構是什麼？搞清楚這個 SEO 基礎

URL 結構是指一個完整網址的各組成部分的排列方式，包含協定（Protocol）、網域（Domain）、路徑（Path）、查詢字串（Query String）四個主要元素。這個排列方式不只決定了訪客看到的網址長什麼樣，也直接影響 Google 爬取和理解你頁面的方式。

很多人把 URL 當成純粹的「地址」，一旦設定好就不再多想。但實際上，URL 結構是 Google 爬蟲在讀取你的頁面之前，最先接收到的語意信號之一。把這個信號設計好，等於在 Google 讀內容前就幫它做了一次方向校準。

URL 的五個組成部分

用一個真實的範例來拆解：

https://akseolabs.com/blog/url-structure-guide?ref=newsletter#faq

• 協定（Protocol）：https://。告訴瀏覽器和爬蟲使用加密連線。HTTP 和 HTTPS 對 Google 而言是不同的 URL。
• 網域（Domain）：akseolabs.com。你的網站識別身份，也是 PageRank 累積的基礎單位。
• 路徑（Path）：/blog/url-structure-guide。描述頁面在網站中的位置和內容主題，是 URL 設計的核心。
• 查詢字串（Query String）：?ref=newsletter。問號後面的參數，通常用於追蹤或篩選。如果是主要內容頁，最好避免查詢字串出現在 URL 中。
• 錨點（Fragment）：#faq。讓頁面跳到特定位置。Google 爬蟲不讀取 fragment，所以這部分對爬取索引沒有影響。

這五個部分各有分工。在 SEO 能發揮的空間，主要集中在「路徑」，其次是「協定」（HTTPS）。網域是長期品牌資產，改起來成本最高；查詢字串則是要盡量讓主要內容頁遠離它的地方。

Google 怎麼讀 URL：不只是地址，是語意信號

Google 的爬蟲並不是先讀完你的頁面才知道這篇文章在講什麼，URL 路徑是它的第一個資訊來源。路徑中的每個片段（segment）對 Google 來說都是一個 topic signal，協助它在爬取前預判頁面的主題和位置關係。

這不是什麼神秘機制。Google 的官方文件明確寫道：「過於複雜的 URL，尤其是含有多個參數的 URL，可能會導致 Googlebot 爬取問題，消耗更多頻寬，並妨礙頁面被完整索引。」這段話說明的是，URL 的複雜程度直接影響 Google 願意投入多少爬取資源。

具體來說，有三個機制你應該知道：

• 路徑深度影響爬取頻率：越靠近根目錄的頁面（路徑層級淺），通常被爬取的頻率更高。/blog/url-seo 比 /resource/guide/category/2026/url-seo-tips 更容易被定期爬取。
• 查詢字串會製造 URL 爆炸：一個帶有多個篩選參數的頁面（例如電商的 ?color=red&size=L&sort=price&page=3）可以衍生出幾千個 URL，全部指向相似或相同的內容。這對 crawl budget 是一種浪費，也會稀釋主要頁面的信號強度。
• URL 路徑幫助建立主題關聯：路徑 /blog/seo/keyword-research 告訴爬蟲：這是一個 blog，屬於 SEO 主題，具體是關鍵字研究。這個層級關係輔助 Google 理解站內的主題架構，對 topical authority 的建立有間接貢獻。

多數競品只說 URL 會「影響 SEO 排名」，但沒說清楚影響的是哪個環節。URL 對直接排名的影響有限，它的主要價值在於爬取效率、用戶體驗、以及間接的 CTR 信號。把這個層次搞清楚，你才不會因為 URL 沒設好就以為整個 SEO 垮掉，也不會因為 URL 設好了就以為萬事大吉。

設計 SEO 友善 URL 的六個原則

SEO 友善 URL 的核心邏輯只有一個：對人可讀，對機器可解析，路徑短而有意義。以下六個原則按優先度排列，每條都附上背後的運作機制。

1. 全部用小寫英文字母

   Linux 伺服器預設大小寫敏感，/Blog/What-Is-SEO 和 /blog/what-is-seo 會被視為兩個不同頁面，可能產生重複內容問題。即使你的伺服器目前不敏感，這個問題在系統升級或遷移後很容易浮現。從一開始就統一全小寫，比事後修正省力太多。

2. 用連字號（-）分隔詞語，不用底線（_）

   這是 Google 官方明確建議的做法。Google 把連字號當作「詞語分隔符」，把 keyword-research 解讀為兩個詞「keyword」和「research」；底線則被當作「詞語連接符」，keyword_research 在爬蟲眼中是一個合成詞 keywordresearch。你的路徑如果用底線，等於讓 Google 讀不懂你想表達的個別關鍵字。

3. URL 要短，但每個詞都要有意義

   Backlinko 分析超過 400 萬個 Google 搜尋結果的數據顯示：包含關鍵字的 URL 比沒有關鍵字的 URL，CTR 高出約 45%。但長度也有上限：建議整條 URL 不超過 75 個字元，路徑部分盡量在 40 字元以內。判斷標準很簡單：去掉某個詞後，路徑的意思還是清楚的嗎？如果是，就去掉它。/blog/seo-keyword-research-guide-for-beginners-2026 可以精簡成 /blog/seo-keyword-research，兩者意思一樣，短的那個對用戶和爬蟲都更友善。

4. 路徑層級控制在 3 層以內

   層級越深，爬取頻率越低，PageRank 往下流動也會有遞減效應。合理的結構是：/blog/文章-slug（2 層）或 /blog/category/文章-slug（3 層）。如果你的網站真的需要更深的層級（例如大型電商），一定要搭配完整的 sitemap.xml 和充足的 internal links，確保深層頁面有足夠的爬取入口。

5. 主要內容頁避免查詢字串

   查詢字串（?id=123&category=seo）對動態網站來說是必要的，但如果出現在主要內容頁的外部 URL 或被 Google 索引的路徑中，會製造重複內容風險。解決方式：用靜態路徑結構替代動態參數（/blog/seo-guide 而非 /article.php?id=45），或在 robots.txt 中阻止含特定參數的 URL 被爬取。查詢字串用在 UTM 追蹤或用戶偏好設定（語言、排序）是可以的，但這些 URL 通常不應該被索引。

6. 使用 HTTPS 協定

   Google 在 2014 年正式確認 HTTPS 為排名信號。更直接的影響是瀏覽器體驗：Chrome 對非 HTTPS 網站顯示「不安全」警告，直接衝擊使用者信任和 CTR。在 2026 年，HTTP 已經不是選擇題，而是最低門檻。如果你的網站還沒有 HTTPS，這是目前最值得立刻修正的技術問題之一。

這六個原則不需要一次全部改，但如果是新建網站，應該從一開始就全部採用。已有的網站如果要改，參考後面的「URL 改版五關卡」章節再動手。

子目錄 vs 子網域：一張讓決策不後悔的比較表

在大多數情況下，子目錄（subfolder）對 SEO 更有利；但「大多數情況」有例外，而且這個例外很多人忽略了。

比較維度	子目錄（/blog/、/zh-tw/）	子網域（blog.example.com）
PageRank 繼承	直接繼承主網域的連結權重	獨立累積，不繼承主網域
爬取資源	共用主網域的 crawl budget	Google 視為獨立網站，各自分配
排名建立時程	較快（2-3 個月）	較慢（需從零重建）
技術維護	統一管理，複雜度低	需個別維護 SSL、設定等
適合場景	部落格、多語言版本、內容區塊	完全獨立的服務或應用程式

數據面的支撐：Backlinko 分析 1,180 萬筆 Google 搜尋結果，發現子目錄頁面在競爭性關鍵字上的排名表現一致優於子網域。一個實際案例是：有研究紀錄顯示，將 blog 從子網域遷移至子目錄後，相同內容在四個月內帶來約 34% 的自然流量成長。

機制上的原因很直接：Google 把子目錄視為主網域的一部分，主網域積累的 PageRank 和 E-E-A-T 信號可以直接流入子目錄。子網域則被當作獨立的網站實體對待，需要重頭建立爬取歷史和連結信任。

那什麼時候用子網域是合理的？

• 完全獨立的服務：例如 shop.brand.com（完全不同的產品線，有獨立的技術團隊和品牌定位）
• 用戶生成內容平台：例如 GitHub Pages 的 username.github.io，每個用戶各自擁有自己的子網域
• 明確不想要主網域 SEO 連結的場景：例如測試環境、暫存站

如果你的情境是：「部落格想獨立運作」「多語言版本」「行銷活動專區」，這些全部用子目錄就對了。

多語言的特別說明：Google 建議用子目錄搭配 hreflang 標籤（例如 /zh-tw/、/en/），而不是子網域。這樣語言版本可以共享主網域的 authority，也讓爬取更有效率。如果想深入了解重複頁面的處理策略，Canonical 標籤的設定方式是另一個你需要掌握的工具。

URL 用中文還是英文？台灣的選擇情境

Google 兩種都能讀，技術上沒有絕對對錯。但你的外連策略和追蹤需求，決定了哪個更實際。

中文 URL 的問題不是 Google 不懂，而是它在被分享或引用時，會自動轉成 Percent-encoding：

/blog/SEO關鍵字研究 → 在超連結和大部分後端日誌裡變成 /blog/SEO%E9%97%9C%E9%8D%B5%E5%AD%97%E7%A0%94%E7%A9%B6

這個問題有幾個實際影響：

• 外部網站引用你的連結時，那串 % 碼會原封不動地出現在錨文字或周邊文本中，降低連結的語意清晰度
• 在 Google Search Console 的 URL 報告、GA4 的頁面路徑報告裡，中文路徑通常顯示為 encoded 格式，追蹤時容易混亂
• 複製連結分享時，不同裝置和應用程式的解碼行為不一致，偶爾出現連結斷掉的情況

我個人的看法是：即使你的目標受眾完全是台灣用戶，英文 slug 在技術層面的管理成本更低。/blog/seo-keyword-research 在任何環境下都是可讀的，不需要擔心 encoding 問題。

但是，有一個值得考慮的例外：如果你的網站是純在地服務（例如台北某家診所、特定縣市的服務商），而且你沒有任何對外獲取 backlink 的需求，那中文 slug 在搜尋結果摘要中的顯示效果有時更自然，使用者掃到中文路徑比英文路徑更直覺地知道頁面在講什麼。

決策框架很簡單：有外連計畫或任何國際曝光可能性，用英文。純在地、不靠 backlink 的服務型網站，中文可接受。Pinyin（拼音）在兩種情境下都不建議，因為對用戶和爬蟲都沒有語意優勢。

改 URL 不掉排名：這五個步驟都要做

URL 一旦有排名和流量，改版是高風險操作。但「只設 301 轉址」是最常見的不完整做法。以下是我整理的「URL 改版五關卡」，每一關都有具體的執行和驗證方式。

1. 建立完整 URL 清單（不能靠記憶）

   從 Google Search Console 匯出「已索引頁面」清單，篩選出有自然流量的 URL。搭配 Screaming Frog 或 Sitemap.xml 補上所有已爬取的路徑。這份清單是改版的地圖，沒有它你不知道自己改了多少、漏了哪些。

2. 製作 1:1 轉址對應表

   每個舊 URL 必須對應到唯一的新 URL，不允許多個舊頁面都指向同一個新頁面（這會傳遞混亂的語意信號）。如果某些舊頁面在新架構中不再存在，要判斷最相關的替代頁是哪一個，而不是全部導回首頁。把對應關係存成試算表，清楚標注優先度和實施時程。

3. 設定 301 轉址，禁止轉址鍊

   301 是「永久轉址」，Google 官方確認 301 會傳遞 PageRank（但因為 PageRank decay 的設計，每一跳都有小幅損耗）。這裡最關鍵的問題是：轉址鍊（redirect chain）的代價比你想像的大。每多一跳，大約損失 15% 的 PageRank 信號；三跳的鍊，累積損失接近 38%。實作前先確認沒有「舊 URL A → 中間舊 URL B → 新 URL C」這種鍊式結構。

4. 更新所有站內 internal links（這是最多人跳過的一步）

   這是我看到客戶改版後流量下滑的最常見原因。設了 301 但忘了更新站內連結，等於你的每一個 internal link 都還指向舊 URL，每次訪客或爬蟲點擊都要多走一跳。這不只是速度問題，也是 PageRank 流動效率的問題。更新完 301 之後，用 Screaming Frog 重新爬一遍，確認全站 internal links 已更新為新 URL，沒有任何一條還在用舊路徑。

5. 更新 Sitemap.xml 並在 GSC 重新提交

   舊 Sitemap 還列著舊 URL 是一個很常見的遺漏。更新 Sitemap 後，到 Google Search Console → Sitemaps，提交新版 Sitemap，讓 Google 知道新的 URL 清單。如果你有重要頁面，也可以用 GSC 的「URL 檢查工具」手動要求重新索引，加速 Google 更新索引記錄。

改版完成後，建議追蹤 6-8 週。重點觀察 GSC 的「已排除頁面」報告，確認舊 URL 沒有在索引中持續出現，新 URL 的索引數量正常成長。如果發現某些舊 URL 仍然有索引但流量在下降，通常是因為 301 設了但 Google 還沒完全接受新 URL，這種情況等待即可；如果發現流量直接消失，先檢查是否有轉址錯誤或新 URL 被 robots.txt 封鎖了。

更多關於 URL 排名信號在整體技術 SEO 架構中的位置，可以參考 SEO 排名因素完整解析，那篇文章有 URL 相關因素在全排名體系中的比重說明。

網站改版或新建架構，最怕的就是 URL 設計在初期就埋下技術債？我們從現有網站的爬取結構出發，幫你找出 URL 設計缺口，規劃改版路線。了解我們的技術 SEO 顧問服務，看是否符合你目前的需求。

URL 結構真的會影響 SEO 排名嗎？

有影響，但不是主要因素。URL 的直接排名影響相對有限，它的主要價值在於：爬取效率（清晰的 URL 讓 Googlebot 爬取更順暢）、CTR（含關鍵字的 URL 在搜尋結果中點擊率更高，Backlinko 數據顯示差異約 45%）、以及 PageRank 流動效率（路徑深度和轉址鍊會影響連結權重傳遞）。把 URL 設計好是 SEO 的基礎建設，不是排名魔法。

URL 要用中文還是英文？

兩者 Google 都能讀。但中文 URL 在分享和外連引用時會轉成 Percent-encoding（%E4%B8%AD%E6%96%87），在 GSC 和 GA4 的追蹤報告中也較難閱讀。如果你的網站有外連建置計畫或任何國際曝光可能，建議用英文 slug。純在地、不依賴 backlink 的服務型網站，中文也可以接受，但 Pinyin（拼音）在任何情境下都不建議。

URL 越短越好嗎？有沒有長度限制？

短但有意義，不是短而無意義。建議整條 URL 不超過 75 個字元，路徑部分盡量在 40 字元以內。關鍵不是一味刪短，而是去掉不影響語意的詞（年份、冠詞、停用詞）。/blog/url-structure 和 /blog/url-structure-seo-best-practices-complete-guide-2026 比起來，前者更好；但 /blog/url 這樣過於簡短的路徑，反而沒有足夠的語意信號。

子目錄和子網域哪個對 SEO 比較好？

多數情況下子目錄更好。子目錄直接繼承主網域的 PageRank 和 E-E-A-T 信號；子網域在 Google 眼中是獨立網站，需要從零建立。Backlinko 分析 1,180 萬筆結果顯示子目錄在競爭性關鍵字的排名上一致優於子網域。例外情境：完全獨立的服務（不同產品線、不同用戶群）才考慮子網域。部落格、多語言版本、行銷活動頁，全用子目錄。

改了 URL 只要設 301 轉址就夠了嗎？

不夠。設 301 只是五個步驟中的第三步。很多人設了 301 但忘了更新站內 internal links，導致每一個站內連結點擊都還要多走一跳，既增加爬取負擔，也讓 PageRank 流動效率下降。完整流程：建立 URL 清單 → 製作對應表 → 設 301（無轉址鍊）→ 更新站內連結 → 更新 Sitemap + GSC 重新提交，加上 6-8 週監控。

查詢字串（?id=123）會影響 SEO 嗎？

會，特別是大量查詢字串組合造成的 URL 爆炸問題。電商的篩選功能（顏色、尺寸、排序、頁碼）可以組合出成千上萬個 URL，稀釋爬取資源並產生重複內容。解決方式：主要內容頁用靜態路徑，篩選參數頁面用 robots.txt 排除爬取，或用 Canonical Tag 指向主頁面。UTM 追蹤參數（?utm_source=newsletter）不會被 Google 用於索引，但要確認在 GSC 中的 URL 處理設定是否正確。

連字號（-）和底線（_）有什麼差別？

Google 把連字號當詞語分隔符，把底線當詞語連接符。keyword-research → Google 讀到「keyword」和「research」兩個詞；keyword_research → Google 讀到「keyword_research」這個合成詞，等於你的個別關鍵字消失了。這個差別對中文路徑影響較小（中文本身不需要分隔），但對英文路徑影響很直接。如果你的路徑是英文，用連字號。

URL 路徑層級最多幾層比較好？

一般內容網站建議 2-3 層（/blog/slug 或 /blog/category/slug）。超過 3 層的 URL 路徑，爬取頻率通常會下降，PageRank 往深層頁面流動的效率也會降低。大型電商如果必須有更深的層級，需要搭配完整的 sitemap.xml 和豐富的 internal links 確保深層頁面有足夠爬取入口。核心原則：每多一層路徑，你就要多投入一些「爬取維護成本」。

URL 大小寫要統一嗎？

一定要統一，而且統一為全小寫。Linux 伺服器大小寫敏感，/Blog/Article 和 /blog/article 是兩個不同頁面，有重複內容風險。更現實的問題是：多人維護的網站或 CMS 如果沒有強制規則，路徑大小寫很容易在日積月累中出現不一致。建議在伺服器層（Nginx/Apache）設定強制小寫轉址，或在 CMS 層統一過濾。

現有網站的 URL 結構很亂，需要大改嗎？

不一定，要看「亂」的程度和流量的大小。如果已有排名流量，輕易大改 URL 風險很高，即使做足 301 也可能有 2-3 個月的排名波動期。建議先評估：有沒有無法索引的深層 URL？有沒有大量查詢字串頁面被索引？有沒有大小寫混亂的重複頁面？這些才是需要優先處理的問題，而不是「路徑不夠漂亮」。新建網站或尚無流量的網站，現在就設計好架構，代價最小。詳細的技術 SEO 排查方式可以參考 PageSpeed Insights 教學 裡的核心網站健康指標章節。