SEO Migrasi Domain: Daftar Periksa untuk Profesional Web

Ada sejumlah alasan yang sangat bagus untuk memigrasikan situs web Anda:

• Untuk beberapa bisnis, ini masalah keamanan . Contoh yang baik adalah domain http yang perlu dipindahkan ke domain https.
• Bagi yang lain, ini masalah pembersihan sambil mengubah hal-hal seperti sistem manajemen konten. Jika Anda pindah dari, katakanlah, Joomla ke Drupal, mungkin ini saat yang tepat untuk memigrasikan konten yang masih penting, dan merencanakannya.
• Untuk beberapa organisasi, ini masalah akuisisi . Perusahaan yang dibeli terkadang perlu dimasukkan ke dalam domain "induk".
• Untuk beberapa perusahaan, itu hanya waktu untuk rebranding , dan nama domain adalah salah satu hal yang harus diubah.

Apa pun alasan Anda melakukan migrasi, Anda perlu memahami bahwa semua migrasi domain membawa beberapa risiko , beberapa di antaranya tidak berbahaya, yang lain merusak lalu lintas situs web.

Migrasi yang direncanakan dengan hati-hati mengurangi risiko tersebut. Ini juga memberi pemilik situs web kesempatan yang lebih baik untuk mempertahankan rujukan mesin pencari yang sudah ada, atau benar-benar meningkatkan lalu lintas situs web secara keseluruhan.

Benchmarking sebelum pindah

Sebelum merencanakan aspek yang lebih teknis dari migrasi, ada beberapa hal yang perlu Anda gali untuk menggunakan alat yang berbeda . Ini mirip dengan menendang ban Anda sebelum perjalanan panjang. Lebih baik masuk ke proyek migrasi yang sudah disiapkan.

Setiap situs web berbeda, tetapi Anda mungkin menginginkan beberapa variasi item di bawah ini:

• Dari Google Search Console , ekspor tayangan, klik-tayang, dan posisi Google selama satu tahun. Ini akan menetapkan dasar untuk kehadiran mesin pencari yang harus Anda penuhi setelah pindah.
• Dari alat analisis situs web (seperti WebTrends atau Google Analytics), ekspor statistik bulanan untuk lalu lintas organik, total kunjungan, jumlah rata-rata 404 kesalahan, rasio pentalan, dan konversi. Dapatkan ini setidaknya selama satu tahun juga. Jika alat Anda memiliki fungsi waktu nyata, rasakan lalu lintas serentak pada hari kerja, sehingga Anda juga dapat membandingkannya dengan domain baru setelah peluncuran.
• Jika Anda memiliki alat survei (seperti ForeSee atau Qualaroo) ekspor tingkat kepuasan, dan persentase orang yang dapat menemukan apa yang mereka butuhkan.
• Jika konversi Anda adalah pengiriman formulir dan bukan pembelian, ekspor ini dari alat otomatisasi pemasaran dan/atau manajemen hubungan pelanggan (CRM) .

Statistik tersebut akan memberi Anda campuran statistik kualitatif dan kuantitatif untuk dibandingkan. Salah satu keuntungan mengumpulkan berbagai statistik untuk migrasi adalah jika terjadi kesalahan, Anda dapat melakukan triangulasi, dan mengisolasi apa masalahnya dengan cukup cepat .

Beberapa migrasi dapat memiliki banyak bagian yang bergerak, dan sebagian besar tim kemungkinan akan sangat sibuk selama pemindahan. Anda akan ingin mengoptimalkan waktu yang diperlukan untuk mengidentifikasi dan mengisolasi masalah, sehingga tidak terlalu membebani tim yang sudah sibuk. Dengan cara ini, krisis data terjadi selama fase persiapan, bukan pada hari peluncuran, di mana semua tim kemungkinan besar akan ditarik.

Mengumpulkan statistik dasar untuk mengisolasi masalah di masa depan adalah sesuatu yang harus dilakukan semua pemasar jika mereka berencana untuk migrasi situs web.

Merencanakan berbagai jenis migrasi situs web

