WordPress หน้าขาว (White Screen of Death) เข้าเว็บไม่ได้ แก้ยังไง

WordPress หน้าขาว หรือ White Screen of Death (WSoD) คืออาการที่เปิดเว็บแล้วเจอหน้าขาวล้วน ไม่มีข้อความ Error ใดเลย ส่วนใหญ่เกิดจาก PHP ทำงานพังกลางทางแต่ถูกตั้งค่าไม่ให้แสดง Error บนหน้าจอ เอกสารของ WordPress ระบุว่าทั้ง PHP Error และ Database Error แสดงผลเป็นหน้าขาวได้ และต้นเหตุที่พบบ่อยคือปลั๊กอินหรือธีม (WordPress Developer Resources) วิธีแก้คือหาสาเหตุจาก HTTP Status Code และ Error Log ก่อน แล้วค่อยปิดปลั๊กอิน สลับธีม ล้างแคช หรือรีเซ็ต .htaccess ตามที่ log บอก ข้อมูลในฐานข้อมูลไม่ได้หายไปไหน

หน้าขาวน่ากลัวกว่า Error ทั่วไปตรงที่ไม่มีอะไรบอกใบ้เลย บทความนี้จะพาไล่ดูทีละจุดแบบที่หมอเว็บใช้จริง ตั้งแต่ดูรหัสสถานะในเบราว์เซอร์ไปจนถึงรีเซ็ตไฟล์ตั้งค่า ข้อมูลอ้างอิงเอกสาร WordPress, PHP และผู้ให้บริการ ณ วันที่ 29 ตุลาคม 2026 ถ้าเว็บล่มด้วยอาการอื่น ดูภาพรวมได้ที่ WordPress เว็บล่ม แก้ยังไง

White Screen of Death คืออะไร ทำไมถึงน่ากลัวกว่า Error ทั่วไป

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

• หน้าขาวทั้งเว็บ ทั้งหน้าบ้านและ wp-admin ใช้ไม่ได้
• หน้าขาวเฉพาะหลังบ้าน คนทั่วไปเข้าเว็บได้ปกติ แต่เข้า wp-admin ไม่ได้
• หน้าขาวเฉพาะบางหน้า เช่น หน้าแก้ไขโพสต์ หน้าสินค้า หรือหน้าที่ใช้ Shortcode บางตัว

ตั้งแต่ WordPress 5.2 เป็นต้นมา Fatal Error ที่มาจากปลั๊กอินหรือธีมส่วนใหญ่จะแสดงเป็นข้อความ “There has been a critical error on this website” แทนหน้าขาว (Make WordPress Core, 2019) ถ้าเว็บคุณขึ้นข้อความนี้ ให้ไปที่ WordPress Critical Error แก้ยังไง ซึ่งมีขั้นตอนใช้ Recovery Mode แต่ถ้าเป็นหน้าขาวล้วนจริง ๆ แปลว่าปัญหาอาจอยู่นอกระบบนั้น เช่น ระบบป้องกันถูกปิดไว้ แคชเก็บหน้าว่างไว้ ปัญหาฐานข้อมูล หรือไฟล์ตั้งค่าเซิร์ฟเวอร์เสีย

ทำไมถึงเกิดอาการหน้าขาว

PHP พังแต่ถูกตั้งไม่ให้แสดง Error

บนเซิร์ฟเวอร์จริง ค่า display_errors ของ PHP ควรปิดไว้ ไฟล์ตั้งค่ามาตรฐานสำหรับ production ของ PHP เองก็ตั้งเป็น Off และคู่มือ PHP แนะนำให้บันทึก Error ลง log แทนการแสดงบนหน้าเว็บ (PHP Manual) ผลคือเมื่อโค้ดพังกลางทาง ผู้เข้าชมจะเห็นแค่หน้าว่าง ส่วนรายละเอียดอยู่ใน log ซึ่งเป็นเหตุผลว่าทำไมขั้นตอนหลักของบทความนี้คือ “ไปอ่าน log”

ปลั๊กอินขัดกัน โดยเฉพาะกลุ่ม Cache และ Security

