2026年6月21日

ドメインのwwwあり・なしを統一する設定方法（DNS・SSL・301リダイレクト・WordPress）

VPS・クラウド

www.example.com と example.com の両方でサイトが開ける状態は、どちらか一方を「正規のURL」に決め、もう一方からは301リダイレクトで転送する形に整えるのが基本です。この記事では、どちらを選ぶかの考え方から、DNS・SSL証明書・Webサーバー（Apache／Nginx）の設定、WordPress側のURL変更、検証方法までを順番に説明します。読み終えるころには、転送の連鎖やリダイレクトループを起こさずに統一できるようになります。

なぜwwwあり・なしを統一するのか

2つのホスト名で同じページが表示されると、検索エンジンからは別々のURLに同じ内容がある状態に見えます。Googleは多くの場合どちらかを正規URLとして自動的に選びますが、その選択がサイト運営者の意図と一致するとは限らず、被リンクやアクセス解析の数値も2つに分散します。

運用面でも、WordPressのログインCookieはホスト名ごとに扱われるため、wwwありでログインしたあとwwwなしのURLを開くと未ログイン扱いになる、といった混乱が起きます。目的は「ユーザーも検索エンジンも、常に1つのURLにたどり着く」状態にすることで、リダイレクトに加えて内部リンク・canonical・サイトマップも同じURLにそろえます。

wwwあり・なし、どちらを選ぶか

検索順位の面ではどちらを選んでも有利不利はありません。判断材料は技術的な事情です。

wwwなし（example.com）: URLが短く覚えやすい。一方、DNSの仕様上、ゾーンの頂点（apex）にはCNAMEを置けないため、CDNやPaaSを使う場合はAレコードの固定IPか、DNS事業者独自のALIAS／ANAME／CNAMEフラット化機能が要ります。
wwwあり（www.example.com）: CNAMEで外部サービスに向けやすく、CDN導入やサーバー移転が柔軟です。

すでに運用中のサイトなら、検索結果やSearch Consoleで現在多く表示されている側、被リンクが多く集まっている側を正規URLにすると移行の影響が小さく済みます。新規サイトで迷う場合、将来CDNを使う予定があるならwwwありが扱いやすい、という程度の目安で構いません。

作業前の確認と準備

本番で作業する前に、次の点を確認します。

バックアップ: データベースとファイル（特に .htaccess やNginxの設定ファイル）を保存します。WordPressのURL変更はデータベースを書き換える作業です。
現在の挙動の記録: 4通りのURL（http／https × wwwあり／なし）にアクセスしたとき、それぞれ何が返るかを控えておきます。後述の curl -I で調べられます。
CDNやリバースプロキシの有無: Cloudflareなどを経由している場合、リダイレクトをCDN側のルールで行うかオリジンサーバーで行うかを決めます。両方で設定すると二重転送やループの原因になるため、どちらか一方に寄せます。
ステージング環境: 可能なら同じ構成のステージングで手順を試してから本番に反映します。

DNSとSSL証明書を両方のホスト名に対応させる

リダイレクトはサーバーにリクエストが届いて初めて動作します。そのため、転送元のホスト名もDNSで名前解決でき、HTTPSで接続できる状態にしておく必要があります。

DNSでは、apex（example.com）のAレコード（IPv6を使うならAAAAも）と、wwwのAレコードまたはCNAMEを用意します。wwwは www CNAME example.com. の形で頂点に向けるのが一般的です。dig +short example.com と dig +short www.example.com で両方が同じサーバーを指していることを確認します。

SSL証明書は、両方のホスト名を含めて発行します。証明書がwwwなししか含んでいないと、https://www.example.com/ にアクセスした時点でブラウザが証明書エラーを出し、リダイレクトまで到達しません。Let's Encryptとcertbotを使う場合は、次のように2つのドメインを指定します。

# Nginxの例（Apacheなら --apache）
sudo certbot --nginx -d example.com -d www.example.com

# 発行済み証明書が含むホスト名を確認
sudo certbot certificates

レンタルサーバーでは、コントロールパネルの無料SSL設定でwwwありも対象に含めるかを選ぶ項目があることが多いので、管理画面の該当箇所を確認してください。

Webサーバーで301リダイレクトを設定する

転送はWebサーバーの設定で行うのが基本です。WordPressにも転送機能はありますが、PHPが動く前の段階で処理するほうが軽く、画像やCSSなどの静的ファイルにも同じルールが適用されます。

ポイントは、http→https とホスト名の統一を1回の転送でまとめることです。http://example.com → https://example.com → https://www.example.com のように2段階になると、表示がわずかに遅くなり、設定ミスがあると連鎖が長くなります。

Apache（.htaccess）の例

wwwありに統一する場合の例です。WordPressが生成する # BEGIN WordPress ブロックより上に書きます。WordPressのブロック内に書くと、パーマリンク設定の保存時に上書きされることがあります。

<IfModule mod_rewrite.c>
RewriteEngine On
# http でアクセスされた、または www なしでアクセスされた場合に転送
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]
</IfModule>

wwwなしに統一する場合は、2つ目の条件を ^www\.example\.com$ に、転送先を https://example.com%{REQUEST_URI} に置き換えます。%{REQUEST_URI} にはクエリ文字列が含まれないので、mod_rewriteの既定どおり元のクエリ文字列は転送先にそのまま引き継がれます。

CDNやロードバランサーでSSLを終端している構成では、オリジン側から見ると常にhttpで届くため %{HTTPS} off が毎回成立してループします。その場合はプロキシが付けるヘッダー（X-Forwarded-Proto など）で判定するか、転送をCDN側に任せます。

Nginxの例

