วิธีย้ายเว็บไซต์ไปโฮสต์ใหม่ โดยเว็บไม่ล่มและอีเมลไม่หาย

เมื่อย้ายเว็บไซต์ไปโฮสต์ใหม่ การคัดลอกเว็บไซต์แทบไม่เคยเป็นส่วนที่ยาก สิ่งที่มักพลาดคือเรื่องที่ไม่มีใครจดไว้ เช่น DNS record ที่มีอยู่แค่ที่โฮสต์เดิม กล่องอีเมลที่มาพร้อมแพ็กเกจโฮสติ้ง หรือฟอร์มติดต่อที่อีเมลแจ้งเตือนเข้ากล่องสแปมตั้งแต่วันที่ย้าย

คู่มือปฏิบัติงานนี้แสดงวิธีเปลี่ยนผู้ให้บริการโฮสติ้ง โดยเว็บไม่ล่มและอีเมลไม่หาย ครอบคลุมเฉพาะโครงสร้างพื้นฐาน คือโดเมนและที่อยู่หน้าเดิม บนเซิร์ฟเวอร์ใหม่ ถ้า URL ของคุณเปลี่ยนด้วย ให้ใช้ เช็กลิสต์ SEO สำหรับการย้ายเว็บไซต์ ควบคู่กันไป

คำตอบสั้นๆ

การย้ายเว็บไซต์ไปโฮสต์ใหม่ โดยเว็บไม่ล่มและอีเมลไม่หาย

1. ทำแผนที่ ว่าโดเมน DNS เว็บไซต์ และอีเมล แต่ละอย่างอยู่ที่ไหน
2. Export DNS record ทุกตัว รวมถึง MX, SPF, DKIM และ DMARC
3. ตัดสินใจ ว่าอะไรต้องย้าย และย้ายทีละอย่าง
4. คัดลอกและทดสอบ เว็บไซต์บนโฮสต์ใหม่ ด้วยโดเมนจริงของคุณ ก่อนเปลี่ยน DNS
5. ลดค่า TTL ล่วงหน้าสองสามวัน แล้วเปลี่ยนเฉพาะ record ของเว็บไซต์
6. ตรวจสอบ เว็บไซต์ SSL ฟอร์ม และอีเมล
7. เปิดโฮสต์เดิมไว้ จนกว่า log ของมันจะเงียบ

ไม่มีเว็บล่ม เพราะเซิร์ฟเวอร์ทั้งสองเสิร์ฟเว็บไซต์เดียวกัน ระหว่างที่แคช DNS หมดอายุ และอีเมลยังใช้งานได้ เพราะ record ของมันยังชี้ไปที่เดิมเหมือนที่เคยเป็น

ขั้นที่ 1: ทำแผนที่ว่าอะไรอยู่ที่ไหน

เว็บไซต์พึ่งพาบริการสี่อย่าง ซึ่งมักซื้อจากบริษัทเดียวกัน หาให้ได้ว่าใครให้บริการแต่ละอย่าง คู่มือภาษาง่ายๆ ว่าเว็บไซต์ถูกสร้างขึ้นอย่างไร ของเรา อธิบายแต่ละชั้นไว้

ตรวจด้วยตัวเอง เครื่องมือ DNS lookup ออนไลน์ หรือคำสั่ง dig NS example.com และ dig MX example.com จะแสดง nameserver และเมลเซิร์ฟเวอร์ของคุณ ถ้า MX record ระบุชื่อ Google หรือ Microsoft แปลว่าอีเมลของคุณอยู่ที่นั่น ถ้าชี้ไปที่โดเมนของคุณเอง mail.example.com หรือโฮสต์เดิม อีเมลน่าจะเป็นส่วนหนึ่งของแพ็กเกจโฮสติ้ง

ขั้นที่ 2: export DNS record ทุกตัวก่อน

คุณดูรายการ record ทั้งหมดของโดเมนจากภายนอกให้ครบถ้วนไม่ได้ จึงต้อง export จากแผงควบคุมของผู้ให้บริการ DNS เป็นไฟล์ zone หรือภาพหน้าจอ พลาดไปตัวเดียว ก็มีบางอย่างพังแบบเงียบๆ ซึ่งมักเป็นอีเมล

