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

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

URL 結構是一個完整網址中各組成部分的排列方式，主要包含協定、網域、路徑、查詢字串與錨點。它影響可分享性、路由、重複 URL 管理與搜尋系統理解頁面的線索，但不是在內容讀取前就決定排名的單一信號。

URL 在 SEO 流程中的位置

URL 是頁面可發現、路由與重複管理的一部分。搜尋系統會透過連結、sitemap 與抓取請求發現 URL，再讀取頁面內容；不要把 URL 寫成在內容之前完成排名判斷的單一語意信號。

Google 會從連結與 sitemap 等入口發現 URL，再依資源與系統判斷抓取、渲染、索引與服務；URL 的可讀性與一致性有助於管理，但不能推論爬蟲已依路徑先判定頁面主題或優先順序。

URL 的五個組成部分

用一個真實範例拆解：https://akseolabs.com/blog/url-structure-guide?ref=newsletter#faq。協定 https:// 告訴瀏覽器與爬蟲使用加密連線。HTTP 與 HTTPS 對 Google 而言是不同的 URL；網域 akseolabs.com 是主機名稱；不要把它寫成 PageRank 累積的單一基礎單位。

路徑 /blog/url-structure-guide 可表達網站自己的分類與頁面用途。查詢字串常用於追蹤、篩選或排序；主要內容頁應先決定 canonical、內鏈與可索引版本，不是所有含參數 URL 都必須移除。

錨點 #faq 讓頁面跳到特定位置，但 Google 爬蟲不讀取 fragment，所以這部分對爬取與索引沒有影響。五個部分各有分工；路徑、協定與主機設定都是可管理的技術面向，實際搜尋表現仍要和內容、索引與使用者資料一起判斷。網域是長期品牌資產，改起來成本最高；查詢字串則要盡量讓主要內容頁遠離它。

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

URL 同時是瀏覽器定位資源、網站路由與搜尋系統管理版本的輸入。Google 會依連結、sitemap、伺服器回應與頁面內容處理 URL；路徑可提供辨識線索，但不能寫成 Googlebot 在讀取內容前就預判主題或排名。

Google 說過於複雜、含大量參數的 URL 可能造成抓取與索引問題；這是風險提醒，不是每一層路徑都必然降低爬取頻率。實務上應分別檢查參數組合、重複內容、canonical、內鏈與實際 Search Console／伺服器資料。

路徑深度如何影響爬取頻率

路徑深度只是結構描述，沒有通用證據能把層數直接換算成爬取頻率或優先佇列。比較深的路徑若仍有清楚內鏈、sitemap、穩定回應與可索引內容，不應僅因斜線數量判定為問題。

複雜度可能來自大量參數、重複版本與無法管理的路由，不等於單純的目錄深度。重要頁面應有可追蹤的內鏈與 sitemap 入口；是否需要調整，要以實際抓取、索引與使用者導覽資料判斷。

查詢字串如何造成 URL 爆炸

查詢字串是 URL 中問號之後的參數組合，常見於電商與新聞網站，用來記錄篩選條件、排序方式與分頁狀態。以一個商品列表頁為例，?color=red&size=L&sort=price&page=3 四個參數同時出現，系統就會為每一種排列組合建立對應的 URL。若這些選項可以自由組合，單一列表頁可能衍生出數千個 URL；是否形成問題要看實際內容差異、索引版本與站內管理方式。

大量近似 URL 會增加抓取、索引、canonical 與報表管理的複雜度；不同參數 URL 也可能被分開發現與評估。若參數真的產生近似版本，應以 canonical、內鏈、sitemap 及適當的伺服器／CMS 規則管理，不能把所有參數都寫成會稀釋排名。因此，若參數造成大量近似 URL，應用 canonical、內鏈、sitemap 與必要的伺服器／CMS 規則管理；不要把所有查詢字串都當成會稀釋排名的同一類問題。

第三個面向是資訊架構。以 /blog/seo/keyword-research 為例，路徑可讓使用者與維護者辨識內容類型與分類；搜尋系統是否採用這些線索，仍要和頁面內容、內鏈與索引結果一起驗證。這種路徑可作為站內資訊架構與內容規劃的線索，但不能宣稱它單獨建立 Google 的 topical authority 或排名權重。

