Analisis perubahan tautan situs saat migrasi

Buat peta redirect sebelum peluncuran

Peta redirect adalah bagian dari perpindahan yang sering diremehkan. Tujuan sangat penting. Sebelum Anda menganalisis data tautan situs setelah perpindahan, URL lama perlu memiliki tujuan yang jelas, karena itulah alamat yang sudah ditunjuk oleh tautan Anda.

Satu-ke-satu lebih baik daripada dump ke halaman utama

Mengirim ratusan URL lama yang tidak relevan ke halaman utama memberi sedikit informasi bagi mesin pencari dan pengunjung. Relevansi adalah kuncinya. Petakan setiap URL lama bernilai tinggi ke halaman baru terdekatnya, dan arahkan sisanya ke bagian yang masih sesuai dengan topik tersebut.

Ekspor URL lama beserta kode statusnya terlebih dahulu. Simpan file itu dengan aman. File itu adalah daftar periksa, dan menunjukkan halaman mana yang mendapatkan tautan.

Di mana halaman tidak memiliki kecocokan dekat, sebutkan dalam peta dan arahkan ke bagian terdekat, dengan catatan. Sel kosong menyembunyikan keputusan. Sel kosong di tabel adalah keputusan yang tidak diambil oleh siapa pun.

Ratakan rantai sebelum peluncuran

Redirect yang melewati dua aturan sebelumnya sebelum mencapai halaman baru menambah keterlambatan dan risiko. Rantai mudah terbentuk ketika migrasi kedua berada di atas migrasi pertama, jadi tinjau peta sebelum setiap pengalihan daripada mengasumsikan masih bersih. Setiap hop tambahan memiliki biaya. Minta setiap URL lama sekali setelah pengalihan dan konfirmasi bahwa itu menjawab dengan satu hop.

Perbaiki sejak awal. Perbaiki rantai dalam peta itu sendiri, bukan satu per satu setelah peluncuran, agar daftar tetap pendek.

Pertahankan jalur yang masih berfungsi

Mengubah struktur URL dalam desain ulang adalah kerugian yang paling dapat dihindari. Setiap perubahan pada jalur juga merupakan perubahan pada setiap tautan yang menunjuk ke sana, dan tautan-tautan itu berada di luar kendali Anda. Pertahankan apa yang berfungsi. Jika jalur masih berfungsi, pertahankan, dan ubah hanya apa yang dipaksa oleh perpindahan.

Lebih sedikit redirect, lebih sedikit kesalahan. Setiap jalur yang Anda pertahankan adalah tautan yang sama sekali tidak memerlukan redirect.

Jalur yang dipertahankan berarti baris anchor lama tetap menunjuk ke sesuatu yang berguna, yang berarti satu hal lebih sedikit untuk dibangun kembali di spreadsheet. Lebih sedikit pembangunan ulang di kemudian hari.

Apa yang diharapkan setelahnya

Mereka melakukan pekerjaan berat, dan 301 dari URL lama ke URL baru memungkinkan tautan lama tetap berfungsi. Mempertahankan satu redirect per URL lama, tanpa rantai di antaranya, adalah cara paling sederhana untuk menjaga nilai setiap tautan tetap utuh. Redirect. Rantai tiga atau empat hop memperlambat crawler dan sebaiknya diratakan.

Anchor text tidak berubah saat URL berpindah, karena teks tersebut berada di halaman yang menautkan. Yang berubah adalah jumlah tujuan: tabel halaman teratas Anda akan menunjukkan host lama memudar dan yang baru meningkat selama beberapa pembaruan bulanan. Tujuan bergeser secara perlahan.

Kejutan umum adalah menghapus platform lama terlalu cepat. Jangan. Squarespace, Wix, dan host serupa sering menyimpan aturan redirect, sehingga membatalkan langganan dapat menghapusnya, dan tautan kemudian menunjuk ke jalan buntu hingga Anda membangun kembali aturan di tempat lain.

Hreflang dan canonical juga perlu diperiksa. Ketidakcocokan sering terjadi. Setelah migrasi CRA ke Next.js, misalnya, situs sering berakhir dengan tag canonical yang tidak sesuai dengan set hreflang mereka, dan tautan terpecah di dua versi halaman.

Jika angka tidak cocok setelah perpindahan, periksa tabel pemecahan masalah sebelum mengasumsikan tautan hilang. Pembaruan bulanan saja menjelaskan banyak kesenjangan. Kesenjangan sering kali disebabkan oleh waktu.

Harapkan perbandingan bersih pertama sekitar dua pembaruan bulanan setelah peluncuran, dan tuliskan tanggal setiap pembaruan di spreadsheet Anda agar bulan yang datar tidak disalahartikan sebagai bulan yang macet. Beri waktu. Ahrefs atau Semrush dapat mengisi kesenjangan dengan crawler yang lebih segar jika Anda memerlukan bacaan sementara.

Perhatikan apa yang bergerak tanpa pemberitahuan peluncuran

Hari peluncuran memiliki daftar periksa, tetapi beberapa masalah muncul kemudian dan secara diam-diam. Mereka muncul di baris dan di indeks, lama setelah tim beralih ke pekerjaan lain. Mereka mudah terlewatkan.

Noindex yang ikut dengan build staging

