Panduan Lengkap Migrasi Server: Pindah Hosting Tanpa Kehilangan Data & SEO

Migrasi server adalah proses pemindahan fail laman web, pangkalan data, akaun e-mel, rekod DNS, dan tetapan aplikasi secara terancang dari pelayan lama ke pelayan baharu. Untuk memindahkan laman web tanpa kehilangan data, kaedah asasnya adalah seperti berikut: ambil sandaran penuh terlebih dahulu, sediakan pelayan baharu dengan versi perisian yang sama atau lebih terkini, pindahkan fail dan pangkalan data, lakukan ujian menggunakan fail hosts atau URL sementara, ubah hala DNS dengan nilai TTL yang rendah, dan selepas migrasi, periksa log, borang, aliran pembayaran, penghantaran e-mel, dan isyarat SEO.

Proses migrasi server bukanlah sekadar kerja salin dan tampal biasa. Terutamanya untuk WordPress, WooCommerce, Laravel, aplikasi PHP tersuai, portal berita dengan trafik tinggi, atau perniagaan yang menggunakan e-mel korporat, migrasi yang silap boleh mengakibatkan kehilangan pesanan, aksara bahasa Melayu yang rosak, ralat 500, amaran SSL, gangguan e-mel, dan penurunan keterlihatan enjin carian. Oleh itu, pelan migrasi mesti dilaksanakan dengan senarai semak teknikal dan pelan pemulihan kecemasan.

Dalam panduan ini, kami akan membincangkan langkah demi langkah cara menukar hosting atau pelayan anda selaras dengan jangkaan prestasi dan SEO 2026. Kami juga akan menyentuh pelbagai senario seperti cPanel, Plesk, VPS, pelayan awan, dan migrasi manual; serta berkongsi cadangan praktikal untuk tempoh DNS, skop sandaran, keserasian pangkalan data, pemasangan SSL, dan pemeriksaan SEO selepas migrasi.

Bilakah Migrasi Server Diperlukan?

Keperluan untuk memindahkan laman web ke pelayan baharu biasanya timbul daripada keperluan prestasi, keselamatan, kos, atau skalabiliti. Sebagai contoh, laman web korporat dengan 5,000 pelawat bulanan mungkin berfungsi dengan lancar di hosting kongsi, manakala laman e-dagang dengan 20,000 pelawat harian mungkin mengalami isu had CPU, pertanyaan pangkalan data yang perlahan, dan masa tamat pada halaman pembayaran. Pada ketika ini, pakej hosting yang lebih berkuasa, VPS, atau infrastruktur awan adalah pilihan yang lebih baik.

Isyarat umum yang menunjukkan keperluan migrasi server adalah:

• Masa muat halaman melebihi 3 saat dan metrik Core Web Vitals semakin merosot.
• Had penggunaan CPU, RAM, inode, atau ruang cakera kerap penuh dalam panel hosting.
• Keperluan versi terkini untuk komponen seperti PHP, MySQL, MariaDB, Node.js, atau ionCube.
• Kerap menghadapi masalah pembaharuan SSL, penghantaran e-mel, atau pengurusan DNS.
• Kualiti sokongan, tahap sandaran, atau keselamatan di penyedia semasa yang tidak memuaskan.
• Trafik laman web meningkat secara mendadak semasa kempen, iklan, atau musim perayaan.

Jika laman web anda sedang berkembang dan menghampiri had pakej semasa, adalah lebih selamat untuk membuat pelan migrasi terkawal daripada terpaksa berpindah secara tergesa-gesa ketika krisis. Bergantung pada keperluan anda, anda boleh membandingkan pilihan di pakej hosting web, penyelesaian VPS, atau hosting korporat untuk memilih infrastruktur yang tepat.

Persediaan Pra-Migrasi: Fasa Paling Kritikal

Kebanyakan projek migrasi yang mengalami kehilangan data gagal bukan semasa pemindahan, tetapi disebabkan kekurangan persediaan. Sebelum memulakan migrasi, inventori laman web semasa mesti disenaraikan, dan data yang akan dipindahkan serta perkhidmatan yang sensitif terhadap gangguan mesti dikenal pasti dengan jelas.

1. Senaraikan Inventori Laman Web

