วิธีย้ายเว็บไซต์ไปเซิร์ฟเวอร์ใหม่โดยไม่สูญเสียข้อมูล (Server Migration) พร้อมคู่มือป้องกันปัญหายอดนิยม

การย้ายเว็บไซต์หรือเซิร์ฟเวอร์ (migration) คือกระบวนการถ่ายโอนไฟล์เว็บไซต์ ฐานข้อมูล อีเมล บัญชี DNS และการตั้งค่าต่างๆ จากเซิร์ฟเวอร์เดิมไปยังเซิร์ฟเวอร์ใหม่อย่างเป็นระบบ เพื่อลดความเสี่ยงสูญเสียข้อมูล วิธีป้องกันปัญหาหลักคือ: สำรองข้อมูลเต็มรูปแบบ เตรียมเซิร์ฟเวอร์ใหม่ให้รองรับเวอร์ชันซอฟต์แวร์ที่เท่ากันหรือใหม่กว่า โอนถ่ายไฟล์และฐานข้อมูล ทดสอบด้วย hosts file หรือ URL ชั่วคราว ปรับ DNS ด้วยค่า TTL ต่ำ แล้วตรวจสอบ log ฟอร์ม ระบบจ่ายเงิน อีเมล และ SEO หลังย้ายเสร็จ

การย้ายเซิร์ฟเวอร์ไม่ใช่แค่ copy-paste โดยเฉพาะกับ WordPress, WooCommerce, Laravel, ระบบ PHP เฉพาะทาง เว็บไซต์ข่าวหรือธุรกิจที่ใช้อีเมลองค์กร หากทำผิดพลาดอาจเกิดผลเสียทั้งสูญเสียคำสั่งซื้อ, ปัญหาอักขระไทย, error 500, แจ้งเตือน SSL, อีเมลหยุด และอันดับ SEO ลดลง ดังนั้นต้องมีแผน migration, เช็คลิสต์เทคนิค และแผน fallback เตรียมไว้

คู่มือนี้จะพาคุณย้ายเว็บไซต์หรือเซิร์ฟเวอร์ให้สอดคล้องกับมาตรฐาน SEO และประสิทธิภาพปี 2026 แบบทีละขั้นตอน พร้อมเทคนิคสำหรับ cPanel, Plesk, VPS, Cloud และการย้ายแบบ manual รวมถึงข้อควรระวังเรื่อง DNS เวลา, ขอบเขตการสำรอง, ความเข้ากันได้ของฐานข้อมูล, การติดตั้ง SSL และการตรวจสอบ SEO หลัง migration

เมื่อไรควรย้ายเซิร์ฟเวอร์?

การย้ายเว็บไซต์ไปเซิร์ฟเวอร์ใหม่มักเกิดจากเหตุผลด้านประสิทธิภาพ ความปลอดภัย ค่าใช้จ่าย หรือความสามารถในการขยายตัว เช่น เว็บไซต์บริษัทที่มีผู้เข้าชมเดือนละ 5,000 คนอาจใช้ hosting แบบแชร์ได้ แต่เว็บ e-commerce ที่มี 20,000 คน/วัน จะเจอปัญหาขีดจำกัด CPU, query ช้า หรือ timeout หน้า checkout จึงต้องเลือก hosting ที่ทรงพลังกว่า เช่น VPS หรือโครงสร้าง cloud

สัญญาณที่บอกว่าควรย้ายเซิร์ฟเวอร์มีดังนี้:

• เวลาการโหลดหน้าเว็บเกิน 3 วินาที และค่า Core Web Vitals เริ่มตก
• CPU, RAM, inode หรือ disk ใน hosting พุ่งเต็มบ่อยครั้ง
• ต้องการอัปเดต PHP, MySQL, MariaDB, Node.js หรือ ionCube ให้เป็นเวอร์ชันใหม่
• ปัญหาเรื่อง SSL, อีเมล, DNS บ่อย ๆ
• ระบบสำรองข้อมูลหรือความปลอดภัยของผู้ให้บริการไม่เพียงพอ
• ทราฟฟิกเว็บพุ่งขึ้นจากแคมเปญหรือฤดูกาล

หากเว็บเติบโตและเข้าใกล้ขีดจำกัด hosting ควรวางแผน migration ล่วงหน้า ไม่ใช่ย้ายตอนเกิดวิกฤต เปรียบเทียบ แพ็คเกจการโฮสต์เว็บไซต์, โซลูชันเซิร์ฟเวอร์ VPS หรือ โฮสติ้งธุรกิจ เพื่อเลือกโครงสร้างที่เหมาะสม

