A WordPress site that will not load is a panic moment for any UK business owner — the white screen, the 500 Internal Server Error, "there has been a critical error on this website". Visitors cannot reach you; Google cannot crawl you; WooCommerce orders cannot be placed. The good news: every failure mode has a known cause and a known fix. This guide walks through eight solutions in order of likely impact, from quick server checks to deeper database diagnosis. Follow them sequentially and stop when the site comes back online. Every solution is available via Plesk on smartxhosting.uk.
What "site not loading" looks like · Common causes · Solution 1: check for a server issue · Solution 2: increase PHP memory limit · Solution 3: enable WP_DEBUG · Solution 4: use WordPress Recovery Mode · Solution 5: deactivate all plugins via Plesk File Manager · Solution 6: switch to a default theme · Solution 7: check and regenerate .htaccess · Solution 8: check error logs in Plesk · When to contact smartxhosting.uk support · Frequently asked questions
Different failure modes point to different underlying problems.
Work through the solutions below in order. Stop when the site comes back online.
Before modifying WordPress, rule out server-level problems.
If you have multiple sites on the same smartxhosting.uk plan, try them. If all are down, the issue is server-wide, not WordPress-specific.
Open your site on a mobile phone on mobile data (not your home Wi-Fi). If the site loads there, the issue may be DNS propagation or a local network problem.
Temporary server load spikes or routine maintenance can cause brief interruptions. Refresh after 2–3 minutes.
smartxhosting.uk publishes server status. If there is a known issue, waiting for resolution is the fastest path.
If Plesk is accessible, log in. Plesk > Websites & Domains should show your domain. If the domain is not listed, there is a Plesk-level issue — contact support.
If only your WordPress site is affected while other sites on the same server work normally, proceed to WordPress-specific solutions.
When PHP runs out of memory, WordPress either shows a white screen or displays "Fatal error: Allowed memory size exhausted". Increasing the limit often resolves immediately.
memory_limit. Change to 256M (or higher).Open wp-config.php via Plesk File Manager. Above "That's all, stop editing!" add:
define( 'WP_MEMORY_LIMIT', '256M' ); define( 'WP_MAX_MEMORY_LIMIT', '512M' );
Refresh the site. If it loads, the problem was memory. Identify and replace memory-hungry plugins.
WordPress debug mode writes detailed PHP error messages to a log file, making it easy to identify the exact cause.
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 );
WP_DEBUG_DISPLAY false keeps errors out of visitor-facing HTML while still logging.
Check wp-content/debug.log via Plesk File Manager. Look for lines containing Fatal error. They reveal the exact file, line number and error type causing the problem.
After fixing, set WP_DEBUG back to false. Debug output on production leaks internals.
Since WordPress 5.2, when a plugin or theme causes a fatal error, WordPress catches it and emails a recovery link to the administrator.
The email contains a one-time link that opens a temporary dashboard session with the broken plugin paused. From there, deactivate or delete the problem plugin.
Recovery link expires after 24 hours. If you miss it, use Solution 5.
Full details in plugin conflicts guide.
The reliable fallback when Recovery Mode email does not arrive or you cannot access the dashboard.
httpdocs/wp-content/.plugins folder to plugins-disabled.plugins-disabled back to plugins. WordPress sees plugins again but they are all still deactivated (because renaming broke their activation state).If you suspect a specific plugin (e.g. the one you just updated), rename only its folder (e.g. problem-plugin-disabled). WordPress cannot load it; the site often recovers immediately.
If the site still fails after deactivating plugins, the theme may be the cause.
Plesk WordPress Toolkit > site card. Plugins and themes panel. Change active theme to Twenty Twenty-Five or another default. If the site loads, the theme was the issue.
If you cannot access the dashboard:
httpdocs/wp-content/themes/.custom-theme → custom-theme-disabled).If the site loads with default theme, investigate what broke the original theme — usually a template file has been corrupted or a function removed between updates.
A corrupted .htaccess file can prevent pages from being served, causing 500 errors or redirect loops.
Plesk File Manager > httpdocs/.htaccess. The standard WordPress .htaccess should start with:
# BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On ... </IfModule> # END WordPress
If the file looks corrupted, rename it (e.g. to .htaccess-broken) and try loading the site. WordPress continues to work without .htaccess but with Plain permalinks only.
If the site loads, regenerate .htaccess:
.htaccess.If WordPress cannot write to .htaccess (e.g. file permissions 644 for directory ownership mismatch), it displays the .htaccess contents on the Permalinks page. Copy those contents into a new .htaccess via File Manager.
Plesk exposes server-level logs that show what PHP, Apache/LiteSpeed and MySQL actually saw.
Plesk > domain > Logs. Filter to error log. Recent errors include PHP fatal messages, Apache rewrite failures, permission denied events.
Usually shown in the same log filter. Errors indicate specific files and line numbers.
Less commonly needed; shown in Plesk > Tools & Settings > Services Management if you have MySQL database-level issues.
Contact support when:
Plesk WordPress Toolkit's SSO login can sometimes bypass issues that the normal login page cannot. Support can investigate server-level logs you do not have access to.
My site is showing just a white page. What is the first thing to try?
Try WordPress Recovery Mode — check your admin email for a recovery link. Then increase PHP memory limit. Then enable WP_DEBUG to see the actual error.
What causes a 500 Internal Server Error in WordPress?
Most common: PHP memory exhaustion, a broken .htaccess file, or a plugin conflict causing a fatal PHP error. Check PHP error log in Plesk to pinpoint the exact cause.
I see "Error establishing a database connection" — what now?
Check in Plesk > Databases that the database exists. Verify the credentials in wp-config.php match. Check MySQL is running (Plesk > Tools & Settings > Services Management). If all looks correct, contact support — may be a server-level MySQL issue.
Can I get my site back without losing any content?
Yes, in almost all cases. Recovering from a plugin or theme conflict never touches your content. Even a backup restore preserves all content up to the backup point.
How do I know if it is my plugin or my theme?
Deactivate all plugins first (rename the plugins folder). If the site loads, it is a plugin. If not, switch to a default theme. If that fixes it, it is the theme.
Does hosting up-time have anything to do with WordPress availability?
Partly. smartxhosting.uk's 99.8% uptime guarantee covers server availability. WordPress-level outages (plugin crashes, memory exhaustion) are separate. The 99.8% figure is for server hosting, not for site-level WordPress issues.
Why does the site load intermittently — sometimes yes, sometimes no?
Usually indicates a resource issue. Memory, CPU or database overload that hits some requests but not others. Plugin caching differences can also cause intermittent behaviour. Enable WP_DEBUG and watch the log during a bad request.
What if I cannot log in to Plesk either?
Try Plesk from a different network. If still down, contact smartxhosting.uk support via email or phone — support access is separate from the panel.
My host says everything is fine but my site still is not loading.
Could be DNS propagation issue, local browser cache, or an issue only affecting your specific WordPress installation. Try from a different browser, different device, different network (mobile data). Clear local DNS cache (ipconfig /flushdns on Windows).
How do I prevent this from happening again?
Keep backups daily (smartxhosting.uk does this automatically). Use staging for testing updates before applying on production. Keep PHP memory at 256 MB. Use the Plesk WordPress Toolkit's Smart Update to test updates on a clone before production. Keep plugin count modest — each plugin is another potential failure point.
Launch your WordPress site on smartxhosting.uk
UK hosting with the Plesk WordPress Toolkit, LiteSpeed Cache, Redis object caching, free Let’s Encrypt SSL, free CDN and daily backups — from £2/month.
View WordPress hosting plans →