WordPress errors: the complete fix guide (47 errors, step by step)

We fix WordPress sites for agencies every week, and the same errors come up again and again. This guide collects them in one place, with the exact error text, why it happens and the fix we use, in the order we try it. It’s written for site owners and developers who can open wp-config.php or a hosting panel. No guesswork, no “reinstall everything”.

Applies to: WordPress 7.1 and PHP 8.3 to 8.5, cPanel and LiteSpeed hosting. Last verified: November 2026.

Server-side problem? Our companion guide covers hosting, PHP and cPanel errors: account limits, PHP settings, phpMyAdmin, AutoSSL and errors after moving hosts.

01Quick reference: every error, its likely cause and the first fix

Find your error, then jump to the full fix. Each section lists the quick fix first, then the cause, then step by step instructions.

02Before you touch anything: find the real error in 5 minutes

Most WordPress errors look scary and have boring causes: one plugin, one theme file, one server limit. Guessing wastes hours. These five checks show you the real cause, and almost every fix below starts with them.

1. Take a backup first

Download the site files and export the database before you change anything. Your host’s backup tool, cPanel’s Backup page or a quick wp db export with WP-CLI all work. A fix you can undo is a safe fix.

2. Check the admin email for a recovery link

When a plugin or theme causes a fatal error, WordPress emails the site admin a recovery mode link. It logs you in with the broken plugin paused, so you can deactivate or update it from the dashboard. Check spam too, and look for the subject line “Your Site is Experiencing a Technical Issue”.

3. Turn on the debug log

Open wp-config.php in your host’s File Manager or over SFTP. Add these lines above the line that says “That’s all, stop editing!”:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Reload the broken page, then open wp-content/debug.log. The last lines name the file and line that failed, which usually points straight at a plugin or theme. Errors go to the log file and stay hidden from visitors. Set WP_DEBUG back to false when you’re done.

4. Read the server error log

Some errors happen before WordPress loads, so they never reach debug.log. In cPanel, open Metrics → Errors or look for an error_log file in the site root. On managed hosts, the log is usually in the hosting dashboard.

5. Isolate plugins and the theme without the dashboard

If you can’t log in, rename wp-content/plugins to plugins-off. WordPress deactivates every plugin. If the site comes back, rename the folder back, then rename plugin folders one at a time until it breaks again. Do the same with the active theme folder in wp-content/themes: WordPress falls back to a default theme if one is installed.

wp plugin deactivate --all
wp plugin activate plugin-name
wp theme activate twentytwentyfive  # or any default theme you have installed

With WP-CLI over SSH, the commands above do the same job faster.

03Site down errors

There has been a critical error on this website

Quick fix: Use the recovery mode link in the admin email, or read wp-content/debug.log to find the plugin or theme that failed, then deactivate or update it.

Why it happens: A PHP fatal error stopped the page. Since WordPress 5.2, fatal error protection catches it and shows this message instead of a blank screen.

1. Check the site admin inbox (and spam) for the recovery mode email and click the link.
2. Deactivate the plugin or theme named in the email, then update it or replace it.
3. No email? Turn on the debug log and read the last fatal error line.
4. Can’t reach the dashboard at all? Rename the plugin folder named in the log over SFTP or File Manager.
5. Reload. If the site still fails, repeat with the next error in the log.

White screen of death (blank page, no error)

Quick fix: Turn on the debug log and reload the page. If it’s still blank, deactivate all plugins by renaming the plugins folder, then switch to a default theme.

Why it happens: A fatal PHP error or exhausted memory killed the page before anything printed, and error display is off. Older sites without fatal error protection show this instead of the critical error message.

1. Check whether only /wp-admin or only the front end is blank. That tells you if it’s admin-only code.
2. Turn on the debug log and read the last lines.
3. If the log mentions memory, raise the limit (see memory exhausted).
4. Rename wp-content/plugins to test all plugins at once, then narrow it down.
5. Rename the active theme folder to test the theme.
6. Clear any page cache and CDN cache. A cached blank page can outlive the fix.

500 Internal Server Error

Quick fix: Rename .htaccess to .htaccess-old, reload the site, and if it works, save Settings → Permalinks to create a clean one.

