ย้าย WordPress จาก Staging ไป Production อย่างปลอดภัย

การย้าย WordPress จาก Staging (เว็บทดสอบ) ไปยัง Production (เว็บจริง) เป็นขั้นตอนที่นักพัฒนาและเจ้าของเว็บหลายคนมองข้ามความสำคัญ จนเมื่อเกิดปัญหาขึ้นจริงอย่างเว็บพัง ข้อมูลหาย หรือ SEO เสียหาย จึงค่อยรู้ว่าควรวางแผนตั้งแต่ต้น บทความนี้อธิบายทุกขั้นตอนอย่างละเอียดตั้งแต่การเตรียมการก่อน Deploy ไปจนถึงการตรวจสอบหลังย้าย เพื่อให้เว็บ Production ทำงานได้อย่างราบรื่นไม่มีสะดุด

ทำความเข้าใจ Staging กับ Production คืออะไร

ก่อนเริ่มกระบวนการย้าย ควรเข้าใจก่อนว่า Staging Environment และ Production Environment ต่างกันอย่างไร เพราะความเข้าใจตรงนี้จะช่วยให้วางแผนการย้ายได้อย่างถูกต้อง

Staging Environment คือสภาพแวดล้อมสำหรับทดสอบที่จำลองระบบ Production ให้ใกล้เคียงที่สุด ใช้สำหรับทดสอบฟีเจอร์ใหม่ อัพเดต Plugin หรือ Theme แก้บัก และตรวจสอบว่าทุกอย่างทำงานถูกต้องก่อนที่ผู้ใช้จริงจะเห็น ข้อดีคือถ้าเกิดความผิดพลาดใน Staging ก็ไม่กระทบกับเว็บที่ผู้ใช้ใช้งานอยู่

Production Environment คือเว็บไซต์จริงที่ผู้ใช้และ Search Engine เข้าถึงทุกวัน การเปลี่ยนแปลงที่นี่มีผลทันทีกับ Traffic SEO และประสบการณ์ของผู้ใช้ ดังนั้นทุกการเปลี่ยนแปลงต้องผ่านการทดสอบใน Staging ก่อนเสมอ

ประเด็นสำคัญที่ต้องเข้าใจคือ WordPress เก็บ URL ของเว็บไซต์ไว้ใน Database ทั้ง siteurl และ home รวมถึงลิงก์ภายในในเนื้อหาบทความ เมื่อย้ายจาก Staging ไป Production ต้องอัพเดต URL เหล่านี้ทั้งหมด ไม่เช่นนั้นเว็บจะทำงานผิดปกติ

การเตรียมการก่อนย้าย — สิ่งที่ต้องทำก่อน Deploy

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

1. สำรองข้อมูล Production ปัจจุบัน

แม้ว่าจะเป็นการย้ายข้อมูลจาก Staging มา Production แต่ควรสำรองข้อมูล Production ที่มีอยู่ก่อนเสมอ เผื่อในกรณีที่ต้องการ Rollback กลับไปเวอร์ชันเดิม

# Backup Database Production ด้วย mysqldump
mysqldump -u USERNAME -p PRODUCTION_DB_NAME > backup_production_$(date +%Y%m%d_%H%M%S).sql

# Backup ไฟล์เว็บทั้งหมด
tar -czf backup_files_$(date +%Y%m%d_%H%M%S).tar.gz /home/username/public_html/

2. ตรวจสอบและทดสอบใน Staging ให้เรียบร้อย

ก่อนย้ายควรตรวจสอบรายการต่อไปนี้ใน Staging ให้ครบ:

• ฟีเจอร์ทุกอย่างทำงานถูกต้อง ไม่มี PHP Error ใน Error Log
• Form ต่างๆ ส่งข้อมูลได้ปกติ
• รูปภาพและมีเดียแสดงผลครบถ้วน
• Plugin ทุกตัว Compatible กับ PHP version ที่ใช้
• เว็บดูดีบนมือถือ (Mobile Responsive)
• ความเร็วหน้าเว็บผ่านเกณฑ์ที่ยอมรับได้

3. จดบันทึก Credentials และการตั้งค่าสำคัญ

รวบรวมข้อมูลที่จำเป็นสำหรับการตั้งค่า Production ไว้ล่วงหน้า ได้แก่ Database Name, Database User, Password, Database Host, FTP/SSH credentials ของ Production Server และ Domain ของ Production จริง

ขั้นตอนที่ 1 — Export ข้อมูลจาก Staging

เริ่มกระบวนการย้ายด้วยการ Export ข้อมูลทั้งหมดจาก Staging ออกมาก่อน แบ่งเป็น 2 ส่วนหลัก คือ Database และ ไฟล์เว็บ

