何年もの間、私たちのアドレスバーでは小さな衒学戦争が激しさを増しています。 片隅にはこんなブランドが でログイン, Instagram, Facebook. このグループはリダイレクトすることを選択しました example.com 〜へ www.example.com. 反対側の隅: GitHubの, DuckDuckGo, Discord. このグループは、逆方向にリダイレクトすることを選択しました www.example.com 〜へ example.com.
「WWW」は URL に含まれますか? 一部の開発者は、この件について強い意見を持っています。 少し歴史を振り返った後、それに対する賛否両論を探ります。
Wsはどうしたの？
XNUMX つの W は "ワールドワイドウェブ"、ブラウザとウェブサイトを世界に紹介した1980年代後半の発明. 「WWW」を使用する慣行は、提供するサービスの種類に基づいてサブドメインに名前を付けるという伝統に由来しています。
- の Web サーバー www.example.com
- の FTP サーバー ftp.example.com
- のIRCサーバー irc.example.com
WWW レス ドメインに関する問題 1: サブドメインへの Cookie の漏えい
「WWW レス」ドメインの批評家は、特定の状況では、 subdomain.example.com によって設定された Cookie を読み取ることができます。 example.com. これは、たとえば、クライアントがドメイン上でサブドメインを操作できるようにする Web ホスティング プロバイダーの場合、望ましくない場合があります。 懸念事項は有効ですが、動作は Internet Explorer に固有のものでした。
RFC 6265 ブラウザーが Cookie を処理する方法を標準化し、この動作が正しくないことを明示的に指摘します。
漏れの別の潜在的な原因は、 Domain 値 によって設定されたすべての Cookie の example.com。 もし Domain 値が明示的に設定されています example.com、Cookie はそのサブドメインにも公開されます。
| クッキーの価値 | にさらされる example.com | にさらされる subdomain.example.com |
|---|---|---|
secret=data |
✅ | ❌ |
secret=data; Domain=example.com |
✅ | ✅ |
結論として、明示的に設定しない限り、 Domain 値が設定されていて、ユーザーが Internet Explorer を使用していない場合、Cookie のリークは発生しません。
WWW レス ドメインの問題 2: DNS の頭痛の種
「WWW レス」ドメインは、ドメイン ネーム システム (DNS) の設定を複雑にする場合があります。
ユーザーが入力するとき example.com ブラウザのアドレス バーに入力するには、ブラウザはアクセスしようとしている Web サーバーのインターネット プロトコル (IP) アドレスを知る必要があります。 ブラウザーは、ドメインのネームサーバーからこの IP アドレスを要求します。通常は、ユーザーのインターネット サービス プロバイダー (ISP) の DNS サーバーを介して間接的に要求されます。 ネームサーバーが 記録 IP アドレスを含む場合、「WWW レス」ドメインは正常に機能します。
場合によっては、代わりに 正規名 (CNAME) あなたのウェブサイトのために記録します。 そのようなレコードは、次のことを宣言できます。 www.example.com のエイリアスです example123.somecdnprovider.comの IP アドレスを検索するようにユーザーのブラウザに指示します。 example123.somecdnprovider.com そこにHTTPリクエストを送信します。
上記の例では WWW サブドメインを使用していることに注意してください。 の CNAME レコードを定義することはできません example.com。 によると RFC 1912、CNAME レコードは他のレコードと共存できません。 CNAME レコードを定義しようとした場合 example.com、ネームサーバー (NS) レコード example.com ドメインのネーム サーバーの IP アドレスを含むファイルは存在できません。 その結果、ブラウザーはネーム サーバーの場所を特定できなくなります。
一部の DNS プロバイダーでは、この制限を回避できます。 Cloudflareは彼らのソリューションを呼び出します CNAME の平坦化. この手法では、ドメイン管理者が CNAME レコードを構成しますが、ネームサーバーは A レコードを公開します。
たとえば、管理者が CNAME レコードを example.com を指す example123.somecdnprovider.com、および A レコード example123.somecdnprovider.com を指している 1.2.3.4の場合、Cloudflare は A レコードを公開します。 example.com を指す 1.2.3.4.
結論として、この懸念は CNAME レコードの使用を希望するドメイン所有者にとって有効ですが、現在、特定の DNS プロバイダーは適切な回避策を提供しています。
WWWレスのメリット
大部分 反対の議論 WWW は実用的または装飾的です。 「No-WWW」の支持者は、言いやすく、入力しやすいと主張しています。 example.com より www.example.com (技術に詳しくないユーザーにとっては混乱が少ないかもしれません)。
WWW サブドメインの反対者は、それを削除することで、ささやかなパフォーマンス上の利点が得られることも指摘しています。 そうすることで、Web サイトの所有者は各 HTTP リクエストを 4 バイト削減できます。 これらの節約は、Facebook のようなトラフィックの多い Web サイトでは加算される可能性がありますが、帯域幅は一般的に不足しているリソースではありません.
WWWの特典
WWW を支持する実際的な議論の XNUMX つは、新しいトップレベル ドメインの場合です。 例えば、 www.example.マイアミ の場合、すぐに Web アドレスとして認識されます。 たとえば .miami そうではありません。 これは、次のような認識可能なトップレベル ドメインを持つサイトではあまり問題になりません。 .COM.
検索エンジンのランキングへの影響
現在のコンセンサスは、あなたの選択が検索エンジンのパフォーマンスに影響を与えないということです. 一方から他方に移行する場合は、一時的なリダイレクト (HTTP 301) ではなく、永続的なリダイレクト (HTTP 302) を構成する必要があります。 永続的なリダイレクトにより、古い URL の SEO 値が新しい URL に確実に移行されます。
両方をサポートするためのヒント
サイトは通常、どちらかを選択します example.com or www.example.com 公式 Web サイトとして、HTTP 301 リダイレクトを構成します。 理論的には、両方をサポートすることが可能です www.example.com および example.com. 実際には、コストがメリットを上回る場合があります。
技術的な観点からは、技術スタックがそれを処理できることを確認する必要があります。 コンテンツ管理システム (CMS) または静的に生成されたサイトは、内部リンクを相対 URL として出力して、訪問者の優先ホスト名を維持する必要があります。 ホスト名をエイリアスとして構成できない限り、分析ツールは両方のホスト名へのトラフィックを別々にログに記録する場合があります。
最後に、検索エンジンのパフォーマンスを保護するために、追加の手順を実行する必要があります。 Google は、URL の「WWW」バージョンと「非 WWW」バージョンを、 コンテンツを複製する. 検索インデックス内のコンテンツの重複を排除するために、Google は XNUMX つのうちユーザーが好むと思われる方 (良くも悪くも) を表示します。
Google での表示方法を制御し続けるために、canonical リンク タグを挿入することをお勧めします。 最初に、どのホスト名を公式 (正規) にするかを決定します。
たとえば、 www.example.com、次のスニペットを タグを付ける https://example.com/my-article:
このスニペットは、「WWW レス」バリアントが同じコンテンツを表していることを Google に示します。 通常、Google は、検索結果で正規としてマークしたバージョンを優先します。この例では、「WWW」バリアントになります。
まとめ
どちらの陣営も熱心なキャンペーンを行っていますが、メリットと限界を認識している限り、どちらのアプローチも有効です。 すべての拠点をカバーするには、一方から他方への永続的なリダイレクトを必ず設定してください。これで準備完了です。