Nginxでは、転送専用のserverブロックを分けると見通しがよくなります。

# http は両ホスト名とも https://www へ
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

# https の www なしは www へ
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;
}

# 正規URL（ここに通常のWordPress設定を書く）
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;
    # ... location 設定など
}

$request_uri はパスとクエリ文字列を含むため、そのまま転送先に付けられます。設定を変えたら sudo nginx -t で構文を確認してから sudo systemctl reload nginx で反映します。証明書のパスはcertbotの出力に表示されたものに合わせてください。

レンタルサーバーで .htaccess が使えない、または管理画面に「www統一」や転送の設定がある場合は、その機能を使うほうが安全です。

WordPress側のURLを正規URLにそろえる

サーバーで転送しても、WordPressの「WordPressアドレス（URL）」と「サイトアドレス（URL）」が転送元のホスト名のままだと、WordPress自身が逆方向に転送してループします。管理画面の「設定」→「一般」で、2つのURLを正規URLに変更します。データベースでは wp_options テーブルの siteurl と home にあたります。

変更すると即座にログイン状態が切れることがあるので、新しいURLで管理画面にログインし直してください。項目が灰色で編集できない場合は、wp-config.php で WP_HOME と WP_SITEURL が定義されています。その場合は定数の値を書き換えます。

// wp-config.php（定義されている場合のみ書き換える）
define( 'WP_HOME', 'https://www.example.com' );
define( 'WP_SITEURL', 'https://www.example.com' );

なお、WordPressのコア関数 redirect_canonical() は、フロントエンドへのリクエストのホスト名が「サイトアドレス」とwwwの有無だけ異なる場合に転送する処理を持っています。ただしPHPを経由するリクエストにしか効かないため、サーバー側の転送の代わりにはなりません。

本文中の古いURLを置き換える

記事本文や画像URLに転送元のホスト名が直接書き込まれていると、ページを開くたびにリダイレクトが発生します。WP-CLIが使えるなら wp search-replace で置き換えます。シリアライズされたデータも正しく扱われます。

# まずバックアップ
wp db export before-www.sql

# 変更内容を確認（--dry-run は書き換えない）
wp search-replace 'https://example.com' 'https://www.example.com' --skip-columns=guid --dry-run

# 問題なければ実行
wp search-replace 'https://example.com' 'https://www.example.com' --skip-columns=guid

guid 列はフィードの識別子として使われるため、置き換えの対象から外すのが一般的です。WP-CLIが使えない環境では、置換系プラグイン（Better Search Replaceなど）を使う方法もありますが、どちらの場合も実行前のバックアップを取ってください。キャッシュ系プラグインやCDNのキャッシュは、変更後に削除します。

動作確認の方法

ブラウザはリダイレクトをキャッシュするため、確認には curl を使うと正確に調べられます。-I はヘッダーのみ、-L は転送を最後まで追う指定です。

# 4通りのURLを確認
for u in http://example.com/ http://www.example.com/ https://example.com/ https://www.example.com/; do
  echo "== $u"
  curl -sIL "$u" | grep -iE '^(HTTP/|location:)'
done

期待する結果は、正規URL以外の3つが 301 と location: https://www.example.com/ を1回返し、そのあと 200 になることです。転送が2回以上続く、同じURLを行き来している、といった場合は設定を見直します。下層ページ（例: /sample-page/?utm_source=test）でもパスとクエリ文字列が保たれるかを確認してください。

301は恒久的な転送としてブラウザに長くキャッシュされることがあります。設定に自信がないうちは、一時的に302で試してから301に切り替えると、間違えたときの影響を抑えられます。

検索エンジン向けの後処理

転送を設定したら、検索エンジンにも正規URLが伝わるように整えます。

canonical: WordPressは個別ページに rel="canonical" を出力します。SEOプラグインを使っている場合も、出力されるURLが正規URLになっているかページのソースで確認します。
XMLサイトマップ: サイトマップ内のURLが正規URLになっているかを確認し、Search Consoleに送信し直します。
Search Console: ドメインプロパティ（DNS確認）で登録しておくと、wwwあり・なしやhttp／httpsをまとめて確認できます。

転送は長期間残しておく前提で設定します。古いURLへのリンクは外部サイトやブックマークに残り続けるためです。

つまずきやすいポイント

リダイレクトループ: WordPressの「サイトアドレス」とサーバーの転送先が食い違っている、CDNとオリジンの両方で転送している、SSL終端の構成で %{HTTPS} の判定が常にoffになる、のいずれかが典型です。
証明書エラー: 転送元のホスト名が証明書に含まれていないと、転送以前にブラウザが警告を出します。
HSTS: includeSubDomains 付きのHSTSを設定している場合、wwwを含むすべてのサブドメインがHTTPSで応答できる必要があります。
マルチサイト: WordPressマルチサイトではネットワーク全体のドメイン設定や wp-config.php の DOMAIN_CURRENT_SITE も関係するため、単一サイトとは別の手順として扱います。

この記事の手順は一般的な構成を前提にしています（2026年10月現在）。WordPressやレンタルサーバーの管理画面の項目名は変わることがあります。

まとめ

wwwあり・なしは、どちらを選んでも検索上の優劣はありません。CDNの使いやすさや既存の被リンクで決めます。
転送元のホスト名もDNSで解決でき、SSL証明書に含まれている状態にしてから転送を設定します。
転送はWebサーバーで、http→httpsとホスト名の統一を1回の301にまとめます。
WordPressの「WordPressアドレス」「サイトアドレス」と本文中のURLを正規URLにそろえ、canonicalとサイトマップも確認します。
確認は curl -sIL で4通りのURLを試し、転送が1回で終わることを見ます。