5 Kesalahan Migrasi Situs SEO yang Harus Dihindari dengan Sara Moccand

Apakah Anda pernah terlibat dalam migrasi situs bencana? Mungkin Anda telah dibawa ke sebuah proyek untuk menangani efek dari migrasi situs web yang dipikirkan dengan matang.

Hari ini kita akan membahas lima kesalahan utama yang harus dihindari saat memigrasikan situs web Anda dengan seorang wanita yang tahun lalu menyerah dan berlangganan Netflix dan Disney Plus. Dia adalah co-host pertemuan SEO Nerds Switzerland dan SEO Specialist di Liip, agen pengembangan web dan seluler dengan enam kantor di Swiss. Sambutan hangat di podcast In Search SEO, Sara Moccand.

Kesalahan yang harus dihindari adalah:

1. Perencanaan yang buruk
2. Tidak menguji pengalihan
3. Tidak mengaudit pementasan
4. Bermigrasi dalam periode permintaan tinggi
5. Memiliki pementasan yang diindeks

5 Tips Migrasi Situs yang Harus Diperhatikan

Sara: Hai.

D: Hei, Sara. Anda dapat menemukan Sara di liip.ch. Jadi Sara, mengapa migrasi situs web menjadi masalah besar bagi SEO?

S: Terutama karena Anda dapat kehilangan semua lalu lintas organik yang merupakan sumber pendapatan, menurut saya. Itulah alasan utamanya, jadi setiap orang harus sangat berhati-hati dalam migrasi situs web mereka.

D: Jadi hari ini, kita berbicara tentang lima kesalahan utama yang harus dihindari saat memigrasikan situs web Anda. Dimulai dengan nomor satu, perencanaan yang buruk.

1. Perencanaan yang Buruk

S: Ya, salah satu kesalahan terbesar adalah perencanaan yang buruk. Saya punya beberapa contoh. Perencanaan yang buruk bisa dimulai dari awal. Misalnya, di sebuah agensi, menjual jumlah hari yang salah, yang berarti Anda harus membahas kembali anggaran, yang membuatnya sangat rumit. Ada beberapa contoh tapi mari kita mulai dengan masalah utama. Jelas, Anda tidak mendapatkan hal-hal yang diimplementasikan seperti yang Anda inginkan jika Anda tidak merencanakan dengan benar. Masalah kedua, seperti yang saya katakan sebelumnya, adalah hilangnya lalu lintas. Itulah skenario bencana, kehilangan lalu lintas, dan solusi untuk ini adalah mempelajari nama semua orang yang terlibat. Itulah rahasianya. Pelajari siapa pengembangnya, siapa front end, backend, desainernya, dll. Pelajari semua yang Anda bisa tentang nama mereka dan apa yang mereka lakukan sehingga Anda selalu dapat menghubungi mereka.

Setiap migrasi situs web seperti proyek baru. Jadi Anda memiliki proyek, yang kemudian memiliki rencana. Dan di sanalah Anda dapat melihat dengan tepat di mana SEO dapat berinteraksi. Itu penting untuk diingat. Misalnya, pada awalnya, pengembang tahu apa yang harus dilakukan, mereka akan memilih teknologi yang akan digunakan. Jadi menarik bagi SEO untuk mengetahui teknologi mana yang mereka rencanakan untuk digunakan. Dan mungkin Anda juga bisa mempengaruhi teknologi yang digunakan. Kadang-kadang, tidak terlalu sering, tetapi kadang-kadang. Ini hanyalah sebuah contoh tentang mempelajari keseluruhan perencanaan dan mencari tahu di mana Anda dapat berinteraksi.

D: Ada banyak hal yang bisa Anda masukkan ke dalam rencana, tentu saja, tetapi apakah ada elemen standar yang akan Anda masukkan ke dalam rencana? Atau apakah setiap proyek cukup unik?

