Server Errors: The Complete Troubleshooting Guide

A server error is a message your website shows when it cannot load a page correctly, usually because of a problem on the web server or in your site's setup. This guide helps you identify exactly which error you have, work out whether it is your site or your host, and jump straight to the step-by-step fix.

First, take a breath. Seeing a bare error page where your website should be is stressful, especially if the site is your business. The good news is that almost every server error is fixable, often in a few minutes, and your content is very rarely lost. An error page is a symptom, not a death sentence for your site.

This page is the front door for every hosting error we cover. Instead of guessing, you will do two quick things: identify which error you actually have, then follow the link to the exact guide that fixes it. If you are not sure where to begin, read the next two sections, then use the error table to route yourself to the right place.

This guide is written for site owners and beginners, not server engineers. If a term looks technical, we define it the first time it appears. For the full library of hosting fixes and explainers, you can always return to the Hosting Help Center.

One reassurance before you start: an error page almost never means your files, posts, or images are gone. In the vast majority of cases the content is safe on the server and only the connection between the visitor and that content is broken. Once you find and undo the cause, the site returns exactly as it was. That is why the calm, methodical approach below beats panicked guessing every time.

Every time your browser asks a web server for a page, the server answers with a short numeric HTTP status code — a three-digit number that reports whether the request succeeded or failed. HTTP (HyperText Transfer Protocol) is simply the language browsers and servers use to talk to each other. When everything works, the code is 200 OK and you never see it. When something breaks, the server sends an error code and shows it on screen instead of your page.

The first digit tells you the family the error belongs to. For troubleshooting, two families matter most:

4xx errors are client-side or request-side. "Client" means the request itself — the exact address (URL), your browser, permissions, or a rule your own site is enforcing. A 404 Not Found or 403 Forbidden usually means the page or access being requested is missing or blocked, not that the server has crashed. In practice, 4xx problems are often something you can fix inside your own site or settings.

5xx errors are server-side. The request was valid, but the server could not complete it. A 500, 502, 503, or 504 means something failed while the server was building your page — a crashed process, an overloaded machine, a bad configuration, or a broken connection between servers. Some 5xx errors are your host's responsibility; many are triggered by your own plugin, theme, or code.

The practical takeaway for a site owner: the code narrows down where to look. A 4xx points you toward the specific page, a permission, or a redirect rule. A 5xx points you toward the server, the error log, and whatever you most recently changed. Neither code, on its own, tells you the exact cause — that is what the log and the steps below are for.

You will also see errors that are not standard HTTP codes. WordPress adds its own messages, such as "Error establishing a database connection" and the blank "white screen of death," which behave like 5xx problems but come from the application rather than the web server. Treat them the same way: find out what changed, read the log, and match the message to its fix. Whatever the wording, the goal is always the same — turn a vague on-screen message into a specific, named cause you can act on.

Match the error you are seeing to the row below. Each one links to a dedicated, step-by-step fix. If your exact message is not listed, the diagnosis steps further down work for any error.

Note that the last two are not standard HTTP codes — they are WordPress-specific messages — but they are among the most common things site owners see, so they belong here. If you are getting a broken response inside the WordPress editor rather than a full page error, see the guide to the "Updating failed / JSON response" error.

If your error is not in the table, or you want to understand the cause before you act, work through these checks in order. They apply to every error and take only a few minutes.

1. Ask what changed. Did the error appear right after you installed or updated a plugin, switched a theme, edited a file, or ran a core update? A change immediately before the error is your number-one suspect. If nothing changed on your side, lean toward a host or resource issue.
2. Check the scope: one page or the whole site? Visit your homepage, then a couple of inner pages and the wp-admin login. If only one page fails, the problem is that page (a broken link, a redirect, or its content). If everything fails, the problem is site-wide — usually the server, a core plugin, or the database.
3. Read the error log. The log records the real cause when the on-screen message is vague. In your hosting panel — hPanel (Hostinger) or cPanel — open the Websites → Manage → Error Logs (or Metrics → Errors) section and read the most recent lines. For WordPress, turn on logging by editing wp-config.php: set define('WP_DEBUG', true); and define('WP_DEBUG_LOG', true);, reload the broken page, then read /wp-content/debug.log. The log usually names the exact file or plugin at fault.
4. Confirm it is down for everyone, not just you. Open the site in a private/incognito window, on your phone over mobile data, and from an online checker such as a "down for everyone or just me" tool. If it works elsewhere, the fault is on your side — your cache, your browser, or your DNS. Clearing your browser cache or flushing your computer's DNS cache (the local record of which server an address points to) often clears it.
5. Check your host's status page. Most hosts publish a live status page and post on social media during outages. If your host reports an incident, the error is on their end and the fix is usually to wait and then verify.

By the end of these five checks you will know three things: which error you have, whether it is one page or the whole site, and whether it started after your own change. That is enough to pick the right fix guide with confidence.

This is the single most useful question in troubleshooting, and the one beginners find hardest to answer. Use the callout below as a quick rule of thumb.

When in doubt, the "what changed" test wins. Servers rarely break on their own for no reason; sites frequently break right after an update. If you made a change in the last hour and the site broke, start by undoing that change.

Before you edit any file or change any setting, run through this short checklist. It protects your site and often fixes the error on its own.

