2026年6月1日

Nginxでwwwあり・なしを統一するリダイレクト設定

Webサーバー・Nginx

Nginx で www あり・なしを統一するには、正規にするホスト名を1つ決め、http://・http://www.・https://www.（www なしを正規にする場合）からの3通りを、それぞれ1回の 301 で正規 URL へ転送します。ポイントは、HTTPS の www 側にも証明書が要ることと、WordPress の「サイトアドレス」を正規のホスト名と一致させることです。この記事では、どちらを正規にするかの決め方、両方向の設定例、DNS と証明書の準備、WordPress 側の注意点、4通りの URL をまとめて確認する方法を説明します。

HTTP から HTTPS への転送そのもの（Let's Encrypt の更新やプロキシ背後でのループ対策など）は、別記事「NginxでHTTPからHTTPSへリダイレクトする設定方法」で詳しく扱っています。この記事は「ホスト名の統一」に絞った内容です。

なぜ統一するのか

example.com と www.example.com は、ブラウザや検索エンジンから見ると別のホストです。両方で同じページが表示される状態だと、次のような問題が起きます。

外部からのリンクやブックマークが2つの URL に分かれ、検索エンジンがどちらを正規とみなすかを推測することになる
ログインの Cookie はホスト名ごとに管理されるため、片方でログインしても、もう片方では未ログインに見える
アクセス解析で同じページが2行に分かれる

Google 検索は正規 URL の判断に 301 リダイレクトと rel="canonical" の両方を手がかりにすると案内しています。WordPress は rel="canonical" を自動で出力するので、サーバー側で転送をそろえれば、両者の示す内容が一致します。統一によって検索順位が上がるわけではありませんが、評価やデータが分散するのを防げます。

www あり・なし、どちらを正規にするか

技術的にはどちらでも構いません。迷ったときは、次の点で判断します。

すでに運用中のサイトなら、現在の WordPress の「サイトアドレス」と、Search Console で多く表示されている側に合わせる。変える理由が無ければ変えない
www なし（example.com）は短く覚えやすい。ただし DNS の仕様上、ドメインの頂点（apex）には CNAME を置けないため、CDN を使う場合は DNS 事業者の ALIAS やフラット化の機能が必要になることがある
www ありは CNAME を使えるため、CDN やホスティングの切り替えがしやすい。サブドメインに Cookie が広がる問題も起きにくい

新規サイトの場合でも、一度決めたら変えないことが最も大切です。

事前準備: DNS と証明書

転送元になる側にも、DNS のレコードと証明書が必要です。www.example.com の DNS レコードが無ければ、そもそもサーバーに到達しません。また、https://www.example.com/ にアクセスされた時点で TLS の接続が先に行われるため、www 側の証明書が無いと、転送する前にブラウザが証明書エラーを表示します。

Let's Encrypt なら、1枚の証明書に両方の名前を入れておくのが簡単です。

sudo certbot certonly --nginx -d example.com -d www.example.com
sudo certbot certificates   # Domains に両方が入っているか確認

すでに example.com だけの証明書がある場合、Certbot は既存の証明書に名前を追加するか確認してくることがあります。新しい証明書として作られると保存先が example.com-0001 のように変わるため、certbot certificates に表示されるパスを Nginx の設定に書いてください。

作業前に /etc/nginx をバックアップしておきます。

sudo cp -a /etc/nginx /etc/nginx.bak-$(date +%Y%m%d)

www なしを正規にする設定例

# 1. HTTP は www あり・なしとも https://example.com へ
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

# 2. https://www.example.com から https://example.com へ
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    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 301 https://example.com$request_uri;
}

# 3. 正規のサイト
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;

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

    root /var/www/example.com;
    index index.php index.html;
    # 以下、WordPress の設定
}

HTTP/2 を使う場合、Nginx 1.25.1 以降は listen 行ではなく http2 on; ディレクティブで有効にする書き方に変わっています。古い版の listen 443 ssl http2; は新しい版では非推奨の警告が出ることがあります。使っている版は nginx -v で確認してください（2026年10月現在）。

1つの server ブロックで if を使わない理由

server_name example.com www.example.com; の中で if ($host = www.example.com) { return 301 ...; } と書く方法もありますが、ホスト名ごとに server ブロックを分けるほうが、Nginx がリクエストを受けた時点で振り分けを済ませられ、設定も読みやすくなります。転送専用のブロックには root も PHP の設定も不要です。

転送は1回で済ませる

http://www.example.com/ が https://www.example.com/ を経由して https://example.com/ に届く、という2段階の転送は避けます。上の例では HTTP 側の転送先を最初から https://example.com に固定しているため、どの入口からでも1回で正規 URL に到達します。

www ありを正規にする設定例

向きを逆にする場合は、転送先と正規サイトの server_name を入れ替えるだけです。

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    root /var/www/example.com;
    # 以下、WordPress の設定
}

WordPress 側で確認すること

サイトアドレスを正規のホスト名と一致させる

WordPress は、「設定」→「一般」の WordPress アドレス（URL）とサイトアドレス（URL）に入っているホスト名と違う URL でアクセスされると、自分でもその URL へ転送します。Nginx で www なしへ転送しているのに WordPress の設定が www ありのままだと、Nginx と WordPress が逆方向に転送し合い、「リダイレクトが繰り返し行われました」になります。サーバー側の転送を入れる前に、両方の URL が正規のホスト名になっているか確認してください。

管理画面に入れなくなった場合は、wp-config.php に次の定数を書くと、データベースの値より優先されます。

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

本文中の URL と Cookie の設定

既存サイトで正規ホストを変更した場合は、投稿本文などに古いホスト名の URL が残ります。WP-CLI の wp search-replace を --dry-run で確認してから、データベースのバックアップを取って置換します。wp-config.php に COOKIE_DOMAIN を独自に定義している場合は、正規のホスト名と食い違っていないかも確認します。マルチサイトではサブサイトごとにドメインの設定があるため、単一サイトより影響範囲が広く、ステージング環境での確認が欠かせません。

反映と4通りの確認

sudo nginx -t && sudo systemctl reload nginx

for u in http://example.com/ http://www.example.com/ https://www.example.com/ https://example.com/; do
  printf '%-28s ' "$u"
  curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' "$u"
done

www なしを正規にした場合、上から3つが 301 https://example.com/、最後が 200 になれば成功です。パスとクエリを付けた URL（例: https://www.example.com/sample-page/?p=1）でも試し、Location に元のパスが引き継がれているかも見ておきます。ブラウザは 301 をキャッシュするため、設定を試行錯誤している間はプライベートウィンドウで確認すると混乱しにくくなります。

最後に、Search Console で正規のホスト名のプロパティ（ドメインプロパティならまとめて）を確認し、サイトマップの URL も正規のホスト名で登録されているかを見直します。

まとめ

正規にするホスト名を1つ決め、運用中のサイトは現在の設定に合わせて変えない
転送元の www 側にも DNS レコードと証明書が必要。証明書には両方の名前を入れる
HTTP・転送元の HTTPS・正規サイトで server ブロックを分け、return 301 で1回で転送する
WordPress のサイトアドレスを正規のホスト名と一致させないと転送がループする
curl で4通りの入口を確認し、パスとクエリが引き継がれているかも見る