ปลั๊กอินที่เพิ่งติดตั้งหรืออัปเดตเป็นผู้ต้องสงสัยอันดับแรกเสมอ (WordPress Developer Resources) ปลั๊กอินแคชและความปลอดภัยต้องจับตาเป็นพิเศษ เพราะทำงานตั้งแต่ช่วงแรกของการโหลดหน้า บางตัวเขียนกฎลง .htaccess หรือสร้างไฟล์ drop-in ใน wp-content ถ้าตั้งค่าผิดหรือเวอร์ชันชนกับปลั๊กอินอื่น ทั้งเว็บจะได้รับผลกระทบ อ่านกลไกเพิ่มที่ Plugin Conflict

แก้ functions.php แล้วพิมพ์ผิด

เคสคลาสสิกคือก๊อปโค้ดจากอินเทอร์เน็ตไปวางใน functions.php ของธีมผ่านหน้า Theme File Editor แล้วขาดวงเล็บหรือเครื่องหมาย ; ไปตัวเดียว PHP จะหยุดทำงานด้วย Parse Error ทันที อีกแบบคือธีมหรือ Child Theme มีโค้ดที่ไม่เข้ากับ WordPress เวอร์ชันใหม่ ดู Theme Conflict

หน่วยความจำเต็มกะทันหัน

Error “Allowed Memory Size Exhausted” แปลว่า WordPress ได้หน่วยความจำไม่พอ (WordPress Developer Resources) มักเกิดตอนใช้งานหนัก เช่น นำเข้าสินค้า สร้างรูปย่อ หรือมีบอทยิงเข้าเว็บพร้อมกันจำนวนมาก

PHP เวอร์ชันไม่รองรับ และไฟล์ตั้งค่าเสีย

ถ้าโฮสต์เพิ่งเปลี่ยนเวอร์ชัน PHP ปลั๊กอินหรือธีมเก่าที่ใช้ฟังก์ชันที่ถูกถอดออกจะพังทันที อ่านวิธีเช็กใน PHP Version ไม่รองรับ ส่วนไฟล์ wp-config.php ที่มีช่องว่างหรืออักขระเกินมาก่อน <?php หรือ .htaccess ที่มีกฎผิดก็ทำให้หน้าขาวหรือ Error 500 ได้เช่นกัน

มัลแวร์หรือสคริปต์แฝง

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

วิธีตรวจสอบและกู้คืนหน้าขาวทีละขั้น

ก่อนแก้อะไร ดาวน์โหลดไฟล์ที่จะแก้และสำรองฐานข้อมูลไว้ก่อน เอกสาร WordPress ระบุว่าการสำรองต้องมีทั้งฐานข้อมูลและไฟล์ (WordPress Developer Resources) จากนั้นทำตามลำดับ หยุดเมื่อเว็บกลับมา

ขั้นที่ 1: ดู HTTP Status Code ใน DevTools

หน้าขาวที่ตาเห็นเหมือนกัน อาจเป็นคนละปัญหาก็ได้ วิธีดูใน Chrome (Chrome for Developers)

1. เปิดหน้าเว็บที่ขาว กด Ctrl+Shift+J (Mac: Command+Option+J) เพื่อเปิด DevTools
2. คลิกแท็บ Network แล้วกดรีโหลดหน้า เพราะ DevTools บันทึกเฉพาะตอนที่เปิดอยู่
3. ดูบรรทัดแรก (ชื่อโดเมนหรือชื่อหน้า) ในคอลัมน์ Status

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

ขั้นที่ 2: อ่าน Error Log ของโฮสต์ หรือเปิด WP_DEBUG_LOG

log คือคำตอบที่หน้าขาวไม่ยอมบอก แหล่งที่หาได้

• cPanel: เมนู Metrics → Errors แสดง Error ล่าสุดของเว็บเซิร์ฟเวอร์สูงสุด 300 รายการ เรียงจากใหม่ไปเก่า (cPanel Docs)
• DirectAdmin, Plesk และแผงควบคุมอื่น: มักมีเมนู Logs หรือ Error Log ของแต่ละโดเมน ถ้าหาไม่เจอให้ขอจากโฮสต์ได้
• ไฟล์ในโฟลเดอร์เว็บ: บางโฮสต์มีไฟล์ error_log อยู่ในโฟลเดอร์หลักหรือโฟลเดอร์ wp-admin

