penutupan situs web

Penutupan situs web  Baru-baru ini, saya telah diminta oleh merek global utama untuk mendukung proyek penutupan situs web. Perusahaan tidak menghasilkan cukup uang untuk menopang dirinya sendiri dan menghasilkan keuntungan. Merek global yang sama juga memiliki beberapa perusahaan serupa lainnya di ceruk pasar.

Mematikan situs web itu mudah, tetapi ketika Anda harus melakukannya bersama dengan pengalihan, apa dan bagaimana Anda melakukannya?

Salah satu persyaratannya adalah membuat penutupan berjalan lancar dan mengalihkan separuh lalu lintas ke satu situs web, dan separuh lainnya ke situs lainnya. Faktor penentunya adalah jenis produk.
Mengapa disebut ‘migrasi terpisah’?

Migrasi situs web adalah proses prosedural terperinci yang sering kali melibatkan perubahan domain dan URL, perancangan ulang, atau platform ulang. Meskipun membosankan bahkan di situs kecil, masalah yang dapat Anda hadapi hanya akan bertambah besar dengan setiap halaman tambahan situs.

Sekarang, bayangkan sebuah situs dengan ribuan halaman atau produk yang perlu Anda sertakan dalam migrasi. Tambahkan kerumitan karena harus memigrasikan bagian dari satu situs di antara dua situs lainnya.

Bagaimana Anda menangani ribuan halaman dan produk ketika Anda harus memindahkannya ke dua situs web yang berbeda dan sudah ada?

Sebelum titik ini, saya tidak pernah melakukan migrasi terpisah, tetapi saya memiliki gambaran umum tentang di mana harus memulai dan bagaimana memulai prosesnya.

Sayangnya, migrasi lebih dari sekadar pengalihan sederhana. Setiap migrasi memiliki kesulitannya sendiri, tetapi yang satu ini sedikit lebih mudah karena hanya menyertakan pengalihan URL dari halaman sumber ke halaman tujuan.

Namun, prosesnya akan lebih melelahkan untuk migrasi normal atau platform ulang yang mencakup:

  • Metadata
  • Isi
  • Judul
  • 404 kesalahan
  • Pengalihan yang ada
  • Gambar-gambar
  • Dll.

Dalam hal jaminan kualitas (QA), pengalihan URL dasar lebih mudah untuk menguji dan memverifikasi bahwa semuanya berfungsi dengan baik. Namun, kami masih melalui beberapa fase untuk membuat proses berjalan lancar, dimulai dengan “penemuan.”

Fase penemuan

Saya tahu bahwa tantangan terbesar saya adalah mengidentifikasi halaman yang ada di ketiga situs web. Untuk privasi, kekayaan intelektual, dan alasan hukum lainnya, sebut saja Sumber, Tujuan1 dan Tujuan2.

Saya memulai dengan crawling Screaming Frog yang akan menelusuri situs web sumber, mengidentifikasi semua halaman yang dapat diindeks. Dan untuk proses pengambilan keputusan yang lebih mudah, saya harus menarik data Google Analytics dan Google Search Console menggunakan API.

Tapi saya masih kehilangan sepotong data. Saya tidak memiliki akses API Semrush sehingga harus menarik data backlink secara terpisah. Setelah Anda memiliki daftar URL yang perlu Anda kerjakan, pastikan untuk menarik data backlink juga.

Anda dapat mengubah ini ke Ahrefs atau sumber lain yang Anda inginkan. Intinya disini adalah untuk mengetahui betapa pentingnya sebuah URL dalam hal backlink.

Fase pengaturan

Sekarang setelah saya mengumpulkan semua URL saya dari situs sumber tempat saya bekerja, saya memerlukan beberapa hal untuk membuat prosesnya lebih lancar:

  • Bersihkan daftar untuk mengecualikan parameter URL atau duplikat lainnya.
  • Identifikasi pemilik halaman (ke situs mana yang harus dituju – Tujuan1 atau Tujuan2).
  • Apa prioritas halaman? (Apakah itu memiliki lalu lintas langsung? Apakah peringkatnya di Google? Apakah itu memiliki tautan balik?)
  • Apa kode status halaman? (Apakah itu 200 atau 301 atau 404?)

Awalnya, saya membagikan file dengan semua pihak dan pemilik yang terlibat, ini memungkinkan mereka untuk memilih URL milik tujuan tertentu. Ingatlah bahwa setiap URL mungkin memiliki mitra pemiliknya di setiap situs web tersebut.