Why it happens: The server failed to run the request. The common causes are a broken .htaccess rule, a PHP fatal error, a PHP memory or process limit, wrong file permissions, or a PHP version a plugin doesn’t support.

1. Rename .htaccess in the site root and reload.
2. If that fixes it, go to Settings → Permalinks and click Save to regenerate the file.
3. Still failing? Read the server error log: it names the real cause.
4. Test plugins and the theme by renaming their folders.
5. Check that folders are 755 and files are 644. Files set to 777 make many servers refuse to run PHP.
6. If you changed the PHP version recently, switch back and test.

A clean WordPress .htaccess for a single site looks like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
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]
</IfModule>
# END WordPress

Error establishing a database connection

Quick fix: Open wp-config.php and check DB_NAME, DB_USER, DB_PASSWORD and DB_HOST against the database details in your hosting panel.

Why it happens: WordPress can’t reach MySQL or MariaDB. The login details are wrong (common after a migration or password change), the database user lost its privileges, the database server is down or overloaded, or tables are damaged.

1. Compare the four database values in wp-config.php with your hosting panel. DB_HOST is usually localhost, but some hosts use a hostname.
2. In cPanel → MySQL Databases, confirm the user is added to the database with All Privileges.
3. Ask your host if the database server is down. If the admin area shows a different message saying tables need repair, continue below.
4. To repair tables, add define( 'WP_ALLOW_REPAIR', true ); to wp-config.php and open /wp-admin/maint/repair.php.
5. Remove the repair line when you’re done. Anyone can open that page while it’s enabled.

WordPress database error: Table doesn’t exist, or Unknown column

Quick fix: Check that $table_prefix matches your tables, then run any pending database update from the dashboard or with wp core update-db.

Why it happens: After a migration, a partial import or a failed plugin update, WordPress or a plugin asks for a table or column that isn’t there.

1. Note the table name in the error and look for it in phpMyAdmin.
2. If every table has a different prefix, fix $table_prefix in wp-config.php.
3. If only one plugin table is missing, deactivate and reactivate that plugin so it can recreate its tables.
4. Run wp core update-db after core updates.
5. If tables were lost in an import, restore the database backup and import again.

503 Service Unavailable

Quick fix: Wait a minute and reload. If it keeps happening, check your host’s resource usage page: you’re likely hitting CPU, memory or process limits.

Why it happens: The server is too busy or a limit was reached. Shared hosting caps how many PHP processes run at once, and a traffic spike, a bot crawl or a heavy plugin can fill them.

1. Look at your hosting panel’s resource usage (CloudLinux shows entry process and CPU faults).
2. Check the access log for a single IP or bot hammering the site, and block it with your firewall or CDN.
3. Deactivate heavy plugins one at a time: backup, broken link checkers and related posts tools are common culprits.
4. Turn on page caching so most visits never run PHP.
5. If limits are hit on normal traffic, the site has outgrown the plan.

502 Bad Gateway or 504 Gateway Timeout

Quick fix: Reload after a minute. If you use Cloudflare or another CDN, check whether the origin server is up by visiting it directly or asking your host.

Why it happens: A proxy in front of WordPress (Nginx, a load balancer or a CDN) didn’t get a valid or timely answer from PHP. PHP crashed, a request ran too long, or the origin is down.

1. Check the host status page and the server error log.
2. Look for a slow request: a long import, a backup or a report page often triggers 504s.
3. Run long jobs with WP-CLI or a background queue instead of a browser request.
4. Ask your host to check PHP-FPM workers and timeouts.
5. On Cloudflare, error pages that mention the host mean the origin failed, not Cloudflare.

429 Too Many Requests

Quick fix: Slow down repeated requests, then check your host, firewall or CDN rate limits. If it hits your own admin, allowlist your IP.

Why it happens: A rate limit blocked the visitor because too many requests came from one IP in a short time. Hosts, Cloudflare rules and security plugins all do this. Uptime monitors and SEO crawlers often trigger it.

1. Find who sets the limit: the error page usually shows the host, Cloudflare or a plugin brand.
2. Check if a crawler, monitor or a script polling admin-ajax.php or the REST API caused it.
3. Lower the crawl rate or allowlist trusted tools.
4. Ask your host for the limit and whether your plan can raise it.

Briefly unavailable for scheduled maintenance. Check back in a minute.

