6 Cara Memindahkan Website ke Cloudflare

Memindahkan Website ke Cloudflare Bukan Sekadar Ganti Nameserver

Mengarahkan domain ke Cloudflare terdengar seperti pekerjaan sepuluh menit. Ganti nameserver, tunggu propagasi, selesai. Kenyataannya banyak website tampil normal tetapi emailnya berhenti bekerja, dan pemiliknya baru sadar dua hari kemudian.

Saya sering menerima keluhan seperti itu. Halaman beranda terbuka mulus, tetapi pesanan lewat email tidak masuk. Penyebabnya hampir selalu sama, record MX tidak ikut berpindah saat nameserver diganti, dan tidak ada yang memeriksanya sebelum cutover.

Cloudflare memang memindahkan seluruh pengelolaan DNS ke dashboardnya. Itu kemudahan sekaligus jebakan, sebab apa pun yang tidak Anda bawa dari penyedia lama tidak akan muncul kembali dengan sendirinya.

Enam langkah di bawah ini menyusun urutan kerja yang aman untuk memindahkan website ke Cloudflare. Tidak ada langkah yang boleh dilompati, terutama bagian mencocokkan record lama dan mengamankan jalur email bisnis Anda.

1. Membuat Akun dan Menambahkan Domain untuk Memindahkan Website ke Cloudflare

Langkah pertama sederhana, tetapi menentukan seluruh alur berikutnya. Buat akun di dashboard Cloudflare, lalu pilih menu untuk menambahkan situs dan ketik nama domain Anda tanpa www, misalnya namausaha.com. Pilih paket gratis lebih dulu.

Setelah domain dimasukkan, Cloudflare langsung memindai record DNS yang masih aktif di penyedia lama Anda. Ia membaca dari nameserver publik yang sedang dipakai sekarang, jadi hasil pindainya adalah cerminan kondisi saat itu, bukan daftar yang Anda tulis sendiri.

Di tahap ini nameserver Anda belum berubah. Domain masih dilayani penyedia lama, dan Cloudflare hanya menyiapkan ruang kerja. Karena itu risiko nol, dan Anda punya waktu untuk memeriksa semua baris dengan tenang sebelum ada trafik nyata yang berpindah.

Paket gratis sudah cukup untuk sebagian besar usaha kecil. Kemampuan lanjutan seperti aturan cache khusus atau analitik mendalam baru perlu dipertimbangkan kalau trafik Anda sudah ramai, dan saat itu tiba Anda bisa naik paket tanpa mengulang proses ini.

Ada satu kebiasaan kecil yang menghemat banyak waktu: beri nama catatan record Anda dengan tanggal, misalnya daftar-dns-oktober. Ketika enam bulan lagi Anda perlu mengubah record lain, Anda punya dasar pembanding. Tanpa arsip seperti itu, setiap perubahan DNS berubah menjadi tebak-tebakan.

2. Mencocokkan Hasil Pemindaian dengan Catatan Record Lama

Inilah langkah yang paling sering dilewati, dan yang paling mahal akibatnya. Pemindaian otomatis tidak sempurna. Record yang jarang dibaca publik sering tidak terbaca, termasuk verifikasi pihak ketiga, DKIM, dan beberapa entri TXT.

Sebelum menekan tombol lanjut, buka panel DNS di penyedia lama Anda di tab lain. Salin semua record A, CNAME, MX, TXT, SPF, DKIM, DMARC, dan record verifikasi yang dipakai layanan lain. Rekam apa adanya, lengkap dengan nilai dan prioritasnya.

Setelah itu bandingkan daftar Anda dengan daftar hasil pindai Cloudflare, baris demi baris. Kalau ada yang hanya muncul di satu sisi, itu yang harus Anda putuskan sekarang: dibawa atau dihapus. Menemukannya setelah cutover jauh lebih melelahkan.

Praktik yang paling aman adalah membandingkan sebelum nameserver berubah, bukan sesudahnya. Kuncinya, Anda bisa memperbaiki record di dashboard Cloudflare sebanyak yang Anda mau tanpa mengubah apa pun di sisi pengunjung. Tidak ada tekanan waktu, karena domain masih dilayani penyedia lama sampai Anda sendiri yang memindahkan nameserver.

