การย้ายเว็บไซต์ที่ดีไม่ใช่เพียง Deploy หน้าใหม่ให้เปิดได้ แต่ต้องรู้ว่าจะป้องกันข้อมูลหาย ลิงก์เก่าเสีย ฟอร์มใช้ไม่ได้ และอีเมลหยุดรับอย่างไร Checklist นี้ออกแบบสำหรับเจ้าของธุรกิจและทีมพัฒนาเพื่อใช้เป็น Runbook ตั้งแต่ก่อนเริ่มงานจนถึงหลัง Cutover

หากยังไม่รู้ว่าควรเก็บระบบ PHP/HTML/CMS เดิมหรือเปลี่ยนเป็น Astro ให้เริ่มอ่าน PHP, HTML และ CMS เก่าย้ายมา Astro ได้ไหม ก่อน ส่วนหน้านี้เน้นกระบวนการ Migration ไม่ผูกกับ Framework รายใดรายหนึ่ง

1. กำหนด Scope และเจ้าของงานก่อน

ต้องบอกให้ได้ว่ากำลังเปลี่ยนอะไร: Hosting, Domain, CMS, Design, URL Structure หรือระบบทั้งหมด งานเปลี่ยน Hosting โดยคง URL เดิมมีวิธีควบคุมความเสี่ยงต่างจากการเปลี่ยน Domain Name และ URL พร้อมกัน

งาน คนรับผิดชอบ หลักฐานก่อนผ่าน
Scope/Approval เจ้าของธุรกิจ/Project Owner รายการหน้าและฟังก์ชันที่ต้องคง
Content/SEO Editor/SEO URL Inventory, Canonical, Redirect Map
Application/Data Developer Backup/Restore, Tests, Integration Inventory
Domain/DNS/Email Domain/DNS Admin Zone Export, Mail Records, Cutover Plan
QA/Operations QA/Ops Staging Test Evidence, Runbook, Rollback Trigger

หากคนหนึ่งรับหลายบทบาทก็ได้ แต่ต้องทราบว่าใครเป็นผู้ตัดสินใจถ้าเจอ Critical Issue ไม่ควรกำหนดวันเปิดเว็บโดยไม่รู้ผู้มีอำนาจสลับ DNS

2. Content Inventory: เก็บของเดิมให้ครบ

รวบรวม Sitemap/URL ที่ให้บริการจริงจาก Crawl, CMS Export และ Search Console/Analytics เท่าที่เข้าถึงได้ เพราะ Sitemap อาจไม่รวมทุกหน้าที่มีคนเข้าผ่านลิงก์เก่า

เก็บอย่างน้อย Title, URL, Content Type, Status Code, Canonical, Meta Description, H1, Images/Downloads, Internal Links และเจ้าของเนื้อหา ใส่หมายเหตุว่าเนื้อหาจะ คงเดิม, ปรับปรุง, รวม, ย้าย URL หรือเลิกเผยแพร่ การเพิ่มเว็บไซต์ใหม่โดยไม่มี Inventory เสี่ยงลืมหน้าที่เคยมีผู้เข้าชมจริง

จัดลำดับหน้าสำคัญ เช่น หน้าแรก บริการ สินค้า ติดต่อ บทความที่ได้รับทราฟฟิก และไฟล์ดาวน์โหลดที่มีลิงก์ภายนอกไว้ก่อน

3. Backup ต้องกู้คืนได้ ไม่ใช่แค่มีไฟล์ ZIP

สำรอง Code/Configuration, Database, Media, CMS Export, DNS Zone และรายการ Secret Names (ไม่เก็บค่า Secret ในเอกสารทั่วไป) ให้ครบตามระบบเดิม ทดสอบ Restore อย่างน้อยหนึ่งครั้งบนสภาพแวดล้อมแยกจาก Production โดยตรวจว่าไฟล์/ข้อมูลที่ต้องใช้เปิดได้จริง