Quick fix: Delete the .maintenance file in the site root.

Why it happens: WordPress creates .maintenance during updates and deletes it at the end. If an update times out or you close the tab, the file stays and the site is stuck.

1. Open the site root (the folder with wp-config.php) in File Manager or SFTP. Show hidden files.
2. Delete .maintenance.
3. Reload the site, then go to Dashboard → Updates and check the update that was running. Rerun it if it failed.

403 Forbidden

Quick fix: Check file permissions (folders 755, files 644), then check your security plugin and host firewall logs for a blocked request.

Why it happens: The server refused the request. Wrong permissions, a deny rule in .htaccess, a missing index file, a security plugin, or a host firewall such as ModSecurity can all cause it.

1. Reset permissions: folders 755, files 644, wp-config.php 640 or 600 if your host allows.
2. Rename .htaccess to rule out a bad deny rule.
3. Check Wordfence, Solid Security or similar for a blocked IP or rule.
4. If the 403 only happens when saving a post or form, ask your host to check ModSecurity for a false positive.
5. Make sure index.php exists in the site root.

This site can’t be reached (DNS_PROBE_FINISHED_NXDOMAIN)

Quick fix: Check that the domain hasn’t expired and that its nameservers or A record point to your current host.

Why it happens: The browser can’t find an IP address for the domain. The domain expired, DNS records were changed or deleted, or a DNS change is still spreading.

1. Look up the domain in a WHOIS tool and check the expiry date.
2. Check the nameservers at your registrar against what your host or CDN expects.
3. Check the A record (and AAAA record if any) points to your server IP.
4. After a change, allow up to 24 to 48 hours, though most updates show within an hour.
5. Test from another network or with a public DNS checker to rule out a local cache.

04Redirect, SSL and 404 errors

ERR_TOO_MANY_REDIRECTS (redirected you too many times)

Quick fix: Make sure the WordPress Address and Site Address use the same protocol and domain, and if you use Cloudflare, set SSL/TLS mode to Full (strict), not Flexible.

Why it happens: Two rules send visitors back and forth forever. The classic case: Cloudflare Flexible SSL talks to your server over HTTP, the server forces HTTPS, and the loop never ends. Mismatched URLs or stacked redirect plugins do the same.

1. Clear cookies for the site and test in a private window.
2. Check Settings → General. Both URLs should match exactly, for example https://example.com.
3. Locked out? Set them in wp-config.php (code below).
4. On Cloudflare, set SSL/TLS to Full (strict) and make sure the server has a valid certificate.
5. Remove duplicate HTTPS redirects: keep one in .htaccess or one plugin, not both.

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Your connection is not private (NET::ERR_CERT_DATE_INVALID or COMMON_NAME_INVALID)

Quick fix: Reissue the SSL certificate in your hosting panel (cPanel → SSL/TLS Status → Run AutoSSL), and make sure it covers both example.com and www.example.com.

Why it happens: The certificate expired, doesn’t cover the exact domain, or was never installed after a move. Free certificates renew automatically only while DNS points to the host that issued them.

1. Click the warning to see which error it is: date invalid means expired, common name invalid means wrong domain.
2. Run AutoSSL or reissue the Let’s Encrypt certificate.
3. If DNS goes through a CDN, check the certificate there too.
4. Clear the browser cache and test again.

Mixed content: padlock missing or “Not secure” on an HTTPS site

Quick fix: Replace old http:// links in the database with WP-CLI search-replace, then purge every cache.

Why it happens: The page loads over HTTPS, but some images, scripts or styles still load over HTTP. The browser blocks or flags them.

1. Open the browser console. It lists every insecure URL.
2. Run a dry run first, then the real replace (commands below). WP-CLI handles serialized data safely, so a raw SQL replace isn’t needed.
3. Fix hardcoded http:// URLs in theme files, widgets and page builder CSS.
4. Purge plugin, server and CDN caches.

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid

Posts and pages return 404, but the home page works

Quick fix: Go to Settings → Permalinks and click Save Changes without changing anything.

Why it happens: The rewrite rules that turn pretty URLs into WordPress requests are missing. A deleted or unwritable .htaccess, a migration, or a server without mod_rewrite causes it. On Nginx, the server block needs a try_files rule.

