URL 結構怎樣影響 SEO？

每次你在瀏覽器輸入網址、點擊搜尋結果，或複製一條連結分享給朋友，你接觸到的就是 URL。它看似只是一串文字，但對搜尋引擎而言，URL 是理解一個頁面的第一道線索。在 Google 爬取內容、讀取標題、分析頁面結構之前，它已經先看過你的網址。

URL 結構的決定，往往在建站初期一次性地定下，之後牽一髮動全身。一個清晰、一致的 URL 架構，能幫助搜尋引擎更有效率地索引你的內容，減少重複內容的技術問題，同時讓用戶在點擊之前就對頁面內容建立預期。反之，混亂的 URL 結構則可能悄悄製造技術負債，累積成難以修復的 SEO 問題。

本文將從 URL 的基本組成說起，逐一解析各個部分的技術意義，再帶出實際的最佳實踐建議。

URL 是什麼？

URL，全稱 Uniform Resource Locator（統一資源定位符），是網際網路上每個資源的唯一地址。無論是一個網頁、一張圖片、一段影片，還是一份文件，只要它存在於網絡上，就必然有一個對應的 URL 指向它。

最簡單的比喻是：URL 就像香港的街道地址。就算你要找旺角彌敦道某棟大廈的某個單位，你需要的不只是街道名稱，還需要門牌號碼和樓層：URL 也是如此，它精確地告訴瀏覽器「資源在哪裡，以及如何取得它」。

URL 的結構解析

一個完整的 URL 由多個部分組成。以下以一個典型例子逐一拆解：

https://www.example.com.hk/blog/seo-tips/

這條 URL 包含以下組成部分：

協議：HTTP vs. HTTPS

HTTP（HyperText Transfer Protocol） 是網頁的基礎通訊協議，而 HTTPS 中的「S」代表 Secure（安全）。HTTPS 使用 SSL/TLS 加密技術，確保瀏覽器與伺服器之間傳輸的數據不被第三方截取或竄改。

對於香港的網站管理員來說，HTTPS 是基本要求。Google 自 2014 年起已將 HTTPS 列為排名訊號，而現代瀏覽器（如 Chrome）更會在 HTTP 網站旁顯示「不安全」警告，直接影響訪客的信任感。

子域名：www 與非 www

www.example.com 與 example.com 在技術上是兩個不同的地址，但通常指向同一網站。「www」是子域名（subdomain）的一種，歷史上源於早期互聯網的命名慣例，並非必要存在。

兩者本身沒有 SEO 優劣之分，關鍵在於選定其中一個作為標準版本（canonical），並確保另一個以 301 永久重定向指向它，避免搜尋引擎將兩者視為重複內容。

路徑與 Slug

路徑（Path）是 URL 中域名之後的部分，代表伺服器上的目錄結構或頁面位置。Slug 則指路徑中最後一段的描述性文字，例如 /seo-tips 或 /url-structure/。

一個清晰的路徑不僅幫助搜尋引擎理解頁面主題，也讓用戶在點擊之前就能預期將看到什麼內容。

子目錄（Subdirectory）

子目錄（Subdirectory），又稱子資料夾，是 URL 路徑中用來組織網站內容層級的結構，以斜線分隔，例如 example.com/blog/ 或 example.com/hk/services/。

與子域名（如 blog.example.com）不同，子目錄的內容被搜尋引擎視為主域名的一部分，因此主域名積累的權威（Domain Authority）能直接傳遞至子目錄下的頁面，這對 SEO 來說是顯著的優勢。

對於香港的多語言或多地區網站，常見的做法是以子目錄區分語言版本，例如：

• example.com/zh/ → 繁體中文
• example.com/en/ → 英文

這種結構配合 hreflang 標籤使用，能有效告知 Google 不同語言版本的對應關係，避免重複內容問題，並為正確的受眾提供正確的語言版本。

在規劃子目錄結構時，應注意層級不宜過深（建議三層以內），過深的路徑會削弱連結權重的傳遞效率，也不利於用戶理解網站架構。

結尾斜線（Trailing Slash）

example.com/blog/ 與 example.com/blog 在技術上是兩個不同的 URL。傳統上，結尾斜線表示這是一個「目錄」，而無斜線則表示一個「文件」。在現代網站架構中，這個分別已不如昔日明顯，但兩者混用仍會引起重複內容問題。

從搜尋引擎的角度來看，若同一頁面同時可透過兩個 URL 存取而沒有適當的重定向，Google 便可能將它們視為兩個獨立頁面，分散頁面的連結權重（Link Equity），影響排名表現。

實際操作上，最重要的是保持全站一致：選定有斜線或無斜線其中一種格式，並透過 301 永久重定向確保另一種格式自動跳轉至標準版本。同時，在 sitemap.xml、內部連結及 canonical 標籤中，也應統一使用同一格式，避免自相矛盾的訊號令搜尋引擎感到混亂。