Tergantung pada jenis migrasi yang akan Anda lakukan, akan ada tugas berbeda yang perlu Anda rencanakan. Ada beberapa hal yang perlu Anda tentukan:

• Perubahan hanya domain versus perubahan jalur URL
• Konten yang sama atau konten yang berbeda
• Sistem manajemen konten (CMS) baru atau CMS yang sama
• Alat baru atau alat yang sama

Mari kita membahas apa yang perlu Anda rencanakan mengingat perbedaannya.

Perubahan hanya domain versus perubahan jalur URL

Pemindahan domain saja tidak mengubah string apa pun setelah domain tingkat teratas . (Ini adalah "jalur" atau "jalur URL".)

Misalnya, jika semua string Anda seperti /products/product1 atau /about/company tidak akan berubah, tetapi domain Anda akan berubah dari domain.com menjadi domain-baru.com, maka Anda hanya memiliki domain yang berubah.

Perubahan domain

• www.domain.com/ path1 ke www.new-domain.com/ path1
• www.domain.com/ path2 ke www.new-domain.com/ path2
• www.domain.com/ path3 ke www.new-domain.com/ path3

Pengalihan http ke https juga akan memenuhi syarat sebagai pemindahan domain saja.

Sebaliknya, migrasi dengan perubahan jalur URL akan berarti perubahan pada string setelah domain.

Perubahan jalur domain dan URL

• www.domain.com/ path1 ke www.new-domain.com/ new-path1
• www.domain.com/ path2 ke www.new-domain.com/ new-path2
• www.domain.com/path3 ke www.new-domain.com/newfolder/ newstringsfornewpath3

Untuk migrasi di mana jalur URL tidak berubah, biasanya ada cara teknis untuk secara otomatis mengubah string domain untuk pengalihan tanpa menulis satu pengalihan untuk setiap halaman di situs web.

Untuk migrasi di mana jalur URL benar-benar berubah, akan ada kebutuhan untuk menulis beberapa pengalihan tingkat halaman 301. Ini pasti lebih merepotkan.

Jika akan ada perubahan arsitektur informasi ke situs dengan ribuan dan ribuan halaman, mungkin tidak mungkin untuk menulis pengalihan tingkat halaman untuk semuanya. Anda mungkin perlu memutuskan ambang lalu lintas . Misalnya, Anda mungkin ingin hanya mengarahkan 5.000 halaman teratas daripada semua 175.000 halaman, berdasarkan mesin pencari dan peringkat lalu lintas total.

Konten yang sama atau konten yang berbeda

Jika Anda akan secara efektif memiliki konten yang sama di domain baru seperti yang Anda lakukan di domain lama, tidak ada banyak hal yang perlu dipertimbangkan sejauh penautan internal, memastikan grup konten masih masuk akal, dll.

Namun, jika Anda akan menambah atau menghapus potongan konten yang signifikan, Anda harus memetakannya dengan hati-hati.

• Apakah ada kategori yang akan Anda ubah, dan apakah Anda akan “menjadi yatim piatu” dalam prosesnya? Halaman-halaman itu mungkin perlu menemukan rumah baru atau dilipat ke halaman lain. Itu perlu menjadi bagian dari rencana Anda.
• Apakah menu utama masih masuk akal mengingat konten baru Anda? Jika ada bagian yang merupakan halaman penting yang akan lebih sulit dijangkau setelah pemindahan, pertimbangkan untuk menyediakan jalur tambahan untuk mereka setelah perubahan konten dilakukan.

CMS baru atau CMS yang sama

Jika Anda berpindah dari www.example.com ke www.new-example.com dan Anda tidak mengubah CMS, maka migrasi konten yang sebenarnya seharusnya sangat sederhana.

Jika Anda beralih dari satu CMS ke CMS lainnya, langkah yang sama mungkin bukan tugas yang mudah. Anda harus…

