WordPress is reliable once it's humming along, but when something breaks it tends to break in one of a handful of characteristic ways. This article covers the most common errors — what they mean, what causes them, and how to get the site back up.

Before you start: enable WordPress debug logging by adding define('WP_DEBUG', true); and define('WP_DEBUG_LOG', true); to wp-config.php just above the "that's all" comment. Errors then write to wp-content/debug.log, which almost always tells you the exact file and line that failed.

The White Screen of Death (WSOD)

What you see: a completely blank page when you visit your site or wp-admin. No error, no content, just white.

What it is: PHP hit a fatal error and produced no output. Modern WordPress ships with recovery mode — it should normally show an error page and email you — but when that fails you get a blank screen.

Fix:

  1. Enable debug logging (see the callout above). Reload the broken page, then look at wp-content/debug.log. The last entry typically names the plugin, theme, or file at fault.
  2. If the log points to a plugin: rename wp-content/plugins/that-plugin to that-plugin.disabled via cPanel's File Manager. WordPress will deactivate it the next time you reload. Check that the site is back up, then update or replace the plugin.
  3. If you can't log in to wp-admin, disable all plugins by renaming wp-content/plugins to plugins.off. Confirm the site loads, rename it back, then re-enable plugins one by one to find the culprit.
  4. If the log points to the active theme: switch to a default theme (Twenty Twenty-Four or similar) via the same trick — rename wp-content/themes/your-theme and WordPress will fall back.

Error Establishing a Database Connection

What you see: an error message on every page that reads literally "Error establishing a database connection".

What it means: WordPress can't reach its database. The credentials in wp-config.php are wrong, the database server is down, or the database has gone missing.

Fix:

  1. Open wp-config.php in cPanel's File Manager and check the DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST values.
  2. Verify the database exists: in cPanel → MySQL Databases, confirm the database named in DB_NAME is listed. It should look like yourusername_wp.
  3. Verify the user has access: on the same page, scroll to Current Users and check the user exists. Scroll to Add User to Database, pick the user and database, click Add, and grant all privileges.
  4. Verify the password: if you're not sure the password in wp-config.php is still correct, reset it in MySQL Databases (→ Current UsersChange Password) and update wp-config.php to match.
  5. DB_HOST should be localhost for CanSpace hosting. If it's something else, change it.

If the database itself is missing, you'll need to restore from a backup — open a ticket and we can help.

Allowed Memory Size Exhausted

What you see: error on a specific page or admin action — "Fatal error: Allowed memory size of 268435456 bytes exhausted". Common during plugin installs, theme imports, or image uploads.

Fix: raise memory_limit via cPanel's MultiPHP INI Editor (see Change your PHP version and tune PHP settings). 256M is a sensible ceiling for most WordPress sites; 512M if you run heavy plugins (WooCommerce + Elementor + several integrations).

If the site keeps hitting memory limits even after raising, something is genuinely using too much memory — usually a poorly-written plugin or a runaway background task. The debug log will often name it. Deactivate one plugin at a time until the problem goes away.

Too Many Redirects (ERR_TOO_MANY_REDIRECTS)

What you see: the browser refuses to load the page with a message like "This page isn't redirecting properly" or "too many redirects."

Typical causes:

  • WordPress's Site URL or Home setting is set to HTTPS but the site isn't actually served over HTTPS (or vice versa).
  • A caching plugin has saved a redirect loop from a previous configuration.
  • A force-HTTPS rule in .htaccess conflicts with WordPress's own canonical redirects.
  • The site is behind a proxy or CDN (Cloudflare in "Flexible SSL" mode is a classic trigger).

Fix:

  1. Clear your browser cache — or test in a private window — first. Loops get cached.
  2. If you have a caching plugin, purge its cache via cPanel's File Manager: delete everything inside wp-content/cache/.
  3. Check wp-config.php for hardcoded URLs: lines like define('WP_HOME', 'http://...'); or define('WP_SITEURL', 'http://...');. Make sure the protocol matches what your site actually uses.
  4. If the URLs in the database are wrong, see Change and Update WordPress URLs in the Database.
  5. If you use Cloudflare: make sure your SSL mode is set to Full or Full (Strict), not "Flexible" — Flexible mode causes a redirect loop with any site that force-redirects to HTTPS.

Briefly Unavailable for Scheduled Maintenance

What you see: "Briefly unavailable for scheduled maintenance. Check back in a minute."

What it means: WordPress creates a .maintenance file during plugin or core updates. If the update gets interrupted, the file is left behind and the site remains in maintenance mode indefinitely.

Fix: in cPanel's File Manager, open your site's root directory, show hidden files (Settings button, top right), and delete .maintenance. The site will load normally again immediately. Then retry the update that failed — this time one plugin at a time if you were bulk-updating.

Connection Timed Out / 504 Gateway Timeout

What you see: a specific action (saving a post, running an import, installing a plugin) fails with a timeout error after 30–60 seconds. The site otherwise works fine.

Fix: see Understanding HTTP error codes — the 504 section covers this. Short version: raise max_execution_time via MultiPHP INI Editor, or move the long-running task to a cron job.

"There has been a critical error on this website"

What you see: a page that says "There has been a critical error on this website. Please check your site admin email inbox for instructions."

What it means: a PHP fatal error — same category as the white screen of death, but WordPress's recovery mode caught it. Check your site's admin email — WordPress sends a recovery link that logs you into a safe mode where only core is active.

Fix: follow the recovery link in the email, deactivate the faulty plugin or switch the theme, then resolve the underlying issue.

Locked out of wp-admin

If you can't log in (forgot password, or admin account compromised), see How to reset your WordPress administrator login — it covers password reset via email, WP Toolkit's one-click admin login, and last-resort database edits.

When to open a ticket

  • The debug log is empty or unhelpful.
  • The site was fine yesterday, nothing has been changed, and it's suddenly broken.
  • Your database is missing or corrupt — you'll need a backup restore.
  • You've tried the above and the issue persists.

When opening a ticket, include: the exact error message (or a screenshot), what you were doing when it started, anything you changed recently (plugin updates, core updates, DNS changes, PHP version changes), and any debug log output.

Related articles

Still stuck? Open a support ticket

Cette réponse était-elle pertinente? 0 Utilisateurs l'ont trouvée utile (0 Votes)