# How to troubleshoot a website: reproduce, isolate, change one thing

> By Lawrence Dauchy, Founder, DFYe. Published 2026-08-29. 10 min read. Guides.
> Source: https://dfye.com/blog/how-to-troubleshoot-website/
> Language: en

Four steps, in this order, with a route back at every one. The route back is the step people skip and the one that turns a broken site into a lost site.

**TL;DR.** To troubleshoot a website: reproduce the fault reliably, read the actual error rather than the symptom, isolate by changing one thing at a time on a copy, and keep a route back at every step. A 500 and a 502 point at different layers and are worth telling apart before you touch anything. The fastest way to lose a site is a confident fix applied to the wrong layer.

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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status) 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](https://developer.chrome.com/docs/devtools/network) 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](https://wordpress.org/documentation/article/debugging-in-wordpress/)
that writes to a log file rather than to the screen, and
[the advanced guide](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/)
covers the rest. The underlying settings are
[PHP's error configuration](https://www.php.net/manual/en/errorfunc.configuration.php),
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](/blog/ai-chatbot-website/), the
engineering habit of measuring before changing is in
[why we dropped GSAP](/blog/we-dropped-gsap/), the configuration detail is in
[the docs](/docs/), and if you are stuck, [contact](/contact/) reaches a person.

## Quick answers

### 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.

## Sources

- [MDN: HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status)
- [WordPress: debugging in WordPress](https://wordpress.org/documentation/article/debugging-in-wordpress/)
- [WordPress: advanced debugging](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/)
- [PHP manual: error handling configuration](https://www.php.net/manual/en/errorfunc.configuration.php)
- [Chrome DevTools: the network panel](https://developer.chrome.com/docs/devtools/network)

---
*Published by [DFYe](https://dfye.com/). Free to read, index, quote and cite with attribution and a link.*