SEO
IT雑学WordPressドメイン

「www あり」と「www なし」―ドメイン選択で失敗しない DNS・SEO 完全ガイド

SEO
この記事は約14分で読めます。

「www を付けるか付けないかで SEO に影響があるのか？ DNS はどう設定すればいいのか？」は、サイト立ち上げやリニューアル時に必ずと言っていいほど議論になるテーマです。
本記事では ユーザー体験・SEO・DNS / インフラ運用 の三つの視点から
「www あり」vs.「www なし」を徹底比較し、あなたのサイトに最適なドメイン設計を選べるようになることをゴールにします。

初心者の方は歴史と比較表だけでも全体像を掴める構成、実務担当者は技術章と SEO 章を中心に読み進めればそのまま設定手順に落とし込めるようにしています。

  • www の歴史と役割を 5 分で理解
  • 9 観点で見るメリット・デメリット完全比較
  • SEO とドメイン正規化のベストプラクティスを最新基準で解説
  • 選択フローとチェックリストで“即決”できる

1. www はどこから来た？ ― 歴史と役割

www は “World Wide Web” の略で、1990 年代初期にftp.example.com や mail.example.com など複数サービスを区別するための慣習的なサブドメインとして誕生しました。
当時はまだブラウザも普及途上で、ユーザーが URL を手入力する場面が多かったため、
「HTTP サーバーは www」と覚えてもらうのが合理的だったのです。

1.1 サービス識別サブドメインの誕生

最初期の Web サーバーである info.cern.ch はネイキッドドメインでしたが、その後 Mosaic や Netscape が広まるにつれ組織内で複数のサーバーを並行運用するケースが増加。
ネットワーク管理者は www.example.com を「ここにブラウザ向けのページがある」と示す看板として使い始めます。

1.2 www が標準化されなかった理由

DNS を定める RFC には www を強制する規定がありません。
そのためドメイン所有者は自由にホスト名を割り当てられ、ポータル型の企業サイトや個人ブログでexample.com を直接 Web に使う事例が徐々に増えました。
さらに SSL/TLS 証明書の SAN が安価・簡単になったことでwww を省くコスト的障壁も消えています。

1.3 モバイルシフトと短い URL 文化

スマートフォンが主流になった 2010 年代以降、URL は「入力するもの」ではなく SNS や QR で「シェアされるもの」へ変化しました。
短い方が視認性に優れるためD2C ブランドやニュースメディアを中心にネイキッドドメイン採用が加速しています。

2. ドメイン階層と DNS 基礎を 5 分でおさらい

www の是非を判断する前に、ドメインと DNS の仕組みをざっと復習しておくと、後工程の設定ミスを減らせます。

2.1 ルートドメインとサブドメイン

ドメインは右から左へ . 区切りで階層化されます。
example.com が「apex（ルート）ドメイン」、その左に付く www や blog がサブドメイン。
つまり www あり／なしはDNS 上まったく別ホストとして扱われるわけです。

2.2 DNS レコード種別

  • A / AAAA … IPv4 / IPv6 アドレスを直接指定。
  • CNAME … ほかのホスト名へエイリアス。apex には置けないのが原則。
  • ALIAS / ANAME … ベンダー独自拡張で、実質 CNAME と同じ動き。
    ルートに置けるため CDN 切り替えが容易。

2.3 TTL とゾーン伝播

TTL（Time To Live）が短すぎると権威 DNS への問い合わせが増え、レスポンス遅延や課金増加の要因になります。
逆に長すぎると IP 変更が世界に行き渡るまで数時間〜数日掛かり、メンテナンス時に影響が出るため通常は 300〜3,600 秒でバランスを取るのが定石です。

3. 「www あり」と「www なし」― 9 つの比較観点

ここではユーザー体験・運用・SEO など 9 項目で両者を比較します。
一覧表と併せて、各項目の“なぜ”が分かる補足を付けました。

観点www あり
(www.example.com)		www なし
(example.com)
ユーザー体験URL が長い短く覚えやすい
DNS 運用CNAME で CDN/WAF 切替が容易ルートは A/AAAA のみ (ALIAS 必要)
Cookie 範囲www だけに限定可全サブドメインへ送信
SEO正規化（301 + canonical）を徹底すれば評価差なし
レガシー互換企業ネットワークで到達率が高い「www を付け忘れると開けない」問い合わせが稀にある

ユーザー体験はシンプルさが正義ですが、CDN・ロードバランサーを柔軟に切り替えたい場合、CNAME が使える www ありが依然として有利です。
また Cookie 範囲はパフォーマンス差に直結するため、重量級アプリを運営する企業は www あり＋静的サブドメイン分離を選ぶケースが多くなります。

4. 技術的メリット・デメリットを深掘り

4.1 ルートドメインは CNAME を置けない問題

