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 fix here uses WordPress-native tools on your smartxhosting.uk hosting.
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 SFTP or file manager · Solution 6: switch to a default theme · Solution 7: check and regenerate .htaccess · Solution 8: check server error logs · 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 your hosting control panel is accessible, log in. Your list of websites and domains should show your domain. If the domain is not listed, there is a server-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.
Open wp-config.php (via SFTP or your host's 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 SFTP or your host's 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.
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.
Via SFTP or your host's file manager, open 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 SFTP or your host's file manager.
Your hosting control panel exposes server-level logs that show what PHP, Apache/LiteSpeed and MySQL actually saw.
In your hosting control panel, open the domain's log viewer and filter to the 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; available in your hosting control panel's service or database tools if you have MySQL database-level issues.
Contact support when:
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 the PHP error log to pinpoint the exact cause.
I see "Error establishing a database connection" — what now?
Check in your hosting control panel's database tools that the database exists. Verify the credentials in wp-config.php match. Check MySQL is running. 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 my hosting control panel either?
Try your hosting control panel 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. Keep plugin count modest — each plugin is another potential failure point.