Kesalahan Migrasi Website Datang dari Detail yang Dilewatkan, Bukan dari Servernya
Memindahkan website terlihat sederhana: unggah berkas, arahkan DNS, tunggu propagasi. Masalahnya, kerugian terbesar hampir tidak pernah datang dari server baru yang lambat. Ia datang dari detail yang dilewati saat pindah, dan tagihannya berupa trafik yang menurun perlahan tanpa Anda sadari. Situs tetap terbuka, email tetap masuk, jadi tidak ada tanda bahaya yang memaksa Anda buru-buru memeriksa.
Saya berulang kali menemukan kesalahan migrasi website yang sama di klien UMKM. Pemilik usaha biasanya baru merasa ada yang salah setelah dua atau tiga minggu, ketika formulir kontak sepi dan pesanan dari Google berhenti masuk. Saat diperiksa, halaman yang dulu mendatangkan pembeli sudah tidak ada di indeks Google.
Kabar baiknya, hampir semua kesalahan ini bisa dicegah tanpa alat mahal atau tim besar. Yang Anda perlukan hanya daftar URL lama, pemetaan pengalihan yang benar, dan satu jam untuk memeriksa hasilnya setelah situs hidup kembali. Tiga hal itu jauh lebih menentukan daripada pilihan paket hosting. Pemeriksaan teliti pada satu malam jauh lebih murah daripada kehilangan pesanan selama sebulan.
Lima kesalahan berikut saya bahas satu per satu, supaya Anda bisa memeriksa situs sendiri malam ini juga.
1. Kesalahan Migrasi Website Nomor Satu: Tidak Mengekspor Daftar URL Lama
Sebelum menyentuh DNS atau memindahkan berkas, ekspor dulu semua alamat halaman yang ada di situs lama. Tanpa daftar itu, Anda tidak punya dasar apa pun untuk menyusun pemetaan pengalihan 301. Vendor mungkin berkata semuanya sudah aman, tetapi tanpa daftar pembanding Anda tidak bisa membuktikannya.
Ambil daftarnya dari Search Console. Buka laporan Halaman, klik Ekspor, lalu simpan semua URL yang pernah terindeks. Kalau akses sudah dicabut, pakai arsip Wayback Machine atau hasil crawl Screaming Frog dari cadangan situs. Simpan sebagai berkas teks, jangan cuma tangkapan layar.
Daftar itu kemudian dipakai untuk memetakan setiap URL lama ke satu URL baru. Halaman produk mengarah ke halaman produk, artikel blog ke artikel blog, kategori ke kategori. Prosesnya membosankan, tetapi di sinilah nilai trafik Anda dipertahankan.
Kerjakan langkah ini minimal sehari sebelum cutover. Kalau DNS sudah terlanjur pindah dan situs lama mati, memetakan URL berubah menjadi merekonstruksi dari arsip, dan itu memakan waktu berkali-kali lebih lama. Urutan aman pindah hosting, termasuk pilihan jam cutover, saya tulis di panduan waktu terbaik pindah hosting.
Format daftarnya sederhana: satu kolom untuk URL lama, satu kolom untuk URL baru, dan satu kolom untuk status pengalihan. Simpan di spreadsheet yang bisa dibuka orang lain, bukan di catatan pribadi vendor. Dokumen itu lalu menjadi bahan pemeriksaan akhir, karena setiap baris bisa diuji satu per satu setelah situs pindah.
2. Semua URL Lama Dialihkan ke Beranda, Soft 404 yang Menguras Otoritas
Ini kesalahan yang paling sering saya temui. Karena bingung memetakan ratusan URL, pemilik situs akhirnya mengarahkan semuanya ke beranda. Terdengar rapi, padahal Google menilainya dengan cara berbeda. Aturan seperti ini juga mudah dibuat lewat satu baris di berkas konfigurasi, sehingga pemilik situs merasa masalahnya sudah selesai padahal justru baru dimulai.
Halaman lama yang hilang lalu dialihkan ke beranda digolongkan sebagai soft 404. Google melihat alamat yang diminta tidak lagi menyediakan isi yang relevan, sehingga nilai otoritas per halaman itu hilang, bukan berpindah ke halaman depan. Beranda tetap masuk indeks, sementara puluhan halaman yang dulu mendatangkan pembeli menghilang satu per satu tanpa peringatan di dasbor.
Bagi pengunjung, akibatnya lebih kasar lagi. Mereka mengklik hasil pencarian tentang harga atau layanan tertentu, lalu mendarat di halaman yang tidak menjelaskan apa pun soal kebutuhan mereka. Sebagian besar langsung menekan tombol kembali, dan itu tercatat sebagai kunjungan gagal.
Pengalihan yang benar mengarah ke halaman terdekat yang relevan. Produk yang dihapus bisa masuk ke kategorinya, artikel yang berubah judul mengarah ke artikel barunya. Kalau memang tidak ada padanan sama sekali, status 410 lebih jujur daripada memaksa semua pengunjung masuk beranda. Setelah pengalihan rapi, lanjutkan dengan strategi SEO setelah migrasi supaya posisi halaman baru cepat pulih.
Kalau jumlah halamannya ratusan, dahulukan yang paling banyak dikunjungi dan paling banyak menghasilkan pesanan. Buka laporan Halaman di analitik, urutkan dari kunjungan terbanyak, lalu tandai dua puluh URL teratas. Memetakan dua puluh halaman penting dengan benar jauh lebih berharga daripada memetakan seluruh situs asal-asalan.
3. Memakai 302 untuk Perpindahan yang Sifatnya Permanen
Kode 301 berarti halaman pindah permanen. Kode 302 berarti pindahan sementara. Banyak plugin dan vendor memilih 302 karena lebih mudah dibatalkan, padahal perpindahannya jelas tidak akan dikembalikan. Alasan praktisnya begini: kalau Anda memasang 301 lalu ingin kembali, cukup ubah satu baris konfigurasi, jadi tidak ada risiko yang perlu ditakuti.
Google menyatakan pengalihan permanen 301 tidak menurunkan PageRank. Jadi tidak ada alasan teknis untuk memakai 302 demi menjaga nilai halaman. Memasang 302 pada perpindahan permanen justru bisa membuat Google terus menganggap URL lama sebagai versi resmi.
Uji sendiri sebelum menyatakan migrasi selesai. Jalankan curl -I https://namadomain.com/halaman-lama di terminal, lalu baca baris pertama responsnya. Kalau tertulis HTTP/1.1 302 Found, aturan pengalihan Anda perlu diperbaiki, biasanya di berkas .htaccess atau di menu Redirects pada plugin SEO.
Rantai pengalihan juga sebaiknya dihindari. Pengalihan berantai dari halaman A ke B lalu ke C memperlambat pemuatan dan menambah peluang bot berhenti di tengah jalan. Satu URL lama cukup menuju satu URL baru secara langsung. Sebagian masalah lain yang sering menyertai pindahan hosting sudah dirangkum di daftar masalah umum migrasi situs web.
Perbaikannya biasanya berada di tiga tempat: berkas .htaccess pada server Apache, konfigurasi blok server pada Nginx, dan menu Redirections di plugin SEO untuk situs WordPress. Cari pola 302 di ketiga tempat itu, ubah menjadi 301, lalu uji ulang dengan curl -I sampai tidak ada pengalihan sementara yang tersisa. Kerjakan seluruh aturan pada malam yang sama sebelum mengumumkan migrasi selesai kepada pelanggan.
7 Cara Pakai AI untuk UMKM Tanpa Modal Besar
4. Tag Noindex dan Robots.txt dari Lingkungan Uji yang Terbawa ke Live
Situs uji biasanya sengaja disembunyikan dari Google dengan tag noindex atau baris Disallow: / di dalam robots.txt. Aturan itu sering ikut terbawa saat seluruh berkas disalin apa adanya ke server produksi. Penyebabnya sepele, yaitu berkas dan basis data dipindah utuh termasuk pengaturan yang hanya cocok untuk tahap pengembangan.
Akibatnya sederhana dan menyakitkan. Halaman Anda tetap bisa dibuka pengunjung lewat tautan langsung, tetapi tidak akan pernah muncul di hasil pencarian. Situs tampak hidup normal, sementara trafik organik merosot hampir ke titik nol. Pelanggan lama pun tidak mengeluh, karena mereka tetap bisa membuka situs lewat tautan yang Anda kirim, sementara calon pembeli baru tidak pernah menemukannya.
Ada tiga hal yang perlu Anda periksa. Buka https://namadomain.com/robots.txt di peramban dan pastikan tidak ada Disallow: /. Lihat kode sumber halaman, cari tag meta robots di bagian head. Lalu cek kotak centang noindex pada plugin SEO, karena satu pengaturan itu berlaku untuk seluruh situs sekaligus. Jangan lupa memeriksa subdomain dan versi www, sebab keduanya punya pengaturan yang bisa berbeda.
Setelah memperbaikinya, buka menu Pemeriksaan URL di Search Console, tempel satu alamat penting, dan tekan Minta Pengindeksan. Ulangi untuk beberapa halaman andalan, bukan hanya beranda. Kalau vendor yang mengerjakan migrasi masih bisa dihubungi, minta dia menunjukkan tangkapan layar pengaturan robots.txt dan noindex pada situs live, bukan pada situs uji.
Tag noindex juga bisa dikirim lewat header HTTP bernama X-Robots-Tag, bukan hanya lewat tag meta di dalam halaman. Header ini sering tertinggal di konfigurasi server uji dan tidak akan terlihat saat Anda membaca kode sumber halaman. Perintah curl -I https://namadomain.com/halaman-contoh menampilkan seluruh header respons, termasuk X-Robots-Tag kalau memang ada. Bila baris itu memuat noindex, hapus pengaturannya di tingkat server, lalu bersihkan cache agar versi lama tidak terus tersaji kepada Google.
5. Internal Link, Canonical, dan Sitemap yang Masih Menunjuk Alamat Lama
Tiga hal ini sering lolos dari pemeriksaan karena tidak terlihat di halaman depan. Padahal ketiganya bekerja di belakang layar untuk memberi tahu Google alamat mana yang dianggap benar. Ketiganya tersimpan di tempat berbeda, sehingga pemeriksaan cepat biasanya hanya menyentuh sebagian saja.
Internal link yang masih menunjuk URL lama mengirim pengunjung ke halaman 404. Tag canonical yang masih menunjuk domain lama memberi sinyal bahwa versi asli halaman ada di tempat yang sudah tidak Anda kelola. Sitemap yang belum diperbarui membuat Google terus merayapi alamat lama, sementara halaman baru menunggu ditemukan.
Cara memperbaikinya tidak selalu harus manual dari nol. Cari pola domain lama di basis data atau berkas tema, ganti dengan domain baru, lalu periksa ulang beberapa halaman contoh. Untuk sitemap, pastikan yang dikirim ke Search Console hanya memuat alamat baru, dan buang sitemap lama dari menu Sitemaps.
Terakhir, pindahkan pengukurannya. Kode analitik dan properti Search Console harus ikut dibawa ke alamat baru, sebab tanpa keduanya kerusakan tidak terukur. Penurunan trafik sementara selama proses pengindeksan ulang itu wajar. Penurunan besar yang menetap, biasanya tanda ada URL penting yang tidak pernah dialihkan, seperti dijelaskan di pembahasan trafik website yang berkurang setelah migrasi.
Angka di analitik menjelaskan banyak hal kalau dibaca sejak hari pertama. Bandingkan kunjungan organik tujuh hari sebelum dan tujuh hari sesudah cutover, lalu lihat halaman mana yang hilang dari daftar teratas. Halaman yang dulu ramai tetapi kini tidak muncul biasanya menandakan aturan pengalihannya salah atau belum pernah dibuat. Pola seperti itu jauh lebih berguna daripada panik melihat grafik total yang turun. Tandai halaman bermasalah itu, lalu alihkan satu per satu sebelum menyerahkan pekerjaan lain kepada vendor. Inilah alasan kesalahan migrasi website sering baru ketahuan berminggu-minggu kemudian.
Kesimpulan: Kerugian migrasi hampir selalu berasal dari langkah yang dilewati, bukan dari pilihan server atau tema. Daftar URL lama, pengalihan 301 yang tepat sasaran, dan pengukuran yang ikut pindah adalah tiga hal yang paling menentukan apakah trafik Anda pulih dalam hitungan hari atau merosot selama berbulan-bulan.
Mulai dari yang paling murah dan cepat. Ekspor daftar URL, buka berkas robots.txt, jalankan curl -I pada beberapa alamat penting, dan cek properti Search Console di domain baru. Sebagian besar perbaikan itu bisa Anda kerjakan sendiri dalam satu malam tanpa menyentuh kode yang rumit.
Kalau hasil pemeriksaan masih mencurigakan, atau Anda tidak punya waktu memeriksa halaman satu per satu, ajak saya melihatnya bersama. Saya biasa mengaudit jejak migrasi situs UMKM: memeriksa pengalihan, internal link, canonical, sitemap, dan laporan Search Console, lalu menyusun daftar perbaikan yang bisa dikerjakan bertahap sesuai anggaran. Kirim alamat situs Anda, dan kita mulai dari halaman yang paling banyak mendatangkan pelanggan. Tidak perlu menunggu semua perbaikan selesai; satu pengalihan yang benar hari ini sudah mengurangi satu rintangan bagi calon pembeli.
Perlu layanan pembuatan web atau ingin diskusi digital marketing?
Konsultasikan kebutuhan infrastruktur digital bisnis anda secara langsung dengan pakarnya.