• Pastikan bahwa tata letak dan templat di situs lama akan didukung secara wajar oleh sistem baru.
• Tentukan apakah ada cara untuk mengekspor konten CMS Anda menjadi sesuatu yang akan diterima oleh sistem pengelolaan konten baru (meskipun ini tidak 100%, otomatisasi sebagian dari migrasi konten dapat membantu).
• Mengukir waktu untuk potongan-potongan migrasi konten yang akan manual karena perubahan CMS.

Alat baru atau alat yang sama

Alat Anda yang sebenarnya dan cara Anda menerapkan alat mungkin berbeda antara domain lama dan domain baru.

Anda perlu memikirkan beberapa hal:

• Pada sistem baru, apakah ada halaman master atau yang serupa dengan skrip plug-in yang Anda perlukan untuk alat, baik secara mandiri atau sebagai bagian dari alat manajemen tag? Atau apakah Anda perlu memasukkan skrip beberapa kali di seluruh situs? Jika yang terakhir, pastikan Anda memiliki cukup waktu untuk itu.
• Jika Anda beralih dari penerapan alat demi alat ke alat pengelolaan tag seperti Google Pengelola Tag, pastikan Anda memiliki cukup waktu untuk menguji skenario ini. Alat manajemen tag berguna, tetapi perlu waktu untuk membiasakan diri, dan itu harus diperhitungkan dalam timeline Anda untuk peralihan domain.
• Jika Anda menambahkan alat, pastikan Anda memiliki waktu untuk pengujian regresi . Alat baru Anda mungkin tidak langsung berfungsi dengan baik dengan alat lama, dan Anda perlu waktu untuk melakukan debug.

Menyelesaikan rencana migrasi situs

Setelah Anda menangani berbagai jenis migrasi situs, saatnya menyiapkan rencana migrasi situs.

Mari kita buat contoh untuk skenario yang cukup rumit, jadi Anda bisa menghapus bagian yang tidak Anda perlukan.

Misalnya Anda bermigrasi dari CMS lama ke CMS baru. Dan arsitektur informasi Anda di situs baru akan sedikit berbeda – beberapa jalur URL akan dipindahkan ke lokasi baru.

Berikut adalah beberapa hal yang perlu Anda lakukan sejak awal dari sudut pandang pengalihan:

1. Pastikan Anda memiliki cara untuk menangani pengalihan 301 tingkat halaman

Ada beberapa cara untuk menyiapkan pengalihan tingkat halaman “manual”. Beberapa di antaranya melibatkan pengeditan file konfigurasi, yang lain melibatkan memasukkan XML ke dalam modul, dan yang lain masih memiliki fungsi CMS dasar yang menangani ini (dengan asumsi Anda masih memiliki akses ke CMS lama). Tentukan jalur mana yang akan Anda ambil sejak awal, sehingga Anda dapat menghindari sakit kepala di kemudian hari.

2. Periksa apakah Anda dapat menangani pengalihan wildcard atau bersyarat

Jika Anda memiliki kemampuan untuk mengubah file .htaccess atau file konfigurasi serupa, Anda dapat mengelola beberapa pengalihan melalui kondisi daripada mengatur setiap pengalihan secara individual. Ini akan menghemat waktu Anda.

3. Ekspor halaman teratas di situs lama

Pilih antara lalu lintas total dan lalu lintas organik sebagai faktor penentu peringkat Anda. (Lalu lintas organik cukup bagus untuk ini, jadi Anda tahu bahwa Anda akan mengarahkan ulang laman yang benar-benar mendorong rujukan mesin telusur sebelum migrasi.)

• Pilih ambang batas yang masuk akal mengingat ukuran situs. 100 halaman teratas dapat optimal untuk situs yang memiliki 500 URL atau lebih di mana sebagian besar lalu lintas adalah untuk 80 halaman teratas. Namun, Anda mungkin memerlukan 5.000 halaman teratas untuk situs yang memiliki puluhan ribu URL.

4. Petakan halaman teratas ke lokasi barunya

Ini adalah langkah manual yang dapat Anda lakukan untuk menghemat waktu. Sejajarkan daftar halaman teratas pada spreadsheet dan tandai sebagai URL lama, lalu tambahkan URL baru di sebelahnya. Ketika Anda tahu apa yang harus dibuat (seperti file XML), Anda akan memiliki file yang bisa Anda mulai.