ถ้าไม่มี log เลย ให้เปิดการบันทึกของ WordPress เอง เพิ่มโค้ดนี้ใน wp-config.php เหนือบรรทัด /* That's all, stop editing! */

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Error จะถูกบันทึกลง wp-content/debug.log โดยไม่แสดงบนหน้าเว็บ (WordPress Developer Resources) รีโหลดหน้าที่ขาวหนึ่งครั้ง แล้วเปิดไฟล์ดูบรรทัดล่างสุด มองหาคำว่า PHP Fatal error หรือ PHP Parse error ซึ่งจะบอกพาธไฟล์และเลขบรรทัด ถ้าพาธอยู่ใน wp-content/plugins/ชื่อปลั๊กอิน/ ก็รู้ตัวต้นเหตุทันที

แก้เสร็จแล้วต้องปิดกลับ หน้า Site Health ของ WordPress เตือนว่าการเปิด WP_DEBUG_LOG ทำให้ Error ถูกเขียนลงไฟล์ที่คนอื่นอาจเปิดอ่านได้ (WordPress.org Documentation)

ขั้นที่ 3: ปิดปลั๊กอินทั้งหมดผ่าน File Manager หรือ FTP

ถ้าเข้า wp-admin ไม่ได้ ให้เข้า File Manager ของโฮสต์ (ไม่ต้องใช้โปรแกรม FTP ก็ได้) แล้วเปลี่ยนชื่อโฟลเดอร์ wp-content/plugins เป็น plugins-off ซึ่งเป็นวิธีที่เอกสาร WordPress แนะนำเพื่อปิดปลั๊กอินทั้งหมด (WordPress Developer Resources)

1. เปิดเว็บ ถ้าหน้าขาวหาย แสดงว่าต้นเหตุคือปลั๊กอิน
2. เปลี่ยนชื่อกลับเป็น plugins ปลั๊กอินทุกตัวจะอยู่ในสถานะปิด
3. เข้า wp-admin → Plugins แล้วเปิดทีละตัว รีเฟรชหน้าเว็บทุกครั้ง ตัวที่เปิดแล้วขาวอีกคือต้นเหตุ

ถ้า log ชี้ชื่อปลั๊กอินไว้แล้ว เปลี่ยนชื่อเฉพาะโฟลเดอร์ปลั๊กอินตัวนั้นก็พอ ถ้าเพิ่งเกิดหลังกดอัปเดต ดูวิธีย้อนเวอร์ชันใน WordPress พังหลังอัปเดต Plugin

ขั้นที่ 4: สลับกลับเป็นธีมมาตรฐาน (Default Theme)

ถ้าปิดปลั๊กอินแล้วยังขาว ให้สงสัยธีม มี 2 วิธี

• ผ่าน File Manager/FTP: เปลี่ยนชื่อโฟลเดอร์ธีมที่ใช้อยู่ใน wp-content/themes/ เมื่อธีมที่ตั้งไว้ไม่ผ่านการตรวจ WordPress จะสลับไปใช้ธีมเริ่มต้นที่ติดตั้งไว้ เช่น Twenty Twenty-Five หรือ Twenty Twenty-Four ให้อัตโนมัติ (WordPress Developer Resources) ต้องมีธีมเริ่มต้นอย่างน้อยหนึ่งตัวอยู่ในโฟลเดอร์
• ผ่าน phpMyAdmin: เปิดตาราง wp_options (คำนำหน้าตารางอาจไม่ใช่ wp_) แล้วแก้ค่าของแถว template และ stylesheet เป็นชื่อโฟลเดอร์ธีมเริ่มต้น เช่น twentytwentyfive สองค่านี้คือค่าที่ WordPress ใช้เก็บธีมที่เปิดอยู่ (WordPress Developer Resources)

ถ้าเว็บกลับมา ปัญหาอยู่ที่ธีม ถ้าเพิ่งแก้ functions.php ให้นำไฟล์เดิมกลับมาวาง หรือลบโค้ดที่เพิ่งเพิ่มออก

