Apacheのwwwあり・なしリダイレクト設定｜VirtualHostと.htaccessの書き方

「www あり」と「www なし」の両方で同じサイトが開ける状態は、どちらか一方に 301 リダイレクトでまとめておくのが基本です。Apache では、サーバーの設定ファイルを編集できるなら VirtualHost の Redirect、レンタルサーバーなら .htaccess の mod_rewrite で設定します。この記事では、どちらに統一するかの決め方、HTTPS への転送と1回のリダイレクトでまとめる書き方、WordPress 側の設定との合わせ方、ループや証明書エラーを避ける確認方法を説明します。

どちらに統一するかを決める

www あり・なしのどちらを選んでも、検索エンジンや訪問者にとっての優劣はありません。判断の材料になるのは次のような運用面です。

• すでに長く使っていて、外部からのリンクや名刺・印刷物に載っている形があるなら、それに合わせる
• example.com の Cookie はサブドメインにも送られる設定になりやすいため、サブドメインを多く使うサービスでは www ありを選ぶ考え方もある
• 一部の DNS サービスでは、ドメインの頂点（www なし）に CNAME を設定できないため、CDN を使う場合に www ありのほうが設定しやすいことがある

決めたら、以後はその形を「正規の URL」として、サイト内のリンク、サイトマップ、WordPress の設定をすべて揃えます。以下では www なし（https://example.com）に統一する例で説明します。

事前に確認すること

DNS と証明書

リダイレクトを受け取るには、転送元のホスト名もサーバーに届いている必要があります。www.example.com と example.com の両方の DNS レコードがサーバーを指しているかを確認します。

dig +short example.com
dig +short www.example.com

HTTPS の場合は、証明書が両方のホスト名を含んでいることも必要です。リダイレクトは TLS の接続が確立した後に行われるため、証明書に www.example.com が含まれていないと、転送される前にブラウザが証明書エラーを表示します。Let's Encrypt の certbot なら -d example.com -d www.example.com のように両方を指定して取得します。

WordPress の URL 設定

WordPress の「設定」→「一般」にある WordPress アドレス（URL）とサイトアドレス（URL）を、統一する側の URL にしておきます。ここが www ありのまま Apache で www なしに転送すると、両者が逆方向に転送し合ってリダイレクトのループになります。設定を変更する前には、データベースのバックアップを取っておきます。

WordPress は、PHP で処理するページについては、設定された URL とホスト名が www の有無だけ違う場合に自前で転送することがあります。ただし、画像や CSS などの静的ファイルは WordPress を通らないため、Apache 側でまとめて転送しておくほうが漏れがなく、PHP を起動しない分だけ速く応答できます。

VirtualHost で設定する（推奨）

設定ファイルを編集できる場合は、転送専用の VirtualHost を作る方法が分かりやすく、条件の書き間違いも起きにくい方法です。HTTP からの転送も同時に扱い、どの入口から来ても1回のリダイレクトで正規の URL に届くようにします。

# HTTP: www あり・なしの両方を https://example.com へ
<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    Redirect permanent / https://example.com/
</VirtualHost>

# HTTPS の www あり: https://example.com へ
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    Redirect permanent / https://example.com/
</VirtualHost>

# HTTPS の正規ホスト: サイト本体
<VirtualHost *:443>
    ServerName example.com
    DocumentRoot /var/www/example
    # ...SSL とサイトの設定...
</VirtualHost>

Redirect permanent / https://example.com/ は、リクエストされたパスとクエリ文字列を保ったまま転送します。https://www.example.com/blog/?p=1 は https://example.com/blog/?p=1 に転送されます。証明書のパスは環境に合わせて書き換えてください。

変更前に設定ファイルをバックアップし、構文確認と VirtualHost の振り分けを確認してから反映します。

sudo apachectl configtest
sudo apachectl -S
sudo systemctl reload apache2   # RHEL系は httpd