DKIM พลาดได้ง่าย เพราะอยู่ใต้ชื่อที่คุณต้องรู้ก่อน เช่น selector._domainkey.example.com หา selector ได้จาก header แบบเต็มของอีเมลที่บริษัทคุณส่งออกไป คือค่า s= ในแต่ละบรรทัด DKIM-Signature เครื่องมือส่งจดหมายข่าวและ CRM ที่ส่งอีเมลในนามของคุณ มักมี DKIM ของตัวเองแยกต่างหาก

ตรวจว่าอีเมลย้ายตามเว็บไปด้วยไหม

ในโฮสต์แบบแชร์หลายเจ้า โดยเฉพาะที่ใช้ cPanel MX record จะชี้ไปที่ตัวโดเมนเอง หรือ mail.example.com ซึ่งเป็นชื่อแฝง (CNAME) ของโดเมน เมื่อเปลี่ยน A record ของโดเมน อีเมลของคุณก็จะย้ายไปพร้อมกับเว็บไซต์

ถ้ากล่องอีเมลจะอยู่ที่เดิม ให้ตั้ง A record ของ mail.example.com แยกต่างหาก ที่ชี้ไปยัง IP ของเซิร์ฟเวอร์เดิม และชี้ MX ไปที่ชื่อนั้น ก่อนวันย้ายจริงนานพอสมควร

ขั้นที่ 3: ตัดสินใจว่าอะไรต้องย้าย และย้ายทีละอย่าง

การย้ายเว็บไซต์ DNS และอีเมลในเย็นเดียว เปลี่ยนปัญหาเล็กๆ สามเรื่อง ให้กลายเป็นปัญหาที่สับสนเรื่องเดียว

ถ้าทำได้ ให้ DNS อยู่ที่เดิม

การเปลี่ยน A record ทำได้เร็วและย้อนกลับได้ การเปลี่ยน nameserver ช้ากว่า เพราะ registry ที่ดูแลนามสกุลโดเมนของคุณ (.com, .org และอื่นๆ) เป็นผู้กำหนดว่าจะแคช nameserver record นานเท่าไร ซึ่งมักเป็นหนึ่งถึงสองวัน และคุณย่นเวลานั้นไม่ได้ ถ้า DNS ของคุณอยู่กับผู้ให้บริการจดโดเมน (registrar) หรือผู้ให้บริการ DNS โดยเฉพาะ ก็ปล่อยไว้ที่นั่น ถ้าอยู่หลัง CDN แบบ proxy คุณแค่เปลี่ยนที่อยู่ origin ซึ่งมีผลแทบจะทันที (ดู อธิบายการแคชเว็บไซต์และ CDN)

ถ้า DNS ต้องย้าย ให้ย้ายก่อน

ถ้าโฮสต์เดิมดูแล DNS ของคุณ และคุณจะเลิกใช้โฮสต์นั้นทั้งหมด ให้สร้างทุก record ใหม่ที่ผู้ให้บริการ DNS รายใหม่ โดยยังชี้ไปที่เซิร์ฟเวอร์เดิม เทียบ zone ทีละบรรทัด สลับ nameserver แล้วรอสองสามวัน ไม่ควรมีอะไรเปลี่ยนที่มองเห็นได้ จากนั้นจึงย้ายเว็บไซต์แยกต่างหาก

ตรวจ DNSSEC ก่อน ถ้าเปิดใช้อยู่ ให้ลบ DS record ที่ registrar แล้วรอหนึ่งถึงสองวันก่อนสลับ หรือทำตามขั้นตอนการย้ายของผู้ให้บริการรายใหม่ ไม่อย่างนั้น resolver ที่ตรวจสอบ DNSSEC อาจมองว่าโดเมนเสีย

ถ้าอีเมลอยู่ที่โฮสต์เดิม ให้แยกเป็นอีกโปรเจกต์

เลือกระหว่างแพ็กเกจอีเมลอย่างเดียวกับโฮสต์เดิม กล่องอีเมลบนโฮสต์ใหม่ หรือบริการอย่าง Google Workspace หรือ Microsoft 365 สร้างทุกกล่องอีเมลที่ปลายทาง คัดลอกข้อความผ่าน IMAP (ด้วยเครื่องมือนำเข้าของผู้ให้บริการ หรือเครื่องมืออย่าง imapsync) สลับ MX record แล้วคัดลอกอีกรอบ เพื่อเก็บอีเมลที่มาถึงช้า อัปเดตทุกโทรศัพท์และแล็ปท็อป และทำทั้งหมดนี้ในวันที่ไม่ใช่วันย้ายเว็บไซต์