Panduan resmi tentang cara mengelola dan mengimpor record ada di halaman manajemen record DNS Cloudflare, dan layak Anda buka sambil menyisir daftar. Khusus record email, jangan menunggu sampai nanti. Periksa MX sekarang, karena satu baris yang terlewat bisa mematikan kotak masuk bisnis Anda.

Kalau Anda memakai layanan email pihak ketiga, perhatikan juga record verifikasi yang mereka minta. Record itu biasanya berupa TXT dengan kode panjang, tampak tidak penting, dan justru yang membuat pengiriman email dari sistem Anda tetap lolos autentikasi. Hapus satu saja, dan email dari formulir kontak bisa berakhir di folder spam pelanggan.

3. Mengarahkan Nameserver di Registrar

Saat record sudah rapi, Cloudflare menampilkan dua nameserver yang harus Anda pakai. Buka panel registrar tempat domain dibeli, cari pengaturan nameserver, lalu ganti nilai lama dengan pasangan dari Cloudflare itu. Simpan, dan biarkan.

Perpindahan nameserver butuh waktu. Umumnya hitungan jam, kadang sehari penuh, tergantung TTL dan kecepatan registrar Anda. Selama masa itu sebagian pengunjung masih diarahkan penyedia lama dan sebagian sudah ke Cloudflare. Keduanya normal.

Jangan mematikan hosting lama begitu nameserver baru tersimpan. Biarkan server lama hidup setidaknya 24 sampai 72 jam, bahkan sampai sekitar satu minggu, karena bot dan pengunjung yang menyimpan catatan DNS lama masih mengetuk ke sana. Kalau dokumen perpindahan Anda perlu disiapkan lebih rapi, urutan lengkapnya ada di panduan pindah dari shared hosting ke VPS.

Kalau lupa detail yang sudah Anda lewatkan di awal, tidak perlu panik. Selama nameserver masih mengarah ke penyedia lama, perubahan apa pun masih bisa Anda batalkan tanpa dampak ke pengunjung.

Ukur juga kesabaran Anda di sini. Setiap kali nameserver berubah, jaringan di seluruh dunia butuh waktu untuk memperbarui salinannya. Ada pengunjung yang masih diarahkan ke server lama berjam-jam setelah Anda mengganti nameserver. Jangan buru-buru menyimpulkan gagal hanya karena satu perangkat di kantor Anda masih membuka versi lama.

Baca Juga

7 Waktu Terbaik Pindah Hosting Website

4. Memahami Arti Awan Oranye dan Awan Abu-Abu

Setiap record di dashboard Cloudflare punya ikon awan. Warnanya bukan hiasan, tetapi menentukan siapa yang menjawab permintaan pengunjung. Salah memilih di sini bisa merusak layanan yang tadinya jalan normal.

Awan oranye berarti record itu diproksikan. Lalu lintas HTTP dan HTTPS masuk dulu ke jaringan Cloudflare, server asal Anda disembunyikan, dan aset yang sudah tersimpan di jaringan tepi bisa dikirim tanpa membebani server. Ini pilihan yang tepat untuk record utama website.

Awan abu-abu, atau DNS Only, berarti permintaan meluncur langsung ke server asal tanpa melewati proxy. Cloudflare hanya menjadi buku alamat, bukan penjaga pintu. Pilih ini untuk semua record yang bukan lalu lintas web biasa.

Aturannya mudah diingat: apa pun yang berkaitan dengan email harus abu-abu. Record MX dan hostname mail tidak melewati proxy HTTP, jadi kalau diproksikan, email bisa berhenti sampai sama sekali. Tandai keduanya sebagai DNS Only sebelum Anda mengubah nameserver.

Perubahan ikon awan bisa dilakukan kapan saja setelah nameserver pindah. Kalau Anda ragu dengan satu record, biarkan abu-abu dulu. Situs tetap bisa diakses langsung ke server asal, hanya kehilangan percepatan dan perlindungan proxy. Setelah Anda yakin record itu memang untuk website, baru nyalakan awan oranye. Salah urutan tidak merusak apa pun, tetapi salah status pada record email cukup untuk mematikan kotak masuk.

5. Memilih Mode SSL dan Menghindari Mode Flexible

Mode SSL menentukan bagaimana data dienkripsi di dua ruas perjalanan: dari pengunjung ke Cloudflare, dan dari Cloudflare ke server asal Anda. Banyak orang hanya melihat ruas pertama, padahal ruas kedua yang paling sering menimbulkan masalah.