เตรียมตัวก่อนย้าย: ขั้นตอนสำคัญที่สุด

การสูญเสียข้อมูลส่วนใหญ่ไม่ได้เกิดระหว่างย้ายแต่เกิดจากการเตรียมตัวไม่ดี ก่อนย้ายต้องสำรวจข้อมูลทั้งหมด และระบุว่าอะไรต้องโอน อะไรสำคัญต่อเนื่อง

1. สร้างแผนผังเว็บไซต์

ขั้นแรกคือทำแผนผังเทคนิคของเว็บไซต์ เช่น CMS หรือ framework ที่ใช้, เวอร์ชัน PHP, ชนิดฐานข้อมูล, ขนาด disk, บัญชีอีเมล, cron jobs, DNS, SSL, redirect พิเศษ และการเชื่อมต่อ third-party สำหรับ WordPress ไม่ใช่แค่โอน wp-content แต่ต้องตรวจสอบ .htaccess, wp-config.php, prefix ตารางฐานข้อมูล, cache plugins และไฟล์สื่อด้วย

สำหรับเว็บ e-commerce ต้องตรวจสอบระบบจ่ายเงิน, ขนส่ง, sync สต็อก, ERP, SMTP และ webhook URL หากหลังย้ายไม่มีคำสั่งซื้อ ปัญหามักอยู่ที่ API หรือ security rule ที่ลืมปรับ ไม่ใช่แค่ไฟล์

2. สำรองข้อมูลเต็มรูปแบบและทดสอบ

สำรองข้อมูลอย่างเดียวไม่พอ ต้องมั่นใจว่า restore ได้ backup ที่สมบูรณ์ควรประกอบด้วย:

• ไฟล์เว็บไซต์: public_html, โฟลเดอร์ apps, uploads, ธีมและ plugins
• ฐานข้อมูล: MySQL, MariaDB, PostgreSQL หรืออื่น ๆ ที่ใช้
• ข้อมูลอีเมล: mailbox, forward, filter, autoresponder
• DNS records: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC
• ไฟล์ config: .htaccess, nginx.conf, php.ini, cron job, environment
• SSL certificates และกฎความปลอดภัย

ถ้าเป็นเว็บใหญ่ ควร backup ไว้ 2 ชุด (บนเซิร์ฟเวอร์เดิมและที่อื่น) ใช้ rsync สำหรับไฟล์, mysqldump สำหรับฐานข้อมูล หรือ panel backup tools ฐานข้อมูลใหญ่เกิน 10GB ควร backup แบบแบ่งไฟล์และ compress

3. ลดค่า DNS TTL ล่วงหน้า

เพื่อให้ DNS เปลี่ยนเร็ว ควรลด TTL ก่อนย้าย 24 ชั่วโมง เช่น TTL เดิม 14400 วินาที จะทำให้บางผู้ใช้ยังเห็นเซิร์ฟเวอร์เก่าเป็นชั่วโมง ถ้าลด TTL เหลือ 300 วินาทีจะควบคุม migration ได้ดีกว่า หลังย้ายเสร็จและตรวจสอบทุกอย่างแล้วจึงเพิ่ม TTL กลับไปที่ 3600 หรือ 14400

จัดการ DNS อย่างเป็นระบบช่วยลดความเสี่ยง migration ศึกษาเรื่อง การตรวจสอบโดเมนและการจัดการชื่อโดเมน เพื่อเข้าใจการตั้งค่า

เปรียบเทียบวิธีการย้ายเว็บไซต์/เซิร์ฟเวอร์

แต่ละเว็บไซต์เหมาะกับวิธี migration ต่างกัน เว็บบริษัทเล็ก ๆ ใช้ panel ได้ง่าย แต่ e-commerce ที่มีทราฟฟิกสูง ต้อง sync แบบค่อยเป็นค่อยไปและเปิด maintenance mode

อย่าเลือกเซิร์ฟเวอร์ใหม่แค่ดู disk space ต้องพิจารณา PHP worker, CPU core, RAM, NVMe disk, ความถี่ backup, ที่ตั้ง data center, LiteSpeed/Nginx, WAF, DDoS protection ถ้าเลือกแพ็คเกจราคาถูกโดยไม่วิเคราะห์ความต้องการ อาจต้องย้ายใหม่ในเวลาไม่นาน