ขั้นที่ 4: คัดลอกและทดสอบบนโฮสต์ใหม่

ทำสภาพแวดล้อมให้ตรงกัน

ปัญหา “บนเซิร์ฟเวอร์เดิมใช้ได้นะ” ส่วนใหญ่มาจากเซิร์ฟเวอร์ ไม่ใช่ตัวเว็บไซต์ (ยังเลือกโฮสต์อยู่? ดู วิธีเลือกเว็บโฮสติ้งให้เว็บเร็ว) ก่อนคัดลอกอะไร ให้เทียบ

• เวอร์ชัน PHP และส่วนขยาย เวอร์ชันฐานข้อมูล ขีดจำกัดหน่วยความจำและการอัปโหลด
• กฎของเซิร์ฟเวอร์ redirect ในไฟล์ .htaccess ของ Apache ไม่มีผลบน Nginx และต้องเขียนใหม่
• งานตั้งเวลา (cron job) สำหรับสำรองข้อมูล ฟีด หรือโพสต์ที่ตั้งเวลาไว้
• บริการภายนอกที่รับเฉพาะ IP ของเซิร์ฟเวอร์คุณ เช่น payment gateway หรือ CRM

คัดลอกไฟล์และฐานข้อมูล

สำหรับ WordPress ให้คัดลอกโฟลเดอร์ wp-content ฐานข้อมูล การตั้งค่าใน wp-config.php และไฟล์อื่นในโฟลเดอร์หลัก เช่น .htaccess โดยใช้ปลั๊กอินย้ายเว็บ บริการย้ายเว็บของโฮสต์ หรือ export เอง

ใช้โดเมนเดิม ถ้า URL ต้องเปลี่ยนชั่วคราว อย่าใช้การค้นหาและแทนที่ในไฟล์ฐานข้อมูล เพราะอาจทำให้ข้อมูลแบบ serialised ที่ WordPress เก็บไว้เสียหาย คำสั่ง search-replace ของ WP-CLI จัดการเรื่องนี้ได้อย่างปลอดภัย

ทดสอบบนโดเมนจริง ก่อนเปลี่ยน DNS

URL พรีวิวชั่วคราวมักทำให้ WordPress พัง เพราะมันคาดหวังโดเมนของตัวเอง ให้แก้ไฟล์ hosts ในคอมพิวเตอร์ของคุณแทน ซึ่งจะแทนที่ DNS สำหรับเครื่องของคุณเท่านั้น โดยใช้สิทธิ์ผู้ดูแลระบบ เพิ่มบรรทัดอย่าง 203.0.113.10 example.com www.example.com (IP ของเซิร์ฟเวอร์ใหม่) ลงใน /etc/hosts บน macOS หรือ Linux หรือ C:\Windows\System32\drivers\etc\hosts บน Windows คุณจะเห็นเซิร์ฟเวอร์ใหม่บนโดเมนจริง ขณะที่คนอื่นยังเห็นเซิร์ฟเวอร์เดิม

ยืนยันด้วยไฟล์ข้อความเล็กๆ ที่มีอยู่บนเซิร์ฟเวอร์ใหม่เท่านั้น จากนั้นทดสอบทุกเทมเพลตหน้า ฟอร์ม การล็อกอิน และการเชื่อมต่อระบบ แล้วลบบรรทัดใน hosts ออกเมื่อเสร็จ

จัดการ SSL ก่อนสลับ

เซิร์ฟเวอร์ใหม่ต้องมีใบรับรองที่ใช้ได้ ตั้งแต่วินาทีที่ทราฟฟิกเข้ามา บางโฮสต์ออกใบรับรองให้ได้ก่อนย้ายจริง ผ่านการยืนยันด้วย DNS (TXT record พิสูจน์ว่าคุณควบคุมโดเมน) หรือคุณจะติดตั้งสำเนาของใบรับรองแบบเสียเงินที่มีอยู่ก็ได้ แต่บางโฮสต์ออกใบรับรองได้ก็ต่อเมื่อ DNS ชี้มาแล้ว ทำให้มีช่วงสั้นๆ ที่เบราว์เซอร์แสดงคำเตือน จึงควรถามไว้ก่อน และตรวจด้วยว่า CAA record (ถ้ามี) อนุญาตผู้ออกใบรับรองของโฮสต์ใหม่

ขั้นที่ 5: ลดค่า TTL แล้วสลับ

