Setiap minggu ada seseorang yang ingin memindahkan situs nyata — yang punya trafik, backlink, dan beberapa tahun kepercayaan Google di belakangnya — ke AI builder. Bukan ide baru, bukan prototipe. Bisnis yang sudah ada dan punya sesuatu untuk dipertaruhkan. Itu pekerjaan yang berbeda dari mulai dari prompt kosong, dan sebagian besar rasa sakit yang saya lihat berasal dari memperlakukannya seolah pekerjaan yang sama.
Ada tiga cara ini bisa berjalan salah, cukup sering hingga saya bisa menebak tiket support sebelum membaca lebih dari subjeknya. Cara yang benar tidak rumit. Itu hanya hal yang Anda dapatkan begitu Anda berhenti melakukan tiga hal ini.
Kesalahan satu: membuang konten lama begitu saja dan berharap struktur akan terurus sendiri
Insting itu masuk akal. Anda punya situs, ada kata-kata di dalamnya, jadi Anda tempel kata-kata itu ke chat dan minta builder untuk "membuatnya lebih baik." Yang keluar biasanya adalah situs yang terlihat baru namun terasa lama — paragraf layanan yang sama panjangnya, tiga heading yang sama melakukan pekerjaan lima belas, sekarang dibungkus dengan template yang lebih bagus. Builder melakukan apa yang Anda minta. Anda meminta untuk mendekorasi ulang, bukan memikirkan ulang.
Kerusakannya muncul sekitar enam minggu kemudian, ketika ranking situs baru berada tepat di posisi yang sama dengan situs lama, atau sedikit lebih rendah. Tidak ada yang membaik karena tidak ada yang berubah pada arsitektur informasi sebenarnya — halaman flat yang sama untuk sebuah layanan yang seharusnya menjadi tiga halaman, konten FAQ yang sama hilangnya sementara situs kompetitor sudah rangking dengan itu selama setahun. Cat baru pada rumah dengan jumlah kamar yang salah tetap saja jumlah kamar yang salah.
Saya pernah punya klien dengan halaman "Layanan" sepanjang 4.000 kata yang mencakup sebelas penawaran berbeda. Ia ingin itu dimigrasikan apa adanya karena "itu selalu berhasil." Padahal tidak berhasil — ia tidak rangking untuk apa pun secara spesifik karena membahas semuanya sekaligus. Memigrasikannya secara setia hanya akan menghasilkan versi yang lebih rapi dari halaman yang sama yang tidak rangking.
Yang benar-benar berhasil di sini adalah memperlakukan migrasi sebagai audit sebelum menjadi build. Masukkan konten lama, tapi minta inventaris konten dulu: halaman apa yang ada, masing-masing sedang mencoba rangking untuk apa, di mana dua topik dijejalkan ke satu URL dan di mana satu topik tipis di lima URL. Inventaris itu menjadi rencananya. Situs lama adalah sumber, bukan template.
Kesalahan dua: lupa bahwa URL adalah hal yang benar-benar dipercaya Google
Ini yang mahal. Migrasi situs yang mengubah struktur URL tanpa memetakan path lama ke path baru — bahkan ketika konten baru benar-benar lebih baik — membuang sinyal yang terkumpul selama bertahun-tahun. Backlink mengarah ke 404. Google harus meng-crawl ulang dan mendapatkan kembali kepercayaan pada halaman yang sudah dipercayainya dengan alamat berbeda. Trafik langsung dari bookmark lama dan tanda tangan email berujung buntu.
Saya sudah melihat orang-orang menyadari ini hanya setelah peluncuran, ketika dashboard analitik menunjukkan jurang bukan lonjakan. Pada titik itu perbaikannya adalah redirect yang ditambahkan setelah fakta, yang memulihkan sebagian kerugian tapi tidak semuanya — jarak antara "URL berpindah" dan "seseorang menyadari dan memperbaikinya" diukur dalam minggu ekuitas hilang yang tidak akan Anda dapatkan kembali.
| Pendekatan lama | Apa yang rusak | Apa yang harus dilakukan sebagai gantinya |
|---|---|---|
| Biarkan builder menghasilkan struktur URL apa pun yang sesuai dengan desain baru | Setiap backlink dan bookmark masuk sekarang mengarah ke 404 | Ekspor sitemap lama dulu, petakan setiap URL yang ada ke ekuivalen barunya sebelum build dimulai |
| Hanya redirect halaman utama, biarkan halaman dalam 404 | Halaman dalam membawa ekuitas link individualnya sendiri — kehilangannya satu per satu bertambah signifikan | 301 setiap URL lama yang berarti, bahkan yang digabung ke dalam halaman yang lebih luas |
| Tambahkan redirect "nanti, setelah live" | Crawler dan pengguna yang mengklik menemui jalan buntu tepat pada periode di mana trafik paling rentan | Redirect langsung aktif pada saat yang sama dengan situs baru, bukan sesudahnya |
Tidak ada dari ini yang eksotis. Ini hanyalah spreadsheet dengan dua kolom, dibuat sebelum siapa pun menyentuh builder. Ini hanyalah langkah yang dilewatkan orang karena membosankan dan build itu sendiri yang menyenangkan.
Kesalahan tiga: cutover sekaligus tanpa jalan kembali
Mode kegagalan ketiga tidak berkaitan dengan konten atau URL sama sekali — ini tentang bagaimana peralihan itu sebenarnya terjadi. Seseorang membangun situs baru, menyukai apa yang dilihatnya di preview, dan mengarahkan domain ke sana sore itu. Tidak ada periode staging, tidak ada perbandingan berdampingan di bawah trafik nyata, tidak ada rencana untuk apa yang terjadi jika ada sesuatu yang rusak yang tidak tertangkap preview — formulir kontak yang diam-diam gagal, flow checkout yang berhasil dalam pengujian tapi tersendat di bawah volume pembayaran nyata, halaman yang tampil bagus di desktop dan rusak di ponsel spesifik yang digunakan setengah dari pelanggan Anda.
Kerusakan di sini adalah jenis yang paling nyaring karena langsung terasa. Inbox support penuh. Seseorang me-refresh analitik setiap sepuluh menit menyaksikan grafik bergerak ke arah yang salah, dan rollback berarti mengarahkan ulang DNS lagi, yang sendirinya butuh waktu untuk merambat, yang berarti pengalaman buruk tetap berlangsung bahkan setelah Anda memutuskan untuk membatalkannya.
Perbaikannya tidak glamor: turunkan TTL DNS satu atau dua hari sebelum cutover agar rollback merambat cepat jika dibutuhkan, jalankan situs baru di subdomain preview atau staging dulu dan benar-benar gunakan itu seperti seorang pelanggan akan menggunakannya, dan biarkan hosting situs lama tetap aktif dan tidak tersentuh setidaknya selama beberapa minggu setelah cutover, bukan menghancurkannya begitu situs baru sudah aktif. Bagian terakhir itu hanya menghabiskan beberapa dolar biaya hosting untuk asuransi nyata. Orang-orang melewatkannya karena membatalkan paket lama terasa seperti menutup lingkaran, dan menutup lingkaran terasa seperti kemajuan.
Seperti apa cara yang benar sebenarnya
Digabungkan, semua ini tidak lebih banyak pekerjaan dari versi yang salah — ini adalah jumlah pekerjaan yang sama dalam urutan yang berbeda. Audit sebelum Anda membangun ulang. Petakan URL sebelum Anda meluncurkan. Staging sebelum Anda cutover, dan pertahankan jalan kembali selama beberapa minggu setelahnya. Situs yang muncul di ujung lainnya tidak hanya terlihat lebih baru. Ia mempertahankan semua yang sudah diperoleh situs lama, yang merupakan seluruh maksud dari migrasi dibandingkan memulai dari awal.