1. Save permalinks once. This rebuilds the rules.
2. If it doesn’t stick, check .htaccess exists and is writable, then add the default WordPress block shown in the 500 section.
3. On Nginx, make sure the location block includes try_files $uri $uri/ /index.php?$args;.
4. Custom post types 404 after adding them? Saving permalinks fixes that too.

05PHP errors

Fatal error: Allowed memory size of 134217728 bytes exhausted

Quick fix: Raise the WordPress memory limit in wp-config.php to 256M, and if that doesn’t work, raise PHP’s memory_limit in your hosting panel.

Why it happens: A script needed more memory than PHP allows. The number is bytes: 134217728 is 128 MB. Large imports, image processing, page builders and badly written plugins hit the limit first.

1. Add the lines below to wp-config.php above “That’s all, stop editing!”.
2. WordPress can’t go above the server limit. If the error remains, raise memory_limit in cPanel → MultiPHP INI Editor or Select PHP Version → Options.
3. Check the error line in the log. If it always points to one plugin, that plugin is the real problem.
4. Don’t set huge values like 2G to hide a leak. Fix the code instead.

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

WP_MEMORY_LIMIT applies to the front end and WP_MAX_MEMORY_LIMIT applies to admin tasks such as image editing.

Fatal error: Maximum execution time of 30 seconds exceeded

Quick fix: Raise max_execution_time to 120 or 300 in your hosting PHP settings, or run the long task with WP-CLI instead of the browser.

Why it happens: PHP stops any request that runs longer than the limit. Imports, backups, large updates and slow external API calls trip it.

1. Find which task triggered it in the log.
2. Raise max_execution_time in the MultiPHP INI Editor, Select PHP Version → Options, or a .user.ini file.
3. Run imports, search-replace and plugin updates with WP-CLI, which has no web timeout.
4. If a plugin waits on a slow external service, ask its developer for a timeout or background processing.

; .user.ini in the site root
max_execution_time = 300

Parse error: syntax error, unexpected … in … on line …

Quick fix: Open the file and line named in the message over SFTP or File Manager and undo the last edit, or restore the file from a backup.

Why it happens: A PHP file has broken syntax, usually from a snippet pasted into functions.php, a missing semicolon or bracket, or curly quotes copied from a web page.

1. Note the file path and line number in the error.
2. Open the file outside WordPress. The theme editor won’t load while the site is broken.
3. Undo the last change or replace the file with a clean copy.
4. Use a code snippets plugin or a child theme for custom code. They catch syntax errors before saving.

Fatal error: Uncaught Error: Call to undefined function

Quick fix: Read the function name. If it belongs to a plugin, that plugin is inactive or missing. If it starts with mysqli_, mb_ or imagecreate, a PHP extension is missing on the server.

Why it happens: Code called a function that doesn’t exist in this setup. A theme relies on a plugin you deactivated, an add-on loaded before its parent plugin, or the server lacks a PHP extension.

1. Search the function name to find which plugin or extension provides it.
2. Reactivate or install the required plugin, or deactivate the add-on that needs it.
3. For missing extensions, enable them in cPanel → Select PHP Version → Extensions, or ask your host.
4. If it started after a PHP upgrade, the function may have been removed from PHP. Update the plugin or theme.

Warning: Cannot modify header information - headers already sent by

Quick fix: Open the file named after “output started at” and remove any blank lines or spaces before <?php or after a closing ?>.

Why it happens: PHP must send headers before any page output. One stray space, a blank line or an invisible BOM character at the start of a file counts as output.

1. Find the “output started at file:line” part of the warning. That file is the culprit, not the one in the first half.
2. Remove whitespace before <?php on line 1.
3. Delete a closing ?> at the end of PHP-only files. It isn’t needed.
4. Save the file as UTF-8 without BOM in your code editor.

Deprecated or Warning messages printed on the site after a PHP upgrade

Quick fix: Hide error display on the live site (WP_DEBUG_DISPLAY false, display_errors off), then update the plugin or theme that triggers them.

Why it happens: Newer PHP versions flag old coding patterns. They are usually notices, not failures, but showing them to visitors looks broken and can break headers and JSON responses.

