整合 www 與 Apex 網域：301/308 重新導向對 SEO 及營運效率的重要性

www 與 Apex 網域，為何必須整合？（301/308 重新導向的重要性）

您最近是否曾仔細觀察過 Chrome、Edge 或 Safari 等現代瀏覽器？即使在網址列中輸入 www.naver.com 或 www.google.com，您會發現 www 在某個時刻消失，只剩下主網域 (Apex Domain)。甚至連行動版的 m. 網域也常被隱藏。

這是因為現代瀏覽器為了讓網址列更簡潔，採用了隱藏「瑣碎子網域 (Trivial Subdomains)」的政策。對使用者而言，網址變短可能更舒適，但作為網頁開發者，我們必須進一步思考。因為「瀏覽器隱藏顯示」與「實際作為獨立網域運作」是截然不同的問題。

比較重新導向前後流程的圖片

DNS 與搜尋爬蟲都清楚識別 'www'

在實際的 DNS 處理過程或對於搜尋引擎機器人 (如 Googlebot) 而言，www.example.com 與 example.com 是截然不同的目的地。如果這兩個網址都返回 200 OK 回應並顯示相同內容，這在技術上等同於營運著兩個具有「重複內容」的網站。

讓我們透過 curl 指令，直接確認全球 IT 企業如何解決這個問題。

1. Yahoo Japan 的案例

$ curl -I https://yahoo.co.jp/
HTTP/2 301 
location: https://www.yahoo.co.jp:443/
...

當透過 Apex 網域存取時，Yahoo Japan 會將請求重新導向至帶有 www 的網址，並發送 301 Moved Permanently 回應。

2. Google 的案例

$ curl -I https://google.com/
HTTP/2 301 
location: https://www.google.com/
...

$ curl -I https://www.google.com/
HTTP/2 200 
...

Google 也是如此。當存取 google.com 時，它會重新導向至 www.google.com，最終只在 www 網域下返回 200 回應。

為何必須將其中一側進行重新導向？

這不單純是為了「看起來更簡潔」。背後有明確的 SEO（搜尋引擎最佳化）和營運效率考量。

1. Canonical Tag 的局限性

許多開發者認為只要設定了 <link rel="canonical" href="..."> 標籤就沒問題了。然而，Canonical 標籤只是給搜尋引擎的一個「提示」。機器人仍需抓取這兩個 URL 的事實並未改變，這會導致抓取預算 (Crawl Budget) 的浪費。機器人在抓取網站新文章的時間裡，卻在抓取已存在文章的「副本」。

2. 連結權重 (Link Juice) 的分散

當網路上其他網站連結到您的文章時，有些人可能會加上 www，有些人則沒有。如果沒有妥善處理重新導向，該頁面應累積的權威度 (Authority) 將會分散到兩個網域，進而在搜尋排名競爭中處於劣勢。

解決方案：在網頁伺服器層級強制重新導向

這種處理方式最有效率的做法，並非在應用程式 (如 Django, Node.js 等) 的程式碼層級，而是在 Nginx 或 Apache 等網頁伺服器 (基礎設施) 層級進行。在請求到達應用程式之前，由伺服器立即轉發，能減少資源消耗並提高速度。

以下是營運 example.com 時，將所有請求統一導向 Apex 網域 (https://example.com) 的 Nginx 設定範例。（如果想統一導向 www，只需更改目標網址即可。）

# 1. www (HTTP) -> Apex (HTTPS)
server {
    listen 80;
    listen [::]:80;
    server_name www.example.com;
    return 308 https://example.com$request_uri;
}

# 2. www (HTTPS) -> Apex (HTTPS)
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 308 https://example.com$request_uri;
}

# 3. Apex (HTTP) -> Apex (HTTPS)
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 308 https://example.com$request_uri;
}

# 4. 實際服務邏輯 (Apex HTTPS 200 OK)
server {
    listen 443 ssl http2;
    server_name example.com;
    # ... 服務設定及 Proxy Pass 等
}