Langkah pertama ialah mencipta peta teknikal laman web. CMS atau rangka kerja yang digunakan, versi PHP, jenis pangkalan data, saiz cakera, akaun e-mel, tugas cron, rekod DNS, sijil SSL, pengalihan khas, dan integrasi pihak ketiga mesti dicatatkan. Sebagai contoh, untuk laman WordPress, memindahkan folder wp-content sahaja tidak mencukupi; peraturan .htaccess, tetapan wp-config.php, awalan jadual pangkalan data, pemalam cache, dan fail media juga mesti diperiksa.

Untuk laman e-dagang pula, infrastruktur pembayaran, integrasi penghantaran, penyegerakan stok, sambungan ERP, perkhidmatan SMTP, dan URL webhook mesti diperiksa secara berasingan. Jika pesanan tidak diterima selepas migrasi, masalahnya selalunya bukan pada pemindahan fail, tetapi pada sekatan IP API yang terlupa atau peraturan keselamatan yang terikat pada pelayan lama.

2. Ambil dan Sahkan Sandaran Penuh

Dalam proses migrasi server, mengambil sandaran sahaja tidak mencukupi; kebolehpulihan sandaran tersebut juga mesti disahkan. Sandaran penuh harus merangkumi komponen berikut:

• Fail laman web: public_html, folder aplikasi, direktori muat naik, fail tema dan pemalam.
• Pangkalan data: MySQL, MariaDB, PostgreSQL, atau pangkalan data lain yang digunakan oleh aplikasi.
• Data e-mel: peti mel, pengalihan, penapis, tetapan autoresponder.
• Rekod DNS: Rekod A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC.
• Konfigurasi: fail .htaccess, nginx.conf, php.ini, cron job, fail environment.
• Sijil SSL dan peraturan keselamatan khas.

Sebagai pendekatan praktikal, ambil sekurang-kurangnya dua salinan sandaran sebelum migrasi: satu simpan di pelayan semasa, satu lagi di lokasi berbeza. Untuk laman web yang besar, rsync boleh digunakan untuk sandaran fail, dan mysqldump atau alat sandaran panel untuk pangkalan data. Untuk pangkalan data melebihi 10 GB, sandaran termampat dan berpecah mungkin lebih selamat daripada satu fail dump tunggal.

3. Rendahkan Nilai TTL DNS Sebelum Migrasi

Untuk penyebaran DNS yang lebih pantas, adalah amalan baik untuk merendahkan nilai TTL 24 jam sebelum proses migrasi. Contohnya, jika nilai TTL ialah 14400 saat, sesetengah pengguna mungkin terus melawat pelayan lama selama berjam-jam. Merendahkan nilai TTL kepada 300 saat sebelum migrasi menjadikan peralihan DNS lebih terkawal. Selepas migrasi selesai dan semuanya disahkan, TTL boleh dinaikkan semula kepada 3600 atau 14400 saat.

Menguruskan DNS domain anda dengan teratur secara langsung mempengaruhi kejayaan migrasi. Untuk konfigurasi domain dan DNS, anda boleh merujuk kepada panduan di semakan domain dan pengurusan domain.

Perbandingan Kaedah Migrasi Server

Kaedah migrasi yang paling tepat tidak sama untuk setiap laman web. Laman web korporat kecil boleh dipindahkan dengan mudah melalui panel, manakala laman e-dagang dengan trafik tinggi mungkin memerlukan penyegerakan berperingkat dan mod penyelenggaraan.

Apabila memilih infrastruktur baharu, hanya melihat ruang cakera adalah mengelirukan. Kriteria seperti bilangan pekerja PHP, teras CPU, RAM, cakera NVMe, kekerapan sandaran, lokasi pusat data, sokongan LiteSpeed atau Nginx, WAF, dan perlindungan DDoS juga menentukan prestasi. Oleh itu, beralih kepada pakej termurah tanpa analisis keperluan mungkin menyebabkan keperluan untuk migrasi semula dalam masa yang singkat.

Langkah Demi Langkah: Cara Melakukan Migrasi Server

Langkah 1: Sediakan Pelayan Baharu

Pada pelayan baharu, sistem operasi, pelayan web, versi PHP, perkhidmatan pangkalan data, dan modul yang diperlukan mesti dipasang. Untuk WordPress, PHP 8.2 atau 8.3, MariaDB terkini, OPcache, dan nilai memory_limit yang sesuai adalah disyorkan. Untuk rangka kerja seperti Laravel, Composer, cron, queue worker, dan keizinan storage mesti dikonfigurasikan secara berasingan. Jika pemalam PHP yang berfungsi di pelayan lama tiada di pelayan baharu, laman web mungkin menunjukkan skrin putih atau ralat 500 selepas dipindahkan.