值得注意的是，不同平台對結尾斜線的預設處理方式各有不同。例如，香港網站常用的 WordPress 是會預設加上斜線，而部分靜態網站生成器（如 Hugo、Next.js）則視乎技術設定而定。因此在建站初期便應確認平台的預設行為，並在技術設定層面統一執行，而非事後逐一修正。

URL 如何運作？

當你在瀏覽器輸入一條 URL 並按下 Enter，背後發生的事情遠比想像中複雜。以下是簡化版的流程：

• 瀏覽器解析 URL，識別協議、域名和路徑
• 向 DNS（域名系統）查詢，將域名轉換為伺服器的 IP 地址
• 瀏覽器向伺服器發送 HTTP/HTTPS 請求
• 伺服器回應，返回對應的網頁內容（HTML、CSS、JavaScript 等）
• 瀏覽器渲染內容，呈現給用戶

在這個過程中，301 重定向扮演了重要角色。當伺服器設定了 301，瀏覽器和搜尋引擎會被引導到新的 URL，同時大部分「鏈接權重」（Link Equity）也會隨之傳遞。這正是統一 www/非 www 及 HTTP/HTTPS 的標準做法。

URL 最佳實踐

以下是針對 SEO 及用戶體驗的 URL 最佳實踐，每項均值得在網站建立或改版時認真落實。

1. 全面切換至 HTTPS

為你的網站安裝有效的 SSL 憑證，確保所有頁面均以 https:// 開頭。大多數香港的虛擬主機服務商及全球平台均提供免費或低成本的 SSL 方案。切換後，務必將所有 http:// 請求以 301 重定向至 https://，避免出現混合內容（Mixed Content）問題。

2. 統一 www 或非 www，並設定重定向

選擇一個版本作為標準，另一個設 301 永久重定向。例如，若你選擇 www 版本為主，則 example.com 應自動跳轉至 www.example.com。

根據個人經驗，我會建議在 Google Search Console 中驗證域名資源（Domain Property）方式驗證網站，這樣可以同時涵蓋 www 與非 www 兩個版本的數據。驗證後，可透過「頁面索引報告（Page Indexing Report）」確認重定向是否正確執行，並檢查 Google 實際收錄的是哪個版本的 URL，確保與你設定的標準版本一致。

3. 結尾斜線保持全站一致

決定是否在頁面 URL 末端加上斜線，並全站貫徹執行。

一旦選定標準，例如統一不使用斜線，就應確保帶有斜線的版本以 301 重定向至無斜線版本（反之亦然）。內部連結也應全部使用統一格式，避免製造不必要的重複內容訊號。

4. URL 應簡短且具描述性

盡量讓 URL 能夠「望文生義」，讓用戶和搜尋引擎僅憑 URL 就能猜到頁面內容。避免使用過長的層級結構，通常建議保持在 3 至 4 個層級以內。例如 /blog/seo-tips 優於 /resources/articles/category/seo/beginner/tips-for-beginners。

對於香港的網站，URL 是使用英文還是中文，並沒有絕對的優劣之分，兩者在 SEO 上均受 Google 支援。關鍵在於選定後全站保持一致，避免中英混用造成結構混亂。

需要注意的是，中文等非拉丁字符在技術層面會經過百分比編碼（Percent-encoding）處理，例如「香港」會被編碼為 %E9%A6%99%E6%B8%AF。雖然現代瀏覽器在顯示時通常會還原成可讀的中文字符，但在部分工具、後台系統或分享連結時，編碼後的字串可能出現，影響可讀性與用戶體驗。

若選擇使用中文 URL，應確保網站的 CMS 或伺服器能正確處理編碼，並在 sitemap.xml 及 canonical 標籤中統一使用編碼後的格式，以避免技術層面的不一致。若選擇英文 URL，則應確保 slug 與頁面內容有合理對應，而非使用無意義的 ID 或亂碼。

5. 使用連字符（-）而非底線（_）

Google 將連字符（hyphen，-）視為單詞分隔符，而底線（underscore，_）則可能被視為連接符，導致 seo_tips 被讀作 "seotips" 一個單詞，令搜尋引擎無法正確識別個別關鍵詞。因此，slug 應寫成 seo-tips 而非 seo_tips。

這個建議早在 2011 年已由 Google 的 Matt Cutts 公開確認，時至今日仍是業界的通行標準。值得一提的是，連字符在 URL 中對用戶同樣更為友善：閱讀時的自然停頓讓內容更易理解，複製或分享時也較少出現斷行問題。