Mode Flexible membuat pengunjung terhubung lewat HTTPS, tetapi Cloudflare menghubungi server asal Anda lewat HTTP biasa. Ikon gembok tetap muncul di browser, jadi semuanya tampak aman. Padahal data yang lewat di sisi belakang berjalan terbuka, dan itu risiko yang tidak perlu.

Saya menyarankan Full atau Full (Strict). Pilihan Strict mewajibkan sertifikat yang valid di server asal, jadi tidak ada celah penipuan sertifikat. Kalau sertifikat Anda masih bermasalah, perbaiki dulu di server, jangan turunkan mode hanya demi cepat online. Rincian tiap mode ada di dokumentasi mode SSL Cloudflare.

Satu jebakan lain: memilih Flexible saat server asal sudah memaksa HTTPS akan membuat keduanya berputar tanpa henti. Halaman tidak pernah selesai terbuka, dan gejalanya terlihat seperti server yang mati. Memperbaiki mode SSL biasanya langsung menyelesaikannya.

Kalau sertifikat di server asal Anda masih berupa sertifikat gratisan yang hampir kedaluwarsa, jadwalkan penggantian sebelum mendaftar ke Cloudflare. Mode Strict akan menolak sertifikat yang tidak valid, dan situs Anda bisa mati total hanya karena tanggal kedaluwarsa yang terlewat. Perbaiki di sisi server, bukan dengan menurunkan mode.

6. Mengarahkan Server Asal, Purge Cache, dan Menjaga Record Email

Cloudflare hanya pintu depan. Isi rumahnya tetap server asal Anda, dan pintu itu harus tahu alamat rumah yang benar. Pastikan record A untuk domain utama sudah menunjuk IP server yang benar, bukan IP server lama yang sebentar lagi dimatikan.

Kesalahan IP di tahap ini punya gejala khas: situs menampilkan halaman default hosting, atau justru error dari akun tetangga. Cek IP yang tertulis di dashboard dengan IP yang diberikan penyedia hosting Anda, karakter demi karakter.

Setelah record benar, periksa dari terminal supaya yakin DNS publik sudah sesuai keinginan:

• dig namadomain.com MX +short, untuk memastikan record email sudah menunjuk penyedia yang benar
• dig namadomain.com TXT +short, untuk memeriksa record SPF yang diawali v=spf1
• dig namadomain.com +short, untuk memastikan alamat IP server asal sudah tepat

Kalau Anda mengubah isi situs atau memindahkan file, bersihkan cache lebih dulu. Cache di jaringan tepi bisa masih menyajikan versi lama sampai di-purge, sehingga perubahan yang sudah Anda unggah seolah tidak muncul. Purge sekali, lalu uji di jendela peramban tanpa riwayat.

Terakhir, dan ini yang paling saya tekankan: pastikan semua record email tetap berstatus DNS Only. SPF ganda pada nama root juga tidak diizinkan dan bisa membuat pengiriman email gagal. Kalau Anda memakai Cloudflare sebagai satu-satunya DNS dan ingin jejak langkah pindah hosting yang tidak mengorbankan email, simpan panduan 6 cara aman pindah hosting tanpa email mati sebagai rujukan cadangan.

Setelah semuanya hijau, jangan langsung melupakan email. Uji kirim pesan dari luar ke alamat bisnis Anda, dan balas dari alamat itu ke pengirim. Autentikasi SPF kadang butuh sampai 48 jam sebelum bekerja penuh, jadi kegagalan hari pertama bukan berarti ada yang salah. Kalau sehari kemudian email masih bermasalah, baru kembali periksa record TXT dan MX.

Kesimpulan:

Memindahkan website ke Cloudflare bukan soal kecepatan memencet tombol, melainkan soal ketenangan setelahnya. Empat hal yang wajib Anda jaga adalah record lama yang sudah dicocokkan, status awan setiap record, mode SSL yang benar, dan jalur email yang tetap hidup.

Kalau ada satu langkah yang harus Anda dahulukan, pilih mencocokkan record. Dari situ semua keputusan lain menjadi jelas, dan Anda tahu persis apa yang berpindah dan apa yang harus tinggal.

Langkah konkretnya: malam ini, salin semua record DNS ke sebuah dokumen, dan tandai mana yang berkaitan dengan email. Besok pagi, baru tambahkan domain ke Cloudflare dengan daftar itu di tangan. Satu jam persiapan hari ini menghemat berhari-hari pemulihan nanti.