多くの人が「ドメイン名」と「ホスト名」という用語を同じ意味で使用していますが、両者には違いがあり、これはセマンティクスだけではありません。 ポイントに集中するために、この説明を少し簡略化します。
IT管理者の場合、ドメインはネットワークになります。 ドメインに名前を付けるのは理にかなっています。 DNSシステムはこれに適合しているため、
example.com
などのドメイン名を登録し
example.com
。 これで、このドメインの下に独自のホストができます。 ネットワークに接続されている各マシンは、ホストと見なされます。 WWWドキュメントサービスマシンは、ドメイン内のホスト名
www
を自然に取得するため、完全修飾ドメイン名（FQDN）は
www.example.com
ます。 Webサーバーを持っているかどうかに関係なく、ネットワーク上の残りのホストについても同じことを行います。 したがって、ネットワークをクリーンアップします。
example.com
ドメインのWebサーバーに移動するには、
www.example.com
という名前のホストに移動する必要があります。 ところで、恐竜がWebをローミングした当時、仮想ホストは存在していませんでした。 各Webサーバーは、1つのWebサイト（少なくとも1つのIPアドレス）のみを提供しました。 ホスト名は、正しいIPアドレスを指しているかどうかは関係ありません。
「ベアドメイン名」、つまり DNSの観点から
example.com
ように「www」のないドメイン名は、オリジンと呼ばれます。 1990年代半ばにWorld Wide Webの人気が高まり、一部の管理者はwwwホストと同じIPアドレスをオリジンとして指定し始めました。 これにより、Webサイトの訪問者は、完全修飾ホスト名の代わりにブラウザで
example.com
のみを入力でき
example.com
。
それからSEOが来ました
example.com
と
www.example.com
は異なるIPアドレスを指すことができるため、1997年1月から同じIPアドレスの異なるWebサイトを指すため、SEOの専門家は正規のホスト名を選択する必要があると言ってきました。そこをポイントする必要があります（HTTPステータスコード301を使用）。
1つの名前を選択するのは理にかなっています。 しかし、どれですか？ SEOにとって、それは実際には問題ではありません。 主なものはそれを持っていることです。 しかし、SEO以外にも問題があります。 読んでください。
人々はどのようにURLを理解しますか
世紀の変わり目にマーケティング代理店で働いていたとき、「www」の部分を省略すると、人々が自分の目の前にワールドワイドウェブのアドレスがあることを理解していないのではないかと心配しました。 つまり、「http：//」をスキップし始めたところです。 さらに、歴史的な理由から、私は個人的に完全な「正しい」ホスト名を使用することを選択しました。
www.example.com
今日、それは重要ではないと思います。 人々は、wwwが存在するかどうかに関係なく、自分の前に有名なトップレベルドメインがある場合、これがWebアドレスであることを理解します。 あるバージョンは引き続き別のバージョンにリダイレクトされるため、正規のホスト名が
www.example.com
であることは問題ではなく、印刷広告では美のために
example.com
を使用し
example.com
。 同時に、.beerなどの数千の新しいトップレベルドメインの1つがある場合、世紀の変わり目でマーケティングを行っていたのと同じ理由でwwwを追加することは理にかなっています。
wwwがなければもっとシンプルで美しい
example.com
速く、読みやすく、スペースを節約するだけです。 人々がwwwのドロップを開始し、正規のホスト名として単にoriginを指定することは理解できます。
なぜ彼らはまだこれについて議論しているのですか？
「www」を使用するかどうかについてまだ議論しているのはなぜですか？ 誰もが彼が望むものを使用してみましょう、それは可能ではありませんか？
もちろんできます。
しかし、あなたがウェブサイト管理者であるなら、あなたはおそらく情報に基づいた選択をして、いくつかの事を事前に考えたいと思うでしょう。 たとえば、Cookie。
Cookieはサブドメインに渡されます
ホストに代わって設定されたCookieもすべてのサブドメインに設定されます。 つまり、
example.com
のサイトがCookieを設定している場合、ブラウザは
www.example.com
アクセスするときにこのファイルも送信します。 いいね、同じサイトだよね？ ただし、Cookieは
cdn.example.com
、
email.example.com
、
intranet.example.com
、
cdn.example.com
などにも
cdn.example.com
れます。 また、多くのサードパーティサービスにより、この方法でドメインを使用できます。
ホスト
www.example.com
から設定されたCookieは、上記のような「兄弟」ホストには送信されません。 ブラウザは、これらが「サブサービス」ではなく、Cookieにアクセスすべきではない完全に異なるサービスであることを理解しています。
不要なCookieがパフォーマンスを低下させる
HTTPおよびCookieが機能する方法は、それらがブラウザからWebサーバーへの各リクエストとともに送信されることです。 これは、サイトがオリジン（example.com）のCookieを設定する場合、このファイルは、たとえば
email.example.com
や
intranet.example.com
に対して行うすべてのリクエストに対しても送信する必要があることを意味し
email.example.com
。 これにより、接続が遅くなります。
Cookieは第三者が読み取ることができます
そのため、Webサイトがオリジン（example.com）と同じであり、CMSシステムを使用している場合、認証後にブラウザにCookieを発行してセッションを開いたままにします。 次に、
someinternalservice.example.com
と、このサービスの管理者がこのCookieを読み取り、コピーして、ユーザーに代わって
example.com
の企業CMSにログインできます。
email.example.com
または
static.example.com
などのリソースをダウンロードするCDNプロバイダーなどにアクセスする場合、電子メールベンダーにも同じことが当てはまり
email.example.com
。
example.com
で少なくとも何かのセキュリティが心配な場合は、その前に「www」を含めるようにしてください。 これで「www」を使用するように説得されない場合でも、それが何を説得できるかはわかりません。 このCookieはマジックトークンであるため、HTTPSも2FAも役に立ちません。 ただし、 IP制限などの他のセキュリティ対策が役立つ場合があります。
必要に応じて、サブドメインからのCookieを共有できます
サブドメイン（たとえば
sso.example.com
）にサービスがある場合、RFC 6265を使用すると、発信元にCookieを設定し、
example.com
または
www.example.com
と共通にすることができます。 したがって、実際には、「裸のドメイン」をホスト名として放棄すると、柔軟性が高まります。
DNS制限
柔軟性について言えば、DNSの話に戻る必要があります。
DNSには、オリジンがAレコードでなければならない、つまり固定IPアドレスを指すという制限があります。
サイトが大きくなり、ホスティングに移動するか、ファイアウォールまたはDDoS保護サービスに転送する場合は、CNAMEレコードを使用して、ホスト名を別の気まぐれなホスト名に転送します。プロバイダーは、トラフィックとニーズに応じて制御します。
ただし、サイトがベアドメイン（example.com）でホストされている場合、これを行うことはできません。 ただし、CNAMEで「www」を使用してホスト名を指定しても問題はありません。 したがって、現在または将来のスケーラビリティが必要な場合は、最初から「www」からホスト名を設定する必要があります。
結論：wwwを選択
これは、wwwを使用するかどうかに関係なく重要です。 裸のドメインはきれいに見えることに同意しますが、これはブラウザのアドレスバーにとって実際的な問題です。 正規のホスト名として
www.example.com
を使用できますが、他の場所ではそのままのドメインを使用します。 ユーザーは必要に応じてリダイレクトされます。
しかし、重要な議論は、パフォーマンス、セキュリティ、および柔軟性のために、「www」で完全修飾ホスト名を使用することを支持しています。
したがって、議論を終わらせるために、「www」を選択してください！