S: Saya akan mengatakan ada tiga hal standar. Mengetahui kapan teknologi dipilih, mengetahui kapan perancang akan mulai merancang arsitektur situs web, dan mengetahui pada titik mana ia akan ditayangkan, Anda dapat menganalisis tahapannya untuk memastikan kapan akan ditayangkan. Ini membawa saya ke rincian migrasi situs web. Anda memiliki rencana Anda dan kemudian Anda memecahnya menjadi beberapa fase. Pertama adalah fase persiapan, di mana Anda berinteraksi dengan para pengembang. Dan di sana Anda juga harus menganalisis bagaimana kinerja situs web, halaman mana yang penting, dll. Dan Anda juga akan menyiapkan peta pengalihan Anda. Tahap selanjutnya ada tahap testing dimana anda menguji semuanya karena apapun yang ada di staging akan live 100% jadi jika ada masalah disana akan ada masalah setelahnya.

D: Anda juga menyebutkan URL di sana. Saya kira beberapa migrasi situs web lebih mudah daripada yang lain. Beberapa Anda mungkin memigrasi server dan mempertahankan teknologi yang sama, CMS, URL yang sama mungkin juga… Apa yang terjadi jika Anda mengubah setiap URL atau sebagian besar URL karena Anda harus melakukannya? Mungkin Anda berpindah dari sesuatu yang memiliki ASP, misalnya, di akhir URL ke URL yang cukup sederhana? Apakah mungkin untuk mempertahankan semua peringkat Anda dan mengubah URL secara bersamaan?

S: Saat saya bekerja di perusahaan pengembangan, orang-orang datang untuk melakukan itu. Mereka tidak datang hanya untuk mengubah server sedikit. Apa yang ingin mereka lakukan adalah persis seperti itu. Mereka ingin mengubah segalanya. Itu adalah masalah saya. Jadi ya, itu berhasil. Anda harus melakukan pengalihan Anda, Anda harus melakukan peta pengalihan Anda, dan Anda punya waktu di mana mesin pencari perlu beradaptasi sedikit. Sebagian besar waktu berfungsi dengan baik, karena ketika Anda melakukan redirect map, tujuannya adalah untuk melakukannya dengan cerdas. Misalnya, Anda tahu bahwa jika suatu halaman diberi peringkat untuk sesuatu yang spesifik, maka Anda akan mengarahkannya ke topik yang sama. Maka Anda harus sedikit berhati-hati di peta pengalihan Anda, dan kemudian berhasil. Sekali lagi, skenario yang paling sering saya lihat adalah di mana mereka mengubah segalanya.

D: Satu pertanyaan lanjutan lainnya sehubungan dengan apa yang Anda katakan. Anda mengatakan bahwa terkadang mesin pencari membutuhkan sedikit waktu untuk beradaptasi. Berapa banyak waktu yang masuk akal untuk diberikan kepada mesin pencari sebelum Anda melihat peringkat yang sama dengan yang Anda miliki sebelumnya?

S: Tidak, maksud saya sebelum Anda panik. Saya akan mengatakan itu tergantung, tetapi saya telah melihat beberapa waktu di mana mereka tidak mengubah segalanya, tetapi mereka sedikit berubah dan mereka beradaptasi dengan cukup cepat. Saya akan mengatakan maksimal satu bulan, satu setengah bulan. Dan jika setelah itu tidak beradaptasi, maka ada beberapa masalah di suatu tempat.

D: Mari kita beralih ke nomor dua, bukan menguji pengalihan.

2. Tidak Menguji Pengalihan

S: Ya. Mari kita lakukan beberapa contoh di dinding rasa malu di mana saya melakukannya dengan buruk. Saya ingat pada awalnya saya mengatur peta pengalihan saya, dan setiap file baik-baik saja. Kemudian saya memberikannya kepada pengembang untuk mempersiapkan semua yang saya uji. Dan saya mengatakan bahwa semuanya baik-baik saja. Kemudian ditayangkan. Dan ketika kami melakukan siaran langsung, saya bertanya-tanya apa yang terjadi. Dan kemudian saya menyadari bahwa itu menghasilkan rantai pengalihan, yang membuat saya sedikit terkejut. Jadi saya cukup beruntung memiliki hubungan yang sangat baik dengan para pengembang, yang mampu memperbaikinya di tempat. Itu adalah satu skenario kasus di mana saya menguji tetapi saya tidak menguji dengan cukup baik, karena saya tidak menyadarinya sebelum ditayangkan.

