# 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`応答を返し、同じコンテンツを表示している場合、これは技術的に「重複コンテンツ」を持つ二つのサイトが運用されているのと同じことになります。

グローバルIT企業がこの問題をどのように解決しているか、`curl`コマンドで直接確認してみましょう。

**1. Yahoo Japanの事例**
```bash
$ curl -I https://yahoo.co.jp/
HTTP/2 301 
location: https://www.yahoo.co.jp:443/
...
```
Yahoo Japanは、Apexドメインでアクセスした場合、`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）が二つのドメインに分散され、検索順位の競争で不利になってしまいます。

---

## 解決策：Webサーバー段階での強制リダイレクト {#sec-e499a7960796}

この処理は、アプリケーション（Django, Node.jsなど）のコードレベルではなく、**[[Nginx]]やApacheのようなWebサーバー（インフラ）段階**で処理するのが最も効率的です。リクエストがアプリケーションに到達する前にサーバーで即座にリダイレクトすることで、リソースの消費が少なく、速度も速いためです。

以下は、`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:** ここで`301`ではなく`308`ステータスコードを使用している理由は、`308 Permanent Redirect`がHTTPメソッド（POST, PUTなど）を変更せずにそのまま維持してリダイレクトするため、モダンなWeb環境においてより安全だからです。

## まとめ {#sec-ad06e7ff5f93}

ブラウザがアドレスを隠してくれるからといって、サーバー側まで放置してはいけません。`www`と`Apex`ドメインが共存し、両方とも`200`を返している場合は、今すぐWebサーバーの設定を確認してください。一方への確実なリダイレクト処理は、検索エンジンにあなたのサイトのアイデンティティを明確に伝える、最も基本的かつ重要な作業です。