• HOME
  • www vs non-www: Why Only One Version Loads and How to Fix It

2026年11月12日

  • シェア
  • ツイート

    • 2026年11月12日

    www vs non-www: Why Only One Version Loads and How to Fix It

    This article is a localized edition of the Japanese original. Read the Japanese original

    www.example.com and example.com are two separate hostnames as far as DNS, SSL certificates and the web server are concerned. When only one of them opens, one of the names is missing in one of those three places, or the redirects point in conflicting directions. This article shows how to identify the failing layer from the error message, fix the DNS records, the certificate, the server configuration and the WordPress URL settings in turn, and finally consolidate everything on one version with a 301 redirect.

    First, use the error message to identify the failing layer

    The browser error tells you fairly precisely which layer is failing. The wording varies by browser and version, but in Chromium-based browsers it breaks down like this.

    • DNS_PROBE_FINISHED_NXDOMAIN / "This site can't be reached ... server IP address could not be found": name resolution is failing. Either the DNS record does not exist, or it was added at a different DNS service.
    • NET::ERR_CERT_COMMON_NAME_INVALID / "Your connection is not private": name resolution and the connection work, but the certificate does not include that hostname.
    • The server's default page, a different site, or a 404 appears: DNS and the certificate are fine, but the web server is not configured to accept that hostname.
    • ERR_TOO_MANY_REDIRECTS: the server and WordPress (or a CDN) are redirecting in opposite directions, www to non-www and non-www to www, and loop forever.

    If the message is unclear, these three checks in a local terminal will narrow things down quickly.

    # 1. Do both names resolve? (no output means a DNS problem)
dig +short example.com A
dig +short www.example.com A

# 2. What does HTTP return? (check the status and the Location header)
curl -sI http://example.com/
curl -sI http://www.example.com/

# 3. Does the certificate include both names? (show the SAN)
openssl s_client -connect example.com:443 -servername www.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

    The -ext option in the third command requires OpenSSL 1.1.1 or later. On older systems, print everything with -text and look for the "Subject Alternative Name" line.

    Cause 1: One of the DNS records is missing (the most common case)

    The most frequent mistake is registering an A record only for the root (@, example.com) when pointing the domain at the server, and forgetting to create www. The reverse also happens: some hosting providers set up only www by default.

    If one of the dig results is empty, add one of the following in your DNS control panel.

    • Point www to example.com with a CNAME (when the IP address changes, you only have to update the root)
    • Give www the same A record as the root (and an AAAA record too if you use IPv6)

    Note that you cannot put a CNAME on the root domain itself. By the DNS specification, a CNAME cannot coexist with other records (such as NS or SOA) at the same name. Some DNS services offer proprietary features such as CNAME flattening or ALIAS records that let you point the root at another hostname, but these are specific to each service.

    The other thing to check is whether the DNS you are editing is actually in use. If the name servers shown by dig +short NS example.com do not match the service whose control panel you are working in, records you add there will never take effect.

    After adding a record, old answers may persist until the record's TTL (cache lifetime) expires. Querying the authoritative server directly lets you confirm what is registered regardless of caches.

    dig +short NS example.com
dig +short @ns1.example-dns.net www.example.com A   # use the NS returned above

    Cause 2: The certificate covers only one of the names

    If DNS works but you get a certificate error, the certificate's Subject Alternative Name (SAN) does not contain both www.example.com and example.com. A certificate for example.com does not cover www.example.com, and, a common stumbling point, a wildcard certificate for *.example.com does not cover the root example.com itself.

    If you use Let's Encrypt with Certbot, reissue the certificate with both names. When adding a name to an existing certificate, --expand extends it while keeping the same certificate name.

    # Example using the Nginx plugin
sudo certbot --nginx -d example.com -d www.example.com --expand