Dari segi keselamatan, polisi port SSH, kata laluan yang kuat, firewall, imbasan malware, dan kemas kini automatik harus dikonfigurasikan. Membina asas keselamatan semasa pelayan baharu masih kosong sebelum migrasi adalah lebih mudah daripada campur tangan kemudian. Jika anda memerlukan SSL, pastikan anda memasukkan topik pemasangan sijil SSL ke dalam pelan migrasi anda.

Langkah 2: Pindahkan Fail

Untuk pemindahan fail, FTP, SFTP, SSH, rsync, atau sandaran panel boleh digunakan bergantung pada saiz laman web. Untuk laman web kecil, membuat arkib termampat dan mengekstraknya di pelayan baharu sudah memadai. Untuk laman web besar, adalah disyorkan untuk mengambil salinan pertama dengan rsync dan melakukan penyegerakan kali kedua sejurus sebelum pertukaran DNS. Kaedah ini menjimatkan masa, terutamanya untuk laman web yang folder muat naiknya sentiasa berubah.

Selepas pemindahan fail, periksa keizinan. Secara umum, folder berfungsi dengan keizinan 755 dan fail dengan 644; namun, keperluan setiap aplikasi mungkin berbeza. Fail sensitif seperti wp-config.php, .env, atau yang serupa tidak sepatutnya boleh dibaca oleh semua orang. Juga, pastikan fail tersembunyi seperti .htaccess dan .user.ini telah disalin.

Langkah 3: Pindahkan Pangkalan Data

Pemindahan pangkalan data adalah bahagian paling sensitif untuk mencegah kehilangan data. Pertama, ambil dump dari pelayan lama, kemudian cipta pangkalan data dan pengguna di pelayan baharu. Set aksara sebaiknya ditetapkan kepada utf8mb4. Untuk mengelakkan aksara bahasa Melayu rosak, struktur collation yang sama mesti dikekalkan semasa eksport dan import.

Untuk laman web yang menjana data masa nyata seperti WooCommerce atau sistem keahlian, mod penyelenggaraan boleh digunakan semasa migrasi. Jika tidak, semasa penyebaran DNS, sesetengah pengguna mungkin menulis data ke pelayan lama, dan yang lain ke pelayan baharu. Ini akan menyebabkan ketidakselarasan dalam pesanan, komen, rekod borang, atau maklumat keahlian. Untuk laman web kritikal, operasi dump pangkalan data terakhir harus diambil selepas mod penyelenggaraan diaktifkan.

Langkah 4: Kemas Kini Fail Konfigurasi

Nama pangkalan data, nama pengguna, kata laluan, maklumat host, dan laluan fail mesti disunting mengikut pelayan baharu. Untuk WordPress, wp-config.php; untuk Laravel, .env; untuk aplikasi tersuai, fail config.php atau yang serupa harus diperiksa. Jika laluan fail mutlak, alamat IP, tetapan SMTP, atau direktori cache milik pelayan lama kekal, laman web mungkin kelihatan berfungsi tetapi sebenarnya menghasilkan ralat di latar belakang.

Selain itu, nilai memory_limit, upload_max_filesize, post_max_size, dan max_execution_time PHP mesti diselaraskan mengikut keperluan aplikasi anda. Sebagai contoh, jika panel pentadbir memuat naik imej produk 200 MB, tetapi had muat naik kekal 32 MB, operasi tidak dapat diteruskan walaupun migrasi berjaya.

Langkah 5: Uji Sebelum Menukar DNS

Amalan migrasi yang paling selamat adalah menguji laman web di pelayan baharu sebelum menukar DNS. Untuk melakukan ini, anda boleh memetakan domain anda ke alamat IP pelayan baharu dalam fail hosts komputer anda. Dengan cara ini, pelawat masih melihat pelayan lama, sementara anda menguji pelayan baharu dengan domain sebenar.

Senarai ujian harus merangkumi pemeriksaan berikut:

• Adakah halaman utama, kategori, produk, blog, dan halaman hubungan dibuka?
• Adakah penghantaran borang, log masuk ahli, set semula kata laluan, dan aliran pembayaran berfungsi?
• Adakah imej, CSS, dan fail JavaScript dimuatkan sepenuhnya?
• Adakah panel pentadbir boleh dibuka tanpa ralat?
• Adakah sijil SSL dipasang untuk domain yang betul?
• Adakah terdapat ralat 404, 500, kandungan bercampur (mixed content), atau gelung pengalihan?
• Adakah robots.txt, sitemap.xml, dan tag kanonikal betul?

