{"id":2944,"date":"2025-12-05T16:03:34","date_gmt":"2025-12-05T13:03:34","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/fixing-the-wordpress-white-screen-of-death-from-the-hosting-side\/"},"modified":"2025-12-05T16:03:34","modified_gmt":"2025-12-05T13:03:34","slug":"fixing-the-wordpress-white-screen-of-death-from-the-hosting-side","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/fixing-the-wordpress-white-screen-of-death-from-the-hosting-side\/","title":{"rendered":"Fixing the WordPress White Screen of Death from the Hosting Side"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>Seeing a completely blank page instead of your WordPress site is frustrating, especially when you know visitors and customers may be hitting that same white screen. In most cases, this so\u2011called \u201cWhite Screen of Death\u201d (WSoD) is not random: it\u2019s a clear signal that something on the PHP or server layer has gone wrong. The good news is that with a structured, hosting\u2011side approach, you can usually find the root cause in minutes instead of guessing for hours.<\/p>\n<p>In this guide, we\u2019ll walk through the exact PHP and server troubleshooting process we use at dchost.com when a WordPress site suddenly goes blank. We\u2019ll focus on error logs, PHP configuration, resource limits, web server rules and basic file\u2011level checks you can do from cPanel, DirectAdmin, or a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>. Along the way, we\u2019ll share practical tips to prevent white screens from happening again, using staging environments, monitoring and sane backup policies. Whether you\u2019re on shared hosting, a managed plan, or your own VPS\/<a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>, you can follow the same steps.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#What_the_WordPress_White_Screen_of_Death_Really_Means_on_the_Server\"><span class=\"toc_number toc_depth_1\">1<\/span> What the WordPress White Screen of Death Really Means on the Server<\/a><\/li><li><a href=\"#Step_1_Confirm_Its_Really_a_PHPServer_Error\"><span class=\"toc_number toc_depth_1\">2<\/span> Step 1 \u2013 Confirm It\u2019s Really a PHP\/Server Error<\/a><ul><li><a href=\"#Check_Different_URLs_and_Devices\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Check Different URLs and Devices<\/a><\/li><li><a href=\"#Check_HTTP_Status_Codes\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Check HTTP Status Codes<\/a><\/li><\/ul><\/li><li><a href=\"#Step_2_Read_the_Error_Logs_Dont_Guess\"><span class=\"toc_number toc_depth_1\">3<\/span> Step 2 \u2013 Read the Error Logs (Don\u2019t Guess)<\/a><ul><li><a href=\"#Where_to_Find_PHP_and_Web_Server_Logs_on_Shared_Hosting\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Where to Find PHP and Web Server Logs on Shared Hosting<\/a><\/li><li><a href=\"#PHPFPM_Logs_on_VPS_and_Dedicated_Servers\"><span class=\"toc_number toc_depth_2\">3.2<\/span> PHP\u2011FPM Logs on VPS and Dedicated Servers<\/a><\/li><li><a href=\"#What_Youre_Looking_For_in_the_Logs\"><span class=\"toc_number toc_depth_2\">3.3<\/span> What You\u2019re Looking For in the Logs<\/a><\/li><\/ul><\/li><li><a href=\"#Step_3_Fix_Common_PHPLevel_Causes\"><span class=\"toc_number toc_depth_1\">4<\/span> Step 3 \u2013 Fix Common PHP\u2011Level Causes<\/a><ul><li><a href=\"#Increase_PHP_memory_limit_if_Its_Exhausted\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Increase PHP memory_limit if It\u2019s Exhausted<\/a><\/li><li><a href=\"#Check_Youre_on_a_Compatible_PHP_Version\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Check You\u2019re on a Compatible PHP Version<\/a><\/li><li><a href=\"#Make_Sure_Required_PHP_Extensions_Are_Enabled\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Make Sure Required PHP Extensions Are Enabled<\/a><\/li><li><a href=\"#Resolve_Syntax_Errors_and_Corrupted_Files\"><span class=\"toc_number toc_depth_2\">4.4<\/span> Resolve Syntax Errors and Corrupted Files<\/a><\/li><\/ul><\/li><li><a href=\"#Step_4_Check_Web_Server_Rules_htaccess_and_Timeouts\"><span class=\"toc_number toc_depth_1\">5<\/span> Step 4 \u2013 Check Web Server Rules, .htaccess and Timeouts<\/a><ul><li><a href=\"#Reset_a_Broken_htaccess_ApacheLiteSpeed\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Reset a Broken .htaccess (Apache\/LiteSpeed)<\/a><\/li><li><a href=\"#Nginx_and_FastCGI_Timeouts\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Nginx and FastCGI Timeouts<\/a><\/li><\/ul><\/li><li><a href=\"#Step_5_Check_Hosting_Resource_Limits_and_Process_Caps\"><span class=\"toc_number toc_depth_1\">6<\/span> Step 5 \u2013 Check Hosting Resource Limits and Process Caps<\/a><ul><li><a href=\"#AccountLevel_Limits_on_Shared_and_Reseller_Hosting\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Account\u2011Level Limits on Shared and Reseller Hosting<\/a><\/li><li><a href=\"#PHPFPM_max_children_and_SystemLevel_Caps_on_VPS\"><span class=\"toc_number toc_depth_2\">6.2<\/span> PHP\u2011FPM max_children and System\u2011Level Caps on VPS<\/a><\/li><\/ul><\/li><li><a href=\"#Step_6_Use_WordPressAware_Debugging_Without_Breaking_Production\"><span class=\"toc_number toc_depth_1\">7<\/span> Step 6 \u2013 Use WordPress\u2011Aware Debugging Without Breaking Production<\/a><ul><li><a href=\"#Enable_WP_DEBUG_Safely\"><span class=\"toc_number toc_depth_2\">7.1<\/span> Enable WP_DEBUG Safely<\/a><\/li><li><a href=\"#Disable_Plugins_and_Themes_via_File_System\"><span class=\"toc_number toc_depth_2\">7.2<\/span> Disable Plugins and Themes via File System<\/a><\/li><\/ul><\/li><li><a href=\"#Step_7_Prevent_Future_White_Screens_with_Solid_Hosting_Practices\"><span class=\"toc_number toc_depth_1\">8<\/span> Step 7 \u2013 Prevent Future White Screens with Solid Hosting Practices<\/a><ul><li><a href=\"#Set_Up_Regular_Backups_and_Test_Restores\"><span class=\"toc_number toc_depth_2\">8.1<\/span> Set Up Regular Backups and Test Restores<\/a><\/li><li><a href=\"#Harden_WordPress_and_the_Server\"><span class=\"toc_number toc_depth_2\">8.2<\/span> Harden WordPress and the Server<\/a><\/li><li><a href=\"#Choose_Hosting_Aligned_with_Your_Sites_Load\"><span class=\"toc_number toc_depth_2\">8.3<\/span> Choose Hosting Aligned with Your Site\u2019s Load<\/a><\/li><\/ul><\/li><li><a href=\"#When_to_Ask_Hosting_Support_for_Help\"><span class=\"toc_number toc_depth_1\">9<\/span> When to Ask Hosting Support for Help<\/a><\/li><li><a href=\"#Bringing_It_All_Together\"><span class=\"toc_number toc_depth_1\">10<\/span> Bringing It All Together<\/a><\/li><\/ul><\/div>\n<h2><span id=\"What_the_WordPress_White_Screen_of_Death_Really_Means_on_the_Server\">What the WordPress White Screen of Death Really Means on the Server<\/span><\/h2>\n<p>From the browser\u2019s perspective, the White Screen of Death is \u201cjust\u201d a blank HTML response. From the server\u2019s perspective, it\u2019s almost always one of the following:<\/p>\n<ul>\n<li>A <strong>PHP fatal error<\/strong> (syntax error, missing function\/class, out\u2011of\u2011memory)<\/li>\n<li>A <strong>500\u2011level HTTP error<\/strong> (500, 502, 503, 504) without a friendly error page configured<\/li>\n<li>A <strong>web server misconfiguration<\/strong> (broken <code>.htaccess<\/code>, invalid Nginx rule, bad redirect loop that ends in an empty response)<\/li>\n<li>Hosting <strong>resource limits<\/strong> being hit so aggressively that PHP cannot complete the request<\/li>\n<\/ul>\n<p>To you, all of these look like \u201cwhite page, nothing else.\u201d To the server, they\u2019re completely different issues with different fixes. That\u2019s why our first job is to stop treating it as a mysterious WordPress problem and start treating it as a PHP\/web\u2011server incident.<\/p>\n<p>Also, distinguish a real WSoD from DNS or SSL problems. If the domain does not resolve at all, or the browser shows connection\/SSL errors instead of a blank page, you\u2019re dealing with DNS or certificate issues, not a WordPress white screen. For genuine DNS problems, see our detailed guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-hatalari-yuzunden-site-acilmiyor-dns_probe_finished_nxdomain-teshis-rehberi\/\">fixing DNS_PROBE_FINISHED_NXDOMAIN and common DNS errors<\/a>.<\/p>\n<h2><span id=\"Step_1_Confirm_Its_Really_a_PHPServer_Error\">Step 1 \u2013 Confirm It\u2019s Really a PHP\/Server Error<\/span><\/h2>\n<p>Before digging into logs, confirm the symptom from multiple angles. This quickly rules out browser\u2011side glitches and caching quirks.<\/p>\n<h3><span id=\"Check_Different_URLs_and_Devices\">Check Different URLs and Devices<\/span><\/h3>\n<ul>\n<li>Open your <strong>homepage<\/strong>, a <strong>single post<\/strong>, and <strong>\/wp-admin\/<\/strong> in a private\/incognito window.<\/li>\n<li>Test from another browser and another device (desktop + mobile).<\/li>\n<li>If you use a CDN or WAF, temporarily append a cache\u2011bypass parameter like <code>?nocache=1<\/code> to the URL.<\/li>\n<\/ul>\n<p>If <strong>every<\/strong> URL returns a blank page, you\u2019re likely dealing with a global PHP or server issue. If only specific URLs are blank (for example, a single page or only wp\u2011admin), the error may be triggered by a specific plugin, theme, or admin\u2011only hook \u2014 but the underlying cause is still usually a PHP fatal error.<\/p>\n<h3><span id=\"Check_HTTP_Status_Codes\">Check HTTP Status Codes<\/span><\/h3>\n<p>Next, check the HTTP status with your browser\u2019s developer tools:<\/p>\n<ol>\n<li>Open the site, then press F12 (or right\u2011click \u2192 Inspect) and switch to the <strong>Network<\/strong> tab.<\/li>\n<li>Reload the page and click on the main request (usually the domain root).<\/li>\n<li>Look at the <strong>Status<\/strong> code.<\/li>\n<\/ol>\n<ul>\n<li><strong>200 OK with an empty response<\/strong>: usually a PHP exit\/die before output, or a misconfigured template.<\/li>\n<li><strong>500 Internal Server Error<\/strong>: classic PHP fatal error or .htaccess problem.<\/li>\n<li><strong>502\/503\/504<\/strong>: upstream (PHP\u2011FPM) crashed, timed out, or was unavailable.<\/li>\n<\/ul>\n<p>Knowing whether it\u2019s 200 vs. 500+ already narrows your search. We\u2019ll address both cases when we get to logs and PHP settings.<\/p>\n<h2><span id=\"Step_2_Read_the_Error_Logs_Dont_Guess\">Step 2 \u2013 Read the Error Logs (Don\u2019t Guess)<\/span><\/h2>\n<p>Almost every WordPress white screen is explained somewhere in a log file. The challenge is simply knowing where to look.<\/p>\n<h3><span id=\"Where_to_Find_PHP_and_Web_Server_Logs_on_Shared_Hosting\">Where to Find PHP and Web Server Logs on Shared Hosting<\/span><\/h3>\n<p>On a typical cPanel or DirectAdmin account, you\u2019ll find logs in one or more of these locations:<\/p>\n<ul>\n<li><strong>cPanel \u2192 Metrics \u2192 Errors<\/strong> \u2013 recent Apache and PHP errors for your account.<\/li>\n<li><strong>cPanel \u2192 Metrics \u2192 Raw Access \/ Awstats<\/strong> \u2013 combined access + error logs.<\/li>\n<li>A dedicated <strong>error_log<\/strong> file inside your site\u2019s document root (e.g. <code>\/home\/user\/public_html\/error_log<\/code>).<\/li>\n<li>Per\u2011directory <code>error_log<\/code> files inside <code>wp-admin<\/code>, <code>wp-content<\/code>, etc., depending on configuration.<\/li>\n<\/ul>\n<p>On DirectAdmin, you\u2019ll usually see an \u201cError Log\u201d icon for each domain, or you can check log files under <code>\/var\/log\/httpd<\/code> or <code>\/var\/log\/nginx<\/code> on a VPS with root access.<\/p>\n<h3><span id=\"PHPFPM_Logs_on_VPS_and_Dedicated_Servers\">PHP\u2011FPM Logs on VPS and Dedicated Servers<\/span><\/h3>\n<p>If you run your own VPS or dedicated server, PHP is often served via PHP\u2011FPM. Check:<\/p>\n<ul>\n<li><code>\/var\/log\/php-fpm\/error.log<\/code> (CentOS\/AlmaLinux\/Rocky Linux)<\/li>\n<li><code>\/var\/log\/php8.1-fpm.log<\/code> or similar (Debian\/Ubuntu, version\u2011specific)<\/li>\n<li>Pool\u2011specific logs configured in <code>www.conf<\/code> or per\u2011pool config.<\/li>\n<\/ul>\n<p>Web server logs live in paths like <code>\/var\/log\/nginx<\/code> or <code>\/var\/log\/httpd<\/code>. If you\u2019re not sure, your hosting support can point you to the right file.<\/p>\n<h3><span id=\"What_Youre_Looking_For_in_the_Logs\">What You\u2019re Looking For in the Logs<\/span><\/h3>\n<p>Reproduce the white screen (load the page), then immediately refresh the error log. Look for lines containing:<\/p>\n<ul>\n<li><strong>PHP Fatal error<\/strong><\/li>\n<li><strong>Allowed memory size of \u2026 bytes exhausted<\/strong><\/li>\n<li><strong>Call to undefined function<\/strong> or <strong>Class not found<\/strong><\/li>\n<li><strong>Parse error<\/strong> (syntax error, unexpected &#8216;}&#8217; etc.)<\/li>\n<li><strong>mod_fcgid: read data timeout in 45 seconds<\/strong> or <strong>upstream timed out<\/strong> (Nginx)<\/li>\n<\/ul>\n<p>Copy the exact error message and the file path it references. Even if you don\u2019t write PHP, the filename and line number will tell you whether the culprit is a plugin, theme, or core file \u2014 and whether the problem is likely due to PHP settings or something broken in code.<\/p>\n<h2><span id=\"Step_3_Fix_Common_PHPLevel_Causes\">Step 3 \u2013 Fix Common PHP\u2011Level Causes<\/span><\/h2>\n<p>Once you have an error message or at least a suspicion that PHP is failing, go through the most common hosting\u2011side causes.<\/p>\n<h3><span id=\"Increase_PHP_memory_limit_if_Its_Exhausted\">Increase PHP memory_limit if It\u2019s Exhausted<\/span><\/h3>\n<p>If your log shows something like:<\/p>\n<pre>PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate ...)<\/pre>\n<p>then PHP simply ran out of memory. On many shared hosting accounts, the default <code>memory_limit<\/code> is 128M, which is sometimes too low for heavy themes, builders, or WooCommerce.<\/p>\n<p>To increase <code>memory_limit<\/code> on cPanel without touching the system\u2011wide configuration:<\/p>\n<ul>\n<li>Go to <strong>cPanel \u2192 Select PHP Version<\/strong> or <strong>MultiPHP INI Editor<\/strong>.<\/li>\n<li>Switch to <strong>Editor Mode<\/strong> for your domain.<\/li>\n<li>Set <code>memory_limit = 256M<\/code> (or 512M if you know you need it).<\/li>\n<li>Click <strong>Save<\/strong> and reload the site.<\/li>\n<\/ul>\n<p>On a VPS, edit your pool or global PHP config (e.g. <code>\/etc\/php.ini<\/code> or <code>\/etc\/php\/8.1\/fpm\/php.ini<\/code>) and restart PHP\u2011FPM:<\/p>\n<pre>memory_limit = 512M\nsystemctl restart php8.1-fpm<\/pre>\n<p>Be aware that memory_limit is still bounded by your hosting account\u2019s resource quotas. If you\u2019re regularly hitting hard caps, it\u2019s worth revisiting our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-hostingde-resource-limit-reached-hatasini-onlemek\/\">how to avoid the \u201cResource Limit Reached\u201d error on shared hosting<\/a> and possibly planning a move to a larger plan or VPS.<\/p>\n<h3><span id=\"Check_Youre_on_a_Compatible_PHP_Version\">Check You\u2019re on a Compatible PHP Version<\/span><\/h3>\n<p>Many WSoD incidents start right after a PHP upgrade. A site that worked on PHP 7.4 may fail on PHP 8.x because a plugin or theme uses deprecated features. Typical errors include \u201cCall to undefined function\u201d or \u201cUnsupported operand types\u201d.<\/p>\n<p>On cPanel and DirectAdmin, you can usually switch the PHP version per domain:<\/p>\n<ul>\n<li>Open <strong>Select PHP Version<\/strong> or a similar menu.<\/li>\n<li>Note the current version; if it\u2019s very old (e.g. 5.6, 7.0), plan an upgrade soon.<\/li>\n<li>If the white screen appeared <em>after<\/em> an upgrade, temporarily roll back to the previous version to restore service.<\/li>\n<li>Then test and fix compatibility issues on a staging copy before upgrading again.<\/li>\n<\/ul>\n<p>We\u2019ve covered per\u2011site PHP selection in detail in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanel-ve-directadminde-coklu-php-surumu-yonetimi-her-site-icin-dogru-php-7-x-8-x-secimi\/\">managing multiple PHP versions on cPanel and DirectAdmin<\/a>. And if you\u2019re planning a permanent jump to PHP 8.x, our <a href=\"https:\/\/www.dchost.com\/blog\/en\/php-8-x-yukseltme-kontrol-listesi-wordpress-ve-laravelde-geriye-uyumluluk-opcache-preload-ve-fpm-havuz-ayarlari-nasil-tatli-tatli-kurulur\/\">PHP 8.x upgrade checklist<\/a> walks through the compatibility and performance tuning steps we recommend for WordPress.<\/p>\n<h3><span id=\"Make_Sure_Required_PHP_Extensions_Are_Enabled\">Make Sure Required PHP Extensions Are Enabled<\/span><\/h3>\n<p>Some plugins rely on specific extensions: <code>curl<\/code>, <code>mbstring<\/code>, <code>intl<\/code>, <code>imagick<\/code>, <code>zip<\/code>, etc. If an extension is missing after a PHP version change, you might see fatal errors or a blank page.<\/p>\n<p>On cPanel\u2019s \u201cSelect PHP Version\u201d screen, you can usually tick checkboxes to enable common extensions for that version. After enabling, save and test again. On a VPS, install modules via your package manager (for example, <code>apt install php8.1-mbstring php8.1-intl<\/code>), then restart PHP\u2011FPM.<\/p>\n<h3><span id=\"Resolve_Syntax_Errors_and_Corrupted_Files\">Resolve Syntax Errors and Corrupted Files<\/span><\/h3>\n<p>If your logs show <strong>Parse error<\/strong> messages (unexpected T_STRING, unexpected &#8216;}&#8217; etc.), PHP can\u2019t even interpret the file. This often happens after a failed manual edit or partial upload.<\/p>\n<p>Common hosting\u2011side fixes:<\/p>\n<ul>\n<li>Use the <strong>File Manager<\/strong> in cPanel\/DirectAdmin or SFTP to open the file named in the error and fix or revert your changes.<\/li>\n<li>If the file is a WordPress core file (e.g. <code>wp-includes\/some-file.php<\/code>), re\u2011upload a fresh copy from a clean WordPress download.<\/li>\n<li>If it\u2019s a theme\/plugin file, reinstall that theme or plugin from a known\u2011good version.<\/li>\n<\/ul>\n<p>This is one more reason why solid backups are non\u2011negotiable. If you don\u2019t already have them, start with our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-yedekleme-stratejileri-paylasimli-hosting-ve-vpste-otomatik-yedek-ve-geri-yukleme\/\">WordPress backup strategies for shared hosting and VPS<\/a> or, for full\u2011account recovery, our <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanelde-tum-siteyi-yedekleme-ve-geri-yukleme-rehberi\/\">Full cPanel backup and restore guide<\/a>.<\/p>\n<h2><span id=\"Step_4_Check_Web_Server_Rules_htaccess_and_Timeouts\">Step 4 \u2013 Check Web Server Rules, .htaccess and Timeouts<\/span><\/h2>\n<p>Not every white screen is purely a PHP issue. Apache and Nginx configuration problems are also common culprits, especially after migrations or manual rewrites.<\/p>\n<h3><span id=\"Reset_a_Broken_htaccess_ApacheLiteSpeed\">Reset a Broken .htaccess (Apache\/LiteSpeed)<\/span><\/h3>\n<p>In Apache or LiteSpeed environments, WordPress relies on <code>.htaccess<\/code> for pretty permalinks. A malformed rule, extra character, or conflicting directive can break requests and result in a white page or 500 error.<\/p>\n<p>To safely test this:<\/p>\n<ol>\n<li>Use File Manager or SFTP to rename <code>.htaccess<\/code> to <code>.htaccess.bak<\/code>.<\/li>\n<li>Reload your site. If the homepage comes back (perhaps without pretty URLs), you\u2019ve confirmed <code>.htaccess<\/code> is the issue.<\/li>\n<li>Log into <strong>wp-admin \u2192 Settings \u2192 Permalinks<\/strong> and click <strong>Save Changes<\/strong>. WordPress will write a fresh default <code>.htaccess<\/code>.<\/li>\n<\/ol>\n<p>If you had custom rules, copy them back piece by piece from <code>.htaccess.bak<\/code> to identify the offending directive.<\/p>\n<h3><span id=\"Nginx_and_FastCGI_Timeouts\">Nginx and FastCGI Timeouts<\/span><\/h3>\n<p>On Nginx, a white screen with <strong>504 Gateway Timeout<\/strong> or <strong>upstream timed out<\/strong> in the error log points to PHP\u2011FPM taking too long. This can be due to:<\/p>\n<ul>\n<li>Extremely heavy queries or slow plugins<\/li>\n<li>Under\u2011provisioned PHP\u2011FPM pools (too few children, long queues)<\/li>\n<li>Low CPU or IO capacity on the server<\/li>\n<\/ul>\n<p>You can often mitigate this by:<\/p>\n<ul>\n<li>Raising <code>fastcgi_read_timeout<\/code> in your Nginx vhost for that site.<\/li>\n<li>Tuning PHP\u2011FPM pools (e.g. <code>pm.max_children<\/code>, <code>pm.max_requests<\/code>).<\/li>\n<li>Upgrading to a plan with more CPU\/RAM or moving high\u2011traffic sites to a dedicated VPS.<\/li>\n<\/ul>\n<p>We go deeper into these performance\u2011related server tweaks in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/yuksek-ttfb-sorununu-cozmek-wordpress-ve-php-sitelerde-sunucu-tarafli-nedenler-ve-cozumler\/\">fixing high TTFB for WordPress and PHP sites<\/a> and in our broader guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-icin-sunucu-tarafi-optimizasyon-php-fpm-opcache-redis-ve-mysql-ile-neyi-ne-zaman-nasil-ayarlamalisin\/\">server\u2011side optimizations for WordPress (PHP\u2011FPM, OPcache, Redis and MySQL)<\/a>.<\/p>\n<h2><span id=\"Step_5_Check_Hosting_Resource_Limits_and_Process_Caps\">Step 5 \u2013 Check Hosting Resource Limits and Process Caps<\/span><\/h2>\n<p>Even perfectly valid PHP code can \u201cwhite screen\u201d if your hosting provider\u2019s resource limits are too tight or regularly exceeded.<\/p>\n<h3><span id=\"AccountLevel_Limits_on_Shared_and_Reseller_Hosting\">Account\u2011Level Limits on Shared and Reseller Hosting<\/span><\/h3>\n<p>On multi\u2011tenant servers, each cPanel\/DirectAdmin account is confined by limits on:<\/p>\n<ul>\n<li><strong>CPU<\/strong> and <strong>RAM<\/strong><\/li>\n<li><strong>IO<\/strong> (disk throughput)<\/li>\n<li><strong>EP<\/strong> (entry processes \/ concurrent connections)<\/li>\n<\/ul>\n<p>When these limits are reached, PHP processes may be queued, throttled, or killed, which can produce 500\/503 errors or a blank page with no explanation.<\/p>\n<p>In cPanel, open <strong>Resource Usage<\/strong> to see if your account is frequently hitting \u201cResource Limit Reached\u201d. If so, combine two strategies:<\/p>\n<ul>\n<li><strong>Optimize<\/strong> the site (disable heavy plugins, add caching, reduce cron load).<\/li>\n<li><strong>Right\u2011size<\/strong> the hosting plan or move to a VPS with dedicated resources.<\/li>\n<\/ul>\n<p>We explain how these limits work and how to interpret the graphs in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanelde-kaynak-limitleri-cpu-io-ep-ram-ve-resource-limit-reached-hatasi\/\">cPanel resource limits and the \u201cResource Limit Reached\u201d error<\/a>.<\/p>\n<h3><span id=\"PHPFPM_max_children_and_SystemLevel_Caps_on_VPS\">PHP\u2011FPM max_children and System\u2011Level Caps on VPS<\/span><\/h3>\n<p>On your own VPS\/dedicated server, there\u2019s no hosting provider imposing EP limits \u2014 but you still have to tune PHP\u2011FPM and the OS:<\/p>\n<ul>\n<li><strong>PHP\u2011FPM pool settings<\/strong>: too few <code>pm.max_children<\/code> will queue requests (leading to timeouts); too many will exhaust RAM and trigger OOM kills.<\/li>\n<li><strong>Systemd and OS limits<\/strong>: <code>LimitNOFILE<\/code>, <code>ulimit<\/code>, and overall RAM can all cause PHP processes to die under high load.<\/li>\n<\/ul>\n<p>Symptoms can look like a white screen, occasional 502\/504 errors, or sporadic crashes only under traffic spikes. This is where proper monitoring helps: CPU, RAM, and process counts over time make capacity issues obvious. If you\u2019re just getting started with observability on a VPS, our guide to <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-izleme-ve-alarm-kurulumu-prometheus-grafana-ve-uptime-kuma-ile-baslangic\/\">VPS monitoring and alerts with Prometheus, Grafana, and Uptime Kuma<\/a> is a practical starting point.<\/p>\n<h2><span id=\"Step_6_Use_WordPressAware_Debugging_Without_Breaking_Production\">Step 6 \u2013 Use WordPress\u2011Aware Debugging Without Breaking Production<\/span><\/h2>\n<p>Sometimes logs alone aren\u2019t enough, especially if the error is triggered only under certain conditions. In that case, WordPress\u2019s own debugging tools help \u2014 as long as you enable them carefully.<\/p>\n<h3><span id=\"Enable_WP_DEBUG_Safely\">Enable WP_DEBUG Safely<\/span><\/h3>\n<p>In <code>wp-config.php<\/code>, you can enable debug mode by adding or changing:<\/p>\n<pre>define( 'WP_DEBUG', true );\ndefine( 'WP_DEBUG_LOG', true );\ndefine( 'WP_DEBUG_DISPLAY', false );<\/pre>\n<p>This tells WordPress to log errors to <code>wp-content\/debug.log<\/code> without showing them to visitors. Reload the problematic page, then open <code>debug.log<\/code> via File Manager or SFTP and review the entries.<\/p>\n<p>Never leave <code>WP_DEBUG_DISPLAY<\/code> enabled on a production site; it can leak sensitive information. Once you\u2019re done debugging, switch <code>WP_DEBUG<\/code> back to <code>false<\/code> and delete the debug log if it\u2019s no longer needed.<\/p>\n<h3><span id=\"Disable_Plugins_and_Themes_via_File_System\">Disable Plugins and Themes via File System<\/span><\/h3>\n<p>Although this is more of an application\u2011side step, you accomplish it entirely from the hosting panel, and it often resolves a white screen caused by a bad update:<\/p>\n<ul>\n<li>Rename <code>wp-content\/plugins<\/code> to <code>plugins.off<\/code>. This deactivates all plugins in one go.<\/li>\n<li>If the site loads again, rename it back and then rename individual plugin folders one by one to find the culprit.<\/li>\n<li>Similarly, switch themes by renaming the active theme\u2019s directory; WordPress will fall back to a default theme if available.<\/li>\n<\/ul>\n<p>Once you\u2019ve found the problematic plugin or theme, you can roll back its version, replace its files from a fresh download, or choose an alternative. For higher\u2011risk updates (WooCommerce, major theme changes), we strongly recommend testing in a staging copy first. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-staging-ortami-nasil-kurulur-cpanelde-alt-alan-adi-klonlama-ve-guvenli-yayina-alma\/\">creating a WordPress staging environment on cPanel<\/a> walks through a safe workflow.<\/p>\n<h2><span id=\"Step_7_Prevent_Future_White_Screens_with_Solid_Hosting_Practices\">Step 7 \u2013 Prevent Future White Screens with Solid Hosting Practices<\/span><\/h2>\n<p>Once you\u2019ve recovered from a WSoD, use the momentum to harden your stack so the next issue is either less likely \u2014 or at least easier to diagnose.<\/p>\n<h3><span id=\"Set_Up_Regular_Backups_and_Test_Restores\">Set Up Regular Backups and Test Restores<\/span><\/h3>\n<p>A reliable backup is the most powerful \u201cundo\u201d button you can have. At minimum, configure:<\/p>\n<ul>\n<li>Daily <strong>file + database backups<\/strong> stored on a separate server or storage.<\/li>\n<li>Retention of at least 7\u201330 days, depending on your change rate.<\/li>\n<li>Occasional <strong>test restores<\/strong> to a staging subdomain to confirm backups are valid.<\/li>\n<\/ul>\n<p>If you prefer a simple, hosting\u2011integrated approach, start with our <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-yedekleme-stratejileri-paylasimli-hosting-ve-vpste-otomatik-yedek-ve-geri-yukleme\/\">WordPress backup strategies for shared hosting and VPS<\/a>. For full\u2011account snapshots including email and multiple sites, combine that with the <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanelde-tum-siteyi-yedekleme-ve-geri-yukleme-rehberi\/\">cPanel backup and restore guide<\/a>.<\/p>\n<h3><span id=\"Harden_WordPress_and_the_Server\">Harden WordPress and the Server<\/span><\/h3>\n<p>Many white screens follow a hacked plugin or theme, where injected code breaks PHP execution. Basic hardening steps help here:<\/p>\n<ul>\n<li>Keep core, themes and plugins up\u2011to\u2011date from trusted sources.<\/li>\n<li>Harden file permissions so attackers can\u2019t write arbitrary PHP files.<\/li>\n<li>Limit login abuse (rate\u2011limit <code>wp-login.php<\/code>, use strong passwords and 2FA).<\/li>\n<li>Consider a WAF \/ security plugin, combined with server\u2011side protections.<\/li>\n<\/ul>\n<p>We maintain a detailed <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-guvenlik-sertlestirme-kontrol-listesi-dosya-izinleri-salt-keys-xml-rpc-ufw-fail2ban-nasil-tatli-tatli-kurulur\/\">WordPress hardening checklist<\/a> that covers file permissions, salt keys, XML\u2011RPC, and host\u2011level protections like UFW and Fail2ban.<\/p>\n<h3><span id=\"Choose_Hosting_Aligned_with_Your_Sites_Load\">Choose Hosting Aligned with Your Site\u2019s Load<\/span><\/h3>\n<p>If you repeatedly hit resource limits or need custom PHP tuning that\u2019s not possible on basic shared hosting, it\u2019s a sign the site has outgrown its current environment. At dchost.com we see this often with:<\/p>\n<ul>\n<li>WooCommerce stores with many plugins and heavy queries<\/li>\n<li>Membership and LMS sites with logged\u2011in traffic<\/li>\n<li>Agencies hosting dozens of client sites under one account<\/li>\n<\/ul>\n<p>In these cases, moving the busiest sites to a <strong>VPS<\/strong> or <strong>dedicated server<\/strong> with properly tuned PHP\u2011FPM, OPcache, and database settings dramatically reduces the risk of white screens and random 500s. Our team can help you plan the right mix of shared hosting, VPS, dedicated servers and even colocation for your workloads.<\/p>\n<h2><span id=\"When_to_Ask_Hosting_Support_for_Help\">When to Ask Hosting Support for Help<\/span><\/h2>\n<p>There are moments when it\u2019s smarter to escalate than to keep poking around:<\/p>\n<ul>\n<li>The logs clearly show <strong>server\u2011level issues<\/strong> (disk full, MySQL refusing connections, PHP\u2011FPM failing to start).<\/li>\n<li>You don\u2019t have access to relevant logs or PHP config on a managed environment.<\/li>\n<li>Multiple sites on the same server are showing white screens at once.<\/li>\n<\/ul>\n<p>In your ticket, include:<\/p>\n<ul>\n<li>Exact URL(s) showing the white screen<\/li>\n<li>Timestamps when you reproduced the issue<\/li>\n<li>Any error messages you\u2019ve already found in logs<\/li>\n<li>Recent changes (plugin\/theme updates, PHP version changes, migrations)<\/li>\n<\/ul>\n<p>This gives the support team a head start, often cutting resolution time dramatically.<\/p>\n<h2><span id=\"Bringing_It_All_Together\">Bringing It All Together<\/span><\/h2>\n<p>The WordPress White Screen of Death looks mysterious from the browser, but from the server side it\u2019s almost always a straightforward combination of PHP errors, configuration issues, or resource limits. By methodically checking HTTP status codes, reading the right logs, and reviewing PHP settings like <code>memory_limit<\/code> and version compatibility, you can usually move from \u201cblank page\u201d to clear diagnosis in a matter of minutes.<\/p>\n<p>From there, the fixes are concrete: raise memory sensibly, reset a broken <code>.htaccess<\/code>, tune PHP\u2011FPM, disable a bad plugin, or right\u2011size your hosting plan. The real win is what you do afterwards: set up reliable backups, harden WordPress and the server, introduce a staging workflow for risky updates, and monitor resource usage so you see problems <em>before<\/em> users do.<\/p>\n<p>If you\u2019re tired of firefighting white screens and 500 errors, our team at dchost.com can help you move to hosting that matches your site\u2019s real needs \u2014 whether that\u2019s a tuned shared plan, an NVMe\u2011based VPS, a dedicated server, or colocation for your own hardware. If you\u2019d like a second pair of eyes on your current setup or a migration path that minimises risk, reach out to us and we\u2019ll design a practical, no\u2011drama plan for your WordPress stack.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Seeing a completely blank page instead of your WordPress site is frustrating, especially when you know visitors and customers may be hitting that same white screen. In most cases, this so\u2011called \u201cWhite Screen of Death\u201d (WSoD) is not random: it\u2019s a clear signal that something on the PHP or server layer has gone wrong. The [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":2945,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-2944","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2944","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=2944"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2944\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/2945"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=2944"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=2944"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=2944"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}