2026年5月24日

www あり/なしの片方だけアクセスできない原因と解決手順

DNS・名前解決

www.example.com と example.com は、DNS・SSL証明書・Webサーバーのどれから見ても「別々のホスト名」です。片方だけ開けないときは、この3か所のどこかで片方の名前が抜けているか、リダイレクトの向きが食い違っています。この記事では、エラー表示から原因の層を特定し、DNSレコード・証明書・サーバー設定・WordPressのURL設定を順に直して、最後に「どちらか一方へ301リダイレクトで統一する」ところまでを扱います。

まずエラー表示で原因の層を見分ける

ブラウザのエラーは、どの層で止まっているかをかなり正確に教えてくれます。表示はブラウザやバージョンで変わりますが、Chrome系では次のように分かれます。

DNS_PROBE_FINISHED_NXDOMAIN / 「サーバーのIPアドレスが見つかりませんでした」: 名前解決の段階で失敗しています。DNSレコードが無い、または別のDNSサービスに登録しているケースです。
NET::ERR_CERT_COMMON_NAME_INVALID / 「この接続ではプライバシーが保護されません」: 名前解決と接続はできていますが、証明書にそのホスト名が含まれていません。
サーバーの初期ページ、別サイト、404が出る: DNSと証明書は通っていて、Webサーバーがそのホスト名を受け付ける設定になっていません。
ERR_TOO_MANY_REDIRECTS: サーバー側とWordPress側（またはCDN）で、wwwあり→なしとなし→ありのリダイレクトが逆向きに働いてループしています。

表示が曖昧なときは、手元のターミナルで次の3つを確認すると切り分けが早くなります。

# 1. 両方の名前が解決できるか（何も返らなければDNSの問題）
dig +short example.com A
dig +short www.example.com A

# 2. HTTPで何が返るか（ステータスとLocationヘッダーを見る）
curl -sI http://example.com/
curl -sI http://www.example.com/

# 3. 証明書に両方の名前が入っているか（SANを表示）
openssl s_client -connect example.com:443 -servername www.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

3つ目の -ext オプションは OpenSSL 1.1.1 以降で使えます。古い環境では -text で全体を出し、「Subject Alternative Name」の行を探してください。

原因1: 片方のDNSレコードが無い（最も多い）

ドメインを取得してサーバーに向けたとき、ルート（@、example.com）のAレコードだけを登録し、www を作り忘れている例がもっとも多く見られます。逆に、レンタルサーバーの初期設定で www だけが用意されていることもあります。

dig で片方が空なら、DNSの管理画面に次のどちらかを追加します。

www を CNAME で example.com に向ける（IPアドレスの変更時にルートだけ直せば済む）
www にもルートと同じ Aレコード（IPv6を使っているならAAAAレコードも）を登録する

ルートドメインそのものにはCNAMEを置けない点に注意してください。DNSの仕様上、CNAMEは同じ名前に他のレコード（NSやSOAなど）と共存できないためです。一部のDNSサービスにはCNAMEフラットニングやALIASレコードといった独自機能があり、ルートを別ホスト名に向けられますが、これはサービス固有の仕組みです。

もう一つ確認したいのは、編集しているDNSが実際に使われているかです。dig +short NS example.com で表示されたネームサーバーが、いま操作している管理画面のサービスと一致していなければ、そこにレコードを足しても反映されません。

追加後は、レコードのTTL（キャッシュ保持時間）が切れるまで古い応答が残ることがあります。権威サーバーに直接問い合わせると、キャッシュに関係なく登録内容を確かめられます。

dig +short NS example.com
dig +short @ns1.example-dns.net www.example.com A   # 上で出たNSを指定

原因2: 証明書が片方の名前しか含んでいない

DNSは通るのに証明書エラーが出る場合、証明書の「サブジェクト代替名（SAN）」に www.example.com と example.com の両方が入っていません。example.com 用の証明書は www.example.com をカバーしませんし、ワイルドカード証明書 *.example.com もルートの example.com 自体はカバーしない点がつまずきやすいところです。

Let's Encrypt と Certbot を使っている場合は、両方の名前を指定して証明書を取り直します。既存の証明書に名前を足すときは --expand を付けると、同じ証明書名のまま拡張されます。

# Nginx プラグインを使う場合の例
sudo certbot --nginx -d example.com -d www.example.com --expand

# 取得後、更新が通るかを確認
sudo certbot renew --dry-run

レンタルサーバーやマネージドホスティングの無料SSLでは、管理画面で「wwwあり」と「wwwなし」を別々に申請する方式のところもあります。画面の表記は事業者ごとに異なるため（2026年10月現在）、各社のマニュアルで「対象ドメイン」の指定方法を確認してください。証明書の発行には、その名前のDNSが先に正しく向いている必要があるので、原因1を先に直してから申請します。