Langkah 6: Pasang Sijil SSL

Dalam laman web moden, SSL adalah wajib bukan sahaja untuk keselamatan tetapi juga untuk SEO dan kepercayaan pengguna. Jika DNS ditukar tanpa memasang SSL di pelayan baharu, pengguna mungkin melihat amaran "tidak selamat". Oleh itu, sijil SSL mesti disediakan sejurus sebelum atau serentak dengan pertukaran DNS. Sijil percuma seperti Let's Encrypt mungkin mencukupi untuk banyak laman web; namun, untuk projek korporat yang menerima pembayaran, pilihan SSL dengan tahap pengesahan yang lebih tinggi boleh diutamakan.

Selepas SSL, pastikan alamat HTTP dihalakan ke HTTPS dengan kod status 301, tiada ralat kandungan bercampur, dan peta laman mengandungi URL HTTPS. Untuk produk dan pilihan pemasangan SSL, anda boleh melihat halaman sijil SSL.

Langkah 7: Tukar Rekod DNS

Selepas ujian berjaya diselesaikan, rekod A di pihak DNS dihalakan ke alamat IP pelayan baharu. Jika perkhidmatan e-mel turut dipindahkan dalam pelayan yang sama, rekod MX, SPF, DKIM, dan DMARC juga mesti dikemas kini. Jika e-mel kekal di penyedia yang berbeza, rekod MX tidak boleh disentuh. Salah satu kesilapan yang paling kerap berlaku ialah menukar rekod e-mel secara tidak sengaja semasa hanya ingin memindahkan laman web, lalu memutuskan trafik mel.

Penyebaran DNS biasanya selesai antara beberapa minit hingga 24 jam. Jika TTL telah direndahkan terlebih dahulu, kebanyakan pengguna akan mencapai pelayan baharu dalam masa yang singkat. Jangan matikan pelayan lama serta-merta dalam proses ini. Amalan selamat adalah mengekalkannya boleh diakses sekurang-kurangnya 48 jam, dan jika boleh, 72 jam.

Langkah 8: Lakukan Penyegerakan Terakhir dan Semakan Log

Selepas pertukaran DNS, periksa sama ada terdapat data baharu yang ditulis ke pelayan lama. Terutamanya, pesanan, borang hubungan, pendaftaran pengguna, dan komen harus dibandingkan. Fail log akses pelayan web dan log ralat membantu memahami IP mana yang menghantar permintaan ke pelayan mana.

Dalam tempoh 24 jam pertama selepas migrasi, ralat 500, peningkatan ralat 404, pertanyaan pangkalan data yang perlahan, lonjakan CPU, dan baris gilir e-mel harus dipantau. Jika pemeriksaan ini tidak dilakukan, laman web mungkin kelihatan berfungsi tetapi sebenarnya mengalami kehilangan penukaran di latar belakang.

Senarai Semak Profesional untuk Migrasi Tanpa Kehilangan Data

Senarai semak berikut merangkumi perkara yang paling kerap menyebabkan masalah dalam amalan. Menandai senarai ini sebelum dan selepas migrasi secara signifikan mengurangkan risiko migrasi.

• Masa migrasi dirancang pada waktu trafik rendah.
• Sandaran penuh fail, pangkalan data, e-mel, dan DNS telah diambil.
• Kebolehbukaan dan kebolehpulihan sandaran telah diuji.
• Nilai TTL DNS direndahkan sekurang-kurangnya 24 jam lebih awal.
• PHP, pangkalan data, dan modul yang diperlukan disediakan di pelayan baharu.
• Fail dipindahkan sepenuhnya dan keizinan diperiksa.
• Keserasian set aksara dan collation pangkalan data disahkan.
• Fail konfigurasi dikemas kini mengikut maklumat pelayan baharu.
• Ujian dilakukan menggunakan fail hosts sebelum disiarkan secara langsung.
• SSL dipasang, pengalihan HTTPS diperiksa.
• Rekod DNS A, AAAA, MX, TXT dikemas kini dengan betul.
• Pelayan lama dibiarkan aktif sekurang-kurangnya 48 jam.
• Google Search Console, Analitik, dan rekod log dipantau.

Pemeriksaan Pasca-Migrasi untuk Mengelakkan Kehilangan SEO

