What Does a 500 Error Mean, and Why Did My Site Go Down?

A 500 Internal Server Error means the web server ran into an unexpected problem and couldn't deliver the page you asked for. It's a generic "something broke" message: the fault is on the website's server, not in your browser or your internet connection. On WordPress sites the usual causes are a faulty plugin or theme, a broken .htaccess file, PHP running out of memory or a PHP version change, and the exact reason is written in the server's error log.

You open your website and, instead of the usual page, you get a blunt "500 Internal Server Error". No images, no menu, just that line of text. Panic is a natural reaction, especially if the site brings you customers or bookings. The good news: a 500 almost never means anything is lost for good. Your files and content are usually intact, and the cause is specific and fixable. Below is what's actually happening, the real causes, and the order in which to check them.

What a 500 error actually means

When you open a site, your browser asks a server for the page. The server prepares it (runs code, reads from a database) and sends it back. A 500 happens when the server received the request, tried to process it, tripped over something along the way and couldn't finish.

It's a catch-all code: the server uses 500 when no more specific error fits. That's why the message tells you almost nothing about the cause.

Unlike a 404, which says the page doesn't exist, a 500 says nothing about the page itself: the server failed before it could give a normal answer. The message is also vague on purpose, because a public site shouldn't show visitors technical details about its code. The real explanation, with the file name and the line number, sits in the server's error logs.

The same error can look different depending on the browser and the platform:

• "500 Internal Server Error", "HTTP Error 500" or simply "Internal Server Error".
• In Chrome, when the site sends no error page of its own: "This page isn't working", with "HTTP ERROR 500" underneath.
• On WordPress: "There has been a critical error on this website." That's WordPress catching a fatal PHP error.
• A completely blank white page, when the server is set not to display errors.

500 vs 502, 503 and 504

Every 5xx code means the problem is on the server side, but each one points you somewhere different:

If you're only visiting a site that shows a 500

If it isn't your site, there's not much you can fix, but a few things are worth trying:

• Wait a minute and reload (F5, or Cmd+R on a Mac). Sometimes the server was overloaded for a moment.
• If the error appeared while you were paying or placing an order, don't resubmit straight away. Check your email or banking app first to see whether the order went through, so you don't pay twice.
• Open the page in a private window or on your phone over mobile data. If it fails everywhere, the site really is down.
• Come back later, or contact the business by phone or email.

The most common causes

On real sites, a 500 almost always comes from one of these:

• A plugin or theme (especially on WordPress) that updated badly or clashes with something else.
• A code error after a recent edit: someone changed a line and broke the syntax.
• A PHP version change. Hosts move their servers to newer PHP versions from time to time, and an old plugin or theme may not run on them.
• PHP running out of memory. In the log it usually shows up as "Allowed memory size ... exhausted".
• A corrupted .htaccess file or a bad rule inside it (on Apache and LiteSpeed servers).
• A database that can't be reached: wrong password in the configuration, or a database server that is down or overloaded.
• Wrong file permissions after a migration or a restored backup.
• Hosting plan limits: memory or process limits, a full disk, or more files than your plan allows. On some hosts the same limits show up as a 503 or 508 error instead of a 500.
• A script that runs too long (a big import, a backup) and gets cut off by the server.
• An outage at your host, CDN or cloud provider, in which case many sites go down at once.

Notice the pattern: a 500 most often shows up right after a change, such as an update, a new plugin, a move to another server or a PHP upgrade. If the site worked an hour ago, the first question is what changed in between.

Step 1: work out how big the problem is

Before you touch any files, take two minutes to narrow it down:

• Is it the whole site or just one page? One broken page usually points to a single template, plugin or form; the whole site points to configuration, PHP or the server.
• Does the admin area (/wp-admin on WordPress) still open? If it does, you can deactivate plugins from there instead of over FTP.
• Write down the exact time the error started and anything that changed around then: updates, new plugins, code edits, a host migration. The time lets you match entries in the error log, and it's one of the first things your host's support will ask for.

Step 2: read the error log

The error log is where the server writes the real reason behind the 500. Where to find it:

• In cPanel: Metrics, then Errors. It lists the most recent entries from the web server's error log, newest first.
• A file called error_log in your site's folder (often public_html), which you can open from the hosting File Manager.
• Other panels (Plesk, DirectAdmin or your host's own dashboard) have a logs section, and support can pull the log for you.

Look for lines that contain "PHP Fatal error" or "Uncaught Error". The file path tells you who's to blame: if it points into wp-content/plugins/some-name, that plugin is the problem; if it points into wp-content/themes, it's the theme.

Step 3 (WordPress): recovery mode and the debug log

If visitors see "There has been a critical error on this website", check the inbox of the site's admin email address. Since version 5.2, WordPress emails the admin a link to recovery mode. It pauses the plugin or theme causing the fatal error for you only, so you can log in and update, replace or remove it. Visitors keep seeing the error until you do.

If there's no email and the hosting log doesn't help, turn on WordPress's own log. Open wp-config.php and add these lines above the one that says "That's all, stop editing!", as described in the official WordPress debugging guide:

• define( 'WP_DEBUG', true );
• define( 'WP_DEBUG_LOG', true );
• define( 'WP_DEBUG_DISPLAY', false );

Errors then go to wp-content/debug.log instead of appearing on screen for visitors. WordPress advises against running debug mode on a live site, so switch it off again once you've found the cause. If you get a completely blank page instead of an error message, our step-by-step guide to the WordPress white screen of death covers the same checks (debug, plugins, theme, memory) in more detail.

Step 4: undo the last change

Steps 4 to 6 involve FTP or your host's File Manager. If you're not comfortable with that, stop here: renaming folders and editing config files at random can turn a small problem into a big one. Write down what you saw in the log and ask for help.

Most 500 errors are fixed by reversing whatever changed last. Work through it in this order:

• Plugins. If the dashboard opens, deactivate all plugins from the Plugins screen, then reactivate them one at a time until the error comes back. If it doesn't open, rename the wp-content/plugins folder (for example to plugins_old). If the site comes back, a plugin is to blame: open the Plugins screen once so WordPress marks them all inactive, rename the folder back to plugins and reactivate them one by one.
• Theme. Rename the active theme's folder in wp-content/themes, then log in and open Appearance, then Themes. WordPress notices the active theme is missing and switches to a default theme (one of the "Twenty..." series), as long as one is installed. If the site works on the default theme, your theme was the cause.
• .htaccess. Rename .htaccess to .htaccess_old (it's a hidden file, so you may need to turn on "show hidden files"). If the site comes back, go to Settings, then Permalinks, and click Save Changes: WordPress writes a fresh .htaccess, or shows you the rules to paste in if the file isn't writable.
• Code edits. If someone edited functions.php or another file, put the previous version back.

Step 5: check PHP memory, PHP version and hosting limits

• Memory. If the log says "Allowed memory size ... exhausted", the limit needs raising. WordPress reads the WP_MEMORY_LIMIT setting from wp-config.php, but some hosts don't let WordPress raise it; in that case raise memory_limit in your hosting panel or ask your host.
• PHP version. In cPanel you'll find it under Software, then MultiPHP Manager (some hosts use their own PHP selector). If the 500 appeared right after a PHP upgrade, the real fix is to update or replace the incompatible plugin or theme. Switching back to the older PHP version only buys you time.
• Hosting limits. Look at your panel's resource usage, disk space and file count. If you keep hitting your plan's limits, the fix is a cleanup or a bigger plan, not another plugin.

Step 6: permissions and core files

• Permissions. On shared hosting, WordPress recommends 755 (or 750) for folders and 644 (or 640) for files, with wp-config.php at 440 or 400. Never use 777, not even for an uploads folder.
• Core files. If WordPress files were damaged during an update, re-upload the wp-admin and wp-includes folders from a fresh WordPress download, as the official WordPress troubleshooting guide suggests. Don't overwrite wp-content: that's where your themes, plugins and uploads live.

Not on WordPress?

• Website builders (Wix, Squarespace, Shopify and similar). The servers belong to the platform, so you can't fix a 500 on your side. Check the platform's status page and contact its support. If only one page fails, review any custom code you added recently.
• Custom-built sites and web apps. Check the application or deployment logs at your host. If the error started with a new release, roll back to the previous deployment first, then look for the bug.

When to restore a backup or call your host

If you have a backup from before the problem started, restoring it is often the quickest way back online, especially when you can't tell what changed. Keep in mind that anything added since that backup (orders, form entries, new posts) may need to be redone.

Contact your host if the log points to the server rather than your code, if you're hitting resource limits, or if several sites on the same account are down. Send them the domain, the exact URL, the time the error started and what changed. With that, support can check server logs and limits you can't see yourself.

Does a 500 error hurt your Google rankings?

A short outage usually doesn't; a long one can. According to Google's documentation on server errors, when pages return 5xx errors, Google's crawlers temporarily slow down, in proportion to the number of failing URLs, and ignore the content of those responses. Pages that are already indexed are kept for a while, but they are eventually dropped if the errors continue. Once the server answers normally again, Google gradually increases the crawl rate.

• Fix the error first, then check Search Console: the Page indexing report lists affected pages under "Server error (5xx)", and once they're fixed you can click Validate fix.
• If you need to take the site offline for a day or two, for maintenance for example, don't leave it throwing 500s: for short breaks like that, Google recommends an informational page with a 503 status.

How to stop it from happening again

A site shouldn't collapse because of a simple update. A few habits make the difference:

• Automatic, regular backups, stored away from the server and test-restored now and then. If you have a copy from yesterday, a 500 becomes reversible in minutes.
• Test updates on a copy (staging) before they touch the live site. Here's our 6-step staging workflow for updating WordPress safely.
• Keep plugins few and actively maintained, and delete the ones you don't use.
• When your host announces a PHP upgrade, check that your theme and plugins support the new version before the switch.
• Set up uptime monitoring that alerts you by email or text, so you hear about a 500 before your customers do.
• Choose a host with enough resources and support that actually responds.

At MPO Web Studio we build sites so the owner doesn't wake up to an error page. We work with backups, a staging environment and clean code, not a heap of plugins glued together. And if something does break, we fix it remotely, without leaving you offline for hours.

When your site brings in customers, time matters

A 500 error on a brochure site is annoying. On a site that brings in bookings, orders or clients, every hour offline means lost money and shaken trust: someone searching for your service hits an error page and goes to a competitor.

That's why it pays to have someone who picks up the phone quickly, not three days later. We also provide remote maintenance wherever you are, and we tell you upfront exactly what you'll pay, with no surprises.

If you're stuck with a 500 right now and don't know where to start, message us on WhatsApp with your site address and what happened before it went down. We'll take a look and tell you honestly whether it's something quick or serious.