ขั้นตอนการย้ายเว็บไซต์ไปเซิร์ฟเวอร์ใหม่แบบละเอียด

ขั้นที่ 1: เตรียมเซิร์ฟเวอร์ใหม่

ติดตั้ง OS, web server, PHP version, database service และ modules ที่จำเป็น สำหรับ WordPress แนะนำ PHP 8.2/8.3, MariaDB ล่าสุด, OPcache, memory_limit ที่เหมาะสม Laravel ต้องตั้ง composer, cron, queue worker, storage permissions หาก PHP extension เดิมไม่มีบนเซิร์ฟเวอร์ใหม่ เว็บจะ error หรือจอขาวหลังย้าย

ด้านความปลอดภัย ตั้ง SSH port, password แข็งแรง, firewall, malware scan, อัปเดตอัตโนมัติ ยิ่งเซิร์ฟเวอร์ใหม่ยังไม่มี load ยิ่งควรตั้ง security ก่อน migration ถ้าต้องใช้ SSL อย่าลืมวางแผน การติดตั้งใบรับรอง SSL

ขั้นที่ 2: โอนถ่ายไฟล์เว็บไซต์

เลือกวิธีการโอนตามขนาดเว็บ: FTP, SFTP, SSH, rsync หรือ panel backup เว็บเล็ก zip ไฟล์แล้วแตกบนเซิร์ฟเวอร์ใหม่ก็พอ เว็บใหญ่ใช้ rsync ทำ copy รอบแรก แล้วก่อนปรับ DNS ให้ sync อีกรอบ เพื่อลดเวลาย้ายโดยเฉพาะโฟลเดอร์ upload ที่มีไฟล์ใหม่ตลอด

หลังโอนไฟล์ ตรวจสอบ permission โฟลเดอร์ควรเป็น 755 ไฟล์ 644 แต่ละแอปอาจต่างกัน wp-config.php, .env หรือ config สำคัญไม่ควรให้คนอื่นอ่านได้ อย่าลืมโอน .htaccess และ .user.ini ด้วย

ขั้นที่ 3: ย้ายฐานข้อมูล

ขั้นตอนสำคัญที่สุดในการป้องกันข้อมูลหาย คือ backup ฐานข้อมูลจากเซิร์ฟเวอร์เดิม สร้างฐานข้อมูลและ user ใหม่บนเซิร์ฟเวอร์ใหม่ ตั้ง charset เป็น utf8mb4 เพื่อรองรับอักขระไทย export/import ต้องใช้ collation ตรงกันเพื่อไม่ให้ข้อมูลผิดพลาด

เว็บที่มีระบบคำสั่งซื้อหรือสมาชิกแบบ real-time ควรเปิด maintenance mode ระหว่าง migration เพราะช่วง DNS เปลี่ยน ผู้ใช้บางคนอาจโพสต์ข้อมูลไปเซิร์ฟเวอร์เก่า บางคนไปใหม่ จะเกิดความไม่สอดคล้อง ตรวจสอบให้ dump ฐานข้อมูลครั้งสุดท้ายหลังเข้า maintenance mode

ขั้นที่ 4: อัปเดตไฟล์ config ให้ตรงเซิร์ฟเวอร์ใหม่

ปรับชื่อฐานข้อมูล, user, password, host และ path ให้ตรงกับเซิร์ฟเวอร์ใหม่ WordPress ใช้ wp-config.php Laravel ใช้ .env ส่วนแอปอื่นใช้ config.php หาก path, IP, SMTP หรือ cache directory ยังเป็นของเซิร์ฟเวอร์เก่า เว็บจะ error แม้หน้าเว็บจะแสดงผลปกติ

ตรวจสอบ PHP memory_limit, upload_max_filesize, post_max_size, max_execution_time ให้ตรงกับความต้องการ เช่น ถ้า admin ต้องอัปโหลดรูป 200MB แต่ limit เหลือ 32MB migration สำเร็จแต่ใช้งานจริงไม่ได้

ขั้นที่ 5: ทดสอบเว็บไซต์บนเซิร์ฟเวอร์ใหม่ก่อนเปลี่ยน DNS

