LiveChat 
Support 
Website Error Troubleshooting: The Complete Guide to Diagnosing and Fixing Site Errors
A website error rarely announces what is actually wrong. You get a number on a blank page, a browser message that “this site can’t be reached,” or a screen that loads halfway and stops. The instinct is to start changing things — clear the cache, restart something, toggle a setting — and hope one of them lands. That approach occasionally works, but it works by accident, and when it does not, you are left more confused than when you started, with no idea which change helped and which made things worse.
There is a calmer way to do this. Website error troubleshooting is not about memorizing a fix for every error message; there are too many, and new ones appear all the time. It is about *isolating the cause* — methodically narrowing down where, in the journey from a visitor’s browser to your server and back, the failure is happening. Once you know the layer, the fix is almost always obvious. This guide is the map for that whole process: how to think about errors, what the status codes mean, and where each class of problem lives. Each major category has a dedicated deep-dive article; this page connects them so you can reason your way to the answer instead of guessing.
Key Takeaways
• Website error troubleshooting is a diagnostic discipline, not a memory game — the goal is to *isolate which layer is failing*, then apply the obvious fix for that layer.
• Every error lives in one of a few layers: DNS, network/connection, the web server, the application (WordPress/PHP/database), or the browser/client.
• HTTP status codes are your single most useful clue — the class (2xx, 3xx, 4xx, 5xx) tells you instantly whether the problem is on the client side or the server side.
• A reliable method beats guessing: reproduce → isolate the layer → check the logs → fix → verify. Skipping the “isolate” step is why most troubleshooting goes in circles.
• Some errors are yours to fix and some belong to your host — knowing the difference saves hours of frustration.
How should you think about troubleshooting a website error?
Before touching a single setting, it helps to adopt a method. The same five-step loop works for almost any website error, whether it is a cryptic 502 or a site that simply will not load.
Reproduce it. Confirm the error is real and consistent before you chase it. Does it happen every time, or only sometimes? On every page, or just one? For every visitor, or only you? An error that appears for you but not on another device or network is telling you something important — the problem may be local to your browser, your cache, or your connection, not the website at all.
Isolate the layer. This is the step everyone skips, and it is the most important. A request to your website passes through several distinct stages, and the failure lives in exactly one of them. Your job is to figure out which. The status code and the *point* at which things break are your evidence.
Check the logs. Once you suspect a layer, the logs for that layer usually tell you precisely what went wrong. A server error log, an access log, or the browser’s developer console will often hand you the exact line, file, or query that failed — far faster than guessing.
Fix the actual cause. With the layer and the log in hand, the fix is targeted: a permission, a configuration line, a plugin, a DNS record. You are no longer poking randomly.
Verify. Reload, test from a clean browser or device, and confirm the error is genuinely gone — not just hidden by a cache. Then you are done.
The rest of this guide gives you the knowledge to do step two — isolate the layer — quickly and confidently.
What do HTTP status codes actually mean?
When your browser asks a server for a page, the server answers with a three-digit HTTP status code. This number is the most honest piece of diagnostic information you will get, because the server is telling you, in a standardized language, how the request went. Learning to read the *class* of the code — the first digit — instantly narrows down where to look.
| Class | Meaning | Where the problem usually lives |
|---|---|---|
| 2xx | Success — the request worked | No error; the page was delivered |
| 3xx | Redirection — the resource moved | Redirect rules, HTTPS forcing, canonical settings |
| 4xx | Client error — the request was bad or not allowed | The request itself: URL, permissions, authentication, the browser |
| 5xx | Server error — the server failed to fulfill a valid request | The server or the application running on it |
The single most useful split is 4xx versus 5xx. A 4xx code means the server received your request and is refusing or unable to honor it *because of something about the request* — a missing page, a permission, a bad URL. A 5xx code means the request was fine, but the server *broke while trying to answer it* — a crashed process, an overloaded backend, a timeout. That one distinction tells you whether to look at the client side and your content, or at the server and your application. Everything that follows is organized around that map.
What causes client-side 4xx errors?
4xx errors point at the request. The server is reachable and responding — it simply will not give you what you asked for, and it is telling you why. These are often the most fixable errors because the cause is usually specific and named.
- 400 Bad Request — the server could not understand the request, often due to a malformed URL, an oversized cookie, or corrupted browser data. Clearing cookies for the site frequently resolves it.
- 401 Unauthorized — authentication is required and either missing or wrong. You need to log in, or the credentials provided were rejected.
- 403 Forbidden — the server understood the request but refuses to allow it. This is almost always a *permissions* problem: file or folder permissions, an `.htaccess` rule, a directory with no index file, or a security plugin blocking access.
- 404 Not Found — the requested resource does not exist at that URL. Common after a page is moved or renamed, or when a permalink structure changes and old links break.
- 429 Too Many Requests — the client sent too many requests in too short a window and is being rate-limited, often by a firewall or a brute-force protection layer.
The defining feature of the 4xx family is that the server is healthy. That means the fix lives in your URLs, your file permissions, your redirects, or your access rules — not in restarting services. The two you will meet most often, 403 and 404, each have their own detailed walkthroughs.
What causes server-side 5xx errors?
5xx errors are a different animal entirely. Here the request was valid, but the server failed while trying to produce a response. The browser did its part; the breakdown is behind the scenes, on the server or in the application stack. These errors feel scarier because the message is usually vague — but the vagueness is the point: the server’s answer-building process broke before it could explain itself, which is exactly why you go to the logs.
- 500 Internal Server Error — the catch-all for “something went wrong on the server.” For a PHP application like WordPress, this often means a fatal error in code, a corrupted `.htaccess`, an exhausted memory limit, or a misbehaving plugin or theme. The server log will usually name the file and line.
- 502 Bad Gateway — one server, acting as a gateway or proxy, got an invalid response from an upstream server. Common when a reverse proxy (like Nginx) sits in front of an application server (like PHP-FPM) that crashed, restarted, or timed out.
- 503 Service Unavailable — the server is temporarily unable to handle the request, often because it is overloaded, out of resources, or in maintenance mode. It is a “come back shortly” signal, but a persistent 503 means a real capacity or configuration problem.
- 504 Gateway Timeout — a gateway waited for an upstream server to respond and gave up. The upstream process took too long — a slow database query, a long-running script, or an unresponsive backend.
Notice the pattern: 502 and 504 are both *gateway* errors, which means they almost always involve the relationship between a front-end web server and a back-end application process. When that link is slow or broken, you get a 504 (too slow) or a 502 (bad answer). Each of these codes has a dedicated guide that walks through the specific causes and fixes.
The real secret to troubleshooting: isolate the layer first
Here is the idea that changes everything, the one principle that turns frustrating guesswork into calm diagnosis: the secret to troubleshooting any website error is not memorizing fixes — it is isolating the layer. Every error, no matter how cryptic the message, lives in exactly one of a small number of layers, and once you know *which* layer, the fix is usually obvious.
Picture the journey of a single request. It starts at the browser/client — where a stale cache, a rogue extension, or local network trouble can break things before a single byte leaves your machine. Next is DNS — does the domain name resolve to an IP address at all? Then the network/connection — can you actually reach that server over the wire? Then the web server — is it up and responding, and *with what status code*? Then the application — WordPress, PHP, the database, the code that builds the page. Each layer can fail independently, and an error in one looks nothing like an error in another.
The brilliance of this model is that the symptoms tell you the layer almost for free. A “this site can’t be reached” message means you never got to a status code — so the problem is DNS or the network, not the application. A clean 404 means DNS, network, and server are all fine — the request arrived and got a real answer; the problem is your content or a redirect. A 500 means everything up to the application worked, and the application itself broke. *The status code and the point of failure are a map straight to the layer.* So the discipline is simple: never start by changing things. Start by asking “which layer?” — narrow it with the symptom and the status code, confirm it with the logs, and only then reach for the fix. Diagnose the layer first; the fix follows on its own.
| If you see… | The layer is likely… | Start by checking… |
|---|---|---|
| “This site can’t be reached” / no status code | DNS or network | DNS resolution, connectivity, the host’s status |
| A 3xx redirect loop | Web server config | Redirect rules, HTTPS forcing, `.htaccess` |
| A 403 or 404 | Web server / content | Permissions, URLs, redirects, index files |
| A 500 / white screen | Application (PHP/WordPress) | Error logs, plugins, themes, memory limits |
| A 502 / 504 | Server ↔ application link | PHP-FPM, upstream timeouts, slow queries |
| Wrong site or old site loads | DNS / cache | Propagation, browser cache, CDN cache |
Why does my browser say “this site can’t be reached”?
When you never even get a status code — just a browser message like `DNS_PROBE_FINISHED_NXDOMAIN` or `ERR_CONNECTION_REFUSED` or `ERR_CONNECTION_TIMED_OUT` — that is a powerful clue. It means the request did not get far enough to receive a server response at all. The failure is below the application, in the bottom two layers: name resolution or the network connection.
`NXDOMAIN`-style errors are about DNS — the domain name could not be turned into an IP address. That points to a missing or misconfigured DNS record, a domain that has expired or is not pointed at the right place, or a nameserver problem. Connection-refused or timed-out errors are about reachability — the name resolved, but the server is not accepting connections (a firewall, a downed service, or the wrong IP). Distinguishing the two is half the battle, and both have their own diagnostic paths in the networking and DNS guides.
How do I troubleshoot WordPress-specific errors?
A large share of website errors are not really web-server errors at all — they are application errors inside WordPress, which means the server is healthy and responding (often with a 500) while the PHP application underneath has broken. These have a recognizable family of symptoms.
- The White Screen of Death — a blank page with no error shown. Usually a PHP fatal error or an exhausted memory limit. The page rendered nothing because the code stopped mid-execution. Enabling debug logging or reading the server error log reveals the offending plugin, theme, or function.
- “Error establishing a database connection” — WordPress cannot reach its database. The credentials in `wp-config.php` may be wrong, the database server may be down or overloaded, or the database may be corrupted. This is a database-layer problem, not a WordPress-code problem.
- “There has been a critical error on this website” — WordPress’s modern, friendlier wrapper around a fatal PHP error. It usually emails the site admin a recovery link and writes details to the debug log, which is where the actual cause hides.
The unifying theme is that these are *layer-four* problems — they live in PHP, the database, or a plugin, and they are diagnosed from logs, not from the front end. The WordPress and database pillars cover the systematic process for each.
What causes SSL and HTTPS errors?
SSL/HTTPS errors are their own distinct category because they break the secure layer *before* the page content is even considered. The browser refuses to load or trust the page, often with a stern full-screen warning, and the message text tells you the specific cause.
- Mixed content — the page loads over HTTPS, but it requests some resources (images, scripts, stylesheets) over plain HTTP. Browsers block or flag these, leaving the padlock broken. The fix is to ensure every resource uses HTTPS.
- Certificate errors — `NET::ERR_CERT_DATE_INVALID` (the certificate expired), `ERR_CERT_COMMON_NAME_INVALID` (the certificate does not match the domain), or an incomplete certificate chain. These are certificate problems, not content problems.
- Protocol errors — `ERR_SSL_PROTOCOL_ERROR` and similar, where the secure handshake itself fails, often due to outdated protocol versions or a server misconfiguration.
Because SSL sits between the network and the content, an SSL error means the connection succeeded but the *secure handshake or trust check* failed. That keeps your diagnosis focused on the certificate, the chain, and the HTTPS configuration. The SSL pillar walks through each error and its fix.
How do DNS and propagation issues cause errors?
Some of the most baffling problems are DNS problems, because the symptoms can be intermittent and inconsistent. A site loads for one person and not another. An old version of the site appears after you have moved hosts. The domain works on your phone’s mobile data but not on your office Wi-Fi. These are the fingerprints of DNS in flux.
DNS is the system that translates your domain name into a server IP address, and changes to it do not take effect everywhere instantly — they *propagate* across the internet’s caches over time. During that window, different visitors may be served different (cached) answers, which is why a site can simultaneously “work” and “not work.” A genuinely unresolvable domain, a record pointing at the wrong IP, or a stale local cache can all masquerade as a broken website when the server is perfectly fine. Recognizing that a problem is DNS-shaped — rather than a server or application fault — saves enormous wasted effort.
How are performance issues and timeout errors connected?
Not every error is a hard failure; some are performance failures wearing an error’s clothing. The clearest example is the 504 Gateway Timeout — it is, at heart, a speed problem. The request was valid, the server was up, but the back-end process took so long that a gateway gave up waiting. Slow database queries, an overloaded server, a resource-hungry plugin, or a script stuck in a loop can all push response times past the timeout threshold and convert “slow” into “broken.”
This is why performance and troubleshooting overlap. When you see intermittent 5xx errors under traffic spikes, or pages that fail only at busy times, you are often looking at a capacity or efficiency problem, not a configuration bug. Diagnosing the slow layer — server response time, caching, queries, or assets — is the same isolating discipline applied to speed.
Where do I find error logs and what do they tell me?
If isolating the layer is the strategy, reading the logs is how you confirm it. Logs are the server’s diary, and they almost always contain the precise cause of an error that the front-end message only hints at. There are two you will rely on most.
| Log type | What it records | When it helps |
|---|---|---|
| Error log | PHP fatal errors, warnings, server faults, the exact file and line | 500 errors, white screens, application crashes |
| Access log | Every request, its URL, status code, and source IP | 404 patterns, suspicious traffic, rate-limit and 429 issues |
The error log is your first stop for any 5xx or application failure — it typically names the file, line, and message behind a 500 or a white screen, turning a mystery into a one-line fix. The access log shows the flow of requests and their status codes, which is invaluable for spotting which URLs 404, where redirect loops form, or whether a flood of requests triggered rate-limiting. On most hosts these live in your control panel’s metrics or logs section, in a `logs` directory in your account, or in standard server paths on a VPS. Knowing where they live — and how to read a log line — is a skill that pays off on every single error.
When should I fix it myself, and when should I contact my host?
A practical question sits underneath all troubleshooting: is this *mine* to fix, or does it belong to my hosting provider? The layer model answers it neatly. Anything in the application layer and above — your WordPress plugins and themes, your file permissions, your redirects, your content, your SSL configuration, your code — is generally yours to fix, because you control it. Anything in the server, network, and infrastructure layers — a server that is down, a hardware fault, a network outage, a DNS or nameserver issue on the host’s side, or persistent 5xx errors that have nothing to do with your code — is your host’s territory.
A simple test: if the error is consistent across every browser and device, lives in your application or content, and the logs point at a file you control, it is yours. If the entire server is unreachable, multiple sites on the same host are down, or the error appears at the infrastructure level with no application cause, contact your host — and bring them the evidence you gathered (the status code, the symptom, the log line). Good support works far faster when you arrive having already isolated the layer.
Fewer errors to troubleshoot in the first place — DarazHost
The best troubleshooting session is the one you never have to start. DarazHost is built to minimize the errors you will ever have to chase down. Servers are actively monitored and backed by a 99.9% uptime commitment, so the infrastructure-layer failures — the ones that are not yours to fix anyway — are kept rare. Automatic backups mean that when a bad plugin or a botched change does cause a 500 or a white screen, you can roll back to a working state instead of debugging under pressure. Sensible PHP and resource limits, free SSL done right, and reliable DNS quietly remove the most common causes of the errors covered in this guide before they ever reach you.
And when something does go wrong, you are not left alone in front of a cryptic code. Real 24/7 technical support helps you do exactly what this guide teaches — isolate the layer and fix the actual cause — fast. That combination, fewer errors plus genuine help when one appears, is what turns troubleshooting from a recurring ordeal into a rare, quickly resolved event.
Frequently asked questions
What is the difference between a 4xx and a 5xx error? A 4xx error is a *client-side* error: the server is healthy and responding, but the request itself was bad or not allowed — a missing page (404), a permission block (403), or a bad URL (400). A 5xx error is a *server-side* error: the request was valid, but the server failed while trying to answer it — a crashed process (500), a bad gateway (502), or a timeout (504). The first digit tells you instantly which side to investigate.
Why does my website work for me but not for other people (or vice versa)? This inconsistency is the classic fingerprint of a *caching or DNS* problem rather than a server fault. Your browser, a CDN, or a DNS resolver may be serving you a cached answer that differs from what others receive — common during DNS propagation after a change, or when a stale cache is involved. Testing from a clean browser, a different device, or another network helps confirm whether the problem is local to you or genuinely on the website.
My site shows a blank white page with no error. What does that mean? That is usually the WordPress “White Screen of Death,” caused by a PHP fatal error or an exhausted memory limit that stopped the page from rendering anything. The page is blank precisely because the code halted before it could output. Enabling debug logging or reading your server’s error log will reveal the specific plugin, theme, or function responsible — it is an application-layer problem, diagnosed from the logs.
How do I know if an error is my fault or my hosting provider’s? Use the layer model. If the error lives in your application or content — a plugin, a theme, file permissions, redirects, your SSL setup — and the logs point at files you control, it is generally yours to fix. If the whole server is unreachable, several sites on the same host are down, or the failure is at the infrastructure level with no application cause, it belongs to your host. Bring them the status code, symptom, and log line so they can act fast.
What does “this site can’t be reached” mean if there is no status code? No status code means the request never reached a responding server, so the problem is in the bottom layers — DNS or the network. `DNS_PROBE`-style messages point at name resolution (the domain could not be turned into an IP), while connection-refused or timed-out messages point at reachability (the server is not accepting connections). Both are diagnosed before the application is ever involved.
Where do I find my website’s error logs? On most shared and managed hosts, logs live in your control panel’s metrics or logs section, or in a `logs` folder within your hosting account. On a VPS or dedicated server, they sit in standard server paths, and WordPress can write its own debug log when enabled. The error log is your first stop for any 500 or white screen; the access log helps with 404 patterns and rate-limiting.
Related guides
– – – – – –