ระบุ RPO/RTO ที่ธุรกิจรับได้ และแยก Backup ก่อนเริ่มงานกับ Backup ล่าสุดก่อน Cutover หากมีการเพิ่มข้อมูลสด เช่น ลูกค้ากรอกฟอร์ม หรือสั่งซื้อ ต้องวางช่วง Freeze, Replication หรือ Delta Data Migration ที่เหมาะสม

สำหรับระบบที่มีข้อมูลส่วนบุคคล ต้องกำหนดการเข้าถึง การเข้ารหัส การเก็บรักษาและลบ Backup ตามนโยบายที่เกี่ยวข้อง

4. URL Mapping และ Redirect Plan

ทำตาราง 1 แถวต่อ URL เดิม ระบุ URL ใหม่ สถานะที่ต้องส่งกลับ และเหตุผล ไม่ควรแก้ slug แบบเหมา ๆ จนบทความที่มีลิงก์จากภายนอกเสีย

URL เดิม (จำลอง) ปลายทาง การจัดการ
/about.php /about-us/ 301 หรือ 308 ไปหน้าที่แทนกันจริง
/products/old-a.html /products/a/ Permanent Redirect ตาม Mapping
/blog/topic-old /articles/topic-new/ Redirect เมื่อเนื้อหาสอดคล้อง
/promotion-expired ไม่มีหน้าเทียบ 404/410 เมื่อเลิกอย่างถาวร

Google แนะนำให้ทำ Mapping, ใช้ Permanent Redirect ที่เกี่ยวข้อง และไม่โยนทุก URL ไปหน้า Home เพราะอาจเป็น Soft 404 และควรเก็บ Redirect ให้นานเพียงพอสำหรับผู้ใช้และ Search Engine Google — Site Move with URL Changes

ตรวจทั้ง HTTP/HTTPS และ www/non-www ด้วย และอย่าลืม Redirect รูป/ไฟล์ PDF ที่มีการอ้างถึงจริง

5. สร้าง Staging ที่ไม่รบกวน Production

สร้าง Environment ทดสอบภายใต้โดเมน/URL ที่ควบคุมได้ หลีกเลี่ยงใช้บัญชีและฐานข้อมูล Production แบบแก้ไขได้โดยไม่จำเป็น ป้องกัน Staging จากการถูก Index โดยการควบคุมการเข้าถึงเป็นหลัก ไม่พึ่ง robots.txt เพียงอย่างเดียว

ทดสอบหน้าสำคัญให้มีเนื้อหาและ Assets ครบ ตรวจ Responsive, Form Submission, Email Notifications, Login, Search, Payment (Sandbox), Consent และ Third-party Integrations ตามที่เว็บไซต์ใช้งานจริง

Staging ต้องมีวิธีตั้งค่า Environment Variables/Secrets ผ่านระบบที่ปลอดภัยและแยกจาก Source Code ห้าม Publish API Keys ใน Git

6. QA Gate ก่อน Cutover

แนะนำรายการตรวจอย่างน้อย:

  1. Content: ตรวจหน้า Landing, Products/Services, Blog, Media, PDF และ Navigation ทั้ง Desktop/Mobile
  2. SEO: Status Codes, Title, Description, H1, Canonical, Hreflang (ถ้ามี), Structured Data, Sitemap, robots/noindex
  3. Functionality: Form ส่งจริงในสภาพแวดล้อมที่ได้รับอนุญาต, API, Login/Session และ Integration
  4. Security: HTTPS, Authentication/Authorization, Input Validation, Secrets, Dependency Risk และ Backup
  5. Performance/Accessibility: ภาพ รูปแบบหน้า Web Vitals เมื่อมีเครื่องมือ การอ่านบนมือถือ และการใช้งาน Keyboard
  6. Redirects: ไล่ URL Map โดยตรวจว่า Redirect ไปปลายทางถูกต้อง ไม่เกิด Loop, Chain ยาว หรือ 404
  7. Observability: รู้ที่ดู Logs, Error Alerts และผู้รับ Incident