URL 的主要價值在可讀性、路由、重複版本管理與使用者辨識；它不是單一排名公式，也不能由 URL 直接推導 CTR 或成效。將 URL 問題和內容、索引、內鏈及商業重要性分開診斷，才能決定是否值得改版。

設計 SEO 友善 URL 的六個原則

SEO 友善 URL 的核心邏輯只有一個：對人可讀，對機器可解析，路徑短而有意義。六個原則依照影響範圍可以分成兩組：結構層決定爬蟲如何看待目錄與層級，標記層決定爬蟲如何拆解每一段字元。先定結構，再管標記，URL 才能在維護、分享與版本管理上更穩定；搜尋結果與抓取表現仍需用實際資料驗證。

結構層原則

結構層處理的是 URL 的形狀。大型網站可能需要管理 crawl demand 與重複 URL，但不能把「每個網站都有固定 crawl budget」或路徑深度、PageRank、排名下降寫成通用因果。應先看實際抓取、內鏈、索引與頁面品質。URL 中有描述性的詞可幫助使用者辨識頁面，但沒有必要把未核對的第三方百分比當成 CTR 預期，也沒有公開公式能證明路徑變長會稀釋每個詞的權重。結構層的任務，就是在「短」與「有意義」之間找到平衡。

判斷結構層設計是否合格，可以把 URL 當作一條可導覽的路徑來檢查，而不是一串程式參數。動態網站也可以用靜態路徑對外呈現；主要內容頁如果出現查詢字串，等於讓同一份內容同時掛在多個身分上，爬蟲與使用者都無法一眼判斷哪一個才算正式版本。這個層級的三個原則都指向同一個目標：讓路徑可讀、可導覽、可維護，並讓使用者理解內容主題；抓取與索引效果仍要看實際站內入口與回應。

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

   沒有 Google 公布的 75／40 字元通用門檻。以可讀、可維護、能區分頁面且不含不必要參數為準；去掉某個詞後若仍清楚，可考慮簡化。如果是，就去掉它。例如 /blog/seo-keyword-research-guide-for-beginners-2026 可以精簡為 /blog/seo-keyword-research，兩者傳達的主題相同，短版本對使用者與爬蟲都更友善。

2. 路徑層級保持可導覽與可維護

   許多內容站會使用 /blog/文章-slug 或 /blog/category/文章-slug，但沒有通用的最多三層規則。若需要更深的層級，應確保內鏈、sitemap、canonical 與實際索引狀態可管理。

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

   用靜態路徑替代動態參數，例如 /blog/seo-guide 而非 /article.php?id=45，或依情境使用 canonical、可抓取的 noindex 與站內版本控制；robots.txt 阻止抓取不等於阻止 URL 被索引，noindex 也需要先允許抓取才能被讀到。UTM 可用於分析，但應在自己的站點驗證 canonical 與報表。

標記層原則

標記層處理的是 URL 字串如何被拆解。Google 官方明確指出，連字號是詞語分隔符，底線是詞語連接符；keyword-research 會被解讀為 keyword 與 research 兩個詞，keyword_research 則會被拼成一個合成詞 keywordresearch。大小寫的影響同樣集中在這個層級，Linux 伺服器預設區分大小寫，/Blog/What-Is-SEO 與 /blog/what-is-seo 會被視為兩個不同頁面，遷移或升級時就容易產生重複內容。這些字元規則可改善可讀性與版本一致性；不要把它們寫成爬蟲在讀取內容前已完成排名判斷的信號。

標記層也涵蓋 URL 的協定標記。HTTPS 是 Google 公開的輕量排名信號，也有助於連線安全；但不能把非 HTTPS 直接等同 CTR 必然下降或所有網站的最低排名門檻。應同時檢查憑證、混合內容、轉址與 canonical。標記層的問題不像結構層那樣容易被內容管理系統自動修正，一旦站內混用大小寫、底線與連字號，改版或遷移時就會一次爆發，因此需要在建立 URL 的階段就統一規則。

1. 全部用小寫英文字母

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

2. 用連字號分隔詞語，不用底線

   Google 的 URL 指南建議用連字號分隔詞語，並指出底線在歷史上常被視為詞語連接方式；這是可讀性與一致性的建議，不應延伸成所有查詢的固定分詞結果。