1. Set WP_DEBUG to false on production, or keep logging on with display off (see the debug setup above).
2. Check the log for which plugin or theme triggers the notices.
3. Update it. If there’s no update, report it to the developer or plan a replacement before the next PHP upgrade.

Your site is running on an outdated version of PHP

Quick fix: Switch to PHP 8.3 in your hosting panel after testing on staging. WordPress recommends PHP 8.3, and since WordPress 7.0 the minimum is PHP 7.4.

Why it happens: Old PHP versions are slower and no longer get security fixes. Site Health shows this warning, and plugins increasingly require PHP 8.

1. Check your current version in Tools → Site Health → Info → Server.
2. Copy the site to staging and switch staging to PHP 8.3.
3. Click through key pages, forms and checkout, and read the debug log.
4. Update or replace plugins that fail, then switch production in cPanel → MultiPHP Manager or Select PHP Version.
5. Keep the old version noted so you can roll back in one click if needed.

Fatal error: Uncaught TypeError or ArgumentCountError after upgrading to PHP 8

Quick fix: Update the plugin or theme named in the error. If no update exists, switch back to the previous PHP version while you replace it.

Why it happens: PHP 8 is stricter. Code that passed the wrong type of value or the wrong number of arguments used to get a warning. Now it stops the page.

1. Read the file path in the error to find the plugin or theme.
2. Update it, then test again.
3. If there’s no fix, roll PHP back one version in your hosting panel to get the site up.
4. Replace or patch the code before trying the upgrade again on staging.

Your PHP installation appears to be missing the MySQL extension which is required by WordPress

Quick fix: Enable the mysqli extension for your PHP version in the hosting panel.

Why it happens: The selected PHP version doesn’t have the database extension turned on. It often happens right after switching PHP versions on cPanel hosts.

1. Go to cPanel → Select PHP Version → Extensions.
2. Tick mysqli (and pdo_mysql if listed) and save.
3. Reload the site. If the option isn’t there, ask your host to enable it.

06Login and admin errors

Login page keeps refreshing or redirects back to wp-login.php

Quick fix: Clear cookies for the site, make sure the WordPress and Site Address URLs match exactly, and test with plugins disabled.

Why it happens: WordPress sets a login cookie for the configured domain. If the URL you use differs (www vs non-www, http vs https), the cookie never matches and you loop. Caching the login page or a security plugin can do the same.

1. Clear cookies and try a private window.
2. Check Settings → General, or define WP_HOME and WP_SITEURL in wp-config.php as shown above.
3. Exclude wp-login.php and /wp-admin from page and CDN caching.
4. Rename the plugins folder to rule out a plugin.
5. If you see “Cookies are blocked or not supported by your browser”, the same URL mismatch is the usual cause.

Sorry, you are not allowed to access this page (admin after a migration)

Quick fix: Check that $table_prefix in wp-config.php matches the real table prefix, including the prefix inside the usermeta and options rows.

Why it happens: User roles are stored under keys that include the table prefix, such as wp_capabilities. If you renamed the prefix during a move but didn’t update those keys, WordPress sees your admin as a user with no role.

1. Compare $table_prefix with the table names in phpMyAdmin.
2. If the prefix changed, update the meta_key values oldprefix_capabilities and oldprefix_user_level in the usermeta table.
3. Update the oldprefix_user_roles option name in the options table.
4. If the prefix is right, check the user’s role with WP-CLI: wp user get 1 --field=roles.

Locked out of WordPress admin (lost password, reset email never arrives)

Quick fix: Reset the password with WP-CLI: wp user update USERNAME --user_pass="new-strong-password". No SSH? Ask your host, or use phpMyAdmin as a last resort.

Why it happens: The reset link depends on email. If the site can’t send email or the admin address is old, you can’t get back in through the login page.

1. With SSH, run the WP-CLI command above. It works in seconds.
2. Without SSH, many hosts have a WordPress manager or toolkit that resets admin passwords.
3. After you’re in, fix email delivery (see emails not sending) and update the admin email.
4. If you suspect someone else changed the password, treat it as a hack: see the security section.

Locked out by a security plugin (too many login attempts)

Quick fix: Wait for the lockout to expire, or rename the security plugin’s folder in wp-content/plugins to disable it, log in, then add your IP to its allowlist.