Export Database จาก Staging

ใช้คำสั่ง mysqldump ผ่าน SSH หรือ Export ผ่าน phpMyAdmin ใน DirectAdmin:

# Export ผ่าน SSH (แนะนำ — ไม่มี timeout limit)
mysqldump -u STAGING_DB_USER -p STAGING_DB_NAME \
  --single-transaction \
  --routines \
  --triggers \
  > staging_export_$(date +%Y%m%d).sql

# หรือ Export เฉพาะ Structure + Data ไม่รวม Comments
mysqldump -u STAGING_DB_USER -p STAGING_DB_NAME \
  --compact --no-tablespaces \
  > staging_export_clean.sql

ตัวเลือก --single-transaction สำคัญมากสำหรับ InnoDB Tables เพราะจะทำให้ Export ข้อมูลที่ Consistent กัน โดยไม่ต้อง Lock Table ซึ่งอาจทำให้เว็บช้าระหว่าง Export

Export ไฟล์เว็บจาก Staging

ดาวน์โหลดไฟล์เว็บผ่าน FTP หรือ Compress ผ่าน SSH แล้วดาวน์โหลดมาทีเดียว:

# Compress ไฟล์ทั้งหมดผ่าน SSH (เร็วกว่า FTP มาก)
cd /home/staging_user/public_html/
tar -czf ~/staging_files.tar.gz \
  --exclude='.git' \
  --exclude='*.log' \
  --exclude='wp-content/cache' \
  .

# ดาวน์โหลดไฟล์มาเครื่อง Local
scp [email protected]:/home/staging_user/staging_files.tar.gz ./

ขั้นตอนที่ 2 — อัพโหลดและ Import ไปยัง Production

หลังจากได้ไฟล์และ Database Export แล้ว ขั้นตอนต่อไปคืออัพโหลดไปยัง Production Server และ Import Database

อัพโหลดไฟล์ไปยัง Production

# อัพโหลดและ Extract ผ่าน SSH (แนะนำ)
scp staging_files.tar.gz [email protected]:/home/prod_user/

# SSH เข้า Production แล้ว Extract
ssh [email protected]
cd /home/prod_user/public_html/
tar -xzf ~/staging_files.tar.gz
rm ~/staging_files.tar.gz  # ลบไฟล์ชั่วคราวออก

Import Database เข้า Production

# สร้าง Database ใหม่ใน Production (ถ้ายังไม่มี)
# ทำผ่าน DirectAdmin: Databases > Create Database

# Import ผ่าน SSH
mysql -u PROD_DB_USER -p PROD_DB_NAME < staging_export.sql

# หรือ Import ผ่าน phpMyAdmin
# เลือก Database > แท็บ Import > เลือกไฟล์ .sql

ขั้นตอนที่ 3 — แก้ไข wp-config.php ให้ตรงกับ Production

นี่คือขั้นตอนที่สำคัญมาก เพราะ wp-config.php ที่ Copy มาจาก Staging ยังมีค่า Database ของ Staging อยู่ ต้องแก้ให้ตรงกับ Production ทุก field

# แก้ไข wp-config.php
define('DB_NAME',     'production_database_name');
define('DB_USER',     'production_db_user');
define('DB_PASSWORD', 'production_db_password');
define('DB_HOST',     'localhost');
define('DB_CHARSET',  'utf8mb4');

// ถ้า Staging ใช้ Prefix ต่างจาก Production ต้องแก้ด้วย
$table_prefix = 'wp_';

// Security Keys — Generate ใหม่เสมอสำหรับ Production
// เข้า https://api.wordpress.org/secret-key/1.1/salt/ เพื่อ Generate ใหม่
define('AUTH_KEY',         'ใส่ค่าใหม่ที่ Generate ได้');
define('SECURE_AUTH_KEY',  'ใส่ค่าใหม่ที่ Generate ได้');
define('LOGGED_IN_KEY',    'ใส่ค่าใหม่ที่ Generate ได้');
define('NONCE_KEY',        'ใส่ค่าใหม่ที่ Generate ได้');

ขั้นตอนที่ 4 — เปลี่ยน URL ใน Database (Search and Replace)

นี่คือขั้นตอนที่ละเอียดอ่อนที่สุดในการย้าย WordPress เพราะ WordPress เก็บ URL ไว้หลายที่ใน Database ทั้งใน wp_options, wp_posts, wp_postmeta และอื่นๆ การ Replace ด้วย Simple Find and Replace อาจทำให้ข้อมูลที่ Serialize แล้วเสียหาย วิธีที่ถูกต้องคือใช้เครื่องมือที่เข้าใจ PHP Serialized Data

วิธีที่ 1 — ใช้ WP-CLI (แนะนำที่สุด)