apachectl -S で、www.example.com と example.com がそれぞれ意図した VirtualHost に割り当てられているかを確認できます。

.htaccess で設定する（共用サーバーの場合）

設定ファイルを触れない環境では、ドキュメントルートの .htaccess に mod_rewrite の書き方で設定します。WordPress の # BEGIN WordPress より前に書きます。WordPress のブロック内は、パーマリンク設定の保存時に書き換えられるため避けます。

www なしに統一し、HTTPS への転送も兼ねる

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]
</IfModule>

「HTTP で来た」または「ホスト名が www で始まる」のどちらかに当てはまれば、https://example.com に転送します。転送先のドメインを直接書いておくと、意図しないホスト名に転送される心配がありません。クエリ文字列は mod_rewrite が自動で引き継ぎます。

www ありに統一する場合

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]
</IfModule>

CDN やロードバランサーを使っている場合

前段のサービスで TLS を終端している構成では、Apache には HTTP で届くため %{HTTPS} が常に off になり、転送が繰り返されて「リダイレクトが多すぎます」というエラーになります。前段が X-Forwarded-Proto ヘッダーを付けているなら、条件をそちらに置き換えます。

RewriteCond %{HTTP:X-Forwarded-Proto} !https [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

この構成では、WordPress 側でも HTTPS と認識させる設定が必要になることがあります。CDN 側に「www を転送する」機能がある場合は、そちらに任せて Apache 側では設定しないという選択もあります。サービスごとの設定方法は変わることがあるため、利用しているサービスのドキュメントを確認してください（2026年10月現在）。

試すときは 302 から始める

ブラウザは 301 リダイレクトを強く記憶するため、設定を間違えたまま 301 でアクセスすると、直した後もブラウザが古い転送先へ飛び続けることがあります。動作確認の間は R=302（または Redirect temp）で試し、意図どおりに動くことを確かめてから 301 に切り替えると、やり直しが楽になります。確認にはブラウザのキャッシュに左右されない curl を使います。

curl -sI http://www.example.com/sample-page/?a=1 | grep -i -E "^(HTTP|location)"
curl -sIL http://www.example.com/sample-page/ | grep -i -E "^(HTTP|location)"

1つ目で、転送先（location）にパスとクエリ文字列が残っているかを確認します。2つ目は転送をたどって最後まで表示します。http://www.example.com から始めて、301 が1回だけで https://example.com/... の 200 に届けば理想的な状態です。301 が2回以上続く場合は、HTTP→HTTPS と www の転送が別々に行われているので、上の書き方のように1つにまとめます。

日本語のスラッグを使っている場合は、日本語を含む URL でも試し、転送先の URL が文字化けや二重のエンコードになっていないかを確認しておきます。

統一した後にやること

• サイト内のリンクや画像の URL に、統一前の形が残っていないかを確認する
• XML サイトマップが正規の URL で出力されているかを確認する
• Google Search Console では、ドメインプロパティを使うと www あり・なしの両方をまとめて確認できる

301 リダイレクトは、Google が正規の URL を判断するときの手がかりの1つとして扱われます。ただし、検索結果への反映には時間がかかり、統一によって順位が上がるといった効果を約束するものではありません。目的は、評価やアクセスが2つの URL に分かれる状態を避け、訪問者を常に同じ URL に案内することです。

まとめ

• www あり・なしは運用しやすいほうを選び、301 リダイレクトで一方に統一する
• 転送元のホスト名にも DNS レコードと証明書が必要。証明書に含まれていないと転送前にエラーになる
• WordPress のアドレス設定を統一する側に揃えておかないと、転送が逆向きに重なってループする
• 設定ファイルを触れるなら転送専用の VirtualHost、レンタルサーバーなら .htaccess の mod_rewrite で、HTTPS への転送と1回にまとめる
• 動作確認は 302 と curl で行い、転送が1回で済むことを確かめてから 301 にする

• Apacheのmod_rewriteの使い方
• WordPressの「リダイレクトが多すぎます」エラーを直す