3. 使用 HTTPS 協定

   Google 將 HTTPS 視為輕量排名信號，HTTPS 也有助於連線安全；但不能把非 HTTPS 直接等同 CTR 必然下降或所有網站的最低排名門檻。應同時檢查憑證、混合內容、轉址與 canonical。

這六個原則不需要一次全部改。新建網站應從一開始就全部採用；既有網站若要調整，應先評估每個原則的修改成本與潛在風險，再依序進行。

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

子目錄與子網域都是可用的網站架構選擇。選擇時應看部署、品牌、語言、產品與內容管理邊界；不要把其中一種寫成必然繼承連結權重或更快排名。

比較維度	子目錄（/blog/、/zh-tw/）	子網域（blog.example.com）
架構與管理	同一主機名下的路由與部署邊界	可分開的部署與管理邊界
抓取與索引驗證	以同一套資料與規則觀測	分開檢查主機名、sitemap 與 canonical
遷移與觀察	依實際資料判斷	依實際資料判斷
技術維護	統一管理，複雜度低	需個別維護 SSL、設定等
適合場景	部落格、多語言版本、內容區塊	完全獨立的服務或應用程式

PageRank 繼承差異的機制根源

子目錄與子網域可能在部署、管理與 Search Console 組織方式上不同，但公開文件不足以支持一套 PageRank 或實體繼承公式。子目錄與子網域都是可用的網站架構選擇；子網域在部分 Search Console 與網站管理情境會分開處理，但不能把它寫成 PageRank、E-E-A-T 或信任從零開始的固定規則。決策應看技術、品牌、語言、部署與內容管理邊界。

不同網站結構研究與遷移案例有樣本、內容、內鏈、技術與時間窗限制，不能把未核對的百分比或單一案例外推成子目錄必然優於子網域。若要遷移，應把 URL mapping、轉址、內鏈、sitemap 與實際流量分開驗證。

不同主機名與架構可能讓抓取、報表與部署管理不同，但不能把 crawl budget 或抓取速度寫成子目錄／子網域的固定繼承公式；以實際伺服器、Search Console 與索引資料判斷。

子網域的合理例外情境

子網域不是不能用，而是在以下三種情境下使用是合理的，因為這些情境的業務邏輯本身就需要與主網域切割。第一種是完全獨立的服務或產品線，例如 shop.brand.com 經營與主網域完全不同品類的商品，擁有獨立的技術團隊、技術堆疊與品牌定位，這種切割本來就是商業決策，SEO 權重繼承反而不是首要考量。第二種是用戶生成內容平台，例如 GitHub Pages 的 username.github.io，每個用戶各自擁有自己的子網域來呈現個人內容，這種規模化的子網域結構在技術上難以用單一主網域承載。第三種是明確不希望繼承主網域 SEO 連結權重的場景，例如測試環境、暫存站、內部工具站台，這些頁面通常應透過環境隔離、存取控制或 noindex 等方式避免意外公開；不要把它描述成會稀釋主網域權重的固定結果。

部落格、多語言版本與行銷活動可以使用子目錄，也可能因部署或品牌邊界選擇子網域。選擇後仍要用 canonical、hreflang、內鏈、sitemap 與實際索引資料驗證，不能承諾新內容立即取得既有權重或省下累積時間。多語言版本可用子目錄、子網域或不同網域，重點是正確的 hreflang、canonical、語言內容與內鏈；不要把 Google 的建議誤寫成只能用子目錄或能保證共享 authority／爬取效率。

多語言頁面可用 hreflang 標示語言／地區變體；canonical 應在每個版本的內容與重複關係中正確設定，不能用一個固定版本取代所有本地化頁面。完整的 Canonical 標籤處理重複內容的設定方式，可以參考 Canonical 標籤處理重複內容的完整設定指南。

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

Google 兩種都能讀，技術上沒有絕對對錯。真正決定哪個更實際的，是你的外連策略與追蹤需求，而不是搜尋引擎的偏好。

中文 URL 可被搜尋系統處理，但在分享、日誌與工具中常會以 percent-encoding 顯示；這是管理與可讀性的取捨，不是 Google 不能讀。

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

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