# ดู URL ปัจจุบันก่อน
wp option get siteurl
wp option get home

# ทดสอบก่อนด้วย --dry-run
wp search-replace 'https://staging.example.com' 'https://example.com' \
  --all-tables \
  --dry-run

# รัน Replace จริงเมื่อตรวจสอบแล้ว
wp search-replace 'https://staging.example.com' 'https://example.com' \
  --all-tables

# Flush Cache หลัง Replace
wp cache flush
wp rewrite flush

วิธีที่ 2 — แก้ผ่าน Database โดยตรง (กรณีไม่มี WP-CLI)

-- แก้ siteurl และ home ใน wp_options
UPDATE wp_options
SET option_value = 'https://example.com'
WHERE option_name = 'siteurl';

UPDATE wp_options
SET option_value = 'https://example.com'
WHERE option_name = 'home';

-- ตรวจสอบ URL ที่แก้แล้ว
SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');

หลังจากแก้ wp_options แล้ว ยังต้องใช้ Plugin หรือ Script แยกเพื่อ Replace URL ในเนื้อหาบทความ (wp_posts, wp_postmeta) เพราะข้อมูลบางส่วน Serialize ไว้และต้องการการจัดการพิเศษ ตัวเลือกที่แนะนำคือ Plugin "Better Search Replace" (ดาวน์โหลดได้จาก WordPress.org ฟรี)

ขั้นตอนที่ 5 — ตั้งค่า DNS และ SSL Certificate

เมื่อย้ายข้อมูลและแก้ URL เรียบร้อยแล้ว ขั้นตอนต่อไปคือตั้งค่า DNS ให้ Domain ชี้มายัง Production Server และติดตั้ง SSL Certificate

ตั้งค่า Force HTTPS ใน .htaccess

# เพิ่มใน .htaccess ของ WordPress
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# WordPress Default Permalinks Rule (ต้องมีด้วย)
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

ขั้นตอนที่ 6 — Flush Cache และแก้ไข Permissions

หลังจากย้ายไฟล์และแก้ Database แล้ว ต้องตรวจสอบ File Permissions และ Flush Cache ทุกชั้นเพื่อให้เว็บทำงานได้อย่างถูกต้อง

ตั้งค่า File Permissions ที่ถูกต้อง

# Permissions มาตรฐานสำหรับ WordPress
find /home/username/public_html/ -type d -exec chmod 755 {} \;
find /home/username/public_html/ -type f -exec chmod 644 {} \;

# wp-config.php ต้องเข้มงวดกว่า
chmod 640 /home/username/public_html/wp-config.php

# wp-content/uploads ต้องให้ PHP เขียนได้
chmod 755 /home/username/public_html/wp-content/uploads/

Flush Cache ทุกชั้น

# Flush WordPress Object Cache (ถ้าใช้ Redis/Memcached)
wp cache flush

# Flush Rewrite Rules (แก้ปัญหา 404)
wp rewrite flush

# ถ้าใช้ Caching Plugin เช่น WP Rocket, W3 Total Cache
wp rocket clean --post=all    # WP Rocket
wp w3-total-cache flush all   # W3 Total Cache

# ล้าง OPcache ของ PHP (ถ้ามี SSH Access)
php -r "opcache_reset();"

ขั้นตอนที่ 7 — ตรวจสอบหลัง Deploy (Post-Deployment Checklist)

การตรวจสอบหลัง Deploy เป็นขั้นตอนที่มักถูกมองข้าม แต่เป็นสิ่งจำเป็นที่ต้องทำทุกครั้ง รายการตรวจสอบที่ควรทำ:

• เปิดเว็บและตรวจสอบหน้าหลัก — ไม่มี Error Message, รูปภาพแสดงผลครบ
• ตรวจ Browser Console — ไม่มี 404 Error สำหรับ JS, CSS หรือรูปภาพ
• ทดสอบ Form ต่างๆ — Contact Form, Comment, Registration ทำงานได้ปกติ
• ทดสอบ Login ทั้ง Front-end และ Admin
• ตรวจสอบ Permalink — URL ทุกหน้าทำงานได้ถูกต้อง ไม่มี 404
• ตรวจ Mixed Content — ไม่มี HTTP Resources บน HTTPS Page
• ทดสอบบนมือถือ — หน้าเว็บดูดีทุกขนาดหน้าจอ
• ตรวจสอบ Google Analytics / Tracking — ข้อมูล Tracking ส่งถูกต้อง
• ตรวจ robots.txt — ไม่ได้บล็อก Search Engine (ตรวจพิเศษกรณีที่ Staging ตั้ง Disallow: /)
• ส่ง Sitemap ไปยัง Google Search Console

