Wawasan Oura • 20 Oktober 2026
Redesign Website Tanpa Mengabaikan SEO: Rencana Migrasi URL
Oura Works
Redesign website tanpa kehilangan SEO bukan hasil yang bisa dijamin. Google perlu menemukan, merayapi, dan memproses perubahan; selama proses itu, visibilitas dapat berfluktuasi. Risiko dapat dikendalikan dengan mempertahankan URL yang masih sesuai, memetakan setiap URL yang berubah ke tujuan paling relevan, menguji akses dan redirect sebelum rilis, lalu memantau data lama dan baru. Langkah pertama adalah memastikan apa saja yang benar-benar berubah.
Ringkasnya
- Perubahan visual saja berbeda risikonya dari perubahan CMS, URL, domain, dan konten sekaligus.
- Simpan baseline dan inventaris halaman sebelum desain atau struktur baru menggantikan situs lama.
- Redirect hanya ke padanan yang relevan; periksa status akhir, canonical, sitemap, tautan, serta pemantauan pascarilis.
Google menyebut fluktuasi peringkat dapat terjadi ketika sistemnya merayapi dan mengindeks ulang situs yang berubah. Untuk situs berukuran menengah, pemrosesan alamat baru dapat memerlukan beberapa minggu atau lebih; situs yang lebih besar bisa memerlukan waktu lebih lama. Ini bukan jadwal pasti atau jaminan pemulihan, sehingga keputusan perlu berdasarkan pemeriksaan URL dan data aktual. Panduan Google tentang perpindahan situs.
Apa saja yang berubah saat redesign website?
Risiko redesign bergantung pada lapisan yang disentuh. Mengganti warna dan tata letak sambil mempertahankan URL serta isi utama berbeda dari memindahkan CMS, mengubah alamat halaman, mengganti domain, atau menulis ulang konten dalam satu peluncuran.
| Lingkup perubahan | Contoh | Fokus pemeriksaan |
|---|---|---|
| Tampilan saja | Komponen, tipografi, warna, jarak, dan tata letak berubah | Pastikan konten utama tetap terbaca, fungsi bekerja, serta heading dan tautan tidak hilang |
| CMS atau platform | Konten berpindah, tetapi URL publik dipertahankan | Bandingkan HTML yang dirender, metadata, canonical, tautan, media, dan aturan indeksasi |
| Struktur URL | Slug, folder, atau pola parameter berubah | Buat inventaris alamat lama, padanan baru, dan aturan redirect yang bisa diuji |
| Domain atau protokol | Domain, subdomain, atau HTTP/HTTPS berubah | Petakan variasi domain, sertifikat, redirect, Search Console, canonical, dan sitemap |
| Beberapa hal sekaligus | CMS, desain, domain, URL, dan konten berubah bersama | Pecah pekerjaan bila memungkinkan agar masalah lebih mudah ditelusuri |
Google menganjurkan agar perubahan besar direncanakan bertahap bila sesuai, dan perubahan yang tidak saling bergantung tidak semuanya dilakukan sekaligus. Namun, tes pada sebagian kecil situs besar belum tentu mewakili dampak untuk seluruh situs. Pilih pendekatan berdasarkan jumlah URL, jenis halaman, kemampuan tim, dan risiko operasional—bukan karena satu pola dianggap berlaku untuk semua bisnis.
Jika tujuan utamanya adalah memperbarui tampilan, jangan mengubah URL hanya karena struktur baru terlihat lebih rapi. Jika alamat lama memang bermasalah, catat alasan dan dampaknya, lalu perlakukan perubahan itu sebagai bagian dari migrasi. Menjaga satu variabel tetap sama juga memudahkan tim memahami apa yang mungkin menyebabkan perubahan performa.
Data apa yang perlu disimpan sebelum redesign?
Sebelum situs lama diganti, simpan kondisi yang dapat digunakan untuk membandingkan situs baru. Ambil URL dari lebih dari satu sumber: sitemap, hasil crawl, halaman yang menerima klik atau konversi, laporan tautan, halaman penting dari CMS, serta log server yang tersedia.
| Baseline | Catat sebelum rilis | Gunanya saat diagnosis |
|---|---|---|
| Search Console | Klik, tayangan, kueri, halaman, negara, dan rentang tanggal | Mengetahui halaman atau kueri mana yang berubah setelah rilis |
| Analitik bisnis | Sesi organik, inquiry, transaksi, dan landing page | Memisahkan perubahan kunjungan dari perubahan prospek atau penjualan |
| Inventaris URL | Status respons, canonical, title, H1, bahasa, dan tautan | Membandingkan isi serta akses versi lama dan baru |
| Tautan dan aset | Halaman ber-backlink, dokumen, gambar, atau video yang diakses | Menghindari kehilangan tujuan yang masih dicari pengguna atau crawler |
| Tanggal dan lingkup rilis | Waktu perubahan, daftar komponen, pemilik, dan catatan deployment | Mencocokkan gejala dengan perubahan yang benar-benar dirilis |
Di laporan performa Search Console, simpan tampilan per halaman dan kueri, bukan hanya angka total situs. Google menyediakan rentang hingga 16 bulan untuk membantu melihat konteks dan pola musiman; gunakan periode sepanjang yang tersedia dan bandingkan rentang yang sepadan. Panduan Google untuk mendiagnosis penurunan traffic menjelaskan cara memakai rentang tersebut. Data klik dan tayangan adalah petunjuk diagnosis, bukan bukti tunggal bahwa desain baru menjadi penyebab perubahan.
Untuk halaman prioritas, simpan juga salinan title, deskripsi, heading utama, canonical, bahasa, data terstruktur, serta tautan masuk dan keluar. Prioritaskan halaman yang membawa prospek, transaksi, tayangan, atau tautan penting. Daftar halaman dari CMS saja dapat melewatkan landing page lama, dokumen, gambar, serta URL yang sudah dihapus tetapi masih dirujuk.
Dokumentasi perpindahan situs Google menyarankan penggunaan sitemap, analitik atau log, dan data tautan untuk menemukan alamat lama yang penting. Panduan tersebut juga menyebut media seperti gambar, video, JavaScript, dan CSS sebagai aset yang perlu diperhitungkan jika lokasinya berpindah. Rujuk panduan URL mapping Google.
Bagaimana membuat peta URL lama ke tujuan baru?
Setiap URL lama perlu memiliki keputusan yang dapat dijelaskan: alamat tetap digunakan, dialihkan ke pengganti yang setara, atau memang dihapus tanpa pengganti yang relevan. Untuk halaman yang pindah, pilih tujuan yang memenuhi maksud pengguna dan mempertahankan konteks isi, bukan tujuan yang paling mudah dibuat.
| Keputusan | Kapan dipakai | Contoh tindakan |
|---|---|---|
| Pertahankan | URL masih jelas dan sesuai isi | Rilis desain baru pada alamat yang sama |
| Redirect langsung | Halaman berpindah atau digabung ke konten yang setara | Arahkan satu URL lama ke halaman baru yang paling dekat maksudnya |
| Hapus dengan status yang tepat | Konten memang tidak lagi tersedia dan tidak punya pengganti setara | Pastikan alamat lama memberi respons 404 atau 410, bukan halaman error berstatus sukses |
| Tinjau manual | Tujuan belum jelas, halaman penting, atau datanya bertentangan | Minta pemilik konten dan SEO menyepakati tujuan sebelum rilis |
Peta migrasi minimal memuat URL lama, URL tujuan, alasan keputusan, prioritas, pemilik pemeriksaan, status redirect, respons akhir, dan catatan. Baris URL dengan nilai tinggi sebaiknya ditinjau satu per satu. Aturan wildcard bisa berguna bila pola lama dan baru benar-benar konsisten, tetapi tetap uji sampel dari setiap jenis rute agar tidak salah mengarahkan parameter atau halaman khusus.
Untuk perpindahan permanen, Google merekomendasikan redirect permanen di sisi server bila memungkinkan, misalnya 301 atau 308. Arahkan pengguna langsung ke tujuan akhir dan hindari rantai seperti URL lama → alamat perantara → halaman final. Google juga memperingatkan bahwa banyak URL yang dialihkan ke homepage yang tidak relevan bisa membingungkan pengguna dan diperlakukan sebagai soft 404. Panduan Google tentang redirect.
URL lama yang digabung ke satu halaman baru dapat dialihkan ke halaman tersebut bila isinya memang mencakup kebutuhan lama. Sebaliknya, jangan mengalihkan halaman yang tidak berkaitan hanya untuk menghindari 404. Pengalaman yang tepat dan status HTTP yang jujur membantu tim memahami apakah halaman benar-benar pindah atau sudah tidak tersedia.
Apa yang harus diuji di staging sebelum desain baru dirilis?
Staging perlu menguji halaman baru sebagai calon pengganti, bukan sekadar membuktikan bahwa tampilannya selesai. Bandingkan inventaris URL dengan hasil crawl versi baru, pastikan setiap keputusan migrasi berfungsi, lalu periksa elemen yang dapat berubah saat template atau CMS diganti.
| Pemeriksaan | Cara memeriksa | Kondisi yang perlu ditindaklanjuti |
|---|---|---|
| Cakupan peta | Cocokkan URL lama dari sitemap, crawl, dan data bisnis dengan daftar keputusan | URL penting tidak punya keputusan atau URL baru tidak memiliki pemilik |
| Redirect | Uji beberapa contoh setiap pola dari alamat lama sampai URL akhir | Tujuan salah, status tidak sesuai, loop, atau lompatan berulang |
| Halaman tujuan | Periksa respons, isi utama, canonical, bahasa, dan aturan indeksasi | 404 tak sengaja, noindex tertinggal, canonical mengarah ke domain/halaman lama |
| Navigasi dan sitemap | Crawl tautan, breadcrumb, canonical, hreflang, dan sitemap versi baru | Tautan internal melewati redirect atau sitemap masih memuat URL lama |
| Media dan fitur | Buka dokumen/gambar penting, formulir, login, pencarian, dan integrasi | Aset hilang, formulir gagal, atau fungsi utama tidak bekerja |
Simpan aturan akses staging agar situs uji tidak terbuka tanpa sengaja. Pada saat yang sama, siapkan daftar aturan robots.txt dan noindex yang perlu berubah saat rilis. Pengujian staging harus mencerminkan perilaku final sejauh lingkungan memungkinkan; pastikan host sementara, cookie, atau konfigurasi server tidak menghasilkan kesimpulan yang berbeda dari situs produksi.
Di versi baru, arahkan tautan internal ke URL final, gunakan canonical yang sesuai, perbarui hreflang jika halaman multibahasa ikut berubah, dan siapkan sitemap baru. Google menyarankan elemen-elemen tersebut diperbarui berdasarkan peta URL. Perubahan redirect, canonical, noindex, dan robots harus ditinjau bersama agar sinyal teknisnya tidak bertentangan.
Apa yang dipantau setelah redesign website diluncurkan?
Setelah rilis, pantau keadaan situs lama dan baru dengan baseline yang sama. Periksa apakah URL prioritas bisa dijangkau, redirect berakhir pada halaman yang relevan, crawler dapat mengakses konten, dan data pencarian maupun bisnis bergerak sesuai konteks.
| Waktu kerja yang disarankan | Pemeriksaan utama | Catat untuk tindak lanjut |
|---|---|---|
| Sebelum rilis | Simpan crawl, sitemap, data halaman dan kueri, serta tanggal snapshot | Baseline, pemilik, dan lingkup perubahan |
| Hari rilis | Uji URL prioritas, redirect sampel, canonical, formulir, dan akses crawler | Status respons, tujuan akhir, waktu pemeriksaan, tiket |
| Minggu pertama | Tinjau error, 404, noindex, sitemap, crawl, tayangan, klik, dan konversi | Perubahan per kelompok halaman serta penyebab yang sudah diuji |
| Minggu berikutnya | Bandingkan tren dengan periode yang sepadan dan cek URL yang belum pulih | Apakah masalah teknis terselesaikan atau butuh analisis lain |
Jadwal pada tabel adalah ritme operasional yang dapat disesuaikan; Google tidak menjanjikan bahwa semua halaman akan diproses dalam jangka waktu tertentu. Gunakan Search Console untuk memeriksa sitemap, cakupan indeks, kueri, serta URL yang tampak bermasalah. Cocokkan dengan log server dan analitik agar penurunan halaman penting tidak tertutup oleh perubahan pada URL lain.
Google mencatat bahwa fluktuasi dapat terjadi saat alamat baru dirayapi dan diproses, dan perubahan lalu lintas juga dapat berasal dari faktor lain. Jika impresi atau klik turun, bandingkan kueri dan halaman yang paling berubah, periksa error teknis serta status indeksasi, lalu lihat tren musiman. Jangan langsung mengubah desain, konten, redirect, dan domain lagi sekaligus karena itu mengaburkan penyebab. Panduan Google untuk mendiagnosis penurunan traffic.
Urutan diagnosis yang bisa digunakan tim:
- Pilih halaman dan kueri yang penurunannya paling besar di Search Console.
- Buka URL final dan periksa respons, redirect, canonical, robots/noindex, serta isi yang terlihat.
- Cocokkan alamat lama dengan peta migrasi dan telusuri rantai sampai tujuan akhir.
- Bandingkan periode yang setara dan periksa apakah permintaan pencarian atau musim berubah.
- Catat dugaan, bukti, pemilik, dan tindakan; ubah satu penyebab yang telah dikonfirmasi lalu ukur kembali.
Google menyebut pemrosesan perpindahan URL terjadi per halaman. Untuk situs menengah, peralihan URL dapat memerlukan beberapa minggu atau lebih; situs besar mungkin lebih lama. Karena tidak ada frekuensi crawl yang tetap, gunakan tren dan inspeksi URL yang relevan daripada menganggap perubahan peringkat harian sebagai kesimpulan akhir.
FAQ — Pertanyaan yang sering diajukan
Tidak. Penurunan bukan hasil yang pasti, tetapi perubahan URL, akses crawler, konten, canonical, dan redirect dapat memengaruhi cara Google menemukan serta memproses halaman. Perencanaan dan QA mengurangi risiko kesalahan migrasi, namun tidak dapat menjamin posisi atau traffic akan tetap sama.
Apakah semua URL lama harus dialihkan?
Tidak jika alamat lama tetap dipakai. Jika halaman pindah, alihkan ke pengganti yang relevan. Jika konten dihapus tanpa tujuan yang benar-benar setara, gunakan respons 404 atau 410. Hindari redirect massal ke homepage hanya demi menghindari halaman tidak ditemukan.
Berapa lama perlu memantau setelah migrasi website?
Tidak ada durasi universal yang menjamin seluruh perubahan selesai diproses. Google menyebut situs menengah dapat memerlukan beberapa minggu atau lebih dan situs besar bisa lebih lama. Pantau error dan halaman prioritas lebih rapat pada minggu pertama, lalu lanjutkan sampai tren dan kendala utama dipahami.
Apa yang dilakukan jika traffic turun setelah redesign?
Cari halaman dan kueri yang berubah melalui Search Console, lalu periksa URL tujuan, status respons, noindex, robots.txt, canonical, dan redirect. Bandingkan periode yang sepadan, cek log serta analitik, dan pertimbangkan faktor musiman. Perbaiki temuan yang terbukti sebelum melakukan perubahan besar berikutnya.
Rujukan resmi
- Perpindahan situs dengan perubahan URL — Google Search Central
- Redirect dan Google Search — Google Search Central
- Mendiagnosis penurunan traffic Search — Google Search Central
- Menggabungkan URL duplikat dan canonical — Google Search Central
Untuk merapikan hierarki konten sebelum migrasi, lihat panduan arsitektur website dan panduan struktur website bisnis. Bila Anda sedang menyusun situs baru, layanan pengembangan website Oura Works menjelaskan cara membahas kebutuhan dan ruang lingkup proyek.
Lanjutkan ke panduan dan cerita yang membahas keputusan serupa.
Fondasi SEO untuk pencarian AI
Rawat akses teknis dan informasi yang membantu pembaca.
Pengukuran prospek dengan GA4
Hubungkan tindakan website dengan konteks sales.
Brief proyek website yang jelas
Sepakati tujuan, cakupan, serta keputusan proyek.
Copy layanan sebelum konsultasi
Perjelas manfaat, cakupan, bukti, dan langkah berikutnya.