Manfaat 301 Redirect

Menambahkan pengalihan tingkat halaman 301 (atau "permanen") ke halaman Anda yang paling berharga saat Anda pindah ke domain baru menyelesaikan dua hal:

• Ini mengirim pengguna ke halaman yang benar, untuk manfaat pengalaman Anda (UX)
• Ini memberi tahu spider mesin pencari tentang langkah tersebut, untuk manfaat SEO

Ketika hanya sebagian situs Anda yang mengalami perubahan arsitektur informasi, Anda biasanya dapat melakukan pengalihan bersyarat atau wildcard pada bagian situs yang masih memiliki jalur URL yang sama, dan hanya menggunakan pengalihan tingkat halaman satu per satu untuk yang lebih kecil jumlah kasus penggunaan di mana mereka benar-benar diperlukan.

Misalnya, mungkin semuanya di bawah /product/ baru saja diubah menjadi /products/ di situs baru. Anda dapat menangani bagian gerakan itu menggunakan penggantian wildcard. Tetapi katakan juga bahwa segala sesuatu di bawah /about/ mendapat "jalur" baru, jadi string yang sebenarnya setelah /about/ akan berubah. Untuk semua di bawah /about/ , Anda perlu memetakan URL lama ke URL baru, dan menambahkan pengalihan tingkat halaman 301.

Dengan cara ini Anda mendapatkan manfaat transfer ekuitas tautan dari domain lama, tanpa membebani tim yang mengelola pengalihan.

Menghindari jebakan umum

Ada banyak cara migrasi domain bisa gagal.

Berikut adalah beberapa yang umum yang perlu Anda waspadai:

1. Alat pengalihan yang Anda miliki tidak cukup kuat untuk beralih.

• Beberapa alat pengalihan hanya mengelola URL http, dan tidak dapat menangani yang https. Jadi, Anda harus menemukan cara lain untuk menangani URL https Anda.
• Beberapa alat pengalihan adalah bagian asli dari CMS dan membutuhkan banyak waktu untuk menyiapkannya. Itu akhirnya bermasalah ketika Anda memiliki ratusan atau ribuan URL.
• Beberapa alat pengalihan tidak dapat menangani karakter pengganti, jadi Anda harus merencanakan pengalihan manual. Dan Anda harus memperhitungkan waktu tambahan yang dibutuhkan.

Migrasi situs web yang berhasil bergantung pada pemasar yang sepenuhnya memahami alat pengalihan yang mereka miliki, dan hanya merencanakan apa yang mungkin.

Mulai klarifikasi apa yang tersedia untuk Anda dengan pengembang Anda sejak dini, menggunakan klarifikasi seperti yang tercantum di atas.

Perhatikan batasan yang akan Anda miliki sebelum hari peluncuran. Jika ada banyak langkah manual, sediakan waktu yang cukup untuk menangani langkah-langkah tersebut.

Ini memastikan bahwa ketika hari pergantian tiba, tidak ada kejutan di area ini.

2. Tim tidak dapat menilai keberhasilan atau kegagalan dengan benar.

Jika tim belum menetapkan tolok ukur yang harus dipenuhi – istilah penelusuran untuk peringkat situs, total lalu lintas organik, total kunjungan, tingkat kepuasan dan keberhasilan di situs, dll. – akan sangat sulit untuk mengetahui apakah migrasi berjalan lancar.

Mungkin lalu lintas keseluruhan hampir sama, tetapi tingkat keberhasilannya mulai menurun. Mungkin skor kepuasannya sama, tetapi ada lebih sedikit istilah pencarian yang diperingkatkan oleh situs dan lalu lintas organik telah turun.

Jika Anda tidak memiliki kisaran angka yang Anda lihat, mungkin terlihat seperti peralihan domain berjalan lancar sementara situs web benar-benar terpukul. Berkinerja buruk dan menyadarinya lebih baik daripada berkinerja buruk dan berpikir Anda melakukannya dengan baik.