Lain waktu di dinding rasa malu dan menyadari betapa pentingnya menguji segalanya dengan sempurna. Saya ingat ada situs web dengan banyak negara, tetapi ada peran khusus untuk URL. Jadi saya meminta pengembang untuk membantu saya melakukan skrip untuk saya sehingga kami akan berjalan lebih cepat. Dia melakukan skrip dan kemudian saya memesan setengah hari dengan pengembang untuk melakukan tes tetapi kemudian dia berkata, "Hei, Sara, saya mengujinya." Fantastis. Jika Anda sudah melakukannya, fantastis. Tapi izinkan saya mencoba satu negara. Jadi saya mengujinya di AS dan saya berkata, "Semuanya berfungsi. Besar. Terima kasih. Selamat tinggal. Beri aku lima!” Kemudian kami melakukan siaran langsung. Saya memeriksa semuanya dan ketika saya memeriksa saya, ”Apa yang terjadi? Apa itu melompat? Di mana Jepang dan Kuwait?” Jadi saya melihat kami memigrasikan semuanya, tetapi kami kehilangan Jepang dan Kuwait, yang tidak saya sadari sebelum mereka ditayangkan. Dan sekali lagi, saya beruntung karena mereka membantu saya memulihkannya segera sehingga tidak ada dampak nyata karena itu terjadi pada hari kami memperbaiki semuanya. Tapi itu masalah. Anda harus menguji.

D: Saya kira itu juga terkait dengan poin tiga karena poin tiga tidak mengaudit pementasan.

3. Tidak Mengaudit Pementasan

S: Ya, itu bagian dari poin tiga. Pada awalnya, saya memiliki tiket saya, saya memeriksanya, dan semuanya baik-baik saja dalam pementasan. Fantastis. Tiket diimplementasikan. Tetapi kemudian saya menyadari bahwa saya tidak mengaudit seperti saya akan mengaudit situs web secara normal. Misalnya, Anda mulai melihat hal-hal aneh. Saya ingat situs web ini, yang terjadi baru-baru ini dan di sisi server ditampilkan dengan sempurna. Saya bisa melihat semuanya dalam kode di konsol. Jadi saya senang. Tapi saya punya masalah dengan elemen tersembunyi, saya selalu memeriksa elemen tersembunyi. Apa yang terjadi adalah JavaScript berperilaku sangat aneh. Itu menghapus semua teks dari elemen tersembunyi. Jadi Anda bisa melihatnya tetapi tidak dalam kode. Itu adalah contoh betapa pentingnya mengaudit pementasan situs web dan memeriksa semua implementasinya.

Hal lain yang perlu Anda lakukan adalah memiliki daftar periksa Anda sendiri, memperbaiki daftar periksa, dengan semua tugas, persis seperti audit, dan kemudian Anda selalu dapat menambahkan kolom. Misalnya, jika Anda menggunakan Google Sheet, ada kolom yang untuk tugas ini saya punya tiket, untuk tugas ini tidak wajib, saya bisa mengambilnya. Misalnya untuk kasus JavaScript yang saya berikan, Anda tidak membuka tiket, Anda hanya membukanya jika ada masalah. Dan kemudian Anda memberikan daftar prioritas Anda di kolom lain, status. URL status mana yang harus dilakukan dalam proses, dan kemudian Anda berkomentar. Komentar sangat penting, semua orang mengambilnya, tetapi komentar penting karena Anda perlu tahu mengapa ada sesuatu yang diblokir. Misalnya, jika seseorang memblokir atau tiket lain memblokir, Anda perlu tahu untuk memblokirnya. Itulah sedikit tentang audit pementasan dan pentingnya. Itu tergantung, tetapi beberapa pengembang juga akan menggunakan, misalnya, noindex di semua halaman, dalam kode. Dan kemudian mereka akan lupa untuk menghapusnya saat ditayangkan. Masalahnya adalah Anda harus menyadari bahwa mereka menggunakannya sehingga Anda dapat meminta mereka untuk mengingat untuk menghapus noindex sebelum ditayangkan.