ลด TTL ล่วงหน้า

DNS record ทุกตัวมีค่า TTL หรืออายุในแคช คือจำนวนวินาทีที่ resolver เก็บ record นั้นไว้ในแคชได้ สิ่งที่คนเรียกว่า DNS propagation ก็คือการหมดอายุของแคชเหล่านั้น ถ้า TTL เป็น 86400 (24 ชั่วโมง) ผู้เข้าชมบางคนอาจยังเข้าถึงเซิร์ฟเวอร์เดิมได้นานหนึ่งวันหลังคุณสลับ

ดังนั้นให้ลด TTL ของ record ที่จะเปลี่ยนลงเหลือประมาณ 300 วินาที ล่วงหน้าอย่างน้อยเท่ากับค่า TTL เดิมหนึ่งรอบก่อนย้ายจริง แนวทางของ Google เรื่องการย้ายโฮสต์ แนะนำให้ทำล่วงหน้าหนึ่งสัปดาห์ resolver บางตัวบังคับค่าต่ำสุดไว้ จึงอาจมีผู้เข้าชมตกค้างอยู่บ้าง

ลำดับการสลับ

1. เลือกช่วงเวลาที่เงียบ และหยุดแก้ไขเนื้อหา
2. ถ้าเนื้อหา ข้อมูลจากฟอร์ม หรือคำสั่งซื้อ มีการเปลี่ยนแปลงหลังจากคัดลอกไปทดสอบ ให้คัดลอกฐานข้อมูลอีกรอบ โดยพักระบบชำระเงินหรือระบบจองไว้ระหว่างนั้น
3. ชี้ A record ของโดเมนหลักไปที่เซิร์ฟเวอร์ใหม่ และทำกับ www ด้วย ถ้าไม่ได้เป็นชื่อแฝงของโดเมนหลัก
4. อัปเดตหรือลบ AAAA record ถ้าเซิร์ฟเวอร์ใหม่ไม่มีที่อยู่ IPv6 record เก่าจะทำให้ผู้เข้าชมที่ใช้ IPv6 ยังไปที่เซิร์ฟเวอร์เดิม
5. อย่าแตะ record ของ MX, SPF, DKIM และ DMARC รวมถึง record ยืนยันความเป็นเจ้าของ และซับโดเมนของอีเมล เมื่อแก้เรื่องอีเมลตามขั้นที่ 2 เรียบร้อยแล้ว
6. ตรวจจากภายนอก ด้วยเครื่องมือ DNS lookup ออนไลน์ หรือ dig +short example.com A @1.1.1.1 แล้วตามด้วย @8.8.8.8

เขียนแผนย้อนกลับไว้ก่อน จดค่าเดิมทุกค่าก่อนเปลี่ยน เมื่อเซิร์ฟเวอร์เดิมยังไม่ถูกแตะ และ TTL สั้น การย้อนกลับใช้เวลาแค่ไม่กี่นาที

ขั้นที่ 6: ตรวจเว็บไซต์และอีเมล

หน้าแรกที่โหลดขึ้นพิสูจน์ได้น้อยมาก ให้ตรวจตามนี้ แล้วตามด้วย เช็กลิสต์เปิดตัวเว็บไซต์ ฉบับเต็ม

• โดเมนหลักและ www โหลดผ่าน HTTPS และ redirect ไปยังเวอร์ชันเดียว โดยไม่มีคำเตือนเรื่องใบรับรองหรือเนื้อหาปะปน (mixed content)
• ทุกฟอร์มส่งได้ และอีเมลแจ้งเตือนเข้ากล่องจดหมาย ไม่ใช่สแปม
• อีเมลแจ้งเตือนนั้นแสดงว่าผ่าน SPF, DKIM และ DMARC (ใน Gmail ให้เปิด “แสดงต้นฉบับ”)
• อีเมลจากบัญชีภายนอกเข้าถึงที่อยู่อีเมลของบริษัทได้ และโทรศัพท์กับแอปอีเมลยังเชื่อมต่อได้
• การชำระเงิน การจอง และการเชื่อมต่อ CRM ทำงานจาก IP ของเซิร์ฟเวอร์ใหม่
• งานตั้งเวลา การสำรองข้อมูล และการตรวจสอบว่าเว็บไซต์ออนไลน์ ทำงานกับเว็บไซต์จริงทั้งหมด