เขียน Acceptance Criteria ให้ชัด: ข้อใดต้องผ่านก่อน Deploy, ข้อใดเป็นข้อจำกัดที่รับได้ และใครเป็นผู้อนุมัติ หากฟอร์มรับลูกค้าหรือ Checkout ยังใช้ไม่ได้ ไม่ควรเปิดเว็บจริงเพียงเพราะ Build ผ่าน

7. เตรียม Domain/DNS และ Email ก่อนสลับ

ตรวจ Registrar, DNS Provider, SSL/TLS, Subdomain, A/AAAA/CNAME, MX และ TXT ทั้งหมด หากต้องย้ายเว็บไซต์แต่คง Email Provider เดิม ให้เก็บ MX/SPF/DKIM/DMARC ไม่เปลี่ยนโดยไม่จำเป็น

เมื่อเปลี่ยน Nameserver ต้องคัดลอก DNS Records ที่เกี่ยวข้องทั้งหมดไปยัง Zone ใหม่และจัดการ DNSSEC ตามขั้นตอน ส่วนการเปลี่ยน A/CNAME บางจุดไม่จำเป็นต้องเปลี่ยน Nameserver เลย อ่าน DNS Explained และ Domain Renewal & Transfer ก่อนงาน DNS ที่มีผลกระทบสูง

TTL ที่ต่ำช่วยเรื่อง Cache บางส่วน แต่ไม่รับประกันว่าผู้ใช้ทั้งหมดเปลี่ยนปลายทางทันที จึงควรคงระบบเก่าไว้อย่างมีแผนในช่วง Cutover

8. Runbook วัน Cutover

ระบุวัน/เวลาตามเขตเวลาที่ใช้ ผู้อนุมัติ ผู้แก้ไข DNS ผู้ตรวจคุณภาพ และช่องทางสื่อสารกรณีผิดพลาด ตามด้วยขั้นตอน:

  1. ประกาศ Freeze หรือวิธีจัดการข้อมูลที่เปลี่ยนระหว่างย้าย
  2. เก็บ Backup ล่าสุดและตรวจ Restore Readiness
  3. ยืนยันว่า Staging/Preview ผ่าน QA Gate และ Build/Deploy Artifact พร้อม
  4. ตั้งค่า DNS/Traffic Routing ตามแผนที่อนุมัติ
  5. ตรวจ HTTPS และหน้า Critical Paths จาก Browser/เครือข่ายภายนอก
  6. ทดสอบ Contact Form, Checkout/Login และ Email Notification ตามบริบท
  7. ตรวจ Redirect Sample และ Top URLs ทุกกลุ่ม
  8. เปิด Monitoring/Issue Log พร้อมผู้รับผิดชอบ และประกาศสถานะต่อทีม

เมื่อพบความผิดพลาด ให้บันทึกเวลา ระบบที่กระทบ และขั้นตอนที่ทำไปแล้ว แทนการแก้หลายค่าใน DNS พร้อมกันโดยไม่มี Log

9. Rollback: กลับอย่างไรถ้าระบบใหม่มีปัญหา

Rollback ต้องมี Trigger เช่น ฟอร์มหลักส่งไม่ได้, Checkout ล้มเหลว, ข้อมูลไม่ตรงกัน หรือ Critical Security Incident พร้อมผู้อนุมัติและขั้นตอนกลับไป Artifact/Hosting/DB ที่พร้อมใช้งานจริง

การแก้ DNS กลับอย่างเดียวไม่ใช่ Rollback ของข้อมูล หาก Database ใหม่รับข้อมูลไปแล้ว ต้องมีวิธีจัดการ Delta Records หรือแผนรักษาความถูกต้องก่อนกลับไประบบเดิม โดยเฉพาะคำสั่งซื้อและข้อมูลธุรกรรม หากไม่มีวิธี Reverse Migration ที่ตรวจได้ ให้เตรียมการหยุดรับข้อมูลหรือ Escalation ตามที่ตกลงก่อนเริ่ม