1. Back up your site. Files and database, downloaded somewhere safe.
2. Clear all caches. Your caching plugin, your host's server cache, any CDN cache, and your own browser. A stale cached copy causes a surprising number of "errors" that are already fixed.
3. Deactivate plugins. If you can reach wp-admin, deactivate all plugins; if the error clears, reactivate them one by one to find the culprit. If you are locked out, rename the /wp-content/plugins folder over SFTP or the File Manager to disable them all at once.
4. Check your .htaccess file. A corrupt .htaccess (the Apache server's rules file) causes many 500 and 403 errors. Rename it to .htaccess_old; if the site returns, regenerate a clean one by re-saving your permalinks in WordPress.
5. Note exactly what changed. Write down the last thing you did before the error, plus the exact wording of the message. You will need both for the fix guide — or for your host.

Contact your host's support when the diagnosis points to the server rather than your site: every site on the account is down, the error follows a traffic spike, the status page shows an incident, or the error log mentions a server process, resource limit, or database service you cannot control. There is no shame in asking early — a good host will check server logs you cannot see.

You will get a faster answer if you give support the right details up front:

• The exact error message and code (for example, 502 Bad Gateway).
• The affected URL, and whether it is one page or the whole site.
• When it started, and what you changed (or that nothing changed) beforehand.
• What you have already tried — cleared cache, deactivated plugins, renamed .htaccess.
• Relevant lines from the error log, copied as text.

Handing over this summary turns a slow back-and-forth into a single, useful ticket.

You cannot avoid every error, but a few habits make them rare and easy to recover from:

• Keep automatic backups. Daily backups mean any error is, at worst, a quick restore away. Set them up once with the website backups guide and forget about it.
• Test changes on staging. A staging site is a private copy of your live site where you can test updates safely before pushing them live. Most hosts include one; use it for plugin and theme updates.
• Update carefully, one at a time. Update plugins and themes in small batches, not all at once, so that if something breaks you know exactly which item caused it.
• Give your site room to breathe. Chronic 503 and 504 errors under normal traffic often mean you have outgrown your plan. Right-sizing your hosting and tuning your PHP settings (such as memory limit and execution time) prevents resource-related crashes.
• Monitor uptime. A free uptime monitor emails you the moment the site goes down, so you find out before your visitors do.

What is the difference between a 4xx and a 5xx error?

A 4xx error is client-side or request-side: the problem is with the request itself — a wrong URL, a missing page, or a permission that blocks access, like 404 Not Found or 403 Forbidden. A 5xx error is server-side: the request was fine, but the server failed to complete it, like a 500 or 503. In short, 4xx usually means "check the page or your site's rules," and 5xx means "check the server, the log, and what you last changed."

How do I read my website's error log?

You have two main options. In your hosting panel (hPanel or cPanel), open the Error Logs or Metrics section and read the most recent lines. For a WordPress-specific log, add define('WP_DEBUG', true); and define('WP_DEBUG_LOG', true); to your wp-config.php file, reload the broken page, then open /wp-content/debug.log. The last few lines usually name the exact plugin, theme, or file causing the error. Turn WP_DEBUG back off when you are done.

Why does only one page show an error?

If a single page fails while the rest of the site works, the problem is specific to that page rather than the server. Common causes are a broken or looping redirect, a permalink or .htaccess rule, a plugin that only runs on that page type, or content the server cannot process (such as a very large query). Because the rest of the site is fine, you can troubleshoot safely: check the page's redirect, re-save your permalinks, and disable any plugin tied to that page.

Is a server error my fault or my host's?

Ask what changed. If the error appeared right after you updated a plugin, switched a theme, or edited a file, it is almost certainly your site — undo that change first. If every site on your server is down, the error followed a traffic spike, or it clears when the host reboots, it points to your host. When you cannot tell, deactivate your plugins and restore a recent backup; if that fixes it, the cause was on your side.

Will a server error fix itself?

Sometimes. Temporary 502, 503, and 504 errors caused by a brief overload or a server restart often clear on their own within a few minutes. But errors caused by a bad plugin, a corrupt .htaccess, wrong database details, or a code edit will not fix themselves — they stay until you undo the change or repair the cause. If an error persists for more than about ten minutes, treat it as something you need to fix rather than wait out.

What does "Error establishing a database connection" mean?

It means WordPress loaded but could not reach the database that stores your content. The usual causes are incorrect database login details in wp-config.php, a database server that has crashed or is overloaded, or corrupted database tables. Because it takes the whole site offline, it feels alarming, but it is a well-understood problem with a clear fix — follow the database connection error guide.

My screen is completely blank with no message — what is that?

A blank white page with no error text is the WordPress "white screen of death." It usually means PHP crashed while building the page — most often because a plugin or theme hit an error, or the site ran out of memory. Turning on WP_DEBUG normally reveals the hidden message, and deactivating plugins or raising the PHP memory limit usually restores the site. The white screen guide walks through it.

A server error looks scary but is almost always fixable. Read the status code to learn whether the problem is request-side (4xx) or server-side (5xx), use the error table to jump to the right fix, and answer the "what changed?" question to decide whether it is your site or your host. Check the error log for the real cause, and back up before you edit anything.

Next step: the most common site-down error is the database one, so if you are unsure which guide you need, start with how to fix "Error establishing a database connection". And before you make any change, set up reliable backups with the website backups guide so recovery is always one click away.

• MDN Web Docs — HTTP response status codes (4xx and 5xx definitions).
• IETF RFC 9110 — HTTP Semantics (the specification defining status code meanings).
• WordPress Developer Documentation — Debugging in WordPress (WP_DEBUG and WP_DEBUG_LOG).
• WordPress Support — Common WordPress Errors (database connection, white screen).