ขั้นที่ 5: ล้างแคชของเซิร์ฟเวอร์และ CDN (Cloudflare)

ถ้าแก้ต้นเหตุแล้วแต่ยังเห็นหน้าขาว อาจเป็นเพราะระบบแคชเก็บหน้าว่างตอนที่เว็บพังไว้แล้วส่งต่อให้ทุกคน ให้ล้างตามลำดับ

1. ปลั๊กอินแคชใน WordPress (ถ้าเข้า wp-admin ได้) หรือลบโฟลเดอร์ wp-content/cache ผ่าน File Manager
2. แคชฝั่งโฮสต์ เช่น LiteSpeed Cache หรือ Varnish ผ่านแผงควบคุมโฮสต์
3. Cloudflare: ใช้คำสั่ง Purge Cache แบบ Purge Everything ในแดชบอร์ดของโดเมน เพื่อลบแคชออกจากเซิร์ฟเวอร์ปลายทาง (edge) ของ Cloudflare (Cloudflare Docs)

ถ้าใช้ปลั๊กอินแคชที่สร้างไฟล์ advanced-cache.php ใน wp-content แล้วปิดปลั๊กอินไปในขั้นที่ 3 ไฟล์นี้อาจยังค้างอยู่ ให้เปลี่ยนชื่อไฟล์นี้ด้วยแล้วลองใหม่

ขั้นที่ 6: รีเซ็ตไฟล์ .htaccess เป็นค่ามาตรฐาน

เอกสาร WordPress ระบุว่าสาเหตุที่น่าจะเป็นที่สุดของ Internal Server Error คือไฟล์ .htaccess เสีย ให้เปลี่ยนชื่อเป็น .htaccess_old แล้วรีโหลดเว็บ ถ้าหายให้ไปที่ Settings → Permalinks แล้วกด Save Changes เพื่อให้ WordPress สร้างไฟล์ใหม่ (WordPress Developer Resources) หรือสร้างไฟล์ใหม่เองด้วยกฎมาตรฐานของ WordPress สำหรับเว็บเดี่ยว (WordPress Developer Resources)

# BEGIN WordPress

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

เก็บไฟล์เดิมไว้ก่อน เพราะอาจมีกฎของ HTTPS redirect หรือปลั๊กอินความปลอดภัยที่ต้องใส่กลับทีหลัง อ่านปัญหาเฉพาะของไฟล์นี้เพิ่มใน .htaccess เสียหาย ไฟล์นี้เป็นไฟล์ตั้งค่าของเว็บเซิร์ฟเวอร์ตระกูล Apache ถ้าไม่แน่ใจว่าโฮสต์ใช้เว็บเซิร์ฟเวอร์อะไร ถามโฮสต์ก่อนแก้

ขั้นที่ 7: เพิ่มหน่วยความจำ PHP

ถ้า log บอกว่า Memory หมด ให้เพิ่มบรรทัดนี้ใน wp-config.php

define( 'WP_MEMORY_LIMIT', '256M' );

WordPress ตั้งค่าเริ่มต้นไว้เพียง 40MB สำหรับเว็บเดี่ยว และบางโฮสต์ไม่อนุญาตให้เพิ่มเอง ต้องติดต่อโฮสต์ให้เพิ่มให้ (WordPress Developer Resources) ถ้าหน้าขาวเฉพาะหลังบ้าน ลองเพิ่ม define( 'WP_MAX_MEMORY_LIMIT', '256M' ); ซึ่งใช้กับหน้าแอดมินโดยเฉพาะ

ป้องกันไม่ให้หน้าขาวกลับมาอีก