Migrasi server secara teorinya tidak sepatutnya menyebabkan kehilangan SEO selagi struktur URL tidak berubah. Walau bagaimanapun, dalam praktiknya, kelambatan, ralat 404, robots.txt yang salah, SSL yang hilang, atau ralat pengalihan boleh menjejaskan kedudukan. Oleh itu, pemeriksaan SEO selepas migrasi adalah sama pentingnya dengan migrasi teknikal.

Pemeriksaan URL dan Pengalihan

Jika anda tidak menukar struktur URL semasa memindahkan laman web, keperluan untuk pengalihan 301 adalah minimum. Walau bagaimanapun, jika nama domain, struktur pautan kekal, atau struktur folder berubah pada masa yang sama, URL lama mesti dihalakan ke pasangan baharunya dengan kod status 301. Pengalihan sementara 302 tidak sesuai untuk pemindahan isyarat SEO secara kekal. Sebagai contoh, jika halaman /produk/abc lama dipindahkan ke alamat /kedai/abc baharu, pengalihan satu-ke-satu mesti dilakukan; mengalihkan semua URL lama ke halaman utama menjejaskan pengalaman pengguna dan prestasi SEO secara negatif.

Pemeriksaan Robots.txt dan Peta Laman

Jika arahan Disallow digunakan dalam robots.txt untuk menyekat enjin carian semasa ujian, ia mesti dialih keluar apabila disiarkan secara langsung. Ralat ini adalah salah satu punca paling klasik kehilangan indeks selepas migrasi. Fail peta laman harus mengandungi URL HTTPS baharu dan dihantar semula melalui Google Search Console.

Prestasi dan Core Web Vitals

Walaupun pelayan baharu lebih berkuasa, tetapan cache yang salah boleh menurunkan prestasi. LiteSpeed Cache, Redis, OPcache, CDN, dan pengoptimuman imej mesti dikonfigurasikan dengan betul. Pada minggu pertama selepas migrasi, pantau PageSpeed Insights, Laporan UX Chrome, dan log pelayan untuk memeriksa sama ada terdapat kemerosotan dalam metrik LCP, INP, dan CLS. Untuk meningkatkan prestasi hosting, anda boleh memanfaatkan kandungan di pengoptimuman kelajuan WordPress.

Perkara yang Perlu Diperhatikan Semasa Migrasi E-mel

Dalam kebanyakan migrasi laman web, fail web dipindahkan tanpa masalah, tetapi bahagian e-mel sering terlepas pandang. Jika e-mel dihoskan di pelayan semasa, peti mel, kata laluan pengguna, pengalihan, dan penapis mesti dipindahkan. Penyegerakan IMAP adalah kaedah yang boleh dipercayai untuk memindahkan mel dari peti lama ke peti baharu.

Di pihak DNS, rekod MX menentukan pelayan mel, SPF menentukan kuasa penghantaran, DKIM mengesahkan tandatangan, dan DMARC menentukan dasar domain. Jika rekod ini salah dikonfigurasikan, e-mel mungkin masuk ke folder spam atau ditolak sepenuhnya. Selepas migrasi, hantaran ujian ke Gmail, Outlook, dan akaun mel korporat mesti dilakukan; maklumat pengepala mel harus diperiksa.

Kesilapan Umum dalam Migrasi Server

Persamaan dalam projek migrasi yang berjaya adalah pencegahan awal terhadap kesilapan mudah. Berikut adalah masalah yang paling kerap dihadapi:

• Melakukan migrasi tanpa mengambil sandaran atau tanpa menguji sandaran.
• Menukar IP tanpa merendahkan nilai TTL DNS.
• Mematikan pelayan lama sebelum penyebaran DNS selesai.
• Memindahkan set aksara pangkalan data dengan salah dan merosakkan aksara bahasa Melayu.
• Terlupa peraturan pengalihan .htaccess atau nginx.
• Menghalakan trafik HTTPS ke pelayan baharu tanpa memasang SSL.
• Salah mengemas kini rekod MX dan TXT e-mel.
• Meninggalkan pemalam cache dengan laluan pelayan lama.
• Tidak melakukan pemantauan Search Console dan log selepas migrasi.

Khususnya untuk laman web yang menjual secara langsung, proses migrasi tidak sepatutnya dilakukan semasa waktu sibuk hari bekerja, tetapi pada selang waktu apabila trafik dan jumlah pesanan berada pada tahap paling rendah. Untuk projek e-dagang yang besar, merancang tetingkap penyelenggaraan selama 15-30 minit menghalang kemungkinan ketidakselarasan data di latar belakang.