Pastikan Anda memiliki tolok ukur untuk berbagai aspek situs untuk menghindari masalah ini.

3. Tim melewatkan halaman penting untuk dimigrasikan.

Untuk domain dengan perubahan arsitektur informasi, halaman yang mendapat peringkat di mesin telusur atau mendapatkan jumlah lalu lintas yang signifikan dari berbagai sumber dapat dengan mudah hilang.

Jika tidak ada yang melakukan ekspor halaman teratas untuk memastikan semua halaman tersebut dimigrasikan, tim biasanya akan melihat penurunan lalu lintas setelah pemindahan.

Jika ini terjadi, tim perlu mengacak laporan bersama-sama dan memeriksa apakah konten lama masih ada di file di suatu tempat sehingga dapat dibawa ke domain baru, atau hidup dengan hilangnya lalu lintas. Jenis kegagalan dalam perencanaan ini benar-benar dapat merusak lalu lintas secara keseluruhan.

Anda perlu memastikan bahwa Anda telah melihat alat analitik Anda dan mengekspor halaman teratas, dan bahwa rencana konten dalam kondisi yang baik sebelum Anda menarik pemicu pengalihan.

4. Volume tugas menjadi terlalu banyak untuk ditangani tim

Ada beberapa hal yang dapat mengubah volume tugas yang diperlukan untuk migrasi domain.

Situs mungkin memiliki tautan absolut daripada tautan relatif, dan Anda harus melakukan lebih banyak penyesuaian tautan internal daripada yang Anda perkirakan sebelumnya.

Alat pengalihan mungkin tidak memiliki kemampuan untuk mendukung karakter pengganti, dan Anda harus mengelola lebih banyak pengalihan manual daripada yang Anda rencanakan.

Mungkin ada item non-halaman-konten yang perlu Anda pindahkan ke CMS baru, seperti hasil unggulan untuk pencarian di tempat, dan Anda harus mencurahkan waktu untuk itu setelah peluncuran.

Biasanya yang terbaik adalah menetapkan beberapa sumber daya tambahan ke situs saat peralihan terjadi, sehingga Anda memiliki ruang gerak ketika segala sesuatunya tidak berjalan sesuai rencana.

Mengelola tugas pada hari pergantian

Katakanlah semua pengalihan bekerja persis seperti yang diharapkan.

Semua konten yang ingin Anda pindahkan telah dipindahkan. Anda tidak mendapatkan lonjakan kesalahan 404, semua alat Anda aktif seperti sebelumnya, semua konfigurasi non-halaman-konten dipindahkan dengan benar.

Itu awal yang bagus, tetapi masih menyisakan beberapa tugas untuk tugas SEO pada hari peluncuran:

1. Memperbaiki kondisi larangan Anda di robots.txt

File robots.txt memberi tahu spider mesin telusur apa yang harus dan tidak boleh dirayapi di situs.

Periksa dengan pengembang dan SEO Anda bahwa Anda memiliki file robots.txt yang dikonfigurasi, dan pindahkan itu. Jika Anda tidak memilikinya, setidaknya pastikan file robots.txt Anda tidak akan terbaca seperti ini:

• Agen pengguna: *
• Larang: /

Kombinasi itu akan memberi tahu Google dan mesin pencari lainnya untuk tidak mengindeks apa pun di situs web Anda. Ini adalah skenario yang harus Anda coba hindari.

2. Membuat dan memvalidasi akun Google Search Console baru

Setelah domain baru dibuat, Anda harus mendaftarkannya ke Google Search Console, dan membuktikan bahwa Anda pemilik domain tersebut. Anda dapat melakukan ini menggunakan sejumlah metode, mulai dari menjatuhkan file yang akan dikenali Google di root hingga menggunakan Google Pengelola Tag.