• ใช้ Child Theme แทนการแก้ธีมหลัก: คู่มือธีมของ WordPress เตือนว่าถ้าแก้ไฟล์ธีมหลักโดยตรง พอธีมอัปเดตครั้งหน้าโค้ดที่เพิ่มจะหายไป Child Theme ช่วยให้อัปเดตธีมหลักได้โดยไม่เสียสิ่งที่แก้ไว้ (WordPress Theme Handbook)
• เลิกแก้โค้ดสดผ่าน Theme/Plugin File Editor: พิมพ์ผิดตัวเดียวเว็บขาวได้ทันที ให้แก้บนเครื่องหรือ Staging แล้วอัปโหลด และปิดหน้าแก้ไขไฟล์ในหลังบ้านด้วย define( 'DISALLOW_FILE_EDIT', true ); ใน wp-config.php (WordPress Developer Resources) ซึ่งยังช่วยเรื่องความปลอดภัยด้วย เพราะถ้ารหัสแอดมินหลุด ผู้บุกรุกจะแก้ไฟล์ PHP จากหลังบ้านไม่ได้
• ทดสอบบน Staging ก่อนอัปเดต: ทั้งปลั๊กอิน ธีม Core และเวอร์ชัน PHP
• สำรองข้อมูลก่อนเปลี่ยนแปลงทุกครั้ง: และตรวจว่าไฟล์สำรองกู้ได้จริง
• ตรวจหน้า Tools → Site Health เป็นระยะ: หน้านี้แจ้งปัญหาสำคัญ เช่น PHP เวอร์ชันเก่า หรือปลั๊กอินที่รออัปเดต (WordPress.org Documentation)

เมื่อไหร่ควรให้ผู้เชี่ยวชาญช่วย

ถ้าไล่ครบทุกขั้นแล้วยังขาว log ว่างเปล่าหรืออ่านไม่เข้าใจ หน้าขาวหายแล้วกลับมาเป็นซ้ำ หรือเจอโค้ดแปลก ๆ ที่ไม่ได้ใส่เองในไฟล์ PHP อาจเป็นสัญญาณว่าเว็บถูกฝังสคริปต์ ซึ่งต้อง ล้างไวรัสและปิดช่องโหว่ ให้ครบก่อน ไม่อย่างนั้นอาการจะกลับมาอีก ส่วนเว็บขายของที่หยุดนานไม่ได้ บริการแก้ WordPress ล่ม / Error ของ WP Doctor Thailand ประเมินอาการให้ฟรีก่อน ผู้ก่อตั้งลงมือแก้เองทุกเคส มีรับประกันงานสูงสุด 180 วันตามแพ็กเกจ และคืนเงินเต็มจำนวนถ้าแก้ไม่ได้

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

แหล่งอ้างอิง

1. WordPress Developer Resources. (ม.ป.ป.). Common WordPress Errors. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/wordpress/common-errors/
2. Make WordPress Core. (2019). Fatal Error Recovery Mode in 5.2. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://make.wordpress.org/core/2019/04/16/fatal-error-recovery-mode-in-5-2/
3. WordPress Developer Resources. (ม.ป.ป.). Debugging in WordPress. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
4. WordPress Developer Resources. (ม.ป.ป.). wp-config.php. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/wordpress/wp-config/
5. WordPress Developer Resources. (ม.ป.ป.). wp_maintenance(). สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/reference/functions/wp_maintenance/
6. WordPress Developer Resources. (ม.ป.ป.). validate_current_theme(). สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/reference/functions/validate_current_theme/
7. WordPress Developer Resources. (ม.ป.ป.). switch_theme(). สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/reference/functions/switch_theme/
8. WordPress Developer Resources. (ม.ป.ป.). Apache HTTPD / .htaccess. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/server/web-server/httpd/
9. WordPress Developer Resources. (ม.ป.ป.). WordPress Backups. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/security/backup/
10. WordPress Theme Handbook. (ม.ป.ป.). Child Themes. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/themes/advanced-topics/child-themes/
11. WordPress.org. (ม.ป.ป.). Site Health screen. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://wordpress.org/documentation/article/site-health-screen/
12. The PHP Group. (ม.ป.ป.). Runtime Configuration: Errors and Logging. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://www.php.net/manual/en/errorfunc.configuration.php
13. MDN Web Docs. (ม.ป.ป.). 500 Internal Server Error. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/500
14. Chrome for Developers. (ม.ป.ป.). Inspect network activity. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.chrome.com/docs/devtools/network
15. cPanel. (ม.ป.ป.). Errors. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://docs.cpanel.net/cpanel/metrics/errors/
16. Cloudflare. (ม.ป.ป.). Purge cache. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developers.cloudflare.com/cache/how-to/purge-cache/