URL ที่ไม่เปลี่ยน ไม่ต้องใช้เครื่องมือ Change of Address ใน Search Console เพราะเครื่องมือนั้นมีไว้สำหรับโดเมนใหม่ แค่เฝ้าดูรายงาน Crawl stats และ Page indexing สักสองสามสัปดาห์

ทำไมอีเมลจากฟอร์มพังหลังย้ายโฮสต์

ถ้าเว็บไซต์ของคุณส่งอีเมลจากเว็บเซิร์ฟเวอร์โดยตรง SPF record ของคุณอาจอนุญาตเซิร์ฟเวอร์เดิมไว้ด้วย IP ถ้าเซิร์ฟเวอร์ใหม่ไม่ได้อยู่ในรายการ อีเมลของมันจะไม่ผ่าน SPF และถ้าไม่มีลายเซ็น DKIM ที่ถูกต้องสำหรับโดเมนของคุณ ก็จะไม่ผ่าน DMARC ด้วย ภายใต้นโยบาย DMARC แบบ quarantine หรือ reject ฝั่งผู้รับอาจส่งอีเมลเหล่านั้นเข้าสแปม หรือปฏิเสธไปเลย

วิธีแก้ที่ยั่งยืน คือส่งผ่าน SMTP แบบยืนยันตัวตน ผ่านผู้ให้บริการอีเมลของคุณ หรือบริการส่งอีเมลอัตโนมัติ (transactional email) ที่ลงนามด้วย DKIM เพิ่มบริการนั้นลงใน SPF record เดิมของคุณ (การมี SPF record สองตัวจะทำให้การตรวจพัง) และอย่าให้เกินขีดจำกัด 10 DNS lookup ของ SPF

อีกกับดักหนึ่ง แผงควบคุมบางตัวถือว่าตัวเองดูแลอีเมลของโดเมนคุณ อีเมลที่เว็บไซต์ส่งไปยังที่อยู่อีเมลของคุณเอง จึงไปตกในกล่องอีเมลภายในเครื่องที่ว่างเปล่า ถ้าอีเมลของคุณอยู่ที่อื่น ให้ตั้ง Email Routing ใน cPanel เป็น Remote Mail Exchanger หรือค่าที่เทียบเท่าในแผงควบคุมของคุณ

ขั้นที่ 7: เปิดโฮสต์เดิมไว้จนกว่าจะเงียบ

การยกเลิกโฮสต์เดิมในวันย้าย คือทางลัดที่แพงที่สุดในการย้ายโฮสติ้ง ให้เก็บบัญชีเดิมไว้หนึ่งถึงสองสัปดาห์ และก่อนปิด

• ดู access log ของมัน เมื่อเหลือแค่บอทเข้ามาประปราย แปลว่าแคชตามทันแล้ว
• เก็บข้อมูลที่หลงไป ได้แก่ ข้อมูลจากฟอร์ม คำสั่งซื้อ หรืออีเมลที่ไปถึงเซิร์ฟเวอร์เดิมระหว่างการสลับ
• ดาวน์โหลดข้อมูลสำรองแบบเต็ม ทั้งไฟล์ ฐานข้อมูล และกล่องอีเมล (ถ้ามี)
• ปรับ TTL กลับ เป็นค่าปกติ เช่น 3600 วินาที
• จัดการสิทธิ์การเข้าถึง ลบปลั๊กอินย้ายเว็บและบัญชีล็อกอินชั่วคราว และเปลี่ยนรหัสผ่านที่แชร์กันระหว่างย้าย คู่มือความปลอดภัย WordPress อธิบายส่วนที่เหลือ
• ตรวจโดเมน ถ้าจดทะเบียนผ่านโฮสต์เดิม ให้โอนย้ายก่อนปิดบัญชี

ก่อนย้ายเว็บไซต์ไปโฮสต์ใหม่

การสลับใช้เวลาไม่กี่นาที แต่การทำแผนที่ การทดสอบ และความอดทนรอบๆ นั้น คือสิ่งที่ทำให้เว็บไม่ล่ม และอีเมลยังรับส่งได้ต่อไป

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

ไม่แน่ใจว่าเซิร์ฟเวอร์คือสิ่งที่ทำให้เว็บไซต์ของคุณช้าหรือเปล่า? เริ่มจาก ตรวจสอบเว็บไซต์ฟรี หรือ คุยกับเราว่าเว็บไซต์ของคุณต้องการอะไร