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


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

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


![比較重新導向前後流程的圖片](/media/whitedec/blog_img/77ecb43d3845413385e9e0ebf6cc351f.webp)


## DNS 與搜尋爬蟲都清楚識別 'www' {#sec-e0d49c76d3ea}

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

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

**1. Yahoo Japan 的案例**
```bash
$ 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 的案例**
```bash
$ 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` 回應。

## 為何必須將其中一側進行重新導向？ {#sec-cf467e61a55d}

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

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

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

---

## 解決方案：在網頁伺服器層級強制重新導向 {#sec-e499a7960796}

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

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

```nginx
# 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 等
}
```

> **Tip:** 在此使用 `308` 而非 `301` 狀態碼的原因是，`308 Permanent Redirect` 會保持 HTTP 方法（如 POST, PUT 等）不變地進行重新導向，這在現代網頁環境中更為安全。

## 結語 {#sec-ad06e7ff5f93}

瀏覽器隱藏網址，不代表伺服器可以坐視不理。如果您的 `www` 和 `Apex` 網域並存且都返回 `200` 狀態碼，請立即檢查您的網頁伺服器設定。明確地將流量重新導向至其中一個網域，是向搜尋引擎清晰傳達網站身份最基本且重要的工作。