วิธี migration ที่ปลอดภัยคือทดสอบเว็บไซต์บนเซิร์ฟเวอร์ใหม่ก่อนปรับ DNS ใช้ hosts file บนเครื่อง PC map domain กับ IP ใหม่ จะเห็นเว็บบนเซิร์ฟเวอร์ใหม่แม้ผู้ใช้งานทั่วไปยังเห็นเซิร์ฟเวอร์เดิม

รายการตรวจสอบ:

• หน้าแรก, หมวดหมู่, สินค้า, บล็อก, ติดต่อ เปิดได้ครบ
• ฟอร์ม, login, reset password, flow การจ่ายเงินทำงาน
• รูปภาพ, CSS, JS โหลดครบไม่มีขาด
• เข้า admin ได้ไม่มี error
• SSL ติดตั้งกับ domain ถูกต้อง
• ไม่มี error 404, 500, mixed content, redirect loop
• robots.txt, sitemap.xml, canonical tag ตรง

ขั้นที่ 6: ติดตั้ง SSL Certificate

SSL จำเป็นต่อทั้งความปลอดภัย SEO และความน่าเชื่อถือ หากย้าย DNS ก่อนติดตั้ง SSL ผู้ใช้จะเจอ security warning ควรเตรียม SSL ไว้ก่อนหรือพร้อมกับ migration Let’s Encrypt ฟรีเหมาะกับหลายเว็บ เว็บที่มีหน้า payment ควรใช้ SSL ที่มี validation สูงกว่า

หลังติดตั้ง SSL ตรวจสอบ redirect HTTP ไป HTTPS แบบ 301, ไม่มี mixed content error และ sitemap มี HTTPS URL ทั้งหมด ดู ใบรับรอง SSL สำหรับตัวเลือก SSL เพิ่มเติม

ขั้นที่ 7: เปลี่ยน DNS Records

เมื่อทดสอบทุกอย่างผ่านแล้ว ให้เปลี่ยน DNS A record ไป IP เซิร์ฟเวอร์ใหม่ ถ้าบริการอีเมลย้ายไปด้วย ต้องปรับ MX, SPF, DKIM, DMARC ด้วย ถ้าอีเมลใช้ผู้ให้บริการเดิม ไม่ต้องแตะ MX record ปัญหาที่พบบ่อยคือเปลี่ยนแค่เว็บแต่เผลอเปลี่ยน MX ทำให้อีเมลหยุด

DNS propagation ใช้เวลา 5 นาทีถึง 24 ชั่วโมง ถ้าลด TTL ล่วงหน้าจะเร็วขึ้น อย่าปิดเซิร์ฟเวอร์เก่าทันที ควรเปิดต่ออย่างน้อย 48-72 ชั่วโมงเพื่อความปลอดภัย

ขั้นที่ 8: sync ข้อมูลล่าสุดและตรวจสอบ log

หลังเปลี่ยน DNS ตรวจสอบว่ามีข้อมูลใหม่โพสต์บนเซิร์ฟเวอร์เก่าหรือไม่ เปรียบเทียบคำสั่งซื้อ ฟอร์ม สมาชิก และ comments ใช้ access log และ error log ดูว่า IP ไหนยังเข้าถึงเซิร์ฟเวอร์เก่าอยู่

24 ชั่วโมงแรกหลังย้าย ให้ monitor error 500, 404, query ช้า, CPU spike และ email queue เพราะอาจเกิดปัญหาที่มองไม่เห็นแต่ส่งผลต่อ conversion

เช็คลิสต์มืออาชีพสำหรับการย้ายเว็บไซต์โดยไม่สูญเสียข้อมูล

รายการด้านล่างนี้คือจุดที่มักเกิดปัญหา ถ้าตรวจสอบก่อนและหลัง migration จะลดความเสี่ยงได้มาก

• กำหนดเวลาย้ายในช่วงทราฟฟิกต่ำ
• สำรองข้อมูลไฟล์ ฐานข้อมูล อีเมล DNS ครบถ้วน
• ทดสอบ restore backup ได้จริง
• ลด TTL DNS อย่างน้อย 24 ชั่วโมงล่วงหน้า
• เตรียม PHP, database, modules บนเซิร์ฟเวอร์ใหม่
• โอนไฟล์ครบและตรวจสอบ permission
• ยืนยัน charset และ collation ของฐานข้อมูล
• อัปเดต config ตามข้อมูลเซิร์ฟเวอร์ใหม่
• ทดสอบผ่าน hosts file ก่อน live จริง
• ติดตั้ง SSL, ตรวจสอบ HTTPS redirect
• อัปเดต DNS A, AAAA, MX, TXT ให้ถูกต้อง
• เปิดเซิร์ฟเวอร์เก่าอย่างน้อย 48 ชั่วโมง
• ติดตาม Google Search Console, Analytics และ log