RFC 1912 は apex での CNAME を禁止しています。
そのためネイキッドドメインを CDN 経由で配信するときはALIAS / ANAME / flattened CNAME を提供する DNS ベンダーを選ぶか、IP アドレスを直接 A/AAAA で列挙する必要があります。
後者はエッジロケーションの IP が変わるたびに手動更新が必要になり、運用コストが跳ね上がる点に注意してください。

4.2 Cookie と転送量

ネイキッドドメインで発行した Cookie は*.example.com 全体に送信されるため、CloudFront や Cloudflare で静的アセットを配信する際、キャッシュキーに Cookie が付与されキャッシュヒット率が低下します。
中規模サイトでも転送量が 2〜7 % 増えた実測データがあり、ページ表示速度や CDN コストに影響する点は無視できません。

4.3 HSTS Preload と www

HSTS Preload リストはexample.com を登録すればサブドメインを包括できますが、www.example.com 単体を登録しても apex は対象外になります。
www ありを正規 URL にする場合は、apex に強制 HTTPS を掛ける追加設定が必要になるので忘れないようにしましょう。

5. SEO 観点での最適解

5.1 検索エンジンの扱い方針

Google は「www あり・なしを別サイトとみなす」と公式に明言しています。
そのためどちらか一方を301 リダイレクト + canonical で正規 URL として宣言することが必須です。
Bing や Yandex も同様のガイドラインを採用しており、これを怠ると評価が分散して検索順位が伸びません。

5.2 canonical と hreflang のベストプラクティス

  • 全ページで self-canonical を指定し、www／非 www の混在をゼロにする
  • 多言語サイトでは hreflang と canonical をペアで記述し、
    各言語版が正規 URL を指し示すように統一
  • サーバー側 301 と HTML 内 canonical を両方設定し、
    クロールバジェット浪費を防止

5.3 301 リダイレクト設計

Apache / Nginx なら RewriteRule、Cloudflare なら Cache Rules や Transform Rules で恒久リダイレクトを 1 ステップで完結させます。
リダイレクトチェーン（URL→www なし→www あり→HTTPS）を作るとクロールエラーの原因になるだけでなく、エンドユーザーの待ち時間が増えるので避けましょう。

6. 選択フロー：あなたはどちらを選ぶべき？

以下のチェックリストで Yes が多い方 が推奨パターンです。

  1. CDN や WAF、ロードバランサーを頻繁に切り替える予定がある → www あり
  2. 短いブランド URL を重視し、DNS ベンダーが ALIAS を提供している → www なし
  3. 静的アセットを別サブドメインへ分離してキャッシュ効率を上げたい → www あり
  4. 社内レガシー環境にアクセス制限があり、www 付きのほうが到達率が高い → www あり
  5. 個人ブログやポートフォリオで URL の覚えやすさを最優先 → www なし

どちらを選んでも反対側を 301 リダイレクトし、SSL 証明書は両パターンを SAN 含みで発行しましょう。
これにより検索評価の分散を防ぎ、ユーザーが打ち間違えても自動で正規 URL へ導けます。

7. www ありを正規 URL にする実装ガイド

7.1 DNS 設定例

最もシンプルな構成は www.example.com にCNAME your-app.cloudfront.net. を置き、example.com から301 リダイレクトを掛ける方法です。Route 53 なら A レコードに「エイリアス（Alias Target）」を選ぶだけで CloudFront と自動連携できます。
Cloudflare の場合は「CNAME flattening」がデフォルトで有効なので特別な設定は不要です。

7.2 Web サーバー／CDN 側 301 設定

# Apache
RewriteCond %{HTTP_HOST}  ^example\.com$ [NC]
RewriteRule ^(.*)$        https://www.example.com/$1 [R=301,L]

# Nginx
server {
    listen 443 ssl;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

CDN で Edge リダイレクトにするとオリジンサーバーに到達する前に転送が完結するため待ち時間を短縮できます。

7.3 TLS 証明書の発行

Let’s Encrypt であれば-d www.example.com -d example.comの SAN 付きでまとめて取得できます。AWS ACM なら無料でワイルドカード *.example.com を含めてもコストゼロです。

7.4 HSTS と HTTPS リダイレクト

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

HSTS Preload 申請時は example.com も HTTPS で応答する必要があります。
www ありを正規 URL にしても apex 側に 301＋TLS をセットしてください。

7.5 インフラ自動化（IaC）

# Terraform（抜粋）
resource "aws_route53_record" "www" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "www"
  type    = "CNAME"
  ttl     = 300
  records = ["${aws_cloudfront_distribution.site.domain_name}"]
}

DNS・証明書・CloudFront を一括デプロイしておくとステージング環境を複製するときも差分管理が容易になります。

8. www なし（ネイキッドドメイン）を正規 URL にする実装ガイド

8.1 ALIAS／ANAME 対応 DNS ベンダーの選定

Cloudflare、Route 53、DNS Made Easy、ConoHa DNS などはapex に仮想 CNAME を置けるため、CDN やマルチリージョンのIP 変更を自動追従してくれます。