Bilakah Anda Memerlukan Sokongan Migrasi Profesional?

Memindahkan laman web perniagaan yang ringkas secara manual mungkin boleh dilakukan; namun, dalam beberapa kes, mendapatkan sokongan profesional adalah lebih menjimatkan kos dan lebih selamat. Laman e-dagang dengan hasil bulanan yang tinggi, syarikat dengan banyak akaun e-mel, portal yang menggunakan perisian tersuai, laman media dengan trafik tinggi, dan perniagaan yang menyimpan data tertakluk kepada peraturan termasuk dalam kumpulan ini.

Dalam sokongan migrasi profesional, proses biasanya terdiri daripada analisis awal, sandaran, persediaan persekitaran ujian, pemindahan, pertukaran DNS, pengesahan, dan pemantauan. Dengan cara ini, bukan sahaja fail dipindahkan, tetapi kesinambungan perniagaan juga terjamin. Jika anda merancang untuk beralih ke infrastruktur Hostragons, anda boleh menyemak halaman penyelesaian hosting Hostragons untuk menilai pilihan hosting, domain, dan SSL yang sesuai dengan keperluan anda.

Kesimpulan: Migrasi Server Terancang Mencegah Gangguan dan Kehilangan Data

Migrasi server bukanlah satu proses yang menakutkan jika dirancang dengan betul. Kunci kejayaan adalah tidak melangkau langkah-langkah seperti sandaran penuh, penyediaan pelayan yang betul, pelan TTL DNS, persekitaran ujian, pemasangan SSL, pemeriksaan e-mel, dan pemantauan selepas migrasi. Khususnya untuk laman web yang pangkalan datanya sentiasa berubah, penyegerakan terakhir dan mod penyelenggaraan memainkan peranan yang kritikal.

Ringkasnya, untuk memindahkan laman web tanpa kehilangan data, jangan tergesa-gesa, sahkan setiap langkah, dan jangan matikan pelayan lama serta-merta. Jika anda ingin menaik taraf infrastruktur anda dan menawarkan pengalaman web yang lebih pantas dan selamat, anda boleh menyemak penyelesaian hosting, domain, dan SSL di Hostragons; dan mencipta pelan peralihan yang tenang dan terkawal mengikut keperluan anda.

Soalan Lazim

Berapa lamakah masa yang diambil untuk migrasi server?

Tempohnya berbeza mengikut saiz dan kerumitan laman web. Laman WordPress kecil boleh dipindahkan dalam masa 30-60 minit, manakala untuk projek e-dagang besar atau korporat dengan banyak e-mel, proses termasuk persediaan, ujian, dan penyebaran DNS boleh mengambil masa 1-3 hari.

Adakah laman web saya akan terhenti semasa migrasi server?

Dengan perancangan yang betul, gangguan boleh dikurangkan kepada beberapa minit sahaja, atau pengguna mungkin tidak merasai sebarang gangguan. Untuk ini, TTL DNS mesti direndahkan terlebih dahulu, pelayan baharu mesti diuji sebelum disiarkan secara langsung, dan pelayan lama mesti dibiarkan aktif sehingga penyebaran DNS selesai.

Apakah langkah paling penting untuk mengelakkan kehilangan data?

Langkah paling penting adalah sandaran penuh yang telah disahkan. Fail, pangkalan data, e-mel, dan rekod DNS mesti disandarkan; terutamanya untuk laman web yang menjana data pesanan atau keahlian, sandaran pangkalan data terakhir harus diambil selepas mod penyelenggaraan diaktifkan.

Adakah migrasi server menjejaskan kedudukan SEO?

Jika struktur URL dikekalkan, laman web berjalan pantas, SSL dan pengalihan dilakukan dengan betul, migrasi server sahaja tidak akan menyebabkan kehilangan SEO. Walau bagaimanapun, ralat 404, robots.txt yang salah, pelayan yang perlahan, atau pengalihan 301 yang tidak betul boleh menjejaskan kedudukan secara negatif.

Adakah akaun e-mel juga dipindahkan semasa migrasi server?

Jika e-mel dihoskan di hosting lama, ia mesti dipindahkan secara berasingan. Peti mel, pengalihan, penapis, dan rekod MX, SPF, DKIM, DMARC mesti diperiksa. Jika e-mel kekal di penyedia yang berbeza, rekod MX tidak boleh diubah.