Salinan staging yang dijauhkan dari pencarian dapat membawa pengaturannya ke situs live. Periksa tag meta robots dan header noindex apa pun pada crawler pertama, dan sampel halaman dari setiap bagian daripada hanya halaman utama. Sampel setiap bagian.

Template rusak terlebih dahulu. Jika seluruh bagian hilang dari indeks setelah peluncuran, lihat templatnya sebelum melihat kontennya.

Screenshot juga membantu. Simpan salinan pengaturan robots dari build staging juga. Ketika sesuatu hilang dari indeks, membandingkan dua set pengaturan membutuhkan waktu beberapa menit daripada sore hari.

Tautan fragmen yang terindeks

Tautan lompat seperti anchor daftar isi dapat muncul sebagai URL terpisah di hasil pencarian. Mesin pencari biasanya menggabungkan ini ke halaman utama, tetapi ketika tidak, konten yang sama dapat muncul di beberapa alamat. Mereka membagi sinyal dari halaman utama, dan mereka dapat terlihat seperti halaman duplikat dalam laporan cakupan. URL hash berkembang diam-diam.

Satu versi, satu alamat. Tag canonical yang menunjuk ke satu alamat sementara sitemap mencantumkan alamat lain mengirim sinyal campuran, dan laporan akan menunjukkan ketidakcocokan. Tetapkan satu versi canonical untuk setiap halaman dan konfirmasi bahwa sitemap mencantumkan versi yang sama.

Periksa laporan cakupan setelah peluncuran untuk URL yang memiliki hash di dalamnya, karena itulah yang berkembang diam-diam. Hash adalah biang keroknya.

Subdomain yang menjadi domain utama

Memindahkan situs dari subdomain staging ke domain utama membawa duplikat sendiri, karena kedua versi dapat tetap dapat diakses untuk sementara waktu. Tentukan host mana yang canonical sebelum peluncuran. Pilih host sejak awal.

Satu host, di mana saja. Ketika host berubah di satu tempat dan tidak di tempat lain, versi lama dapat terus mengumpulkan tautan selama berbulan-bulan tanpa disadari oleh siapa pun. Kemudian pertahankan sitemap, tag canonical, dan set hreflang apa pun yang menunjuk ke host tersebut.

Tautan do-follow yang tampak menghilang

Setelah desain ulang, baris do-follow di alat mungkin turun tajam, dan tebakan pertama adalah tautannya hilang. Bandingkan halaman teratas lama dengan yang baru sebelum menerima tebakan itu, lalu periksa apakah setiap alamat lama sekarang melakukan redirect dengan benar. Periksa sebelum panik.

Perbaiki yang itu terlebih dahulu. Tautan yang masih ada di halaman penaut tetapi menunjuk ke alamat mati adalah kasus yang harus diperbaiki terlebih dahulu.

Tetapkan tanggal sejak awal. Berikan tim tanggal tetap untuk perbandingan, agar tidak ada yang menjalankan pengambilan ulang setiap hari dan membaca noise sebagai berita.

Bekerja dengan developer selama perpindahan

Sebagian besar pekerjaan redirect jatuh pada developer, dan pemantauan jatuh pada siapa pun yang membaca spreadsheet. Menuliskan pembagian sebagai tabel pendek, dengan satu nama di setiap sel, sering kali cukup untuk menghentikan dua orang dari mengasumsikan tugas yang sama. Pisahkan peran itu di atas kertas sebelum peluncuran, agar tidak ada yang mengasumsikan orang lain yang mengawasi. Peran membutuhkan nama.

Berikan peta kepada developer, bukan daftar tugas

Daftar tugas memberi tahu developer apa yang harus dilakukan, sementara peta menunjukkan alamat lama mana yang pergi ke mana. Kirim tabel satu-ke-satu dengan kode status dan alasan untuk setiap baris, agar kasus tepi mendapatkan keputusan daripada tebakan. Keputusan mengalahkan tebakan.

Rencana pengujian datang terlebih dahulu. Minta rencana pengujian singkat yang dimulai dengan alamat lama dari file halaman teratas.

Sepakati siapa yang membaca file bulanan

Perbandingan bersih pertama datang sekitar dua pembaruan setelah peluncuran, dan file akan membutuhkan pembaca. Bacaan pertama setelah peluncuran biasanya bising, dan pembaca yang tahu hal itu akan menghindari bereaksi terhadap bulan tidak biasa tunggal. Namakan orang itu, hari mereka membukanya, dan spreadsheet tempat hasilnya masuk. Seseorang harus memilikinya.

Tanggal menyelesaikan pertanyaan. Menulis tanggal pembaruan di samping setiap file mengubah kekhawatiran tentang indeks yang macet menjadi fakta biasa tentang kalender. Bulan yang datar mudah disalahartikan sebagai bulan yang macet kecuali seseorang menulis tanggal pembaruan.

Minta orang itu menulis satu baris per pembaruan, bahkan ketika tidak ada perubahan, agar file terus mencatat. Satu baris setiap kali.

Rencanakan rollback sebelum peluncuran

Jika host baru merusak jalur kritis, tim membutuhkan cara kembali yang telah diuji sebelumnya. Tulis langkah-langkahnya, termasuk siapa yang dapat mengaktifkan sakelar dan bagaimana perilaku redirect saat dibatalkan. Latih sebelum peluncuran.

Tulis rollback. Rollback yang hanya ada di kepala satu orang bukan rencana.