Cara memindahkan domain tanpa menjatuhkan kedudukan carian anda

Menukar domain ialah salah satu daripada beberapa projek SEO yang mana kesilapan teknikal kecil boleh menjadi sangat ketara dengan sangat cepat. Ubah hala yang hilang, laluan rayapan yang disekat, atau kanonikal yang terlupa boleh menukar penjenamaan semula yang sepatutnya mudah menjadi berminggu-minggu turun naik kedudukan.

Sedikit pergerakan adalah normal. Enjin carian memerlukan masa untuk merayapi URL lama, menemui ubah hala, memproses isyarat, dan menempatkan domain baharu ke dalam indeks. Matlamatnya bukan untuk mengelakkan setiap penurunan. Matlamatnya ialah menjadikan migrasi itu membosankan: satu URL lama menunjuk kepada satu URL baharu yang setara, pelayan memberi respons dengan jelas, dan tiada perkara penting yang hilang.

Mulakan dengan inventori, bukan peraturan ubah hala

Kegagalan migrasi yang paling lazim ialah menganggapnya sebagai tugas konfigurasi pelayan. Bukan begitu. Ia ialah tugas seni bina maklumat yang kebetulan berakhir dengan konfigurasi pelayan.

Sebelum menyentuh DNS, bina senarai URL yang penting:

• URL yang menerima trafik organik
• URL dengan pautan balik luaran
• URL yang menukar, menjana prospek, atau menyokong kempen
• URL kanonikal yang kini berada dalam peta laman XML anda
• PDF, imej, dan fail boleh muat turun yang dipautkan secara luaran
• URL legasi bernilai tinggi yang mungkin tidak muncul dalam navigasi semasa

Untuk setiap URL lama, tetapkan destinasi pada domain baharu. Dalam kebanyakan kes, destinasi itu sepatutnya halaman yang sama dengan niat yang sama. Jika /pricing menjadi https://newdomain.com/pricing, itu mudah. Jika tiga halaman produk lama digabungkan menjadi satu panduan baharu, dokumentasikan keputusan itu dengan sengaja.

Elakkan pola malas: mengubah hala semuanya ke halaman utama baharu. Ia mudah, tetapi ia membuang kerelevanan. Enjin carian dan pengguna sama-sama menjangka destinasi itu menjawab keperluan yang sama seperti URL asal.

Kekalkan struktur URL jika boleh

Migrasi domain lebih mudah apabila laluan kekal stabil. Berpindah daripada oldsite.com/blog/example kepada newsite.com/blog/example jauh lebih bersih daripada menukar domain, CMS, slug, struktur folder, dan kandungan pada masa yang sama.

Kadangkala reka bentuk semula atau migrasi CMS menjadikan perubahan URL tidak dapat dielakkan. Jika begitu, pisahkan keputusan:

1. Apa yang berubah kerana domain berubah?
2. Apa yang berubah kerana struktur laman berubah?
3. Apa yang dipadam, digabungkan, atau ditulis semula?

Semakin banyak pemboleh ubah yang anda perkenalkan, semakin sukar untuk mendiagnosis masalah kemudian. Jika migrasi itu penting dan laman semasa berprestasi baik, pertimbangkan untuk memindahkan domain dahulu dan membuat reka bentuk semula kemudian.

Gunakan ubah hala kekal, satu lompatan

Untuk migrasi domain sebenar, gunakan ubah hala sisi pelayan 301 atau 308 daripada URL lama kepada padanan baharunya. Ubah hala sementara adalah untuk situasi sementara. Ubah hala JavaScript, meta refresh, dan ubah hala lembut ialah isyarat yang lebih lemah dan lebih mudah rosak.

Matlamat ubah hala anda mudah:

• Setiap URL lama yang penting mengembalikan ubah hala kekal.
• Setiap ubah hala pergi terus ke destinasi akhir.
• HTTP mengubah hala ke HTTPS dengan bersih.
• Varian www dan bukan www dikendalikan secara konsisten.
• Ubah hala tidak bergantung pada tingkah laku query-string yang rapuh melainkan perlu.

Rantaian yang buruk kelihatan seperti ini:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

Ia mungkin akhirnya mendarat pada halaman yang betul, tetapi ia perlahan, lebih sukar dirayapi, dan lebih berkemungkinan menyembunyikan kesilapan. Sasarkan satu lompatan daripada setiap varian lama ke URL baharu akhir.

Semasa mengesahkan tingkah laku, periksa respons HTTP sebenar dan bukannya mempercayai apa yang dipaparkan oleh pelayar. Panduan kami tentang menyahpepijat ubah hala dan pengepala HTTP dalam produksi berguna di sini kerana pelayar terlalu sopan: ia mengikuti rantaian dan menyembunyikan bahagian yang berselerak.