• 某些工具或介面會顯示編碼後的字串，可能降低人工閱讀便利性；是否影響外部引用要看平台實作，不能一概而論
• 在不同工具中可能以編碼或解碼形式顯示，團隊應統一報表與解碼流程，不要把它寫成必然追蹤混亂
• 複製與分享是否正確取決於應用程式的 URL 處理；發布前應用實際裝置與平台測試，不把中文 slug 寫成必然斷鏈

若團隊需要跨平台分享、日誌與報表的一致性，英文 slug 可能較容易管理；這是操作偏好，不是 Google 對中文 URL 的限制。

外連策略對 slug 語言的選擇壓力

中文 URL 在部分 CMS、社群或電子報介面可能以 percent-encoding 顯示，影響人工閱讀便利性；是否發生要用目標平台實測，不能直接推論外部連結效果。

若外部合作需要人工辨識連結，英文 slug 可能較方便複製與核對；這是團隊工作流考量，不代表中文 slug 會讓反向連結失效或被拆成兩個頁面。

GA4、Search Console 與伺服器日誌可能依介面以編碼或解碼形式呈現 URL；團隊應統一報表與解碼流程，再以實際資料判斷是否造成辨識成本。

中文 slug 可接受的窄條件

中文 slug 可以使用；是否適合要看品牌語言、分享平台、團隊維護與報表需求。它可能讓中文讀者更快辨識主題，也可能增加跨工具複製與核對成本。

採用中文 slug 前，先用主要 CMS、社群、電子報、分析與 Search Console 流程測試；若團隊需要大量跨平台分享或跨語言維護，英文 slug 可能更省人工核對成本。

沒有一套適用所有網站的中文／英文／拼音規則；以目標讀者、語言版本、分享流程與維護成本做決策，並保持同一站的命名一致。

改 URL 不掉排名：这五个步骤都要做

URL 改版不只是換路徑，而是要管理舊 URL、新 URL、轉址、內容、canonical、內鏈與索引。301 是重要步驟，但不能承諾排名不波動；完整清單與改版後驗證可降低遺漏風險。

为什么只设 301 仍然会掉排名

301 是伺服器端的永久轉址，Google 說永久轉址通常不會造成 PageRank 損失，但轉址仍需正確、相關且可抓取；內容、canonical、內鏈與技術變更仍可能造成流量波動。Google 可能需要重新抓取、索引並選擇 canonical；改版期間的波動取決於內容、轉址、內鏈、抓取與站點資料，不能把任何固定過渡行為或波動幅度當成保證。

常見需要排查的項目包括站內連結仍指向舊 URL、轉址對應不相關、sitemap 未更新，以及 robots／canonical 與新版本衝突；哪一項造成影響要用實際回應、抓取與索引資料確認。

所以完整改版的判斷標準，不是「有沒有設 301」，而是舊 URL 的所有入口是否都已關閉，新 URL 是否完整取代舊 URL 的語意位置。這就需要一套可執行的步驟，而不是單一設定。

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

   從 Search Console、伺服器日誌、sitemap、內鏈爬蟲與分析資料交叉建立 URL 清單；單一報表不一定涵蓋所有已發現或已抓取路徑。

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

   對每個仍有價值的舊 URL 找最相關的新 URL；沒有相關替代頁時，不要把大量舊頁面全部導回首頁。保留 1:1 對應表與例外原因，並先在測試環境驗證。

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

   301 是永久轉址。Google 表示 301 與其他伺服器端永久轉址不會造成 PageRank 損失；仍應避免「舊 URL A 轉址到中間網址 B、再轉到新 URL C」這類轉址鍊，因為它會增加請求延遲、維護成本與爬取複雜度。實作時讓舊 URL 直接指向最終相關頁面。

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

   設了 301 但忘了更新站內連結，等於你的每一個 internal link 都還指向舊 URL，每次訪客或爬蟲點擊都要多走一跳。這可能增加一次轉址與維護成本；是否影響流量，要用實際內鏈、轉址、抓取與效能資料判斷，不能把它寫成多數改版流量下滑的單一原因。更新完 301 之後，用 Screaming Frog 重新爬一遍，確認全站 internal links 已更新為新 URL，沒有任何一條還在用舊路徑。

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

   舊 Sitemap 還列著舊 URL 是一個很常見的遺漏。更新 Sitemap 後，到 Google Search Console 的「Sitemaps」項目，提交新版 Sitemap，讓 Google 知道新的 URL 清單。重要頁面可用 GSC URL 檢查工具提出重新抓取要求，但這不是索引或排名的保證，仍要觀察實際狀態。

