Hampir semua orang yang menghubungi saya soal migrasi website datang dengan pertanyaan yang sama: “checklist-nya apa saja?” Dan hampir semua sudah punya satu. Backup, uji di staging, pasang redirect 301, kirim sitemap baru, pantau Search Console. Lima poin itu muncul di setiap panduan berbahasa Indonesia yang ada di halaman satu Google, dengan urutan yang nyaris identik.<\/p>\n
Masalahnya bukan checklist-nya salah. Poin-poin itu memang benar. Masalahnya, checklist menjawab pertanyaan “apa yang saya centang hari Sabtu malam nanti” sementara yang menentukan hasil migrasi justru dua hal di luar hari itu: daftar apa yang Anda catat sebelum pindah<\/strong>, dan berapa lama Anda mengawasi setelahnya<\/strong>. Migrasi website tanpa kehilangan ranking bukan soal eksekusi satu malam yang rapi. Ia soal apakah Anda punya bahan untuk tahu, tiga bulan kemudian, apakah yang hilang itu nyata atau cuma terlambat.<\/p>\n Di artikel ini saya bongkar lima jenis migrasi yang risikonya berbeda jauh tapi selalu diberi checklist yang sama, data terbaru soal berapa lama pemulihan sebenarnya berlangsung (angkanya jauh dari “4\u201312 minggu” yang biasa dijanjikan), dan urutan kerja yang saya pakai, diurutkan bukan berdasarkan kemudahan, tapi berdasarkan mana yang tidak bisa diulang.<\/p>\n Pola percakapannya selalu mirip. Migrasi jalan hari Sabtu. Minggu pagi website sudah hidup di alamat baru, tampilannya lebih bagus, loading lebih cepat. Semua orang senang. Senin, Selasa, Rabu masih terasa normal karena traffic langsung dari media sosial dan iklan tidak terpengaruh sama sekali.<\/p>\n Yang jatuh baru terlihat sekitar hari kesepuluh sampai minggu ketiga. Dan yang membuat panik bukan angkanya, tapi fakta bahwa tidak ada seorang pun yang bisa menjawab pertanyaan sederhana: turun dari berapa?<\/strong><\/p>\n Salah satu klien saya, sebuah bisnis jasa B2B, pernah datang enam minggu setelah migrasi dengan keluhan “traffic turun sekitar 40 persen”. Waktu saya minta datanya, ternyata angka 40 persen itu berasal dari perbandingan bulan berjalan dengan bulan sebelumnya di dashboard analytics, yang kebetulan bulan puncak mereka. Setelah kami tarik data 12 bulan, penurunan sebenarnya sekitar 22 persen, dan hampir seluruhnya terkonsentrasi di satu kelompok halaman: artikel-artikel lama yang dulu punya URL berakhiran tanggal, yang di website baru strukturnya diubah tanpa dipetakan satu per satu. Halaman utama dan halaman layanan tidak bergerak sama sekali.<\/p>\n Dua hal yang saya pelajari dari kasus seperti ini, dan saya melihatnya berulang kali. Pertama, hampir semua orang mengukur kerugian migrasi dengan pembanding yang salah<\/strong>, karena mereka tidak membekukan angka sebelum pindah. Kedua, kerusakannya hampir tidak pernah merata, ia menumpuk di satu kantong halaman yang punya satu kesamaan teknis. Kalau Anda tahu kantong itu di mana, perbaikannya sering selesai dalam hitungan hari. Kalau tidak, Anda akan menghabiskan tiga bulan memperbaiki hal-hal yang tidak rusak.<\/p>\n Checklist standar tidak membantu Anda menemukan kantong itu. Ia cuma memastikan Anda melakukan hal yang benar di malam peluncuran.<\/p>\n Kata “migrasi website” dipakai untuk lima pekerjaan yang risikonya berbeda sampai berlipat-lipat. Ini sumber kebingungan terbesar yang saya temui, dan akibatnya berjalan dua arah: sebagian orang terlalu takut sehingga bertahan di hosting buruk bertahun-tahun, sebagian lagi terlalu tenang karena merasa sudah mencentang semua poin.<\/p>\n Pindah hosting atau server, URL tidak berubah, risiko SEO mendekati nol.<\/strong> Domain sama, struktur URL sama, konten sama. Yang berubah cuma tempat file disimpan dan alamat IP-nya. Ini bukan migrasi SEO, ini pekerjaan infrastruktur.<\/p>\n Pindah HTTP ke HTTPS, risiko rendah.<\/strong> Perlu redirect dan pembaruan referensi internal, tapi Google memperlakukan ini sebagai kasus khusus dan menyarankan Anda tidak<\/strong> memakai alat Change of Address untuknya, karena perubahannya dikenali otomatis.<\/p>\n Ganti struktur URL di domain yang sama, risiko sedang sampai tinggi.<\/strong> Ubah permalink, ubah kategori, gabungkan halaman, pindahkan blog dari subdomain ke subfolder. Setiap URL lama harus punya tujuan baru yang spesifik. Ini yang paling sering diremehkan karena “kan domainnya tidak ganti”.<\/p>\n Ganti domain, risiko tinggi.<\/strong> Seluruh identitas berpindah alamat. Google harus mengenali ulang situs baru, memindahkan sinyal lewat redirect, dan mengindeks ulang semuanya.<\/p>\n Ganti domain, ganti platform, dan redesign sekaligus, risiko tertinggi, dan ini yang paling sering terjadi.<\/strong> Bukan karena orang ceroboh, tapi karena secara anggaran masuk akal: sekali bayar developer, sekali downtime, sekali repot.<\/p>\n Perhatikan bahwa poin satu dan poin lima diberi panduan yang sama persis di sebagian besar artikel Indonesia. Padahal jaraknya sejauh mengganti ban dengan mengganti mesin.<\/p>\n Sekarang bagian yang perlu saya luruskan, karena ini merugikan banyak bisnis kecil: beberapa artikel penyedia hosting di Indonesia menulis bahwa perubahan alamat IP membuat Anda “perlu merintis ranking dari awal lagi”. Itu tidak benar. Selama domain tetap sama, URL tetap sama, dan situsnya tetap bisa diakses, John Mueller dari Google sudah berulang kali menyatakan alamat IP bukan faktor peringkat, termasuk saat servernya pindah ke lokasi geografis lain, karena Google mendapat sinyal penargetan negara dari sumber lain. Saya kehilangan hitungan berapa kali menemukan bisnis yang bertahan di hosting lambat dan sering mati selama dua sampai tiga tahun karena membaca kalimat itu di blog penyedia hosting yang mereka pakai.<\/p>\n Supaya urutan kerjanya masuk akal, Anda perlu tahu apa yang sedang dipindahkan. Bukan file. File itu bagian paling gampang.<\/p>\n Yang berpindah adalah hubungan antara alamat dan reputasi<\/strong>. Setiap URL lama Anda punya riwayat: sudah dirayapi berkali-kali, punya tautan masuk dari luar, punya catatan kueri apa saja yang memunculkannya, punya posisi rata-rata. Semua itu menempel pada alamat, bukan pada tulisannya. Redirect 301 adalah cara Anda memberi tahu Google, satu per satu, bahwa reputasi yang menempel di alamat A sekarang harus dibaca sebagai milik alamat B.<\/p>\n Kata kuncinya: satu per satu<\/strong>. Ini alasan kenapa mengalihkan seluruh URL lama ke halaman depan bukan penyelesaian, Google umumnya memperlakukan pengalihan massal ke beranda seperti halaman yang tidak ditemukan, jadi efeknya nyaris sama dengan tidak memasang redirect sama sekali, hanya lebih sulit dideteksi karena tidak muncul sebagai error.<\/p>\n Dan proses pengenalannya tidak instan. Google perlu merayapi ulang URL lama Anda cukup banyak kali untuk yakin perpindahan ini permanen. Karena itu rekomendasi resminya adalah mempertahankan redirect minimal satu tahun<\/strong>, bukan satu bulan, bukan sampai “traffic kelihatan pulih”. Kalau redirect dicabut sebelum Google cukup sering melihatnya, sebagian sinyal tidak pernah selesai berpindah.<\/p>\n Ada satu langkah kecil yang hampir tidak pernah disebut di panduan berbahasa Indonesia, dan ini pembaruan resmi Google pada Juni 2026. Kalau Anda pindah domain, ajukan permintaan Change of Address untuk semua varian domain lama<\/strong>, subdomain, versi www, dan versi non-www, bahkan varian yang tidak Anda pakai secara aktif. Semuanya perlu terverifikasi lebih dulu di Search Console. Alasannya sederhana: migrasi domain bekerja paling baik kalau semua varian ikut berpindah. Prosesnya makan waktu sekitar sepuluh menit dan sering terlewat karena orang hanya memverifikasi satu properti.<\/p>\n Yang tidak<\/strong> berpindah lewat redirect: kualitas halaman tujuannya. Kalau di alamat baru isinya Anda ringkas, gabungkan dengan halaman lain, atau tulis ulang, maka yang dinilai Google adalah halaman yang berbeda. Redirect memindahkan alamat, bukan menjamin penilaian.<\/p>\n Ini bagian yang paling jarang saya lihat ditulis, dan menurut saya paling penting.<\/p>\n Kegagalan migrasi terbagi jadi dua jenis yang bentuk grafiknya nyaris identik, tapi obatnya berlawanan.<\/p>\n Jenis pertama: sinyalnya tidak berpindah.<\/strong> Redirect bolong, redirect berantai, redirect ke halaman yang salah, URL lama masih terindeks, robots.txt di server baru masih memblokir warisan dari staging. Ini masalah teknis dan bisa diperbaiki. Ciri khasnya di Search Console: URL lama masih muncul terindeks, atau URL baru belum terindeks sama sekali.<\/p>\n Jenis kedua: sinyalnya berpindah, tapi halamannya sudah bukan halaman yang sama.<\/strong> URL baru terindeks rapi, redirect bersih, tidak ada error tapi posisinya lebih rendah. Ini bukan masalah redirect. Ini karena Anda ikut mengubah isi, menggabungkan beberapa halaman jadi satu, memangkas teks demi desain yang lebih lega, atau memindahkan konten ke elemen yang baru muncul setelah JavaScript jalan. Google sedang menilai halaman yang berbeda, dan ia benar.<\/p>\n Saya pernah menghabiskan hampir tiga minggu mengaudit peta redirect untuk sebuah kasus yang ternyata jenis kedua. Redirect-nya sempurna. Yang berubah adalah halaman kategori produk yang di website lama punya deskripsi 400 kata di atas daftar produk, dan di website baru deskripsi itu dipindah ke tab yang isinya baru dimuat saat diklik. Tiga minggu saya cari di tempat yang salah, karena saya mulai dari asumsi bahwa masalah migrasi adalah masalah redirect.<\/p>\n Dari situ saya berhenti menyebut redirect sebagai “yang menentukan keberhasilan migrasi”. Redirect yang benar adalah prasyarat agar migrasi bisa dinilai<\/strong>, ia menghapus satu penjelasan dari daftar tersangka. Kalau redirect Anda berantakan, Anda tidak akan pernah tahu apakah penurunan itu karena perpindahan atau karena perubahan konten, dan Anda akan menghabiskan berbulan-bulan menebak.<\/p>\n Ini juga alasan paling kuat kenapa Google menyarankan memisahkan perpindahan dari perombakan tampilan. Bukan karena keduanya berbahaya kalau digabung. Tapi karena kalau digabung, Anda kehilangan kemampuan membatalkan hal yang benar<\/strong>. Kalau turun setelah pindah domain saja, Anda tahu di mana mencari. Kalau turun setelah pindah domain plus ganti platform plus redesign plus konsolidasi 40 artikel, Anda punya empat tersangka dan tidak satu pun bisa diuji terpisah.<\/p>\n Kalau Anda pernah mengalami penurunan traffic tanpa tahu sebabnya, urutan pemeriksaan yang saya pakai untuk memisahkan masalah nyata dari masalah pelaporan sudah saya tulis terpisah di urutan diagnosa yang saya pakai sebelum menyentuh konten saat traffic website turun<\/a>\u00a0sebagian besar langkahnya berlaku juga untuk penurunan pasca-migrasi, dengan satu perbedaan penting: pada kasus migrasi Anda sudah tahu tanggal kejadiannya, dan itu menghemat separuh pekerjaan diagnosa.<\/p>\n Urutan di bawah ini tidak disusun dari yang paling mudah, dan juga tidak dari yang paling berdampak. Ia disusun dari mana yang hilang selamanya kalau dilewati<\/strong>. Tahap 1 punya sifat yang tidak dimiliki tahap lain: setelah website lama mati, ia tidak bisa dikerjakan lagi. Selamanya.<\/p>\n Kembali ke lima jenis di atas. Tulis mana yang sedang Anda lakukan. Kalau jawabannya lebih dari satu, pertanyaan berikutnya adalah: bisakah dipisah jadi dua peluncuran berjarak enam sampai delapan minggu?<\/p>\n Urutan yang saya sarankan: pindahkan dulu tanpa mengubah apa pun, lalu rombak setelah angkanya stabil.<\/strong> Ini terasa lebih mahal dan lebih repot. Memang. Tapi biaya tambahannya adalah biaya yang Anda bayar sekali dan diketahui di depan, sementara biaya menggabungkan semuanya adalah biaya yang muncul belakangan dalam bentuk berbulan-bulan menebak.<\/p>\n Dan jawaban paling murah sering kali adalah tidak pindah sama sekali. Saya sadar ini aneh datang dari orang yang salah satu sumber pendapatannya adalah membangun ulang website orang. Tapi kalau alasan migrasi Anda adalah “sudah bosan” atau “punya kompetitor yang tampilannya lebih bagus”, risiko yang Anda ambil tidak sebanding dengan hasil yang Anda kejar. Alasan yang sebanding biasanya terdengar lebih membosankan: platform lama tidak bisa lagi menjalankan alur bisnis yang sekarang, servernya sering mati, atau ada keputusan merek yang memaksa ganti nama.<\/p>\n Ini tahap yang tidak bisa diulang, dan tahap yang paling sering dikerjakan setengah.<\/p>\n Kebanyakan orang membuat daftar URL dari satu sumber: sitemap. Masalahnya, sitemap adalah daftar halaman yang Anda ingat.<\/strong> Yang menghancurkan migrasi selalu halaman yang Anda lupa. Ambil dari empat sumber, lalu gabungkan:<\/p>\n Sumber 1 \u2014 sitemap dan hasil crawl situs.<\/strong> Ini kerangkanya. Halaman yang Anda tahu ada.<\/p>\n Sumber 2 \u2014 laporan Pages di Google Search Console.<\/strong> Ini yang benar-benar diindeks Google, dan hampir selalu memuat URL yang tidak ada di sitemap: arsip tag, halaman paginasi, URL berparameter, halaman kampanye lama, berkas PDF.<\/p>\n Sumber 3 \u2014 data analytics 12 bulan terakhir, diurutkan berdasarkan halaman masuk.<\/strong> Ini yang menghasilkan. Perhatikan ekor panjangnya, bukan sepuluh besarnya \u2014 halaman peringkat 40 sampai 200 sering menyumbang lebih banyak total daripada sepuluh halaman teratas, dan justru merekalah yang paling sering tidak terpetakan.<\/p>\n Sumber 4 \u2014 daftar halaman yang punya tautan masuk dari luar.<\/strong> Reputasi pinjaman ini yang paling mahal kalau putus, dan sering menempel di URL yang sudah lama tidak Anda pikirkan.<\/p>\n Gabungkan keempatnya jadi satu daftar unik. Lalu bekukan angka pembandingnya di hari yang sama: traffic organik 12 bulan, impresi dan klik 16 bulan dari Search Console, daftar 100 halaman masuk teratas, dan posisi rata-rata untuk kueri yang Anda pedulikan. Simpan sebagai berkas dengan tanggal di namanya.<\/p>\n Kalau angka ini tidak dibekukan, tiga bulan lagi Anda akan berdebat soal apakah traffic benar-benar turun dan perdebatan itu tidak bisa dimenangkan siapa pun.<\/p>\n Tahap ini sebenarnya sebagian besar adalah pekerjaan audit, dan kalau Anda mau melakukannya sendiri, kerangka pemeriksaan yang saya pakai untuk menemukan masalah struktural sebelum menyentuh konten sudah saya uraikan di cara audit SEO website untuk menemukan masalah yang benar-benar menahan ranking<\/a>. Kalau lebih nyaman dikerjakan bersama orang luar, ini juga bagian yang biasanya saya kerjakan lewat jasa SEO<\/a>\u00a0bukan karena rumit, tapi karena ini satu-satunya tahap yang tidak bisa diperbaiki setelah website lama dimatikan.<\/p>\n Ambil daftar gabungan dari Tahap 1. Beri setiap URL lama satu tujuan spesifik di website baru. Empat aturan yang saya pakai:<\/p>\n Satu tujuan yang paling mirip, bukan beranda.<\/strong> Kalau halaman tujuannya benar-benar tidak ada padanannya dan tidak ada rencana menggantinya, biarkan menjadi 404 secara sadar. 404 yang disengaja lebih jujur daripada redirect ke halaman yang tidak menjawab apa pun.<\/p>\n Satu lompatan, bukan rantai.<\/strong> Kalau URL lama pernah mengalami perpindahan sebelumnya, perbarui redirect lamanya agar langsung menunjuk tujuan akhir. Rantai bikin lambat, dan seperti yang saya bahas di bagian berikutnya, perayap mesin jawaban AI jauh lebih cepat menyerah pada rantai dibanding Googlebot.<\/p>\n Redirect di sisi server, bukan lewat JavaScript.<\/strong> Pengalihan yang baru terjadi setelah skrip berjalan tidak selalu terbaca sama oleh semua perayap.<\/p>\n Diuji sebelum DNS dipindah, bukan sesudah.<\/strong> Ini yang jarang dilakukan. Jalankan seluruh daftar URL lama Anda melalui aturan redirect di lingkungan uji, lalu hitung berapa persen yang berakhir di halaman berstatus 200 yang masuk akal. Kalau angkanya di bawah 95 persen, Anda belum siap meluncurkan. Menemukan 300 URL bolong sebelum peluncuran biayanya satu sore. Menemukannya enam minggu setelah peluncuran biayanya satu kuartal.<\/p>\n Satu hal terakhir di tahap ini, dan ini kesalahan yang bisa berjalan dua arah: periksa tag noindex dan berkas robots.txt di server baru dua kali<\/strong>. Situs staging biasanya diblokir supaya tidak terindeks, dan blokir itu ikut terbawa saat naik ke produksi. Website yang tampak sempurna tapi diberi tag noindex tidak akan menunjukkan gejala apa pun tidak ada yang rusak, traffic-nya cuma tidak pernah datang.<\/p>\n Pengawasan pasca-migrasi bukan “pantau Search Console”. Setiap titik waktu punya pertanyaan berbeda, dan menjawab pertanyaan bulan ketiga di minggu pertama cuma menghasilkan kepanikan.<\/p>\n Hari 1\u20133: apakah situsnya bisa diakses dan redirect-nya jalan?<\/strong> Uji contoh acak dari daftar Tahap 1, bukan cuma menu utama. Ajukan Change of Address kalau ganti domain, untuk semua varian. Kirim sitemap baru. Pertahankan sitemap lama tetap dapat diakses beberapa minggu supaya Google punya jalan menemukan URL lama untuk dirayapi.<\/p>\n Minggu 1\u20132: apakah Google sudah mulai merayapi versi barunya?<\/strong> Yang dilihat bukan traffic, masih terlalu cepat. Yang dilihat: apakah URL baru mulai muncul terindeks, dan apakah muncul lonjakan error server. Jangan menilai peringkat di fase ini.<\/p>\n Minggu 3\u20136: apakah kerugiannya merata atau menumpuk?<\/strong> Ini pemeriksaan paling berharga. Bandingkan per kelompok halaman terhadap baseline beku Anda, bukan total situs. Kerugian yang menumpuk di satu kelompok hampir selalu berarti satu sebab teknis yang spesifik dan bisa diperbaiki.<\/p>\n Bulan 3: apakah ini jenis kegagalan pertama atau kedua?<\/strong> Pakai pemisahan di bagian sebelumnya. URL lama masih terindeks berarti masalah perpindahan. URL baru terindeks tapi posisinya turun berarti masalah halaman.<\/p>\n Bulan 12: apakah redirect masih menyala?<\/strong> Ini yang paling sering lupa. Perpanjang domain lama, jangan matikan hosting lama sebelum redirect punya rumah baru.<\/p>\n Satu hal yang saya minta diputuskan sebelum<\/strong> peluncuran, bukan sesudah: pada kondisi seperti apa Anda akan mundur ke website lama. Tulis satu kalimat, sepakati dengan orang yang punya akses server. Setelah peluncuran, semua orang terlalu terlibat secara emosional untuk membuat keputusan itu dengan jernih.<\/p>\n Menarik bahwa hampir semua kesalahan migrasi yang mahal terjadi di meja rapat, bukan di terminal. Semuanya masih bisa dibatalkan tanpa biaya pada titik itu.<\/p>\n Menggabungkan pindah, ganti platform, dan redesign dalam satu peluncuran.<\/strong> Sudah saya bahas di atas, tapi saya ulang karena ini penyebab tunggal terbesar. Hemat di anggaran proyek, mahal di kemampuan diagnosa.<\/p>\n Menjadwalkan migrasi menjelang periode tersibuk.<\/strong> Logikanya sering terbalik: “website baru harus siap sebelum musim ramai”. Padahal periode pemulihan Anda justru jatuh tepat di bulan yang paling mahal untuk kehilangan traffic. Kalau bisnis Anda punya puncak musiman, migrasi dilakukan segera setelahnya, bukan sebelumnya.<\/p>\n Menganggap redirect massal ke beranda sebagai “sudah dipasang redirect”.<\/strong> Ini terlihat rapi di laporan developer, nol error 404. Efeknya di mata Google mendekati tidak memasang apa pun.<\/p>\n Mematikan domain atau hosting lama terlalu cepat.<\/strong> Biasanya karena alasan penghematan yang jumlahnya kecil sekali. Rekomendasi resminya minimal satu tahun, dan alasannya bukan formalitas: Google butuh merayapi URL lama berkali-kali sebelum yakin perpindahan ini permanen.<\/p>\n Tidak menugaskan siapa pun untuk mengawasi minggu ketiga sampai keenam.<\/strong> Semua perhatian tercurah ke hari peluncuran. Padahal sinyal paling berguna baru muncul saat semua orang sudah kembali ke pekerjaan masing-masing dan proyeknya secara resmi dianggap selesai.<\/p>\nSemua Checklist Sudah Dicentang, Traffic Tetap Jatuh, Ini yang Biasanya Terjadi<\/h2>\n
5 Jenis Migrasi Website dan Tingkat Risikonya (Jangan Pakai Checklist yang Sama)<\/h2>\n
Apa yang Sebenarnya Berpindah Saat Anda Migrasidan Apa yang Tidak<\/h2>\n
Redirect yang Benar Tidak Membuat Migrasi Berhasil, Ia Membuatnya Bisa Dinilai<\/h2>\n
4 Tahap Migrasi, Diurutkan dari yang Tidak Bisa Diulang<\/h2>\n
Tahap 1: Tentukan jenis migrasinya, lalu coba pecah jadi dua peluncuran<\/h3>\n
Tahap 2: Inventaris dari empat sumber, lalu bekukan baseline<\/h3>\n
Tahap 3: Peta redirect satu-ke-satu, diuji sebelum DNS dipindahkan<\/h3>\n
Tahap 4: Peluncuran dan jendela pengawasan berlapis<\/h3>\n
6 Kesalahan Migrasi yang Terjadi Sebelum Satu File Pun Dipindahkan<\/h2>\n