Why it happens: Brute force protection blocks your IP after failed logins, or a firewall rule flags your network.

1. Try from another network (a phone hotspot) to confirm it’s an IP block.
2. Rename the security plugin folder over SFTP, log in, then rename it back.
3. Allowlist your IP in the plugin settings and use a password manager to stop repeat lockouts.

07Update and install errors

Installation failed: Could not create directory

Quick fix: Make sure wp-content, wp-content/plugins and wp-content/upgrade are writable by the web server user, and that the disk isn’t full.

Why it happens: WordPress can’t write the new files. Wrong ownership after a manual upload, wrong permissions or a full hosting quota are the usual reasons.

1. Check your disk usage in the hosting panel.
2. Set folder permissions to 755. If they are already correct, ask your host to fix ownership.
3. If WordPress asks for FTP details on every update, ownership is wrong. The real fix is ownership, not adding FTP credentials to wp-config.php.

Another update is currently in progress

Quick fix: Wait 15 minutes. If it doesn’t clear, delete the core_updater.lock option.

Why it happens: WordPress locks core updates so two can’t run at once. A failed update can leave the lock behind.

1. Wait 15 minutes. The lock expires on its own.
2. To clear it now, run wp option delete core_updater.lock, or delete that row in the options table with phpMyAdmin.
3. Run the update again.

Destination folder already exists

Quick fix: Delete the leftover plugin or theme folder in wp-content/plugins or wp-content/themes, then install again. Or upload the zip and choose “Replace current with uploaded”.

Why it happens: A previous install failed halfway or the folder was uploaded manually, so WordPress won’t overwrite it.

1. Check whether the plugin is listed under Plugins. If it is, use the replace option when uploading the zip.
2. If it isn’t listed, delete the folder over SFTP and install again.

The package could not be installed. No valid plugins were found

Quick fix: Check you uploaded the plugin zip itself, not a download bundle that contains it, and not a theme zip.

Why it happens: Marketplace downloads often wrap the plugin zip together with docs and licenses. WordPress looks for a plugin header and finds none.

1. Unzip the download on your computer.
2. Find the inner zip named after the plugin and upload that one.
3. Theme zips go under Appearance → Themes → Add New, not Plugins.

Site broke right after a plugin or theme update

Quick fix: Roll the plugin back to its previous version, or restore the backup taken before the update, then report the bug to the developer.

Why it happens: The new version conflicts with another plugin, your theme, your PHP version or custom code.

1. Use recovery mode or rename the plugin folder to get the site back.
2. On WordPress.org plugins, the Advanced View tab on the plugin page lists previous versions to download.
3. Install the previous version and confirm the site works.
4. Test the new version on staging before trying again.
5. For client sites, update on staging first, every time. It costs minutes and saves days.

08Media and upload errors

The uploaded file exceeds the upload_max_filesize directive in php.ini

Quick fix: Raise upload_max_filesize and post_max_size to at least the size you need, in the MultiPHP INI Editor or a .user.ini file.

Why it happens: PHP rejects uploads above its limit before WordPress sees them. post_max_size must be equal to or larger than upload_max_filesize.

1. Check the current limit in Media → Add New (it shows “Maximum upload file size”).
2. Raise both values, for example to 64M.
3. On Nginx, the server also needs client_max_body_size raised, or you’ll see “413 Request Entity Too Large”.
4. For very large files, upload over SFTP and register them with a media import plugin or wp media import.

; .user.ini in the site root
upload_max_filesize = 64M
post_max_size = 64M

The link you followed has expired

Quick fix: Raise upload_max_filesize, post_max_size and max_execution_time. This message usually means the upload was bigger than PHP allows.

Why it happens: When a theme or plugin zip is larger than the post size limit, PHP drops the form data and WordPress can’t verify the request, so it shows this vague message.

1. Raise the limits as in the previous fix.
2. Upload the zip again.
3. Or upload the unzipped folder over SFTP to wp-content/themes or wp-content/plugins.

Are you sure you want to do this? Please try again.

Quick fix: Reload the page and try again. If it repeats on uploads, raise the PHP upload limits. If it repeats everywhere, clear cookies and exclude admin pages from caching.

Why it happens: WordPress protects admin actions with a security token called a nonce. If the token expired, was cached or got lost because the upload was too large, WordPress asks you to try again.