ตรวจสอบ SEO หลัง migration เพื่อป้องกันอันดับตก

หาก migration ไม่เปลี่ยนโครงสร้าง URL จะไม่กระทบ SEO โดยตรง แต่ปัญหาเช่นเว็บช้า, error 404, robots.txt ผิด, SSL ขาด หรือ redirect ผิดจะส่งผลต่ออันดับ จึงควรตรวจสอบ SEO หลัง migration อย่างละเอียด

ตรวจสอบ URL และ redirect

ถ้าไม่เปลี่ยนโครงสร้าง URL ไม่ต้องใช้ 301 redirect มาก แต่ถ้าเปลี่ยน domain, permalink หรือ folder ต้อง redirect ทุก URL เก่าไปใหม่แบบ 301 หลีกเลี่ยง 302 เพราะไม่ส่งสัญญาณ SEO ตัวอย่างเช่น /product/abc เปลี่ยนเป็น /shop/abc ต้อง redirect ตรง ห้าม redirect ทุกหน้าไป home page เพราะจะทำให้ประสบการณ์ผู้ใช้และ SEO ตก

ตรวจสอบ robots.txt และ sitemap

ถ้าทดสอบ migration แล้วใช้ Disallow ใน robots.txt ต้องเอาออกเมื่อ live จริง เพราะจะทำให้เว็บหายจาก index ตรวจสอบ sitemap ให้มี HTTPS URL และ submit ใหม่ใน Google Search Console

ตรวจสอบประสิทธิภาพและ Core Web Vitals

แม้เซิร์ฟเวอร์ใหม่จะเร็วกว่า แต่ถ้าตั้ง cache ผิดอาจช้าลง ต้องตั้ง LiteSpeed Cache, Redis, OPcache, CDN และ optimize รูปอย่างเหมาะสม หลัง migration ควร monitor PageSpeed Insights, Chrome UX Report, server log เพื่อดู LCP, INP, CLS ว่าไม่ตก สามารถดู การปรับแต่งความเร็ว WordPress เพื่อปรับแต่งเพิ่มเติม

ข้อควรระวังเมื่อย้ายอีเมล

เว็บไซต์ส่วนใหญ่มักโอนข้อมูลเว็บครบแต่ลืมเรื่องอีเมล ถ้าอีเมลอยู่บนเซิร์ฟเวอร์เดิม ต้องโอน mailbox, password, forward, filter การ sync IMAP ใช้โอนเมล์ระหว่าง mailbox ได้อย่างปลอดภัย

DNS MX กำหนด mail server, SPF กำหนดสิทธิ์ส่ง, DKIM ใช้ sign, DMARC กำหนด policy ถ้า setup ผิด อีเมลจะเข้า spam หรือถูก reject หลัง migration ต้องทดสอบส่งเมล์ไป gmail, outlook, mail องค์กร และตรวจ header

ข้อผิดพลาดที่พบได้บ่อยในการย้ายเว็บไซต์

โครงการ migration ที่สำเร็จคือโครงการที่ป้องกันข้อผิดพลาดง่าย ๆ ไว้ล่วงหน้า ข้อผิดพลาดที่พบบ่อย:

• ย้ายโดยไม่ backup หรือไม่ทดสอบ restore
• เปลี่ยน IP โดยไม่ลด TTL DNS
• ปิดเซิร์ฟเวอร์เก่าก่อน DNS propagation เสร็จ
• ย้ายฐานข้อมูลโดย charset ผิดทำให้อักขระไทยหาย
• ลืม .htaccess หรือ nginx redirect rule
• redirect traffic ไปเซิร์ฟเวอร์ใหม่โดยไม่มี SSL
• อัปเดต MX หรือ TXT ผิดทำให้อีเมลหยุด
• ปล่อย cache plugin ไว้กับ path เดิม
• ไม่ monitor Search Console หรือ logs หลัง migration

โดยเฉพาะเว็บที่ขายของสด ควรย้ายในช่วงที่ order ต่ำ ไม่ใช่ช่วง peak traffic เว็บ e-commerce ใหญ่ควรมี maintenance window 15-30 นาทีเพื่อตรวจสอบความสอดคล้องของข้อมูล