ตรวจสอบ robots.txt เป็นเรื่องด่วน

WordPress มีตัวเลือกใน Settings > Reading ที่ชื่อว่า "Discourage search engines from indexing this site" ซึ่งมักถูกเปิดไว้ใน Staging เพื่อไม่ให้ Google Crawl ต้องตรวจสอบว่าตัวเลือกนี้ถูก Uncheck แล้วใน Production ก่อนที่จะ Flush Cache

# ตรวจสอบ robots.txt ผ่าน WP-CLI
wp option get blog_public

# ค่า 1 = อนุญาต Search Engine (ถูกต้องสำหรับ Production)
# ค่า 0 = บล็อก Search Engine (ต้องแก้ไข)

# แก้ไขให้ถูกต้อง
wp option update blog_public 1

การแก้ปัญหาที่พบบ่อยหลัง Deploy

แม้จะทำตามขั้นตอนครบแล้ว ยังอาจพบปัญหาบางอย่างหลัง Deploy ซึ่งมักมีวิธีแก้ที่ชัดเจน:

ปัญหา: White Screen of Death (หน้าขาวเปล่า)

สาเหตุที่พบบ่อยคือ PHP Memory Limit ไม่พอ หรือ Plugin/Theme ขัดแย้งกัน วิธีแก้:

# เพิ่ม Memory Limit ใน wp-config.php
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

# เปิด Debug Mode ชั่วคราวเพื่อดู Error
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

# อ่าน Debug Log
tail -f /home/username/public_html/wp-content/debug.log

ปัญหา: หน้าเว็บแสดง 404 ยกเว้นหน้าหลัก

ปัญหานี้เกิดจาก Permalink Rules ไม่ถูก Flush ให้เข้า Admin > Settings > Permalinks แล้วกด Save Changes โดยไม่ต้องเปลี่ยนค่าใดๆ WordPress จะ Regenerate .htaccess ให้อัตโนมัติ

ปัญหา: รูปภาพไม่แสดง

ตรวจสอบว่า URL ใน Database ถูก Replace ครบหรือยัง โดยเฉพาะใน wp_postmeta ที่เก็บ Attachment URL บางครั้ง WP-CLI Search-Replace ต้องรันซ้ำ 2 รอบสำหรับข้อมูลที่ Double Serialize

# ตรวจสอบ URL ที่ยังค้างใน postmeta
SELECT meta_value FROM wp_postmeta
WHERE meta_value LIKE '%staging.example.com%'
LIMIT 10;

คำถามที่พบบ่อย (FAQ)

ควรสำรองข้อมูลก่อนย้าย Staging ไป Production ไหม

ควรสำรองข้อมูลทุกครั้งก่อนย้าย ทั้ง Database ด้วย mysqldump และไฟล์เว็บทั้งหมด (wp-content, wp-config.php) เก็บไว้นอกเซิร์ฟเวอร์ อย่างน้อย 2 ที่ เช่น Local กับ Cloud Storage เพื่อให้สามารถ Rollback ได้หากเกิดปัญหาหลัง Deploy

ทำไม URL ใน WordPress ต้องเปลี่ยนเมื่อย้ายจาก Staging ไป Production

WordPress เก็บ URL ของเว็บไว้ใน Database ตาราง wp_options ค่า siteurl และ home รวมถึงเนื้อหาบทความที่มีลิงก์ภายใน ถ้าไม่เปลี่ยน URL ทุกลิงก์จะยังชี้ไปยัง Staging Domain ทำให้เว็บ Production โหลดทรัพยากรผิดที่ หน้าพัง และ SEO เสียหายเพราะ canonical ชี้ผิด

Search and Replace URL ใน Database ต้องทำด้วยวิธีไหนที่ปลอดภัยที่สุด

ใช้ WP-CLI ด้วยคำสั่ง wp search-replace 'https://staging.example.com' 'https://example.com' --all-tables หรือใช้ Plugin Better Search Replace (ต้องลบออกหลังใช้งาน) วิธีที่ปลอดภัยที่สุดคือทดสอบด้วย --dry-run ก่อน เพื่อดูว่าจะมีการเปลี่ยนแปลงกี่ row ก่อนรัน Replace จริง

หลังย้าย WordPress ไป Production แล้วหน้าเว็บแสดง 404 ต้องทำอย่างไร

ปัญหา 404 หลังย้ายมักเกิดจาก Permalink Structure ค้างจาก Staging ให้เข้า WordPress Admin ไปที่ Settings > Permalinks แล้วกด Save Changes โดยไม่ต้องเปลี่ยนค่าใดๆ WordPress จะ Flush Rewrite Rules และสร้าง .htaccess ใหม่ให้อัตโนมัติ