สร้าง WordPress Staging Site บน Shared Hosting

การทดสอบการเปลี่ยนแปลงบนเว็บไซต์ WordPress จริงโดยตรงเป็นความเสี่ยงที่ควรหลีกเลี่ยง Staging Site คือสำเนาของเว็บที่ใช้ทดสอบ Plugin ใหม่ ธีม หรืออัปเดต WordPress Core ก่อน Deploy จริง บทความนี้แนะนำวิธีสร้าง WordPress Staging Site บน Shared Hosting ด้วย DirectAdmin ทีละขั้นตอน

Staging Site คืออะไรและทำไมถึงจำเป็น

Staging Site คือสภาพแวดล้อมทดสอบที่แยกจาก Production ใช้สำหรับ:

• ทดสอบอัปเดต WordPress Core โดยไม่กระทบเว็บจริง
• ทดสอบ Plugin หรือ Theme ใหม่อย่างปลอดภัย
• ทดสอบการแก้ไขโค้ดหรือ CSS ก่อน Publish
• ป้องกันเว็บดาวน์จากการอัปเดตที่มีปัญหา
• แสดงให้ลูกค้าดูก่อนอนุมัติการเปลี่ยนแปลง

เตรียมความพร้อมก่อนสร้าง Staging

สิ่งที่ต้องมีก่อนเริ่มต้น:

• Subdomain สำหรับ Staging เช่น staging.yourdomain.com
• Database ใหม่แยกจาก Production
• พื้นที่เก็บข้อมูลเพียงพอ (อย่างน้อยเท่ากับขนาดเว็บ Production)

ขั้นตอนที่ 1 — สร้าง Subdomain สำหรับ Staging

1. เข้า DirectAdmin → Domain Setup → Subdomains
2. พิมพ์ชื่อ subdomain เช่น staging
3. คลิก Create
4. DirectAdmin สร้างโฟลเดอร์สำหรับ subdomain ใน File Manager อัตโนมัติ

ขั้นตอนที่ 2 — สร้าง Database ใหม่

1. เข้า DirectAdmin → MySQL Management
2. คลิก Create New Database
3. ตั้งชื่อ เช่น username_staging
4. สร้าง Database User และ Password แล้วกด Create

ขั้นตอนที่ 3 — Copy ไฟล์ WordPress

ใช้ File Manager คัดลอกไฟล์จาก public_html/ ไปยังโฟลเดอร์ Staging:

1. เข้า File Manager
2. เลือกทุกไฟล์ใน public_html/
3. คลิก Copy และเลือกโฟลเดอร์ Staging เป็นปลายทาง

หรือถ้ามี Shell Access:

cp -r /home/username/public_html/. /home/username/domains/staging.yourdomain.com/public_html/

ขั้นตอนที่ 4 — Export และ Import Database

1. เข้า DirectAdmin → phpMyAdmin
2. เลือก Database Production คลิก Export → Go บันทึกไฟล์ .sql
3. ไปที่ Database Staging คลิก Import เลือกไฟล์ .sql

ขั้นตอนที่ 5 — แก้ไข wp-config.php

แก้ไข wp-config.php ในโฟลเดอร์ Staging ให้ชี้ไปยัง Database ใหม่:

define('DB_NAME', 'username_staging');
define('DB_USER', 'staging_user');
define('DB_PASSWORD', 'your_staging_password');
define('DB_HOST', 'localhost');

ขั้นตอนที่ 6 — อัปเดต URL ใน Database

รันคำสั่ง SQL นี้ใน phpMyAdmin เพื่ออัปเดต URL จาก Production เป็น Staging:

UPDATE wp_options SET option_value = 'https://staging.yourdomain.com'
WHERE option_name = 'siteurl' OR option_name = 'home';

หรือใช้ WP-CLI: wp search-replace 'https://yourdomain.com' 'https://staging.yourdomain.com'

สรุปขั้นตอนสร้าง Staging Site แบบทำมือทั้งหมด

เพื่อให้เห็นภาพรวมทั้งกระบวนการ ต่อไปนี้คือลำดับการสร้าง WordPress Staging Site บน Shared Hosting ด้วย DirectAdmin ตั้งแต่ต้นจนจบ ทำตามทีละขั้นตอนจะได้สำเนาเว็บที่ทำงานได้สมบูรณ์บน Subdomain:

1. สร้าง Subdomain — เข้า DirectAdmin → Subdomains แล้วสร้าง staging.yourdomain.com เพื่อให้มีโฟลเดอร์และที่อยู่แยกจาก Production ชัดเจน
2. คัดลอกไฟล์ทั้งหมด — Copy ทุกไฟล์จาก public_html/ (รวมโฟลเดอร์ wp-content, ไฟล์ .htaccess และไฟล์ซ่อนทั้งหมด) ไปยังโฟลเดอร์ Staging
3. คัดลอกฐานข้อมูล — Export Database Production จาก phpMyAdmin แล้ว Import เข้า Database Staging ที่สร้างใหม่
4. แก้ wp-config.php — ชี้ DB_NAME, DB_USER, DB_PASSWORD ไปยังฐานข้อมูล Staging
5. อัปเดต URL ในฐานข้อมูล — ใช้ wp search-replace หรือ SQL เปลี่ยน siteurl/home และ URL ที่ฝังในเนื้อหา (serialized data) ให้เป็นโดเมน Staging
6. ตั้งค่าป้องกันการ Index และล็อกการเข้าถึง — ใส่ Password Protection และ noindex เพื่อไม่ให้ Google เก็บข้อมูล Staging

หัวข้อถัดไปจะลงรายละเอียดของจุดที่มือใหม่มักพลาด ทั้งเรื่องการ search-replace URL, การ push กลับ Production และการใช้ปลั๊กอินช่วย

ใช้ปลั๊กอิน Staging (WP Staging) หรือทำมือ แบบไหนดีกว่ากัน

การสร้าง Staging Site ทำได้ทั้งแบบ "ทำมือ" ผ่าน DirectAdmin/phpMyAdmin ตามขั้นตอนด้านบน และแบบ "ใช้ปลั๊กอิน" เช่น WP Staging, Duplicator หรือ WP Migrate ทั้งสองวิธีมีจุดเด่นต่างกัน:

คำแนะนำ: ถ้าเป็นเว็บเล็กถึงกลางและต้องการความรวดเร็ว ปลั๊กอินอย่าง WP Staging เหมาะที่สุด แต่ถ้าต้องการควบคุมทุกขั้นตอน เข้าใจระบบ และไม่อยากติดตั้งปลั๊กอินเพิ่มบนเว็บ Production การทำมือผ่าน DirectAdmin จะยืดหยุ่นกว่าและไม่กระทบประสิทธิภาพเว็บจริง

Push Staging กลับ Production อย่างปลอดภัย

เมื่อทดสอบบน Staging ผ่านแล้วและต้องการนำการเปลี่ยนแปลงขึ้น Production จริง อย่ารีบ Copy ทับทั้งโฟลเดอร์/ทั้งฐานข้อมูลแบบไม่คิด เพราะระหว่างที่ทดสอบ เว็บ Production อาจมีข้อมูลใหม่เพิ่มเข้ามา (คำสั่งซื้อ คอมเมนต์ สมาชิกใหม่) การทับทั้งหมดจะทำให้ข้อมูลเหล่านั้นหายไป ทำตามแนวทางนี้:

1. Backup Production ก่อนเสมอ — สำรองทั้งไฟล์และฐานข้อมูล Production ผ่าน DirectAdmin ก่อนแตะต้องอะไร เพื่อให้ย้อนกลับได้ทันทีหากมีปัญหา
2. แยกประเภทการเปลี่ยนแปลง — ถ้าเปลี่ยนเฉพาะธีม/ปลั๊กอิน/โค้ด ให้ Copy เฉพาะไฟล์ใน wp-content/themes หรือ wp-content/plugins ไม่ต้องแตะฐานข้อมูล
3. ระวังการทับฐานข้อมูล — ถ้าจำเป็นต้องนำตารางจาก Staging ขึ้น ให้เลือก import เฉพาะตารางที่เกี่ยวข้อง (เช่น wp_options สำหรับการตั้งค่า) ไม่ใช่ทับทั้งฐาน
4. แทนที่ URL กลับเป็นโดเมนจริง — ถ้านำข้อมูลจาก Staging ขึ้น อย่าลืม search-replace https://staging.yourdomain.com → https://yourdomain.com ก่อน ไม่งั้นลิงก์และรูปจะชี้ผิด
5. ทดสอบทันทีหลัง Push — เปิดหน้าแรก หน้าสำคัญ และหน้า login ทันทีเพื่อยืนยันว่าเว็บจริงยังทำงานปกติ

หากกังวลเรื่องข้อมูลที่เพิ่มระหว่างทดสอบ ทางที่ปลอดภัยที่สุดคือทำการเปลี่ยนแปลงซ้ำบน Production โดยตรงในช่วงเวลาที่มีคนใช้น้อย แทนที่จะทับฐานข้อมูลทั้งก้อนจาก Staging