1. Reload and repeat the action.
2. If it happens on theme or plugin uploads, raise upload_max_filesize and post_max_size.
3. Make sure /wp-admin isn’t cached by a plugin or CDN.
4. Test with plugins disabled. A plugin can break its own nonce checks.

HTTP error when uploading images

Quick fix: Try a smaller image first. If that works, raise the memory limit. If not, switch the image library to GD with the snippet below or ask your host about mod_security.

Why it happens: WordPress resizes every upload into several sizes. Very large images, low memory, an Imagick problem or a firewall rule can make that step fail with a generic HTTP error.

1. Resize the image to under 2500 px wide and try again. WordPress scales bigger images down anyway.
2. Raise memory (see memory exhausted).
3. Rename the file to plain letters and numbers.
4. Test with plugins disabled to rule out an image optimizer.
5. If it still fails, make GD the preferred editor with this snippet in a small plugin or your child theme.

add_filter( 'wp_image_editors', function ( $editors ) {
	return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
} );

Sorry, you are not allowed to upload this file type

Quick fix: Convert the file to an allowed format, or allow that type with the upload_mimes filter. For SVG, use a plugin that sanitizes SVG files.

Why it happens: WordPress only accepts common file types for security. SVG, JSON, fonts and some document types are blocked by default.

1. Check whether a normal format works for the job (PNG instead of SVG, PDF instead of DOCX).
2. For SVG logos, install a maintained SVG plugin that sanitizes uploads. SVG files can carry scripts.
3. Avoid ALLOW_UNFILTERED_UPLOADS on live sites. It turns off this protection for every admin.

Unable to create directory wp-content/uploads/… Is its parent directory writable by the server?

Quick fix: Set wp-content/uploads to 755 and check that Settings → Media doesn’t point to an old upload path.

Why it happens: The uploads folder isn’t writable, or an old custom upload path from a previous server is still saved in the database.

1. Fix permissions on wp-content/uploads (and ownership if needed).
2. Run wp option get upload_path. If it shows an old server path, clear it: wp option update upload_path "".
3. Upload again.

Missing a temporary folder

Quick fix: Ask your host to fix the PHP temp directory, or set WP_TEMP_DIR in wp-config.php to a writable folder.

Why it happens: PHP stores uploads in a temp folder first. If that folder is missing or not writable, uploads fail.

1. Create wp-content/temp and make it writable.
2. Add the line below to wp-config.php.
3. Test an upload, then ask your host to fix the server temp directory properly.

define( 'WP_TEMP_DIR', dirname( __FILE__ ) . '/wp-content/temp/' );

Images not showing or broken after a migration

Quick fix: Run a search and replace for the old domain, regenerate thumbnails if sizes are missing, and check hotlink protection and CDN settings.

Why it happens: Image URLs still point at the old domain or staging URL, thumbnail files weren’t copied, or hotlink protection blocks the new domain.

1. Right-click a broken image and copy its URL. It tells you which domain or path is wrong.
2. Replace the old domain with WP-CLI search-replace (dry run first).
3. Regenerate thumbnails with wp media regenerate --only-missing.
4. Turn off hotlink protection in cPanel or add the new domain to it.
5. Purge the CDN if you use one.

Moving a Divi site? Divi adds its own traps, like static CSS files and serialized Theme Options. See moving a Divi site to a new host or domain: 10 errors and fixes.

09Block editor and REST API errors

Updating failed. The response is not a valid JSON response.

Quick fix: Save Settings → Permalinks, then check that nothing blocks the REST API: a security plugin, a firewall rule or Cloudflare. PHP notices printed on screen can also break the response.

Why it happens: The block editor saves through the REST API. If that request returns an error page, a redirect or extra text instead of JSON, saving fails.

1. Open Tools → Site Health and look for a REST API error.
2. Save permalinks to rebuild rewrite rules.
3. Turn off error display on screen (see the debug setup).
4. Check the browser console’s Network tab: the failed request shows the real status code.
5. Disable security plugins and test. If a firewall blocks certain words in your content, ask your host to check ModSecurity logs.
6. Make sure WordPress Address and Site Address use the same protocol.

Site Health: The REST API encountered an error or a loopback request failed

