Redesign yang mengubah URL dan struktur adalah migrasi informasi, bukan hanya penggantian tampilan. Tujuannya adalah menjaga jalur pengunjung dan mesin pencari tetap dapat mengikuti halaman lama menuju tujuan yang paling relevan.
Tidak ada satu pola yang cocok untuk semua bisnis. Skala tim, jenis layanan, kesiapan materi, dan cara pelanggan mengambil keputusan akan mengubah prioritas. Karena itu, panduan ini menggunakan pertanyaan, bukti, dan pemeriksaan yang dapat disesuaikan, bukan angka performa atau janji hasil yang belum memiliki dasar.
Gunakan pembahasan berikut sebagai bahan brief. Catat kondisi saat ini, orang yang bertanggung jawab, dan batas pekerjaan. Ketika sebuah pilihan belum dapat dipastikan, tulis sebagai asumsi yang harus dikonfirmasi dalam proposal atau sebelum perubahan diterapkan.
Mulai dari keputusan yang perlu dibantu
Menjaga jalur pengunjung dan mesin pencari tetap dapat mengikuti halaman lama menuju tujuan yang paling relevan. Sebelum membahas bentuk halaman atau alat yang dipakai, jelaskan keputusan apa yang masih sulit bagi pengunjung dan pekerjaan apa yang terjadi di dalam tim. Dua sudut pandang ini mencegah website tampak rapi tetapi memindahkan masalah ke percakapan, spreadsheet, atau pekerjaan manual yang tidak disiapkan.
Tentukan satu hasil yang paling penting dan tulis batasnya. Hasil dapat berupa informasi yang lebih mudah diperiksa, jalur pertanyaan yang lebih jelas, atau proses yang lebih tertata. Hindari mengubahnya menjadi janji penjualan yang tidak dapat dikendalikan. Website dapat mendukung keputusan, tetapi hasil bisnis tetap dipengaruhi penawaran, pasar, respons tim, dan banyak kondisi lain.
Siapkan bahan kerja yang nyata
Bahan kerja tidak harus sempurna, tetapi harus memiliki sumber dan status. Tandai materi yang sudah disetujui, masih berupa draft, membutuhkan izin, atau belum tersedia. Daftar berikut memberi titik awal yang relevan untuk topik ini:
-
Inventaris URL serta traffic. Tuliskan sumber informasinya, kondisi terbaru, dan siapa yang dapat menyetujui perubahan.
-
Peta halaman lama dan baru. Pisahkan hal yang sudah tersedia dari materi yang masih perlu dibuat atau diverifikasi.
-
Redirect. Gunakan contoh nyata agar tim tidak mengisi kekosongan dengan asumsi yang berbeda.
-
Metadata, canonical, dan internal link. Catat hubungan dengan halaman, akun, atau proses lain yang dapat ikut terpengaruh.
-
Sitemap, staging, monitoring, serta rollback. Tentukan kapan bagian ini perlu ditinjau kembali setelah website digunakan.
Simpan daftar ini di satu tempat yang dapat diakses pihak yang terlibat. Jangan mengirim kata sandi atau rahasia melalui dokumen brief. Akses akun sebaiknya diberikan melalui fitur undangan atau pengelola kata sandi yang sesuai, lalu dicabut ketika tidak lagi diperlukan.
Ubah kebutuhan menjadi keputusan yang dapat diperiksa
Keputusan berikut perlu dibuat dengan melihat tujuan halaman, kemampuan tim, dan dampaknya setelah website digunakan. Setiap keputusan sebaiknya memiliki alasan, pemilik, serta cara pemeriksaan yang sederhana:
1. URL mana yang dipertahankan
Untuk mengambil keputusan ini, periksa inventaris URL serta traffic memakai contoh yang benar-benar akan dipublikasikan. Catat alasan pilihan, orang yang menyetujuinya, serta kondisi yang membuat pilihan perlu ditinjau ulang. Gunakan “setiap URL penting memiliki keputusan” sebagai bukti pemeriksaan, bukan sekadar label selesai.
2. Halaman mana yang digabung atau dihentikan
Untuk mengambil keputusan ini, periksa peta halaman lama dan baru memakai contoh yang benar-benar akan dipublikasikan. Catat alasan pilihan, orang yang menyetujuinya, serta kondisi yang membuat pilihan perlu ditinjau ulang. Gunakan “redirect tidak berantai” sebagai bukti pemeriksaan, bukan sekadar label selesai.
3. Tujuan redirect yang setara
Untuk mengambil keputusan ini, periksa redirect memakai contoh yang benar-benar akan dipublikasikan. Catat alasan pilihan, orang yang menyetujuinya, serta kondisi yang membuat pilihan perlu ditinjau ulang. Gunakan “canonical memakai tujuan produksi” sebagai bukti pemeriksaan, bukan sekadar label selesai.
4. Kapan perubahan domain dilakukan
Untuk mengambil keputusan ini, periksa metadata, canonical, dan internal link memakai contoh yang benar-benar akan dipublikasikan. Catat alasan pilihan, orang yang menyetujuinya, serta kondisi yang membuat pilihan perlu ditinjau ulang. Gunakan “link internal tidak mengarah ke URL lama” sebagai bukti pemeriksaan, bukan sekadar label selesai.
5. Sinyal apa yang memicu rollback
Untuk mengambil keputusan ini, periksa sitemap, staging, monitoring, serta rollback memakai contoh yang benar-benar akan dipublikasikan. Catat alasan pilihan, orang yang menyetujuinya, serta kondisi yang membuat pilihan perlu ditinjau ulang. Gunakan “sitemap hanya berisi URL canonical” sebagai bukti pemeriksaan, bukan sekadar label selesai.
Keputusan tidak harus dibuat sekaligus. Pisahkan keputusan yang menghalangi struktur inti dari pilihan yang dapat ditunda. Pilihan tambahan boleh dicatat sebagai opsi proposal, selama tidak diam-diam menjadi ketergantungan bagi fungsi utama.
Kerjakan dalam urutan yang mengurangi risiko
Urutan kerja yang transparan membuat masalah terlihat lebih awal dan menjaga revisi tetap berkaitan dengan keputusan. Gunakan alur berikut sebagai kerangka, lalu sesuaikan detailnya dengan ruang lingkup tertulis:
- Inventarisasi. Kumpulkan bahan, akun, halaman, dan keputusan yang sudah ada sebelum membuat struktur baru. Hubungkan tahap ini dengan keputusan “URL mana yang dipertahankan” dan bukti “setiap URL penting memiliki keputusan”.
- Prioritaskan. Pilih satu tujuan utama dan urutkan kebutuhan lain berdasarkan dampaknya terhadap pengunjung serta operasi. Hubungkan tahap ini dengan keputusan “halaman mana yang digabung atau dihentikan” dan bukti “redirect tidak berantai”.
- Rancang. Buat struktur sederhana memakai isi nyata, lalu tandai asumsi yang belum mendapat persetujuan. Hubungkan tahap ini dengan keputusan “tujuan redirect yang setara” dan bukti “canonical memakai tujuan produksi”.
- Implementasikan. Kerjakan komponen inti terlebih dahulu dan jaga perubahan tetap dapat ditelusuri. Hubungkan tahap ini dengan keputusan “kapan perubahan domain dilakukan” dan bukti “link internal tidak mengarah ke URL lama”.
- Uji. Periksa skenario normal, kondisi kosong, error, perangkat berbeda, keyboard, dan koneksi yang kurang ideal. Hubungkan tahap ini dengan keputusan “sinyal apa yang memicu rollback” dan bukti “sitemap hanya berisi URL canonical”.
- Serahkan. Dokumentasikan akses, keputusan, batas pekerjaan, pemeriksaan, dan pemilik setelah peluncuran. Hubungkan tahap ini dengan keputusan “URL mana yang dipertahankan” dan bukti “setiap URL penting memiliki keputusan”.
Setiap tahap perlu menghasilkan artefak yang dapat ditinjau, seperti peta halaman, daftar isi, prototipe, data uji, atau catatan penerimaan. Artefak tidak harus rumit; fungsinya adalah membuat status pekerjaan terlihat dan mengurangi perbedaan tafsir.
Contoh alur keputusan
Bayangkan sebuah distributor peralatan yang mengandalkan pertanyaan dari pencarian ingin menjaga jalur pengunjung dan mesin pencari tetap dapat mengikuti halaman lama menuju tujuan yang paling relevan. Tim sudah memiliki inventaris URL serta traffic, tetapi peta halaman lama dan baru tersebar di beberapa dokumen dan belum mempunyai pemilik yang jelas. Kondisi ini membuat diskusi mudah melompat ke tampilan sebelum isi dan alur kerja disepakati.
Dalam brief, tim memilih menjawab dua hal lebih dulu: URL mana yang dipertahankan dan halaman mana yang digabung atau dihentikan. Mereka memakai satu layanan atau produk nyata sebagai sampel, menyusun redirect, lalu menandai asumsi yang belum dapat disetujui. Fitur tambahan tetap dicatat, tetapi tidak dibiarkan mengubah fungsi utama tanpa pembahasan ruang lingkup.
Versi pertama diperiksa dengan dua bukti sederhana: setiap URL penting memiliki keputusan dan redirect tidak berantai. Bila hasilnya tidak sesuai, tim kembali ke sumber materi atau keputusan yang salah, bukan menambal halaman dengan klaim baru. Contoh ini menunjukkan bagaimana topik artikel dapat menjadi pekerjaan yang dapat ditinjau, bukan hanya daftar saran.
Periksa hasil dalam konteks penggunaan
Pemeriksaan tidak harus menghasilkan skor sempurna. Tujuannya adalah menemukan kesalahan yang memengaruhi pemahaman, akses, keamanan, atau pekerjaan tim sebelum masalah tersebut dibawa ke pengunjung.
-
Setiap URL penting memiliki keputusan. Uji pada contoh nyata, catat konteksnya, lalu tetapkan pemilik bila hasilnya belum sesuai dengan keputusan 1.
-
Redirect tidak berantai. Uji pada contoh nyata, catat konteksnya, lalu tetapkan pemilik bila hasilnya belum sesuai dengan keputusan 2.
-
Canonical memakai tujuan produksi. Uji pada contoh nyata, catat konteksnya, lalu tetapkan pemilik bila hasilnya belum sesuai dengan keputusan 3.
-
Link internal tidak mengarah ke URL lama. Uji pada contoh nyata, catat konteksnya, lalu tetapkan pemilik bila hasilnya belum sesuai dengan keputusan 4.
-
Sitemap hanya berisi URL canonical. Uji pada contoh nyata, catat konteksnya, lalu tetapkan pemilik bila hasilnya belum sesuai dengan keputusan 5.
Simpan hasil pemeriksaan yang memengaruhi peluncuran atau penerimaan. Bukti dapat berupa daftar URL, tangkapan status, hasil formulir uji, atau catatan keyboard. Hindari mengumpulkan bukti dekoratif yang tidak terhubung dengan kriteria penerimaan.
Hindari jalan pintas yang terlihat mudah
Jalan pintas biasanya muncul ketika konteks belum lengkap atau tanggung jawab tidak jelas. Waspadai pola berikut dan minta penjelasan tertulis jika pola itu muncul dalam brief atau proposal:
- Menghapus halaman tanpa inventaris.
- Mengarahkan semuanya ke beranda.
- Meluncurkan banyak perubahan sekaligus tanpa catatan.
- Membiarkan staging terindeks.
- Mematikan redirect terlalu cepat.
Ketika salah satu risiko muncul, cari akar keputusannya. Kadang masalah dapat diselesaikan dengan memperjelas copy, mengurangi fungsi, atau menunjuk pemilik. Pada kondisi lain, pekerjaan teknis tambahan memang diperlukan. Perbedaannya harus terlihat dalam ruang lingkup agar biaya dan tanggung jawab tidak muncul sebagai kejutan.
Pertanyaan untuk tim atau penyedia website
Jawaban atas pertanyaan berikut membantu membedakan kebutuhan inti, pilihan tambahan, dan tanggung jawab operasional:
- Siapa memiliki daftar URL.
- Data apa yang menjadi baseline.
- Bagaimana redirect diuji.
- Kapan sitemap dikirim.
- Siapa memantau error dan pengindeksan setelah peluncuran.
Minta jawaban yang menunjuk proses atau artefak, bukan hanya kata seperti aman, cepat, modern, atau SEO-friendly. Istilah tersebut baru berguna setelah dijelaskan melalui tindakan, batasan, dan cara uji yang relevan dengan website Anda.
Checklist sebelum pekerjaan dianggap siap
- Sumber dan pemilik inventaris URL serta traffic sudah dicatat.
- Sumber dan pemilik peta halaman lama dan baru sudah dicatat.
- Sumber dan pemilik redirect sudah dicatat.
- Sumber dan pemilik metadata, canonical, dan internal link sudah dicatat.
- Sumber dan pemilik sitemap, staging, monitoring, serta rollback sudah dicatat.
- Setiap URL penting memiliki keputusan.
- Redirect tidak berantai.
- Canonical memakai tujuan produksi.
- Link internal tidak mengarah ke URL lama.
- Sitemap hanya berisi URL canonical.
- Harga, jadwal, revisi, dukungan, dan tanggung jawab sudah mengikuti proposal tertulis.
Penutup
Hasil yang sehat bukan website yang memuat sebanyak mungkin elemen. Hasilnya adalah sistem informasi yang dapat dipahami pengunjung, dapat dijalankan tim, dan dapat diperbaiki ketika bisnis berubah. Mulailah dari tujuan paling penting, gunakan materi nyata, lalu tulis keputusan serta batasannya.
Jika pekerjaan melibatkan pihak lain, bawa checklist dan pertanyaan di atas ke percakapan awal. Harga, jadwal, dukungan, serta komitmen teknis baru dapat dinilai setelah ruang lingkup dan kondisi awal diperiksa, lalu dituangkan dalam proposal tertulis.
Sumber utama untuk dibaca lebih lanjut
Sumber berikut dipakai untuk menguji prinsip dalam artikel, bukan untuk meminjam angka atau membuat janji. Baca dokumen asal ketika keputusan memengaruhi struktur, keamanan, aksesibilitas, atau migrasi.
Google: Site moves with URL changes
Pedoman perpindahan situs menekankan pemetaan URL, redirect permanen, pembaruan tautan internal, sitemap baru, dan pemantauan. Gunakan urutan ini agar redesign tidak memutus jalur lama secara diam-diam. Baca sumber utama.
Google: Build and submit a sitemap
Sitemap adalah petunjuk URL kanonis yang ingin ditemukan, bukan pengganti navigasi atau jaminan indeks. Pastikan hanya URL publik yang benar masuk ke sitemap dan perbarui setelah perubahan struktur. Baca sumber utama.
Google Search Console documentation
Search Console membantu memeriksa bagaimana Google merayapi, mengindeks, dan menampilkan situs. Data tersebut berguna untuk diagnosis setelah peluncuran, tetapi tidak mengendalikan posisi dan tidak menggantikan pengujian pengalaman pengguna. Baca sumber utama.
