Selama bertahun-tahun, perang kesombongan kecil telah berkecamuk di bilah alamat kami. Di salah satu sudut adalah merek-merek seperti Google, Instagram, dan Facebook. Grup ini telah memilih untuk mengalihkan example.com untuk www.example.com. Di sudut yang berlawanan: GitHub, DuckDuckGo, dan Discord. Grup ini telah memilih untuk melakukan kebalikan dan pengalihan www.example.com untuk example.com.
Apakah "WWW" termasuk dalam URL? Beberapa pengembang memiliki pendapat yang kuat tentang masalah ini. Kami akan mengeksplorasi argumen untuk dan menentangnya setelah sedikit sejarah.
Ada apa dengan W?
Tiga W singkatan "World Wide Web", penemuan akhir 1980-an yang memperkenalkan browser dan situs web kepada dunia. Praktik penggunaan “WWW” berasal dari tradisi penamaan subdomain menurut jenis layanan yang mereka sediakan:
- server web di www.example.com
- server FTP di ftp.contoh.com
- server IRC di irc.contoh.com
Masalah domain tanpa WWW 1: Membocorkan cookie ke subdomain
Kritik terhadap domain "kurang-WWW" telah menunjukkan bahwa dalam situasi tertentu, subdomain.contoh.com akan dapat membaca cookie yang diatur oleh example.com. Ini mungkin tidak diinginkan jika, misalnya, Anda adalah penyedia hosting web yang memungkinkan klien mengoperasikan subdomain di domain Anda. Meskipun kekhawatiran tersebut valid, perilaku tersebut khusus untuk Internet Explorer.
RFC 6265 membakukan cara browser memperlakukan cookie dan secara eksplisit menyebut perilaku ini sebagai salah.
Sumber kebocoran potensial lainnya adalah Domain nilai cookie apa pun yang ditetapkan oleh example.com. Jika Domain nilai secara eksplisit diatur ke example.com, cookie juga akan diekspos ke subdomainnya.
| Nilai kue | Terkena example.com | Terkena subdomain.contoh.com |
|---|---|---|
secret=data |
✅ | ❌ |
secret=data; Domain=example.com |
✅ | ✅ |
Kesimpulannya, selama Anda tidak menetapkan a Domain value dan pengguna Anda tidak menggunakan Internet Explorer, kebocoran cookie tidak boleh terjadi.
Masalah domain tanpa WWW 2: Sakit kepala DNS
Terkadang, domain “kurang-WWW” dapat mempersulit penyiapan Domain Name System (DNS) Anda.
Saat pengguna mengetik example.com ke bilah alamat browser mereka, browser perlu mengetahui alamat Internet Protocol (IP) dari server web yang mereka coba kunjungi. Browser meminta alamat IP ini dari server nama domain Anda – biasanya secara tidak langsung melalui server DNS Penyedia Layanan Internet (ISP) pengguna. Jika server nama Anda dikonfigurasi untuk merespons dengan Rekor berisi alamat IP, domain "kurang-WWW" akan berfungsi dengan baik.
Dalam beberapa kasus, Anda mungkin ingin menggunakan a Nama Kanonis (CNAME) catatan untuk situs web Anda. Catatan seperti itu dapat menyatakan hal itu www.example.com adalah alias dari contoh123.somecdnprovider.com, yang memberi tahu browser pengguna untuk mencari alamat IP contoh123.somecdnprovider.com dan kirim permintaan HTTP ke sana.
Perhatikan bahwa contoh di atas menggunakan subdomain WWW. Tidak mungkin menentukan data CNAME untuk example.com. sesuai RFC 1912, data CNAME tidak dapat berdampingan dengan data lain. Jika Anda mencoba menentukan data CNAME untuk example.com, catatan Nameserver (NS) untuk example.com berisi alamat IP dari server nama domain tidak akan diizinkan ada. Akibatnya, browser tidak akan dapat mengetahui di mana server nama Anda berada.
Beberapa penyedia DNS akan mengizinkan Anda mengatasi batasan ini. Cloudflare memanggil solusi mereka Perataan CNAME. Dengan teknik ini, administrator domain mengonfigurasi data CNAME, tetapi server nama mereka akan menampilkan data A.
Misalnya, jika administrator mengonfigurasi data CNAME untuk example.com menunjuk ke contoh123.somecdnprovider.com, dan rekor A untuk contoh123.somecdnprovider.com ada menunjuk ke 1.2.3.4, maka Cloudflare akan mengekspos catatan A untuk example.com menunjuk ke 1.2.3.4.
Kesimpulannya, meskipun kekhawatiran tersebut berlaku untuk pemilik domain yang ingin menggunakan data CNAME, penyedia DNS tertentu kini menawarkan solusi yang sesuai.
Manfaat tanpa WWW
Sebagian besar argumen melawan WWW bersifat praktis atau kosmetik. Pendukung "No-WWW" berpendapat bahwa lebih mudah untuk mengatakan dan mengetik example.com dari www.example.com (yang mungkin kurang membingungkan bagi pengguna yang kurang paham teknologi).
Lawan dari subdomain WWW juga menunjukkan bahwa menjatuhkannya datang dengan keuntungan kinerja yang sederhana. Pemilik situs web dapat memangkas 4 byte dari setiap permintaan HTTP dengan melakukannya. Meskipun penghematan ini dapat bertambah untuk situs web dengan lalu lintas tinggi seperti Facebook, bandwidth umumnya bukanlah sumber daya yang langka.
manfaat WWW
Salah satu argumen praktis yang mendukung WWW adalah situasi dengan domain tingkat atas yang lebih baru. Sebagai contoh, www.contoh.miami segera dikenali sebagai alamat web ketika contoh.miami tidak. Ini kurang menjadi perhatian untuk situs yang memiliki domain tingkat atas yang dapat dikenali seperti .com.
Berdampak pada peringkat mesin pencari Anda
Konsensus saat ini adalah bahwa pilihan Anda tidak mempengaruhi kinerja mesin pencari Anda. Jika Anda ingin bermigrasi dari satu ke yang lain, Anda ingin mengonfigurasi pengalihan permanen (HTTP 301), bukan yang sementara (HTTP 302). Pengalihan permanen memastikan bahwa nilai SEO dari URL lama Anda ditransfer ke yang baru.
Tips untuk mendukung keduanya
Situs biasanya memilih salah satunya example.com or www.example.com sebagai situs web resmi mereka dan mengonfigurasi pengalihan HTTP 301 untuk yang lain. Secara teori, adalah mungkin untuk mendukung keduanya www.example.com dan example.com. Dalam praktiknya, biayanya mungkin lebih besar daripada manfaatnya.
Dari perspektif teknis, Anda ingin memverifikasi bahwa tumpukan teknologi Anda dapat menanganinya. Sistem manajemen konten (CMS) Anda atau situs yang dibuat secara statis harus mengeluarkan tautan internal sebagai URL relatif untuk mempertahankan nama host pilihan pengunjung. Alat analitik Anda dapat mencatat lalu lintas ke kedua nama host secara terpisah kecuali Anda dapat mengonfigurasi nama host sebagai alias.
Terakhir, Anda harus mengambil langkah ekstra untuk melindungi kinerja mesin telusur Anda. Google akan mempertimbangkan versi URL “WWW” dan “non-WWW”. duplikat konten. Untuk mendeduplikasi konten dalam indeks pencariannya, Google akan menampilkan salah satu dari dua yang menurutnya disukai pengguna – baik atau buruk.
Untuk mempertahankan kontrol atas bagaimana Anda muncul di Google, disarankan untuk memasukkan tag tautan kanonis. Pertama, tentukan nama host mana yang akan menjadi nama resmi (kanonik).
Misalnya, jika Anda memilih www.example.com, Anda harus memasukkan potongan berikut di beri tag https://example.com/my-article:
Cuplikan ini menunjukkan kepada Google bahwa varian "kurang-WWW" mewakili konten yang sama. Secara umum, Google akan memilih versi yang Anda tandai sebagai kanonis di hasil penelusuran, yang akan menjadi varian “WWW” dalam contoh ini.
Kesimpulan
Meski gencar melakukan kampanye di kedua sisi, kedua pendekatan tersebut tetap berlaku selama Anda menyadari manfaat dan keterbatasannya. Untuk menutupi semua basis Anda, pastikan untuk mengatur pengalihan permanen dari satu ke yang lain dan Anda sudah siap.