D: Dan poin nomor empat yang harus dihindari adalah bermigrasi dalam periode permintaan tinggi.

4. Bermigrasi dalam Periode Permintaan Tinggi

S: Ya. Ini harus jelas karena Anda memiliki masalah kehilangan lalu lintas ini, atau setidaknya untuk waktu yang singkat, tidak selalu seperti ini. Sekali lagi, itu tergantung pada migrasi situs web, tetapi ada risiko waktu beradaptasi. Dan kemudian jika Anda punya waktu untuk kegiatan lain… Katakanlah Anda berada di eCommerce. Antara mungkin Oktober dan akhir Desember, Anda tidak ingin memigrasikan situs web Anda karena Natal akan datang dan banyak orang akan membeli melalui toko eCommerce Anda. Klien biasanya tahu bahwa pada periode itu mereka memiliki permintaan yang tinggi. Jadi, Anda dapat memeriksa dengan klien analitik mereka untuk menghindari masalah.

D: Anda menyebutkan sebelumnya bahwa beberapa pengembang bahkan mungkin menempatkan noindex di setiap halaman untuk benar-benar mencoba dan menghindari halaman yang diindeks. Kesalahan nomor lima adalah membuat pementasan diindeks. Apakah Anda menyarankan tag noindex pada setiap halaman di lingkungan pementasan untuk menghindari hal semacam itu?

5. Memiliki Pementasan Terindeks

S: Tidak, proteksi password selalu menjadi solusi. Anda dapat melakukan noindex tetapi, seperti dalam contoh saya, Anda mungkin lupa saat melakukan siaran langsung. Pada akhirnya, solusi terbaik yang selalu berhasil adalah dilindungi kata sandi, titik. Saya ingat suatu kali pementasan diindeks beberapa tahun yang lalu, dan itu mungkin pengalaman paling mengejutkan yang saya miliki. Pementasan diindeks dan masalahnya adalah ... Anda dapat membeli tiket di situs web dan masalahnya adalah orang-orang yang mencoba membeli tiket di situs web pementasan sedikit menimbulkan bencana. Dapatkah Anda membayangkan orang mencoba membeli di situs web pementasan? Jadi mereka menghubungi saya mengatakan bahwa mereka memiliki masalah ini. Dan kami dapat menyelesaikannya karena relatif mudah untuk diselesaikan. Itu mungkin salah satu poin utama bagi saya. Setelah pengembang memasukkan perlindungan kata sandi dan memasukkan file noindex. Jadi saya harus berhati-hati tidak hanya untuk memeriksa apakah itu dilindungi kata sandi tetapi juga untuk memeriksa file noindex.

D: Saya yakin Anda dapat memperluas percakapan ini menjadi 101 kesalahan yang harus dihindari saat memigrasikan situs web kami, tetapi mudah-mudahan, kami mendapatkan lima besar Anda di sana. Seperti biasa, itu hal-hal hebat dari Sara di sana. Mari kita akhiri dengan Pareto Pickle. Pareto mengatakan Anda bisa mendapatkan 80% dari hasil Anda dari 20% dari usaha Anda. Apa satu aktivitas SEO yang Anda rekomendasikan yang memberikan hasil luar biasa untuk tingkat upaya yang sederhana?

The Pareto Pickle - Perencanaan Migrasi Situs Web

S: Bagi saya dalam migrasi website itu perencanaan. Luangkan sedikit waktu dalam perencanaan. Ini bukan jumlah waktu yang besar dibandingkan dengan pekerjaan yang harus Anda lakukan. Jika Anda memiliki struktur, maka Anda tidak membuat kesalahan, dan kemudian Anda menghemat banyak waktu karena untuk setiap kesalahan, Anda perlu meminta waktu untuk pulih dari kesalahan jadi pastilah perencanaan.

D: Rencanakan dengan benar. Saya telah menjadi tuan rumah Anda, David Bain. Anda dapat menemukan Sara di liip.ch. Sara, terima kasih banyak telah hadir di podcast The In Search SEO.

S: Terima kasih.

D: Dan terima kasih telah mendengarkan.