改版後的驗證節點與觀察窗口

改版後應持續觀察，期間依網站規模、抓取頻率、內容變更與資料量決定；沒有通用的 6–8 週或兩週完成保證。以改版前後可比的 URL、查詢、轉址與索引資料判斷是否需要追加修正。

觀察 Search Console 的索引與效能資料、伺服器轉址、canonical、sitemap 與重要頁面實際抓取；不要預設 4–6 週或任何固定窗口就會完成信號轉移。若流量下降，應先排查轉址、內容、內鏈、robots、canonical 與版本差異，再決定等待或修正。

如果流量突然下降，先檢查轉址、回應碼、canonical、robots、noindex、內容版本與追蹤資料；舊 URL 仍有流量只是其中一種線索，不足以單獨證明對應表遺漏。

URL 只是技術與內容判斷中的一個面向；若要排序改版工作，應同時看索引、內容、內鏈、商業重要性、成本與回歸風險。可參考 SEO 排名因素完整解析作延伸閱讀（不是本頁的服務方案或交付承諾）。

改 URL 的投入包含清單盤點、轉址對應、站內連結更新與持續驗證；觀察期間依網站規模、資料量與改版風險決定，不設定固定兩個月窗口。這些工作需要有系統的執行順序與資源安排；若你的團隊沒有足夠人力獨立完成，可以參考 SEO 策略藍圖（15 萬起 / 一次性）的服務內涵。

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

有影響，但不是主要因素。URL 對搜尋理解、分享、重複管理與使用者辨識有幫助，但不是排名魔法；不要把未核對的 CTR 百分比、路徑深度或 PageRank 流動寫成通用因果。

URL 要用中文還是英文？

Google 可以處理中文與英文 URL。中文 URL 在部分分享、日誌與報表介面可能以 percent-encoding 呈現；英文 slug 只是跨平台管理上的一種偏好，不是排名或外連的硬性規則。

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

短但有意義，不是短而無意義。沒有 Google 公布的 75／40 字元上限；去掉不影響語意的詞即可，並以可讀、可維護與不重複為判斷。/blog/url-structure 和 /blog/url-structure-seo-best-practices-complete-guide-2026 比起來，前者更好；但 /blog/url 這樣過於簡短的路徑，反而沒有足夠的語意信號。

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

子目錄與子網域都可能適合。不要把 PageRank、E-E-A-T 或固定排名優勢寫成兩者的公開公式；依產品、語言、部署、品牌與維護邊界決定，並用實際遷移資料驗證。

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

不夠。301 只是改版的一部分；還要檢查對應關係、內容、canonical、站內連結、sitemap、robots 與實際索引。監控窗口依網站與改版規模決定，不設定固定 6–8 週。

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

查詢字串是否造成問題，取決於它是否產生大量近似 URL、可索引版本與清楚的 canonical。篩選頁可依需求用 canonical、適當的索引／抓取控制與內鏈管理；robots.txt 阻止抓取不等於阻止 URL 被索引，noindex 也需要先允許抓取才能被讀到。UTM 主要用於分析，仍應在自己的站點驗證 canonical 與報表。

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

Google 的 URL 指南建議用連字號分隔詞語，並指出底線在歷史上常被視為詞語連接方式；對中文路徑影響較小，對英文路徑則以一致、可讀為優先。

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

URL 路徑層級沒有通用的最多幾層規則。一般內容網站可用可讀、可導覽的路徑；更深的架構要檢查內鏈、sitemap、canonical、抓取與索引資料，不要把層數直接換算成爬取頻率或 PageRank 效率。

URL 大小寫要統一嗎？

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

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

現有網站不一定要大改；先按商業重要性、重複 URL、索引狀態、轉址品質與維護成本排序。已有流量的網站即使正確改版也可能波動，但沒有通用的 2–3 個月窗口或結果保證。可參考 PageSpeed Insights 教學的實際驗證思路。