原因3: Webサーバーがそのホスト名を受け付けていない

DNSと証明書が正しいのに初期ページや別サイトが出る場合は、Webサーバーのバーチャルホスト設定に片方の名前が書かれていません。

Nginx: server_name example.com www.example.com; のように、両方を受け付けるか、片方をリダイレクト専用の server ブロックで受けます。
Apache: ServerName example.com に加えて ServerAlias www.example.com を書きます。

設定を変えたら、反映前に構文チェックを通してから再読み込みします（Nginx は sudo nginx -t、Apache は sudo apachectl configtest）。

原因4: WordPressのURL設定とリダイレクトがぶつかっている

WordPressは「設定 → 一般」の WordPress アドレス（URL） と サイトアドレス（URL）（内部的には siteurl と home オプション）を基準に動きます。さらにコアの redirect_canonical() が、アクセスされたホスト名が home と違う場合に home 側へリダイレクトします。

このため、サーバー側で「wwwなし → wwwあり」に転送しているのに、WordPressの home が https://example.com（wwwなし）だと、両者が互いに逆へ送り合ってリダイレクトループになります。現在の値はWP-CLIで確認できます。

wp option get home
wp option get siteurl

管理画面に入れない場合は、wp-config.php の「編集が必要なのはここまで」のコメントより上に定数を書いて一時的に上書きできます。

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

定数で指定している間は管理画面の該当欄が編集できなくなります。DBの値を正しく直したら、定数は外しておくと後で混乱しません。

CloudflareなどのCDNを通している場合は、CDN側のリダイレクトルールやSSLの暗号化モードもループの原因になります。オリジンがHTTPSへ転送しているのに、CDNとオリジン間がHTTPの設定だと、転送が延々と繰り返されます。CDNの画面項目は変更が多いため、各サービスのドキュメントで「オリジンとの通信方式」を確認してください。

どちらかに統一して301リダイレクトする

両方で開けるようになったら、正規のURLをどちらか一つに決め、もう片方からは301で転送します。同じ内容が2つのURLで見える状態は、検索エンジンにとって重複になるうえ、ログインCookieがホスト名ごとに分かれて「片方ではログインしているのに、もう片方ではログアウトしている」という混乱も起きます。

Nginxで「wwwなし・HTTPS」に統一する例です。証明書には両方の名前が入っている前提です。

# HTTP は両方の名前とも正規URLへ
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

# HTTPS の www は正規URLへ
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;
}

# 正規URL（ここに WordPress 本体の設定を書く）
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;
    # ...以下、PHP-FPM などの設定
}

Apacheの .htaccess で行う場合は、WordPressが書き込む # BEGIN WordPress ブロックより上に置きます。下に置くとWordPressのリライトが先に処理されます。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]
</IfModule>

301はブラウザに強くキャッシュされるため、設定を試している間は302で動作を確かめ、問題がないと分かってから301に切り替えると、やり直しが楽です。

正規URLを変えるならDB内のURLも置き換える

これまで www ありで運用していて、なしへ切り替える（またはその逆）場合、記事本文や画像のURLにも旧ホスト名が残っています。リダイレクトで表示はされますが、毎回転送が挟まるので置き換えておくのが無難です。作業前にDBのバックアップを取り、まず --dry-run で件数を確認してください。

wp db export before-host-change.sql
wp search-replace 'https://www.example.com' 'https://example.com' --skip-columns=guid --dry-run
# 件数と対象テーブルを確認してから --dry-run を外して実行

wp search-replace はシリアライズされたデータも考慮して置き換えます。SQLの REPLACE で直接書き換えると、ウィジェットやテーマ設定のシリアライズ値が壊れることがあるので避けてください。本番の前にステージング環境で一度通しておくと安心です。

確認方法

最後に、4通りのURLすべてが1回の301で正規URLに着地するかを確かめます。-L を付けるとリダイレクトをたどり、途中経過がすべて表示されます。

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 → 200 の2段で終わっていれば完了です。ブラウザで確かめる場合は、以前のリダイレクトやHSTSがキャッシュされていることがあるので、シークレットウィンドウを使ってください。

まとめ

www ありとなしは別のホスト名で、DNS・証明書・Webサーバー・WordPressのURL設定のそれぞれに両方の名前が必要です。
エラー表示で層を見分けます。名前解決エラーならDNS、証明書エラーならSAN、別ページならバーチャルホスト、ループならリダイレクトの向きを疑います。
両方で開けるようになったら、正規URLを一つ決めて301で統一し、WordPressの home・siteurl もそれに合わせます。
正規URLを切り替えるときは、バックアップを取ってから wp search-replace でDB内のURLも置き換えます。

www あり/なし の片方だけアクセスできない原因と解決手順