Sediakan DNS dan sijil sebelum pelancaran

DNS tidak memindahkan kedudukan secara langsung, tetapi DNS yang buruk boleh membuat migrasi kelihatan rosak. Rendahkan nilai TTL sebelum tetingkap pelancaran supaya perubahan tersebar dengan lebih boleh dijangka. Sahkan bahawa domain baharu mempunyai rekod yang betul untuk trafik web, e-mel, dan sebarang subdomain yang diperlukan.

Anda juga memerlukan sijil TLS yang sah untuk kedua-dua domain. Perkara ini mudah terlepas pandang. Domain lama masih perlu menyajikan ubah hala HTTPS selepas migrasi. Jika sijilnya tamat tempoh, pengguna dan perayap mungkin menemui amaran pelayar sebelum mereka sempat sampai ke laman baharu.

Jika perpindahan itu menjejaskan e-mel, jangan anggapnya sebagai perkara sampingan. Perubahan domain kerap merosakkan SPF, DKIM, DMARC, rekod MX, pautan penjejakan, dan mel transaksi. Untuk penyegaran tentang rekod yang penting, lihat panduan mesra pembangun kami tentang MX, SPF, DKIM, dan DMARC.

Semak kanonikal, pautan dalaman, dan peta laman

Selepas pelancaran, domain baharu sepatutnya berkelakuan seolah-olah ia sentiasa menjadi rumah kanonikal bagi kandungan tersebut.

Ini bermaksud:

• Tag kanonikal menunjuk kepada URL baharu, bukan domain lama.
• Pautan dalaman menggunakan domain baharu atau laluan relatif akar.
• Peta laman XML mengandungi hanya URL baharu akhir yang boleh diindeks.
• Anotasi hreflang, jika digunakan, merujuk kepada URL baharu.
• Open Graph, data berstruktur, dan pautan alternatif dikemas kini.
• Robots.txt tidak menyekat bahagian penting.

Jangan terbitkan peta laman yang penuh dengan URL lama dan mengharapkan ubah hala membersihkannya. Peta laman sepatutnya ialah senarai URL yang anda mahu diindeks. Selepas migrasi, itu bermaksud URL akhir pada domain baharu.

Perhatikan juga percanggahan kanonikal. Halaman yang mengubah hala daripada lama ke baharu tetapi mempunyai kanonikal yang menunjuk kembali ke domain lama menghantar isyarat bercampur. Enjin carian biasanya boleh mengurus sedikit ketidakselarasan, tetapi anda tidak sepatutnya meminta mereka berbuat demikian.

Jangan ubah semuanya pada hari pelancaran

Migrasi sudah cukup besar sebagai satu peristiwa. Jika boleh, elakkan menggabungkannya dengan pemangkasan kandungan besar-besaran, penulisan semula templat, perubahan navigasi, perubahan perenderan JavaScript, atau profil prestasi baharu.

Ini bukan tahyul. Ini disiplin penyahpepijatan. Jika kedudukan jatuh selepas pelancaran, anda perlu tahu sama ada puncanya pemetaan ubah hala, akses rayapan, kandungan yang berubah, perenderan yang lebih perlahan, data berstruktur yang hilang, atau sesuatu yang lain.

Pastikan pelancaran awal sedekat mungkin dengan laman lama secara praktikal. Setelah domain baharu stabil, lakukan perubahan editorial dan reka bentuk yang lebih besar dalam kelompok yang lebih kecil.

Beritahu enjin carian apa yang berubah

Dalam Google Search Console, sahkan kedua-dua domain lama dan baharu. Kemudian gunakan alat Change of Address apabila perpindahan itu ialah perubahan pada tahap domain dan kandungan berpindah ke domain baharu. Hantar peta laman baharu selepas pelancaran.

Ini tidak menggantikan ubah hala. Ia menyokongnya. Enjin carian masih memerlukan ubah hala yang boleh dirayapi dan berterusan untuk memahami pemetaan pada tahap URL.

Untuk Bing dan enjin carian lain, gunakan alat webmaster mereka jika tersedia. Kemas kini juga tempat yang anda kawal: profil sosial, penyenaraian perniagaan, destinasi iklan, pengaki e-mel, dokumentasi, pautan rakan kongsi, dan rujukan kanonikal dalam kandungan tersindiket.

Tidak semua pautan luaran akan dikemas kini, dan itu tidak mengapa. Tetapi pautan yang paling penting patut dikemas kini. Jika rakan kongsi utama, pasaran aplikasi, portal dokumentasi, atau halaman akhbar memaut ke domain lama, minta kemas kini.

