Enam kesalahan migrasi yang membuat backlink klien ter stranded
Kebanyakan kehilangan link dalam file klien bukan karena penalti. Itu adalah URL lama yang berhenti merespons saat situs berpindah, dan laporan top-page menunjukkannya dalam hitungan menit.
Tim riset LinkSkimmr ·
Ke mana link pergi saat situs berpindah
Link mengarah ke URL, bukan ke situs. Ubah URL dan setiap link ke URL lama memerlukan forward.
Hal ini terdengar jelas sebelum migrasi dilakukan. Banyak tim mengetahui aturan ini. Migrasi WordPress, beralih dari www ke domain tanpa www, atau struktur kategori baru yang live pada hari Jumat dengan catatan bahwa redirect akan menyusul. Saat Anda memeriksa backlink situs setelah migrasi seperti itu, pertanyaannya bukan berapa banyak link yang ada, tetapi berapa banyak yang masih mengarah ke halaman yang live, dan kolom lima dari rutinitas sepuluh menit menjawabnya.
Panduan Google sendiri untuk migrasi adalah pemetaan satu-ke-satu dari URL lama ke URL baru. Redirect 301 di sisi server melakukan pekerjaan ini. Biarkan berjalan selama yang Anda bisa. Untuk perubahan domain, alat Change of Address di Search Console adalah langkah tambahan. Pemetaan masih rusak dengan cara yang dapat diprediksi, dan Screaming Frog atau Ahrefs Site Audit akan menyoroti sebagian besar dari mereka.
Alat membantu di sini: Search Console menunjukkan crawl dan cakupan di sisi Google, Screaming Frog mencantumkan rantai redirect dari hasil crawl, dan panggilan top-page kami menunjukkan URL mana yang membawa link. Tidak ada satu pun dari mereka yang memberikan gambaran lengkap, dan kombinasi ini memakan waktu kurang dari satu jam pada situs kecil.
Kesalahan, gejala, perbaikan
Kesalahan
Cara hal ini muncul dalam data
Perbaikan
Semuanya di-redirect ke halaman beranda
Halaman yang paling banyak ditautkan semuanya hilang; beranda adalah satu-satunya URL yang tersisa
Petakan setiap URL lama ke halaman baru terdekatnya
www dan domain tanpa www keduanya merespons 200
Link yang sama terbagi di dua host
Pilih satu host, 301 yang lainnya
Rantai redirect tiga hop atau lebih
Halaman utama hanya terpecahkan setelah beberapa lompatan
Arahkan URL lama langsung ke URL akhir
302 digunakan untuk perpindahan permanen
URL lama terus muncul sebagai halaman yang ditautkan
Beralih ke 301 setelah perpindahan selesai
Halaman 'tentang' lama dihapus, tidak di-forward
URL yang banyak ditautkan mengembalikan 404
Forward ke halaman 'tentang' yang baru
Struktur kategori dibangun ulang tanpa peta
Puluhan URL yang ditautkan mengembalikan 404
Ekspor URL lama terlebih dahulu, petakan dalam spreadsheet
Temukan nilai yang ter stranded dalam dua panggilan
Ambil halaman yang paling banyak ditautkan, lalu uji setiap URL di browser atau dengan curl -I. Apa pun yang bukan 200 bersih atau 301 tunggal masuk ke dalam daftar.
bash
# which old URLs carry the links (2 credits, billed once)
curl "https://linkskimmr.com/api.php?action=toppages&q=clientsite.com&per=200&key=sk_live_..."
# then, for each URL you care about
curl -sI https://clientsite.com/old-page | head -5
Urutan perbaikan yang akan kami gunakan
1
Perbaiki host terlebih dahulu
Satu host kanonik, yang lain 301 ke sana. Ini membutuhkan waktu beberapa menit dan menyentuh setiap link sekaligus.
2
Petakan dua puluh URL teratas
Dua puluh halaman yang banyak ditautkan biasanya memegang sebagian besar nilai. Petakan itu secara manual, satu per satu.
3
Ratakan rantai
Ganti setiap jalur multi-hop dengan satu hop ke URL akhir.
4
Periksa kembali bulan depan
Indeks kami diperbarui sekitar sebulan sekali, jadi berikan satu siklus sebelum Anda menyatakan perbaikan berhasil atau gagal.
Batas yang layak disebutkan
Memperbaiki redirect mengembalikan nilai link ke halaman yang live. Ini tidak menjanjikan peringkat, dan tidak dapat memulihkan link yang dihapus di sumber. Catat keduanya dalam file klien.
Pertanyaan redirect yang paling sering kami dengar
Bisakah saya hanya meredirect halaman lama ke halaman 'tentang' yang baru?
Ya, ketika halaman baru melayani tujuan yang sama. 301 dari URL lama ke ekuivalen terdekat menjaga agar link tetap berguna. Mengirimkan setiap URL mati ke halaman beranda bekerja dengan buruk karena tujuan tidak lagi sesuai dengan yang dijanjikan link.
Berapa banyak redirect 301 yang terlalu banyak pada satu situs?
Jumlahnya lebih penting daripada bentuk setiap jalur. Rantai panjang membuang upaya crawl dan lebih sering rusak, jadi pastikan setiap URL lama hanya satu hop dan simpan peta lengkap dalam spreadsheet yang dapat diaudit.
Bagaimana saya mengirim www ke versi non-www?
Pilih satu host sebagai kanonik, lalu tambahkan 301 di seluruh situs dari host lainnya ke sana di server atau penyedia DNS. Uji kedua versi dengan curl -I, dan konfirmasi bahwa link dalam daftar top-page mendarat di host yang dipilih.
Apa yang harus diperiksa minggu saat migrasi live
Jika Anda memeriksa backlink situs minggu saat migrasi, periksa peta sebelum angka. Peta menentukan apakah angka dapat pulih sama sekali.
Crawl sitemap lama, bukan hanya yang baru
Sitemap lama masih mencantumkan URL yang mendapatkan tempat mereka sejak awal. Crawl terhadap situs live, dan setiap baris yang mengembalikan 404 atau rantai redirect menjadi baris dalam peta.
Simpan hasil crawl dengan tanggal dalam namanya. Crawl kedua sebulan kemudian menunjukkan perbaikan mana yang bertahan dan forward mana yang menghilang secara diam-diam.
Bandingkan halaman teratas sebelum dan sesudah
Simpan daftar top-page sebelum migrasi, lalu jalankan panggilan lagi setelah situs baru stabil. Dua daftar URL yang ditautkan harus sejalan setelah peta diterapkan, dan baris yang tidak sejalan adalah daftar tugas Anda.
Setiap panggilan berharga 2 kredit, jadi perbandingannya murah. Biayanya ada pada pemetaan, bukan pada data.
Cari aturan staging yang tertinggal
Aturan yang memblokir crawler dapat bertahan setelah peluncuran tanpa disadari. Periksa robots.txt dan tag noindex apa pun pada template yang membawa halaman paling banyak ditautkan Anda, sebelum Anda menyatakan migrasi selesai.
Satu baris dalam file klien sudah cukup: template mana yang Anda periksa, dan pada hari apa. Tulis pemilik setiap forward di sebelahnya, karena forward yang tidak dapat dijelaskan oleh siapa pun adalah yang akan dihapus dalam redesign berikutnya.
Kode redirect mana yang cocok untuk perpindahan permanen
Kode adalah pilihan kecil dengan efek besar pada pesan yang Anda kirimkan. Crawler membaca kode status sebelum membaca apa pun di halaman lama.
Mengapa 301 cocok untuk perpindahan akhir
301 menyatakan bahwa perpindahan bersifat permanen. 302 menyatakan bahwa alamat lama mungkin kembali, yang merupakan pesan yang salah untuk perpindahan yang final. Gunakan 302 hanya saat pengujian sementara benar-benar berjalan.
Setelah perpindahan stabil, ubah semua forward sementara menjadi 301. Meninggalkan 302 selama bertahun-tahun adalah salah satu cara sunyi untuk menjaga perpindahan setengah selesai.
Mengapa 302 diikuti oleh 301 menjadi salah
302 yang meneruskan ke URL kedua, yang kemudian mengirim 301, menciptakan dua hop dan sinyal campuran. Mesin pencari biasanya dapat mengikuti rantai, tetapi rantai lebih lambat, dan lebih mudah rusak saat seseorang mengedit aturan.
Runtuhkan menjadi satu 301 yang mengarah langsung ke alamat akhir. Satu hop lebih mudah diuji, lebih mudah dijelaskan kepada klien, dan lebih mudah dijaga agar tetap hidup.
Cara meredirect URL dengan parameter kueri
URL lama dengan string kueri umum setelah perubahan CMS. Katakan alamat lama adalah halaman produk dengan parameter warna. Putuskan apakah parameter mengubah konten. Jika ya, peta URL yang diparameterkan ke halaman baru yang sesuai; jika tidak, satu aturan yang menghapus parameter dapat melayani halaman.
Uji beberapa URL yang diparameterkan secara manual setelah aturan live. Aturan yang berfungsi untuk jalur biasa masih dapat mengabaikan string kueri, dan link yang membawa parameter adalah yang akan Anda lewatkan.
Tiga forward yang terlihat seperti perbaikan
Beberapa forward lulus pemeriksaan status dan tetap kehilangan nilai. Halaman merespons dengan 301, tetapi tujuannya salah untuk orang dan crawler yang mengikuti link.
Rute pengalihan (redirect loop)
Dua aturan yang saling mengirim kembali muncul di browser sebagai loop, dan sebagian besar alat menyerah setelah beberapa hop. Uji URL lama, hitung hop dan perbaiki aturan yang mengarah kembali ke tempat asalnya.
Loop adalah masalah termudah untuk dilihat dan termudah untuk dibiarkan selama seminggu. Perbaiki pada hari Anda menemukannya, dan hitung hop dengan curl -sIL agar Anda membaca setiap baris status, bukan hanya yang terakhir.
Forward ke layar masuk
Halaman lama yang banyak ditautkan yang meneruskan ke formulir login memberikan pengunjung tembok alih-alih konten yang dijanjikan link. Katakan Anda meneruskan panduan bekas ke halaman masuk, yang kemudian memantul ke login pihak ketiga. Tidak ada yang membantu link dalam jalur itu.
Teruskan ke halaman publik yang sesuai dengan apa yang dibahas link. Jika tidak ada halaman seperti itu, 404 bersih lebih jujur daripada forward yang tidak mengarah ke mana pun yang berguna.
Contoh kerja, hipotetis
Bayangkan klien yang berpindah dari satu tema blog ke tema lain. Angka contoh saja.
Katakan laporan top-page mencantumkan 140 URL dengan link sebelum migrasi, dan 90 di antaranya mengembalikan 404 setelahnya karena pola permalink baru memindahkan folder tanggal. Memetakan dua puluh yang paling banyak ditautkan dari itu secara manual dapat memulihkan sebagian besar nilai yang ditunjuk pada sore hari, dan tabel ambang batas memberi tahu Anda cara menggambarkan perubahan kepada klien.
Peta yang sama adalah jawaban terbaik ketika klien bertanya apa yang berubah. Tunjukkan dua puluh URL yang dipetakan dengan alamat lama, alamat baru, dan kode status untuk masing-masing. Tabel meyakinkan. Dua puluh baris lebih meyakinkan daripada ringkasan apa pun, dan tabel berfungsi ganda sebagai daftar periksa untuk putaran berikutnya.