# After issuance, confirm that renewal works
sudo certbot renew --dry-run

    With the free SSL offered by rental servers and managed hosting, some providers have you apply for the www and non-www versions separately in the control panel. The wording on screen differs by provider (as of October 2026), so check your provider's manual for how to specify the target domains. Issuing a certificate requires DNS for that name to point to the right place first, so fix Cause 1 before applying.

    Cause 3: The web server does not accept that hostname

    If DNS and the certificate are correct but you see a default page or a different site, one of the names is missing from the web server's virtual host configuration.

    • Nginx: accept both names, as in server_name example.com www.example.com;, or catch one of them in a separate server block used only for redirecting.
    • Apache: add ServerAlias www.example.com in addition to ServerName example.com.

    After changing the configuration, run a syntax check before reloading (sudo nginx -t for Nginx, sudo apachectl configtest for Apache).

    Cause 4: WordPress URL settings conflict with the redirects

    WordPress works from the WordPress Address (URL) and Site Address (URL) under Settings > General, stored internally as the siteurl and home options. On top of that, the core function redirect_canonical() redirects to the home host whenever the requested hostname differs from home.

    So if the server redirects non-www to www while WordPress's home is https://example.com (non-www), each sends visitors back to the other and you get a redirect loop. You can check the current values with WP-CLI.

    wp option get home
wp option get siteurl

    If you cannot get into the admin screen, you can temporarily override them by defining constants in wp-config.php above the "That's all, stop editing!" comment.

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

    While the constants are defined, the corresponding fields in the admin screen cannot be edited. Once you have corrected the values in the database, remove the constants to avoid confusion later.

    If you serve the site through a CDN such as Cloudflare, the CDN's redirect rules and SSL encryption mode can also cause loops. If the origin redirects to HTTPS while the CDN talks to the origin over HTTP, the redirect repeats endlessly. CDN dashboard options change often, so check each service's documentation for how it connects to the origin.

    Consolidate on one version with a 301 redirect

    Once both names open, choose one as the canonical URL and 301-redirect the other to it. Having the same content visible at two URLs counts as duplicate content for search engines, and because login cookies are separated by hostname, you also get confusing situations where you are logged in on one version and logged out on the other.

    Here is an Nginx example that consolidates on non-www over HTTPS. It assumes the certificate contains both names.

    # HTTP: send both names to the canonical URL
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

# HTTPS www: send to the canonical 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;
}

# Canonical URL (put the main WordPress configuration here)
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 and other settings follow
}

    If you do this in Apache's .htaccess, place it above the # BEGIN WordPress block that WordPress writes. If you put it below, WordPress's rewrite rules are processed first.

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

    Browsers cache 301s aggressively, so while you are testing, check the behavior with a 302 and switch to 301 only once you know it works. That makes it much easier to redo things.

    If you change the canonical URL, replace the URLs in the database too

    If you have been running the site on www and switch to non-www (or the other way around), the old hostname remains in post content and image URLs. They will still display thanks to the redirect, but every request goes through an extra hop, so it is safer to replace them. Back up the database before you start, and first check the counts with --dry-run.

    wp db export before-host-change.sql
wp search-replace 'https://www.example.com' 'https://example.com' --skip-columns=guid --dry-run
# Check the counts and target tables, then run again without --dry-run

    wp search-replace handles serialized data correctly when replacing. Rewriting directly with SQL's REPLACE can corrupt serialized values in widgets and theme settings, so avoid it. Running it once on a staging environment before production gives you extra peace of mind.

    How to verify

    Finally, confirm that all four URL variants land on the canonical URL with a single 301. With -L, curl follows the redirects and shows every step along the way.

    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

    You are done when the three non-canonical URLs finish in two steps, 301 then 200. If you check in a browser, use a private (incognito) window, because earlier redirects or HSTS may be cached.

    Summary

    • www and non-www are different hostnames, and both names must be present in DNS, the certificate, the web server and the WordPress URL settings.
    • Use the error message to identify the layer: a name resolution error points to DNS, a certificate error to the SAN, a different page to the virtual host, and a loop to the redirect direction.
    • Once both names open, choose one canonical URL, consolidate with a 301, and set WordPress's home and siteurl to match.
    • When switching the canonical URL, take a backup and then replace the URLs in the database with wp search-replace.
    Views: 4

    Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