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応答を返し、同じコンテンツを表示している場合、これは技術的に「重複コンテンツ」を持つ二つのサイトが運用されているのと同じことになります。
グローバルIT企業がこの問題をどのように解決しているか、curlコマンドで直接確認してみましょう。
1. Yahoo Japanの事例
$ 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の事例
$ 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）が二つのドメインに分散され、検索順位の競争で不利になってしまいます。
解決策：Webサーバー段階での強制リダイレクト
この処理は、アプリケーション（Django, Node.jsなど）のコードレベルではなく、NginxやApacheのようなWebサーバー（インフラ）段階で処理するのが最も効率的です。リクエストがアプリケーションに到達する前にサーバーで即座にリダイレクトすることで、リソースの消費が少なく、速度も速いためです。
以下は、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など
}
Tip: ここで
301ではなく308ステータスコードを使用している理由は、308 Permanent RedirectがHTTPメソッド（POST, PUTなど）を変更せずにそのまま維持してリダイレクトするため、モダンなWeb環境においてより安全だからです。
まとめ
ブラウザがアドレスを隠してくれるからといって、サーバー側まで放置してはいけません。wwwとApexドメインが共存し、両方とも200を返している場合は、今すぐWebサーバーの設定を確認してください。一方への確実なリダイレクト処理は、検索エンジンにあなたのサイトのアイデンティティを明確に伝える、最も基本的かつ重要な作業です。
コメントはありません。