ข้อควรระวังที่มือใหม่มักพลาด

Staging Site ที่ตั้งค่าไม่รอบคอบอาจสร้างปัญหากับ Production หรือกับ SEO ได้ ระวังจุดเหล่านี้:

• ตั้ง noindex ให้ Staging เสมอ — เข้า Settings → Reading แล้วติ๊ก "Discourage search engines" และเพิ่ม Password Protection ผ่าน DirectAdmin เพื่อไม่ให้ Google เก็บ Staging เป็น Duplicate Content ซึ่งกระทบอันดับเว็บจริง
• อย่าลืม search-replace URL ให้ครบ — URL ของ WordPress ฝังอยู่ในข้อมูลแบบ serialized การแก้ด้วย SQL UPDATE ตรงๆ อาจทำให้ข้อมูลที่ serialized เสียหาย จึงควรใช้ wp search-replace ที่เข้าใจ serialized data หรือปลั๊กอินที่จัดการให้
• เคลียร์ Cache บน Staging — ถ้า Production ใช้ปลั๊กอิน Cache (WP Super Cache, LiteSpeed Cache ฯลฯ) ให้ล้าง cache บน Staging หลังคัดลอก ไม่งั้นจะเห็นหน้าเก่าค้างหรือลิงก์ชี้ไป Production
• ปิด WP-Cron บน Staging — เพิ่ม define('DISABLE_WP_CRON', true); เพื่อไม่ให้ Staging รัน scheduled task เช่น ส่งอีเมล โพสต์อัตโนมัติ หรือเรียก API จริงซ้ำซ้อนกับ Production
• แยก SMTP/Payment ออกจากของจริง — บน Staging ควรปิดหรือใช้ค่า sandbox สำหรับ Payment Gateway และระบบส่งอีเมล เพื่อไม่ให้เผลอส่งอีเมลหรือตัดเงินลูกค้าจริงระหว่างทดสอบ

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

Staging Site กิน Subdomain เพิ่มหรือไม่ และมีผลต่อ SEO เว็บจริงไหม

Staging ใช้ Subdomain แยก เช่น staging.yourdomain.com ซึ่งไม่กระทบ SEO ของโดเมนหลัก ตราบใดที่ตั้ง noindex และล็อกด้วย Password Protection ไว้ Google จะไม่เก็บหน้านี้เป็น Duplicate Content แพ็กเกจ AsiaGB Hosting รองรับ Subdomain ไม่จำกัด จึงสร้าง Staging ได้โดยไม่มีค่าใช้จ่ายเพิ่ม

ทำ Staging Site เองยากไหมสำหรับมือใหม่

ถ้าทำมือต้องเข้าใจ 3 เรื่องหลักคือ Subdomain, การคัดลอกฐานข้อมูล และการแก้ wp-config.php ซึ่งบทความนี้อธิบายไว้ครบ หากต้องการความง่ายกว่า สามารถใช้ปลั๊กอิน WP Staging ที่ clone เว็บได้ในไม่กี่คลิก แต่การทำมือผ่าน DirectAdmin จะช่วยให้เข้าใจระบบและไม่ต้องติดตั้งปลั๊กอินเพิ่มบนเว็บจริง

หลังทดสอบเสร็จควรลบ Staging Site ทิ้งไหม

ควรลบหรือปิด Staging เมื่อไม่ได้ใช้งาน เพื่อประหยัดพื้นที่และลดความเสี่ยงด้านความปลอดภัย (Staging เก่ามักไม่ได้อัปเดตปลั๊กอิน/ธีม จึงเป็นช่องโหว่ได้) หากต้องใช้บ่อย ให้คงไว้แต่ล็อกด้วย Password Protection และ noindex เสมอ พร้อม Backup ทั้ง Production และ Staging อย่างสม่ำเสมอ

Push การเปลี่ยนแปลงจาก Staging กลับ Production แล้วข้อมูลลูกค้าหายไหม

มีโอกาสหายถ้าทับฐานข้อมูลทั้งก้อน เพราะ Production อาจมีคำสั่งซื้อหรือสมาชิกใหม่เกิดขึ้นระหว่างทดสอบ ทางที่ปลอดภัยคือ Backup Production ก่อน แล้ว Push เฉพาะไฟล์ธีม/ปลั๊กอินที่เปลี่ยน หรือ import เฉพาะตารางที่จำเป็น ไม่ใช่ทับทั้งฐานข้อมูล