Pantau perkara yang betul selepas pelancaran

Beberapa hari pertama selepas migrasi sepatutnya digunakan untuk pemantauan aktif, bukan meraikan.

Semak:

• Log pelayan untuk aktiviti rayapan pada domain lama dan baharu
• 404 dan ralat 5xx yang tidak dijangka
• Rantaian dan gelung ubah hala
• Status pengindeksan dalam Search Console
• Penemuan dan pemprosesan peta laman
• Halaman pendaratan organik dan pola pertanyaan
• Laluan penukaran yang bergantung pada URL lama
• Penapis analitik dan pengecualian rujukan

Jangkakan hingar pelaporan. Sesetengah alat analitik menganggap domain baharu sebagai harta baharu melainkan dikonfigurasikan dengan betul. Sesetengah papan pemuka membandingkan trafik domain lama dengan trafik domain baharu dan membuat migrasi kelihatan lebih buruk daripada keadaan sebenar.

Keterlihatan carian boleh turun naik selama beberapa minggu. Apa yang anda tidak mahu ialah pola yang mana URL lama bernilai tinggi dirayapi berulang kali tetapi tidak diubah hala dengan betul, atau halaman baharu ditemui tetapi ditandakan sebagai pendua domain lama.

Prestasi juga tidak harus diabaikan. Jika domain baharu dilancarkan dengan templat yang lebih berat, cache yang rosak, atau aset yang tidak dioptimumkan, pengguna mungkin merasai migrasi sebagai kelembapan. Jika anda menggunakan Lighthouse sebagai sebahagian daripada semakan anda, bacalah dengan keutamaan dalam fikiran; tulisan kami tentang cara membaca laporan Lighthouse tanpa panik menerangkan cara memisahkan isu yang bermakna daripada hingar.

Kekalkan domain lama untuk masa yang lama

Jangan biarkan domain lama tamat tempoh selepas migrasi “berfungsi.” Kekalkan pendaftarannya, pastikan sijil sah, dan biarkan ubah hala berjalan selama yang mungkin. Dalam amalan, itu sering bermaksud bertahun-tahun.

Pautan lama terus wujud dalam hantaran blog, penanda halaman, dokumentasi, PDF, e-mel, dan hantaran sosial. Ubah hala ialah jambatan antara jejak sejarah itu dengan domain baharu. Mematikannya terlalu awal memutuskan laluan pengguna dan membazirkan isyarat yang terkumpul.

Simpan juga salinan peta ubah hala dan nota pelancaran anda. Enam bulan kemudian, apabila seseorang bertanya mengapa URL legasi berkelakuan dengan cara tertentu, anda akan bersyukur kerana anda mendokumentasikannya.

<!-- tool-cta:start -->

💡 Cuba ini: Selepas cutover, jejak URL lama anda melalui Redirect Checker untuk mengesahkan bahawa setiap satu diselesaikan dalam satu hop 301 ke halaman baharu yang betul.

<!-- tool-cta:end -->

Senarai semak migrasi yang munasabah

Sebelum pelancaran:

• Sahkan kedua-dua domain dalam Search Console.
• Rayapi laman semasa dan eksport URL penting.
• Bina peta ubah hala satu-ke-satu.
• Rendahkan TTL DNS.
• Sediakan sijil TLS untuk domain lama dan baharu.
• Kemas kini kanonikal, pautan dalaman, hreflang, data berstruktur, dan peta laman.
• Uji ubah hala dalam staging atau persekitaran terkawal.

Pada hari pelancaran:

• Lancarkan ubah hala.
• Sahkan tingkah laku HTTP ke HTTPS.
• Uji sampel URL penting daripada setiap jenis templat.
• Hantar peta laman baharu.
• Gunakan alat Change of Address jika sesuai.
• Pantau ralat pelayan, gelung ubah hala, dan sumber yang disekat.

Selepas pelancaran:

• Pantau ralat rayapan dan laporan pengindeksan.
• Kemas kini pautan luaran penting jika anda boleh.
• Bandingkan trafik mengikut niat halaman pendaratan, bukan hanya jumlah domain.
• Kekalkan ubah hala secara aktif selama-lamanya.
• Tangguhkan reka bentuk semula atau eksperimen kandungan yang tidak berkaitan sehingga perpindahan stabil.

Migrasi domain bukan tanpa risiko, tetapi ia boleh diurus. Kedudukan biasanya terjejas apabila migrasi menghantar isyarat yang tidak jelas: ubah hala yang hilang, kandungan yang berubah, kanonikal yang bercanggah, perayap yang disekat, atau domain lama yang terlupa. Beri enjin carian dan pengguna peta yang jelas, dan perpindahan itu menjadi jauh kurang dramatik.