Quick fix: Find what blocks requests from the server to itself: a firewall, Basic Auth on staging, a security plugin or a DNS problem on the server.

Why it happens: WordPress calls its own URLs for scheduled tasks, plugin editors and health checks. If the server can’t reach itself, those features break quietly.

1. Read the exact error under the Site Health item.
2. Test with plugins disabled.
3. If the site is behind password protection, exclude wp-json and wp-cron.php or accept that checks will fail on staging.
4. Ask your host whether outgoing requests to your own domain are blocked or resolve to the wrong IP.

Changes not showing on the live site

Quick fix: Purge caches in order: page cache plugin, server cache, then CDN. Then test in a private window.

Why it happens: Your edit saved, but visitors still get an older cached copy from one of several cache layers.

1. Confirm the change saved by checking the editor or the preview.
2. Purge the caching plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache and similar).
3. Purge the host cache from the hosting panel.
4. Purge the CDN (Cloudflare, BunnyCDN and others).
5. For CSS or JS changes, also clear the builder’s generated CSS (Divi and Elementor both have a setting for it).

10Cron, email and background task errors

Missed schedule: scheduled posts don’t publish

Quick fix: Set up a real server cron that calls wp-cron.php every 5 minutes, and add DISABLE_WP_CRON so page visits don’t have to trigger it.

Why it happens: WordPress runs scheduled tasks only when someone visits the site. On low traffic sites, cached sites or sites with loopback problems, tasks run late or never.

1. Add this line to wp-config.php: define( 'DISABLE_WP_CRON', true );
2. In cPanel → Cron Jobs, add the command below to run every 5 minutes.
3. Check scheduled events with wp cron event list.
4. If you use Action Scheduler (WooCommerce and many plugins do), check Tools → Scheduled Actions for failed jobs.

*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

WordPress not sending emails (contact forms, password resets, orders)

Quick fix: Install an SMTP plugin and send through an authenticated provider (Google Workspace, Microsoft 365, Brevo, Postmark, Amazon SES), then add SPF, DKIM and DMARC records for your domain.

Why it happens: WordPress uses the server’s mail() function by default. Many hosts block or limit it, and mailbox providers send unauthenticated server mail to spam.

1. Install WP Mail SMTP, FluentSMTP or a similar plugin.
2. Connect it to a real email provider with API keys or SMTP login.
3. Add the SPF and DKIM records the provider gives you, plus a DMARC record.
4. Send a test email and check the headers say SPF and DKIM pass.
5. Use a “from” address on your own domain, not a Gmail address.

11Security warnings and hacked site symptoms

Site redirects to spam pages, or Google shows “Deceptive site ahead”

Quick fix: Treat it as a hack: take a backup for evidence, scan files and the database, remove the malware, update everything, change every password and the security keys, then request a review in Google Search Console.

Why it happens: Attackers usually get in through an outdated plugin or theme, a stolen admin password or a nulled plugin. They add redirects to files, the database or .htaccess.

1. Back up the infected site so you can compare and recover data.
2. Scan with Wordfence or your host’s malware scanner, and compare core files with wp core verify-checksums.
3. Reinstall WordPress core, plugins and themes from clean copies. Delete anything you don’t use.
4. Check for unknown admin users, odd .htaccess rules and injected scripts in posts and options.
5. Change all passwords (WordPress, hosting, SFTP, database) and generate new salts in wp-config.php.
6. Request a review in Search Console → Security issues once the site is clean.

12How to stop most of these errors from happening

Nearly every error above is cheaper to prevent than to fix. This is the routine we run on client sites:

• Staging first: test plugin, theme and PHP updates on a copy before production.
• Backups that restore: daily off-site backups and a test restore every quarter.
• Uptime and error monitoring: get alerted before the client notices.
• One plugin per job: fewer plugins means fewer conflicts. Remove what you don’t use.
• Current PHP: stay on a supported version, ideally 8.3.
• Real cron and SMTP: scheduled tasks and email that don’t depend on luck.
• Licensed code only: no nulled plugins, ever.

Want this handled for you? Our white label care plans cover updates, backups, monitoring and fixes for agencies and their clients. For a deeper look at what a plan should include, read our WordPress maintenance plan guide.

13FAQ