Misalnya, produk tertentu ada di situs web Sumber dan Tujuan, jadi pengalihan terakhir harus ke URL Tujuan dan halaman yang sama.

Anda juga dapat memilih untuk meneruskan parameter. Jadi pastikan Destination diisi dengan benar.

Dalam tugas saya, saya bekerja dengan 18.000 URL, dan setelah memfilter dan menghapus yang tidak penting, saya mendapatkan 11.000.

Pengujian

Dalam kebanyakan kasus, Anda harus menguji ini di server sementara. Ini mungkin atau mungkin tidak memiliki pengaturan URL Sumber Anda yang sebenarnya, misalnya, mungkin dev.source.com bukan source.com. Anda dapat dengan mudah mengganti URL sumber Anda untuk sementara, atau menggunakan duplikat file. Saat menguji, pastikan Anda menggunakan konfigurasi yang sama dengan yang Anda gunakan selama penemuan. Memperbarui ekspor ScreamingFrog di lembar SF-Internal ALL akan secara otomatis menyesuaikan data di lembar URL dan menunjukkan kepada Anda yang memiliki URL tujuan yang gagal.

Tapi apa yang salah?

Setiap migrasi adalah pengalaman belajar. Jika Anda pernah melakukan migrasi, Anda tahu bahwa satu kesalahan dapat menyebabkan kesalahan 404, gambar tidak di muat, atau masalah lainnya. Untungnya, masalah terbesar yang kami miliki adalah dengan cache sisi server global yang memengaruhi proses pengujian.

QA migrasi ini di dasarkan pada dua hal:

  • Penargetan.
  • Memeriksa pengalihan 301.

Kami menghabiskan lebih banyak waktu pada fase penemuan daripada migrasi itu sendiri.

Satu hal yang kami ambil dari migrasi khusus ini adalah Anda benar-benar perlu mempelajari seluk beluk sebuah situs. Di butuhkan banyak waktu untuk bekerja dengan tim besar dan mempelajari siapa pemilik setiap halaman dan bagaimana mengelolanya (halaman atau pemilik halaman).

Tidak ada yang secara khusus menghambat migrasi, tetapi kami mengaitkan ini dengan banyaknya waktu yang di habiskan dalam fase penemuan. Jika kita tidak mendedikasikan banyak waktu untuk fase ini, itu bisa berakhir buruk.

Penemuan memungkinkan kami untuk siap jika ada masalah selama migrasi sehingga kami dapat memanggil orang yang tepat dan memperbaiki kesalahan di tempat. Menggunakan template sangat membantu kami.

Templat

Templat migrasi terpisah ini akan di perbarui saat proyek baru dan serupa datang kepada saya. Harap buat salinan Anda sendiri daripada meminta akses. Juga, tingkatkan atau sarankan peningkatan saat Anda mengerjakannya.

Kesimpulan

Migrasi kami berhasil, kami membutuhkan 5 menit untuk di tayangkan (termasuk membersihkan semua cache global) dan hanya 15 menit untuk menjalankan perayapan daftar untuk mengidentifikasi semua pengalihan berfungsi dengan benar.

Mendefinisikan “sukses” adalah sesuatu yang di butuhkan setiap migrasi. Di sebagian besar migrasi, sepertinya selalu ada yang tidak beres. Bahkan ketika Anda menghabiskan waktu ekstra dalam fase penyiapan, selalu ada detail kecil yang terlewatkan.

Keberhasilan migrasi ini di akui lebih mudah daripada yang di lakukan di masa lalu karena satu-satunya QA nyata yang di perlukan adalah memastikan pengalihan berfungsi. Otomasi membantu di sini untuk memverifikasi bahwa semua pengalihan berhasil.

Namun, itu hanya sebagian dari cerita. Kami juga menunggu hal berikut sebelum menganggap proyek ini sebagai kemenangan:

  • Halaman situs sumber mulai perlahan di-de-index.
  • Peringkat halaman tujuan mulai meningkat.

Kami memang mengalami masalah dengan cache sisi server yang memengaruhi proses verifikasi dan perlu di bersihkan beberapa kali. Tembolok global sepertinya selalu menimbulkan masalah selama migrasi, jadi ini pasti sesuatu yang perlu di pertimbangkan saat mengerjakan migrasi reguler atau terpisah di masa mendatang.

Dalam satu hari kami mulai melihat pembaruan di hasil penelusuran Google dan banyak laman tujuan melonjak karena pengalihan yang di targetkan. Penutupan situs web

By AKDSEO