บันทึกด้วยว่าใครจะตอบผู้ใช้ระหว่าง Incident และจะตรวจความครบของข้อมูลหลังฟื้นระบบอย่างไร

10. Post-deployment QA และ Monitoring

ภายหลัง Cutover ตรวจ HTTP Status, Redirects, Sitemap, Canonical, robots/noindex, Form, API, Mail Notifications และ Web Analytics โดยเริ่มจาก URL ที่สำคัญที่สุด แล้วติดตาม Trend ของ 404/5xx, Server Logs, Search Console Coverage, Traffic และ Conversion ตามระยะเวลาที่ธุรกิจต้องการ

Google แนะนำให้ติดตามทั้งเว็บเก่าและใหม่ระหว่าง Site Move และยอมรับว่าผลค้นหาอาจผันผวนชั่วคราว การเพิ่ม Sitemap หรือผ่าน Lighthouse ไม่ได้การันตีอันดับค้นหา Google — Site Move

ยังไม่ควรยกเลิก Hosting เก่าจนกว่าจะตรวจว่าไม่มีผู้ใช้หรือระบบจำเป็นต้องพึ่งเส้นทางเก่า และ Backup/Redirect/Retention ได้รับการจัดการครบ

FAQ

เปลี่ยน Hosting แต่ใช้ URL เดิมต้องทำ 301 Redirect ไหม

หาก URL เดิมยังเหมือนเดิมโดยสมบูรณ์ ไม่จำเป็นต้อง Redirect URL เพียงเพราะเปลี่ยนโฮสต์ ให้ตรวจ Canonical, HTTPS และการตอบสนองตามเดิม Google — Changing Hosting แยกจากกรณี URL เปลี่ยน

ย้ายเว็บใหม่แล้ว SEO จะดีขึ้นทันทีไหม

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

ต้องปิดเว็บระหว่างย้ายหรือไม่

ขึ้นกับสถาปัตยกรรม หากเป็น Static Site มักย้ายปลายทางและทดสอบก่อนได้ แต่ระบบที่เขียนฐานข้อมูลต่อเนื่องอาจต้องมี Freeze Window หรือกระบวนการ Sync เพื่อไม่ให้ข้อมูลขัดกัน

Checklist ฉบับส่งมอบ

  • Scope/Owner/Acceptance Criteria ชัดเจน
  • Content & Feature Inventory ครบ
  • Backup + Restore Test ผ่าน
  • URL Mapping, Redirects และ Canonical ตรวจได้
  • Staging QA ครบทั้งมือถือ ฟอร์ม อีเมล และระบบหลังบ้าน
  • มี DNS Zone Backup และไม่ได้ทำ Mail Records หาย
  • Runbook, Freeze/Delta Migration และ Rollback Trigger พร้อม
  • ทดสอบ Production หลัง Cutover จากภายนอกจริง
  • ตั้ง Monitoring และผู้รับแก้ Issue หลังเปิดเว็บ
  • จัดทำเอกสารส่งมอบ Domain, Hosting, Code, Backup และ Credentials อย่างปลอดภัย

สำหรับเว็บที่สร้างด้วย AI แต่ยัง Deploy ไม่เป็น ให้เพิ่ม AI Website Production Checklist ที่เน้นโค้ด, Secrets และระบบ Backend ส่วนงานบริการอ่าน Website Migration ของ Prai.io

อ้างอิง: Google Search Central — Site Moves, Google — Changing Hosting, Cloudflare DNS Record Types, Astro Deployment Guide ตรวจ 3 พฤศจิกายน 2026

✳
มีเว็บไซต์เดิมหรือโค้ดจาก AI ที่อยากพัฒนาต่อ?

ประเมินสภาพระบบเดิมก่อนเลือกระหว่าง Deploy ของเดิม ปรับโค้ด หรือเปลี่ยนแพลตฟอร์ม ไม่จำเป็นต้องรื้อใหม่ทุกงาน

ดูขอบเขตบริการที่เกี่ยวข้อง ↗