500, 502 and 503 errors explained

The short answer

These three numbers come from the web server, not from WordPress. A 500 means something inside your site crashed. A 502 means the server in front could not get a usable answer from PHP (the programming language WordPress runs on). A 503 means the site is deliberately or temporarily unavailable, often because an update is in progress or the server is overloaded.

Wait a minute and reload. If it persists, check for a leftover .maintenance file, test your .htaccess file, and disable the plugin you changed most recently. If none of that helps, contact support with the exact time it started.

What it means

Every page request gets a status code back. 200 means fine, 404 means not found, and anything in the 500s means the problem is on the server side rather than in your browser.

500 Internal Server Error is the catch-all. The server tried to run your site and something failed before a page could be produced. The real cause could be a PHP fatal error with the error display turned off, a damaged .htaccess file (a small configuration file that Apache, one kind of web server, reads on every request), or wrong file permissions.

502 Bad Gateway means one layer asked the next and got nothing sensible back. Most hosting stacks have a proxy (such as nginx or Cloudflare) in front of PHP. If PHP crashes, takes too long, or has no free workers, the proxy gives up and reports 502.

503 Service Unavailable is the server saying “not right now”. WordPress sends this itself while an update is running. Servers also send it when they are out of resources or when too many requests arrive at once.

Common causes

• A plugin or theme fault, usually after an update. Shows as a 500, or as a 503 if a maintenance or coming-soon plugin is involved.
• A stuck update. WordPress creates a .maintenance file in the site root while updating and deletes it afterwards. If the update is interrupted, the file stays and every visitor gets a 503.
• A damaged .htaccess file, often from a plugin writing bad rules into it. Classic cause of a 500.
• PHP under strain. A very slow request, a traffic spike, aggressive bots or a runaway scheduled task can use up every PHP worker, so new requests get 502 or 503.
• Wrong file permissions or ownership, sometimes after a migration or a manual upload.
• A server-level problem such as a full disk or a crashed PHP service. This one is for your host to fix.

How to fix it

1. Reload after a minute, and try yoursite.com/wp-admin. A 502 or 503 caused by a short spike often clears on its own. If the admin area works but the front page does not, suspect caching or the theme.
2. 503 straight after an update? Open File Manager in the management console (Plesk with WP Toolkit) or connect over SFTP, look in the site’s root folder (the one containing wp-config.php) for a file named .maintenance and delete it. Also deactivate any maintenance mode or coming soon plugin under Plugins > Installed Plugins.
3. 500? Test .htaccess. In the site root rename .htaccess to .htaccess.old and reload. If the site comes back, log in, go to Settings > Permalinks and click Save Changes; WordPress writes a fresh, clean file. Not every server uses this file, so skip this step if there is none.
4. Read the logs. In the console go to Websites & Domains > Logs and look at the PHP and web server error logs around the time of the error. For WordPress-level detail, add define('WP_DEBUG', true); and define('WP_DEBUG_LOG', true); to wp-config.php and read wp-content/debug.log. Turn them off afterwards.
5. Disable the suspect plugin. In wp-content/plugins rename its folder, for example to plugin-name.off. To test everything at once, rename the whole plugins folder. This works on any host.
6. Check PHP settings. Under Websites & Domains > PHP Settings confirm the version is 8.3 or 8.4 and that memory_limit and max_execution_time are not set unusually low.
7. Fix permissions if a migration or upload preceded the error. Folders should be 755, files 644, and wp-config.php 640 or 600. Your host’s File Manager can set these, or support can do it over SSH.
8. Look for load. If errors come and go, check Tools > Site Health for a failing scheduled task, look at your analytics for a traffic spike, and ask support whether bots are hammering the site.
9. Restore a backup from Backup & Restore if the error began with a change you cannot pin down, then contact support with the exact time and the status code you saw.

On WP Alpha

A business grade web application firewall with brute force protection sits in front of every WP Alpha site, with Cloudflare in front of that, which stops most of the bot floods that cause 502 and 503 errors under load. Redis object caching and page caching are on every plan, so legitimate traffic spikes are served from cache rather than hitting PHP for every visitor.

Updates are the most common trigger for a 500, and WordPress, plugin and theme updates are tested on a staging copy with before and after screenshots and an error log check before they go live. If a change of your own breaks the site, backups run every two hours and are kept for 30 days, and you can restore from a single file up to the whole site from the management console (Plesk with WP Toolkit).

For anything server-side, support is 24/7 by live chat and tickets, with an urgent escalation form. SSH access is available if you want to read the logs yourself.