Selama 20 tahun atau lebih, telah ada diskusi tentang apakah akan menggunakan www dalam nama host kanonik (CNAME) dari situs web Anda. Jadi apa yang digunakan atau tidak?
Meskipun banyak orang menggunakan istilah "nama domain" dan "nama host" secara bergantian, ada perbedaan di antara mereka, dan ini bukan hanya masalah semantik. Saya akan menyederhanakan deskripsi ini sedikit untuk fokus pada intinya.
Untuk Anda, sebagai administrator TI, domain Anda akan menjadi jaringan Anda. Masuk akal untuk memberi domain nama. Sistem DNS disesuaikan untuk ini, jadi Anda mendaftarkan nama domain, misalnya,
example.com . Sekarang, di bawah domain ini Anda akan memiliki host Anda sendiri. Setiap mesin dengan koneksi jaringan dianggap sebagai tuan rumah. Mesin servis dokumen WWW secara alami akan mendapatkan nama host
www di domain Anda, jadi nama domain yang sepenuhnya memenuhi syarat (FQDN) akan menjadi
www.example.com . Anda akan melakukan hal yang sama untuk seluruh host di jaringan Anda, apakah Anda memiliki server web atau tidak. Jadi, Anda membersihkan jaringan Anda.
Untuk pergi ke server web dalam domain
example.com , Anda harus pergi ke host bernama
www.example.com . Ngomong-ngomong, pada hari-hari ketika dinosaurus menjelajahi Web, host virtual tidak ada. Setiap server web hanya melayani satu situs web (setidaknya satu alamat IP). Nama host tidak masalah jika menunjuk ke alamat IP yang benar.
"Nama domain kosong", mis. nama domain tanpa 'www', seperti
example.com , dalam hal DNS, disebut asal. Ketika World Wide Web semakin populer pada pertengahan 1990-an, beberapa administrator mulai menentukan alamat IP yang sama dengan host www sebagai asal. Ini memungkinkan pengunjung situs web untuk memasukkan
example.com di browser alih-alih nama host yang sepenuhnya memenuhi syarat.
Lalu datanglah SEO
Karena
example.com dan
www.example.com dapat menunjuk ke alamat IP yang berbeda, dan sejak Januari 1997 ke situs web yang berbeda pada alamat IP yang sama, spesialis SEO mulai memberi tahu kami bahwa kami harus memilih nama host kanonik, dan sisanya harus menunjuk di sana (dengan kode status HTTP 301).
Masuk akal untuk memilih satu nama. Tapi yang mana? Untuk SEO, itu tidak masalah. Yang utama adalah memilikinya. Tapi selain SEO ada masalah lain. Baca terus.
Bagaimana orang memahami URL
Ketika saya bekerja di agensi pemasaran pada pergantian abad, saya khawatir orang mungkin tidak mengerti bahwa mereka memiliki alamat World Wide Web di depan kami jika kami menghilangkan bagian 'www'. Maksud saya, kami baru saja mulai melewatkan "http: //". Selain itu, karena alasan historis, saya pribadi memilih untuk menggunakan nama host "benar" yang lengkap, yaitu
www.example.com .
Hari ini saya tidak berpikir itu penting. Orang akan mengerti bahwa ini adalah alamat web, apakah www ada atau tidak, ketika di depannya ada domain tingkat atas yang terkenal. Karena satu versi masih dialihkan ke yang lain, tidak masalah bahwa nama inang kanonik Anda adalah
www.example.com , dan Anda menggunakan
example.com untuk iklan cetak hanya demi kecantikan. Pada saat yang sama, jika Anda memiliki satu dari ribuan domain tingkat atas baru seperti .beer, maka masuk akal untuk menambahkan www karena alasan yang sama dengan yang Anda miliki dalam pemasaran pada pergantian abad ini.
Tanpa www itu lebih sederhana dan lebih indah
Saya harus mengakui:
example.com lebih cepat mengetik, lebih mudah dibaca, dan hanya menghemat ruang. Dapat dimengerti bahwa orang-orang mulai menjatuhkan www - dan hanya menentukan asal sebagai nama host kanonik.
Jadi mengapa mereka masih berdebat tentang ini?
Mengapa kita masih mendiskusikan menggunakan 'www' atau tidak? Biarkan semua orang menggunakan apa yang diinginkannya, bukan?
Tentu saja bisa.
Tetapi jika Anda adalah administrator situs web, maka Anda mungkin ingin membuat pilihan berdasarkan informasi dan memikirkan beberapa hal sebelumnya. Misalnya, cookie.
Cookie dilewatkan ke subdomain
Cookie yang ditetapkan atas nama tuan rumah juga akan ditetapkan untuk semua subdomain. Artinya, jika situs di
example.com menetapkan cookie, browser juga akan mengirim file ini ketika mengunjungi
www.example.com . Kedengarannya bagus, ini situs yang sama, bukan? Tetapi cookie juga akan menuju ke
cdn.example.com ,
email.example.com ,
intranet.example.com ,
thirdpartyservice.example.com dan seterusnya. Dan banyak layanan pihak ketiga memungkinkan Anda menggunakan domain Anda dengan cara ini.
Cookie yang diatur dari host
www.example.com * tidak akan * dikirim ke host "persaudaraan" seperti di atas. Browser Anda memahami bahwa ini bukan "subservice", tetapi layanan yang sama sekali berbeda yang tidak boleh mengakses cookie Anda.
Cookie yang tidak perlu merusak kinerja
Cara kerja HTTP dan cookie adalah bahwa mereka dikirim dari browser dengan setiap permintaan ke server web. Ini berarti bahwa jika situs Anda menetapkan cookie untuk asal (example.com) file ini juga harus dikirim untuk setiap permintaan yang Anda buat, misalnya, ke
email.example.com atau
intranet.example.com . Ini memperlambat koneksi.
Cookie dapat dibaca oleh pihak ketiga
Jadi, jika situs web sama dengan asal (example.com) dan menggunakan sistem CMS, maka setelah otorisasi akan mengeluarkan cookie ke browser Anda untuk menjaga sesi tetap terbuka. Kemudian, ketika Anda mengunjungi
someinternalservice.example.com , administrator layanan ini dapat membaca cookie ini, menyalinnya, dan menggunakannya untuk masuk ke CMS perusahaan,
example.com atas nama Anda. Hal yang sama berlaku untuk vendor email ketika mengunjungi
email.example.com atau penyedia CDN yang mengunduh sumber daya, seperti
static.example.com , dan sebagainya.
Jika Anda khawatir tentang keamanan setidaknya sesuatu di
example.com , pastikan untuk menyertakan 'www' sebelumnya. Bahkan jika ini tidak meyakinkan Anda untuk menggunakan 'www', maka saya tidak tahu apa yang bisa meyakinkan. HTTPS maupun 2FA tidak akan membantu, karena cookie ini adalah token ajaib. Namun, langkah-langkah keamanan lainnya, seperti
pembatasan IP , dapat membantu.
Cookie dari subdomain dapat dibagikan jika Anda mau
Jika Anda memiliki layanan di subdomain, misalnya,
sso.example.com , maka RFC 6265 memungkinkan Anda untuk mengatur cookie untuk asal dan menjadikannya umum dengan
example.com atau
www.example.com . Dengan demikian, meninggalkan "domain kosong" sebagai nama host, pada kenyataannya, memberi Anda lebih banyak fleksibilitas.
Pembatasan DNS
Bicara soal fleksibilitas, kita harus kembali membicarakan DNS.
Ada batasan dalam DNS yang asal harus menjadi catatan A, yaitu, arahkan ke alamat IP tetap.
Ketika situs Anda menjadi besar dan Anda memindahkannya ke hosting atau ingin mengarahkannya ke firewall atau layanan perlindungan DDoS, kemudian gunakan catatan CNAME untuk mengarahkan nama host ke nama host lain yang tidak konsisten, yang dikendalikan oleh penyedia tergantung pada lalu lintas dan kebutuhan Anda.
Tetapi jika situs di-host pada domain kosong (example.com), Anda tidak dapat melakukan ini. Namun, tidak ada masalah menentukan nama host dengan 'www' di CNAME. Jadi, jika Anda menginginkan skalabilitas, sekarang atau di masa depan, Anda harus menetapkan nama host dari 'www' dari awal.
Kesimpulan: pilih www
Ini penting apakah Anda menggunakan www atau tidak. Saya setuju bahwa domain kosong terlihat lebih cantik, tetapi ini hanya pertanyaan praktis untuk bilah alamat browser. Anda dapat menggunakan
www.example.com sebagai nama host kanonik, dan di tempat lain cukup gunakan domain kosong. Pengguna masih akan diarahkan jika perlu.
Tetapi argumen-argumen penting mendukung penggunaan nama host yang sepenuhnya memenuhi syarat dengan 'www': untuk kinerja, keamanan, dan fleksibilitas.
Jadi sekali dan untuk semua mengakhiri diskusi: pilih 'www'!