• Menyiapkan akun Google Search Console untuk folder. Setelah domain divalidasi, Anda dapat menambahkan bagian situs Anda sebagai properti tambahan. Ini akan memungkinkan Anda untuk melakukan hal-hal seperti melihat pencarian yang mengarah ke bagian "produk" Anda atau hanya bagian "tentang kami", jika Anda memilikinya. Ini akan memberi Anda lapisan tambahan untuk memeriksa apakah lalu lintas organik Anda selamat dari migrasi domain.

3. Mengirimkan peta situs

Bergantung pada sistem manajemen konten Anda, Anda dapat membuat peta situs dengan daftar URL dari CMS Anda, dari alat perayapan, atau secara manual melalui Notepad.

Satu hal yang dapat Anda lakukan di sini adalah membuat peta situs terpisah untuk setiap bagian situs Anda (satu peta situs untuk bagian "produk", satu peta situs untuk "tentang kami", dll.) Jika Google mengindeks 90% halaman produk Anda tetapi hanya 5% dari halaman tentang Anda, Anda akan tahu untuk memperbaiki hanya bagian yang diindeks dengan buruk. Anda hanya akan melihat masalah itu jika Anda memiliki peta situs terpisah per bagian situs web.

Setelah Anda membuat peta situs untuk bagian situs web yang berbeda, Anda harus mengirimkannya ke Google melalui Search Console.

4. Memberi tahu Google tentang peralihan domain

Ini adalah langkah yang bahkan dilewatkan oleh beberapa pemasar berpengalaman. Google Search Console memiliki alat yang memungkinkan Anda mendeklarasikan "perubahan alamat". Untuk menggunakannya, Anda perlu memvalidasi properti Google Search Console untuk domain lama dan baru, lalu ikuti langkah-langkah yang tercantum oleh Google Search Console.

Memantau statistik setelah peluncuran

Jika Anda telah mengikuti saran pada posting ini sejauh ini, Anda akan memiliki tolok ukur kuantitatif dan kualitatif untuk dibandingkan.

• Data alat survei. Penurunan signifikan dalam kepuasan dan kemampuan orang untuk menemukan apa yang mereka butuhkan dapat berarti bahwa struktur baru situs dapat membingungkan pengunjung. Anda harus memikirkan kembali arsitektur baru .
• Google Search Console dan data alat analitik. Lonjakan kesalahan 404 dikombinasikan dengan beberapa penurunan peringkat dan penurunan lalu lintas organik biasanya berarti setidaknya beberapa pengalihan gagal. Anda harus menyelidiki metodologi pengalihan .
• Data alat analitik. Penurunan yang signifikan dalam total dan lalu lintas rujukan tanpa penurunan besar dalam lalu lintas mesin telusur dapat berarti Anda tidak berpindah ke konten yang ditautkan ke situs web lain. Anda harus mengunjungi kembali konten tersebut .

Pemantauan lalu lintas waktu nyata juga dapat membantu di sini. Jika jumlah pengunjung secara bersamaan di situs Anda jauh di bawah angka pra-peluncuran (misalnya, kurang dari setengah dari jumlah sebelumnya), maka Anda akan tahu ada sesuatu yang tidak beres dan Anda perlu menggali lebih dalam.

Tidak ada yang namanya persiapan berlebihan dalam migrasi domain

Memindahkan domain bisa menjadi proses yang menyakitkan.

Ada banyak cara prosesnya bisa berjalan buruk untuk situs Anda. Dan ada sangat sedikit jalan untuk menyelesaikan kesuksesan.

Semua itu dikatakan, jika Anda perlu mengubah domain Anda, yang terbaik adalah mempersiapkannya secara berlebihan. Jika kamu …

• pelajari apa yang dapat dilakukan alat pengalihan untuk Anda sejak dini,
• terobsesi dengan rencana konten sampai Anda tidak melihat lubang yang tersisa, dan
• gunakan data untuk mengelola transisi

… Anda memiliki peluang yang lebih baik untuk berpindah ke domain baru dengan mulus.

Untuk jenis gerakan tertentu, jika Anda terobsesi dengan rencana tersebut, Anda bahkan dapat meningkatkan lalu lintas dan konversi setelah peralihan.