8.2 IP 直指定運用時の可用性リスク

CDN Edge が動的に IP を変える場合、A/AAAA をハードコードすると障害時に復旧が遅れます。
マルチ値レコードで最低 4〜6 個の IP を登録し、TTL を 60 秒程度に下げておくとダウンタイムを短縮できます。

8.3 反対側（www 付き）からの 301 リダイレクト

# Cloudflare Page Rule
*www.example.com/*  →  https://example.com/$1   (301, Preserve path)

リダイレクトは 1 ステップで完結させ、/robots.txt と sitemap.xml も正規 URL で配信してください。

8.4 キャッシュと Cookie 最適化

静的ファイルを static.example.com に切り離し、HTML のみ apex で配信すると Cookie が不要なアセットに付与されずキャッシュヒット率が向上します。

8.5 CI/CD とステージング分離

ステージング環境は stg.example.net のように別ドメインを使うと Cookie 衝突を防げます。GitHub Actions で本番／ステージングをブランチ別に自動デプロイする構成が定番です。

9. 方針変更したいとき―移行プロセス

9.1 検索評価を落とさない段階移行

  1. Search Console に新旧両ドメインを登録
  2. 1 週間テスト環境で 302 リダイレクトを実施しクロールエラーを確認
  3. 問題がなければ 301 に切替え、同時に rel="canonical" を更新
  4. Sitemap の URL をすべて新ドメインに置換して再送信

9.2 リダイレクトチェーンを作らない QA

curl -I と正規表現で 3xx ループを自動検出する
シェルスクリプトを CI に組み込むと本番反映前に事故を防げます。

9.3 アナリティクス／広告タグの更新

GA4 のプロパティは URL 変更で計測が切れないものの、参照元が自社ドメイン扱いになるため除外リストの更新を忘れないようにしてください。
広告パラメータは過去遡及で変換できないのでキャンペーン URL ビルダーで新ドメインを使う形に統一します。

9.4 ログモニタリングと Search Console 警告

移行後 2 週間は 404／500 系ステータスを重点監視し、Search Console の「カバレッジ」レポートでソフト 404 やリダイレクトエラーが出ていないか日次で確認します。

10. ケーススタディ

10.1 多言語 SaaS 企業 X 社（www あり）

50 以上の国別サブドメインを展開。
www 付きにすることで blog.example.com やapi.example.com などを柔軟に増設しながら
SEO 評価を一本化できた。

10.2 D2C スタートアップ Y 社（www なし）

ブランド名とドメインを一致させ印刷物をシンプルに。
ALIAS 対応 DNS ＋ Shopify CDN で運用コストを最小化しつつ 18 % CVR 改善を記録。

10.3 国内メディア Z 社（移行失敗事例）

www なし → www ありに移行した際、一部の画像 CDN が旧ドメインのまま残り
PageSpeed Insights スコアが低下。
半年でトラフィックが 38 % 落ちたが、Sitemap 再送信と HSTS 修正で 3 か月後に回復。

付録 ― ツール & リソース集

A. 用語集（抜粋）

  • apex … ルートドメイン（example.com）
  • HSTS … HTTPS を強制するレスポンスヘッダー
  • Flattened CNAME … apex に置ける仮想 CNAME

C. Terraform / CloudFormation スニペット

# CloudFront + Route53 基本構成
module "site" {
  source  = "cloudposse/cloudfront-s3-cdn/aws"
  version = "0.83.0"
  aliases = ["example.com", "www.example.com"]
}

D. 301 リダイレクトテスト用 curl コマンド

curl -s -o /dev/null -w "%{http_code} %{url_effective}\n" -L http://example.com

よくある質問（FAQ）

質問回答
www と非 www の両方を公開してもいい？同一内容を同時公開すると重複コンテンツとみなされるため、必ず片方を 301 リダイレクトしてください。
Google Analytics の設定は変える必要がある？プロパティ ID は同じで OK。ただし参照元除外リストに新ドメインを追加し、Search Console 連携を更新します。
メールサーバーに影響は？MX レコードはドメイン全体に適用されるため、www の有無とは独立しています。変更は不要です。
HSTS Preload の申請タイミングは？正規 URL への 301 と HTTPS 配信が安定し、すべてのサブドメインが TLS 対応してから行います。
Let’s Encrypt を使うと毎回 DNS 検証が必要？HTTP-01 チャレンジを使えば自動更新できます。ワイルドカードを含める場合のみ DNS-01 が必要です。

まとめ ― 今すぐ取るべき 3 つのアクション

  1. 正規 URL を決め、反対側に 301 リダイレクトを設定する
  2. SSL 証明書を両パターン（www／非 www）対応で発行し HSTS を仕込む
  3. Search Console とアナリティクスのプロパティを更新し、移行後 2 週間はエラーログを日次チェックする

コメント

タイトルとURLをコピーしました