เมื่อไรควรใช้บริการ migration มืออาชีพ?

เว็บไซต์แนะนำหรือ portfolio สามารถย้ายเองได้ แต่เว็บ e-commerce ที่ขายดี, บริษัทที่มีอีเมลเยอะ, portal ที่ใช้ software เฉพาะ, เว็บข่าวทราฟฟิกสูง หรือองค์กรที่ต้อง comply ด้านข้อมูลควรใช้บริการ migration มืออาชีพ

บริการ migration มืออาชีพประกอบด้วยการวิเคราะห์เบื้องต้น, backup, สร้าง test environment, โอนข้อมูล, ปรับ DNS, ตรวจสอบ และ monitor ทำให้ไม่ใช่แค่ข้อมูล แต่ business continuity ก็ย้ายตาม หากวางแผนย้ายมายัง Hostragons ศึกษา โซลูชันโฮสติง Hostragons เพื่อเปรียบเทียบ hosting, domain, SSL ที่เหมาะกับธุรกิจ

สรุป: การย้ายเซิร์ฟเวอร์โดยมีแผนช่วยลด downtime และป้องกันข้อมูลหาย

การย้ายเว็บไซต์หรือเซิร์ฟเวอร์ไม่ใช่เรื่องน่ากลัวถ้าทำแผนดี สำคัญคือ backup ครบ เตรียมเซิร์ฟเวอร์ใหม่ให้พร้อม ลด TTL DNS ทดสอบก่อน live ติดตั้ง SSL ตรวจสอบอีเมล และ monitor หลัง migration เว็บที่ฐานข้อมูลเปลี่ยนตลอดต้อง sync รอบสุดท้ายและเปิด maintenance mode

อย่ารีบย้าย ให้ตรวจสอบทุกขั้นตอนและอย่าปิดเซิร์ฟเวอร์เก่าทันที หากต้องการโครงสร้างใหม่ที่เร็วและปลอดภัยกว่า สามารถศึกษาบริการ hosting, domain, SSL บน Hostragons และวางแผนย้ายอย่างมั่นใจ

คำถามที่พบบ่อยเกี่ยวกับการย้ายเว็บไซต์/เซิร์ฟเวอร์

การย้ายเซิร์ฟเวอร์ใช้เวลานานแค่ไหน?

ขึ้นอยู่กับขนาดและความซับซ้อน เว็บ WordPress เล็ก ๆ อาจใช้ 30-60 นาที เว็บ e-commerce หรือองค์กรที่มีอีเมลจำนวนมากใช้เวลาเตรียม test และ DNS propagation ประมาณ 1-3 วัน

ระหว่างย้ายเซิร์ฟเวอร์ เว็บไซต์จะหยุดหรือไม่?

ถ้าวางแผนถูกต้อง downtime จะสั้นมากหรือไม่มีเลย ต้องลด TTL DNS ล่วงหน้า ทดสอบเซิร์ฟเวอร์ใหม่ก่อน live และเปิดเซิร์ฟเวอร์เก่าจน DNS propagation เสร็จ

ขั้นตอนสำคัญที่สุดในการป้องกันข้อมูลหายคืออะไร?

สำคัญที่สุดคือ backup ที่ทดสอบ restore ได้ backup ไฟล์ ฐานข้อมูล อีเมล DNS และสำหรับเว็บที่มีข้อมูลสด เช่น order หรือสมาชิก ต้อง backup ฐานข้อมูลรอบสุดท้ายหลังเข้า maintenance mode

การย้ายเซิร์ฟเวอร์กระทบ SEO หรือไม่?

ถ้าโครงสร้าง URL เดิม, เว็บเร็ว, SSL และ redirect ถูกต้อง migration ไม่กระทบ SEO โดยตรง แต่ error 404, robots.txt ผิด, เซิร์ฟเวอร์ช้า หรือ 301 redirect ผิดจะส่งผลต่ออันดับ

อีเมลต้องย้ายด้วยหรือไม่?

ถ้าอีเมลอยู่บน hosting เดิมต้องย้าย mailbox, forward, filter และตรวจสอบ MX, SPF, DKIM, DMARC ถ้าอีเมลอยู่กับผู้ให้บริการแยก ไม่ต้องเปลี่ยน MX record