此外，空格在 URL 中是不被允許的字符，會被編碼為 %20 或在某些情況下顯示為 +，兩者都會令 URL 變得難以閱讀。連字符正是取代空格的標準做法，也是大多數 CMS（如 WordPress）在自動生成 slug 時的預設選擇。

如果你的網站現有大量使用底線的舊 URL，不建議倉促批量更改。由於每次 URL 變動都需要設定 301 重定向，操作不當反而會造成更大的 SEO 損失。新建頁面採用正確格式，舊頁面則視乎實際情況逐步處理即可。

6. 全部使用小寫字母

/Blog/SEO-Tips 與 /blog/seo-tips 在部分伺服器（尤其是 Linux 環境）上會被視為兩個不同頁面，造成重複內容。統一使用小寫字母是最安全的做法，亦是 Google 的官方建議。

在實際操作上，大小寫混用的情況往往不是刻意為之，而是來自人為輸入的偏差。例如不同編輯在後台建立頁面時習慣各異，或系統在特定情況下自動生成含大寫字母的 URL。因此，除了養成統一小寫的習慣外，亦建議在伺服器層面（如 .htaccess 或 Nginx 設定）加入規則，將所有含大寫字母的 URL 自動以 301 重定向至小寫版本，從根本上杜絕問題。

7. 避免堆疊動態參數

如非必要，避免 URL 中出現大量查詢字串，例如 ?id=123&ref=456&session=abc。這類 URL 難以閱讀，也可能令 Google 爬蟲在判斷頁面內容時產生困難，甚至將參數不同但內容相同的頁面視為重複內容。

動態參數常見於電商網站的篩選功能（如顏色、尺碼、排序方式）、追蹤連結（如 UTM 參數）及系統內部的 session ID。處理方式視乎參數的性質而定：

• 篩選與排序參數：若篩選結果頁不需要被搜尋引擎收錄，可在頁面加入 noindex 標籤，或使用 canonical 標籤指向無參數的主頁面，避免爬取資源被大量消耗。
• UTM 追蹤參數：此類參數僅用於分析工具，對頁面內容毫無影響，應確保對應頁面設有 canonical 標籤指向乾淨的 URL，防止帶參數的版本被收錄。
• Session ID：應避免將 session ID 寫入 URL，這是最容易造成大規模重複內容的來源之一，應改以 cookie 處理。

值得注意的是，Google Search Console 過去設有「URL 參數」工具讓管理員自行告知 Google 各參數的用途，但該功能已於 2022 年正式下架。現時建議透過上述的 canonical 標籤、noindex，以及 robots.txt 封鎖特定參數格式等方式來管理爬取行為。

8. 避免在 URL 中加入日期或無關字符

部分 CMS（如常用的 WordPress ）的預設設定會自動將發布日期寫入 URL，例如 /2019/03/28/article-name。這種結構在短期內雖然沒有問題，但長遠而言對 URL 管理仍會造成幾個問題。

首先是內容時效性的觀感問題。當用戶在搜尋結果中看到一篇 2019 年的文章，即使內容已更新，URL 中的舊日期仍可能令人卻步，降低點擊意欲。

其次是結構難以調整。日期一旦寫入 URL 便成為固定部分，日後若想重組網站架構或將文章移至不同分類，便需要大量 301 重定向，操作複雜且風險較高。

除了日期之外，亦應避免在 URL 中出現其他無意義的字符，例如自動生成的文章 ID（/p=123）、隨機字串，或過度冗長的分類層級堆疊。這些字符對搜尋引擎理解頁面內容毫無幫助，亦令 URL 失去「望文生義」的作用。

建議在建站初期便選擇簡潔、不含日期的 URL 結構，例如直接以 /blog/article-name 或 /article-name 呈現。若你的網站已使用含日期的舊結構，遷移前應充分評估影響範圍，並為所有舊 URL 設定正確的 301 重定向，切勿直接棄置舊連結。

小結

URL 結構看似簡單，卻是整個網站技術 SEO 的基礎之一。一個清晰、一致、安全的 URL 架構，不僅有助於搜尋引擎正確索引你的內容，也能提升用戶對網站的信任感與瀏覽體驗。

由於 URL 結構一旦建立了便難以更改，因此網站建立初期花時間處理好基礎，能大大減低技術負債，避免將來要批量修復。

對於香港的網站管理員而言，以下幾點尤其值得立即檢視：

• 你的網站是否已全面使用 HTTPS？
• www 與非 www 是否只有一個版本在回應，另一個已設好重定向？
• 全站的結尾斜線是否保持一致？
• 你的 URL slug 是否簡短、使用英文、並以連字符分隔？

如果任何一項的答案是「不確定」，建議使用 Google Search Console 或 Screaming Frog 等工具做一次全面的 URL 審查。小小的調整，往往能帶來可觀的 SEO 改善。