To troubleshoot a website you reproduce the fault, read the real error, isolate the cause by changing one thing at a time, and keep a route back at every step. The order matters more than the technique. Start by telling a 500 from a 502: the first means your own application hit a fatal error, the second means something in front of it could not reach it, and the status code list says which layer you are standing in before you have touched anything.
The habit worth unlearning is disabling plugins until something changes. It works often enough to feel like a method and tells you nothing on the day it does not.
What do you check before changing anything?
The symptom and the layer it points at. Two minutes here saves an afternoon, because the most expensive troubleshooting is a confident fix applied to the wrong layer.
| What you see | Which layer | Where the real message is |
|---|---|---|
| 500 internal server error | Your application, usually PHP | The server error log |
| 502 or 504 | A proxy in front of your app | The web server log, then the app |
| 503 service unavailable | Overload, or maintenance mode | The host’s status page, then the log |
| White page, no error | PHP fatal with display off | The error log, always |
| Page loads, one thing broken | The browser | The console and network panels |
The last row is the one people misdiagnose most. If the page arrives and a button does nothing, the server did its job and the fault is in front of it. Open the network panel and the console before you look at anything server-side.
The white page deserves its own note. It is not a mystery; it is a fatal error with display turned off, which is the correct production setting. The message exists and it is in the log.
How do you reproduce it reliably?
Deliberately, and write it down, because a fault you cannot reproduce is one you cannot confirm you fixed.
Get four things: the exact URL, the browser and device, whether the person was logged in, and what they did immediately before. That last one catches the faults that only appear after a particular sequence, which are the ones that survive three rounds of guessing.
Then try to reproduce it in a private window and on another network. If it goes away, you are usually looking at caching or at a logged-in difference, and that is a completely different investigation from a broken site. This is the single most common false alarm: the owner sees a cached page and the customer does not, or the other way around.
Write the reproduction steps in a note before you start changing things. In an hour you will have changed four things and your memory of the original will be worse than you expect.
How do you isolate the cause?
One change at a time, on a copy, with the last known good state still available.
Take a copy of the site. Everything below is much safer there, and the version that skips this step is doing it on production while customers watch, which is how one problem becomes two.
A copy worth having is the files and the database together, taken at the same moment. Most hosts offer a one-click staging site, which is the cheapest version of this and worth finding in your control panel before you need it. A copy of the files without the database will not reproduce a data-shaped fault, which is most of them, and a copy taken two days ago is a different site from the one that broke.
For a plugin or theme conflict, deactivate all of them, confirm the fault is gone, and reactivate one at a time. With thirty plugins, halve instead: switch half on, see which half misbehaves, repeat. Five rounds gets you through thirty.
Turn on real error reporting while you do it. WordPress has a documented debug mode that writes to a log file rather than to the screen, and the advanced guide covers the rest. The underlying settings are PHP’s error configuration, which is worth knowing because the same knobs exist outside WordPress.
| Isolation step | What it rules out | The trap |
|---|---|---|
| Switch to a default theme | Your theme and its functions file | Losing customisations if done on live |
| Deactivate all plugins | Plugin conflicts | Deactivating a plugin that holds data |
| Test as a logged-out visitor | Role and admin-bar differences | Your own cached session |
| Disable caching layers | Stale pages masking the fix | Forgetting to turn them back on |
The second row’s trap is real and worth slowing down for. Some plugins clear or migrate data on deactivation, and a membership or ecommerce plugin is not something to switch off casually on a live store.
What if you cannot even reach the admin?
A different problem, because the usual isolation steps all assume you can click things. There are three routes in and it is worth knowing them before you need them.
Rename the plugins folder. Over SFTP or your host’s file manager, rename
wp-content/plugins to something else. WordPress finds no plugins and deactivates them
all, which usually gets you back into the admin. Rename it back and the plugins
reappear, deactivated, ready to switch on one at a time. The same trick on the active
theme’s folder forces the default theme.
Use the recovery link. When a fatal error comes from a plugin, WordPress emails the site administrator a recovery-mode link that loads the admin with the offending plugin paused. Check the address in your site’s settings, because if that mailbox is wrong or unread this feature quietly does not exist for you.
Use the command line. If your host offers WP-CLI, deactivating a plugin is one command and does not need the admin at all. Worth finding out whether you have it on a calm day rather than a bad one.
Database connection errors sit slightly apart from all of that. The message means WordPress could not reach the database, and there are only a few reasons: the credentials in the configuration file are wrong, usually because something was migrated; the database server is down or refusing new connections; or the database itself is corrupted. Check whether anything else on the same host is up. If nothing is, it is not your site and the useful action is asking your host two precise questions: is the database server accepting connections, and what is in the PHP error log right now.
The general rule underneath all of this: you want file access to be something you have already tested. The afternoon to find out you cannot log into your own hosting panel is not the afternoon your site is down.
How do you avoid making it worse?
By changing one thing at a time and writing down each change as you make it.
Keep a list in a text file: what you changed, when, and what happened. It feels excessive for the first ten minutes and is the difference between a clean rollback and an archaeology project at minute ninety. The failure mode is not one bad change; it is six changes and no memory of which came first.
Avoid editing plugin or theme files directly. The edit vanishes at the next update, which means the fault returns in a month with nobody remembering why. If you must patch in an emergency, keep the original file beside it and redo the fix properly afterwards.
And set a limit before you start. Decide that after ninety minutes you will restore and investigate on a copy. Deciding that in advance is much easier than deciding it at minute eighty-five with the site still down.
When is restoring a backup the right call?
Sooner than most people accept, and it is a tool rather than an admission.
Restore when you have spent longer diagnosing than a restore would take. Restore when you have lost track of what you changed, because an unknown state is worse than an old one. Restore immediately when the site is down and money is stopping, then investigate the copy afterwards without an audience.
The only bad restore is the one done without keeping the broken state. Take a copy of the broken site before you overwrite it, or you have destroyed your only evidence and the fault will return with nothing to learn from.
Two cases argue the other way. If you know exactly what you changed and can reverse that one thing, reverse it rather than rolling back a day of orders with it. And if the backup is older than your last order, restoring costs you real data, which turns a technical problem into a customer one. Check the backup’s age before you trust it, and check that it restores at all, because a backup nobody has tested is a hope rather than a plan.
What our own product does when it meets a question it cannot support is in what an AI chatbot for a website actually is, the engineering habit of measuring before changing is in why we dropped GSAP, the configuration detail is in the docs, and if you are stuck, contact reaches a person.
Answers to the usual questions
How do I troubleshoot a website?
In four steps and in this order: reproduce the fault so you can tell when it is fixed, read the real error from the server log or the browser console rather than the friendly message, isolate the cause by changing one thing at a time on a copy of the site, and keep a way back at every step. Most wasted hours come from skipping the first step and guessing at the third.
What does a 500 error mean?
That your own application hit a fatal error and stopped, usually PHP on a WordPress site, which is why it is called an internal server error. It is different from a 502 or 504, where something in front of your application could not reach it or waited too long. The distinction tells you which layer to look at, and the real message is in the error log rather than on the page.
How do I find which plugin is causing the problem?
On a copy of the site, not the live one. Deactivate everything, confirm the fault is gone, then reactivate one at a time, checking after each. Binary search is faster with many plugins: switch half on, see which half misbehaves, repeat. The version that goes wrong is doing this on production while customers watch, which is also how one problem becomes two.
Why does my site work for me but not for visitors?
Nearly always caching or a logged-in difference. You are being served a cached page, or the admin bar, or a personalised version, and your visitors are not. Test in a private window, on another network, and logged out. If it still only happens for them, ask for the browser, the device and the exact URL, because a fault you cannot reproduce is one you cannot confirm you fixed.
Should I edit files directly to fix a problem?
Only with a copy of the original and a way to put it back, and never as the first move. Direct edits vanish at the next theme or plugin update, so a fix that survives has to live somewhere update-safe. The exception is an emergency where the site is down: get it serving, then redo the fix properly rather than leaving the emergency patch in place.
When should I restore a backup instead of fixing it?
When you have spent longer diagnosing than a restore would take, when you no longer know exactly what you changed, or when the site is down and money is stopping. Restoring is not defeat. It converts an unknown state into a known one, and you can investigate the copy afterwards without an audience. The mistake is treating restore as the last resort rather than a tool.
