How to troubleshoot any website problem

Every website fault looks unique the moment it appears — a strange error message, a page that won't load, a form that goes nowhere, styling that's fallen apart. But the way you actually find the cause barely changes from one fault to the next. It's less about knowing every possible error in advance and more about working through the same handful of questions in the same order, every time. This is that method.

Step one: write down exactly what you're seeing

Not "the site is broken" — the precise wording of any error message, the exact URL, and what specifically looks or behaves wrong. "Broken" could mean a blank page, a 500 error, missing styling, or a form that submits and does nothing. Each of those is a different problem with a different fix, and the difference is usually visible the moment you actually look closely rather than describing it from memory a few minutes later.

Step two: ask what changed

Faults very rarely appear from nothing. Something changed shortly before it started — a plugin update, a theme change, a new piece of content, a DNS edit, a certificate renewal, even something that seems unrelated, like a traffic spike from a new marketing campaign. Working backward from "when did this last definitely work" to "what's different since then" identifies the cause more often than any other single step in this list.

If you genuinely can't think of anything that changed, check whether it might have happened automatically — an automatic plugin update, a scheduled task, a certificate that renewed or expired on its own schedule.

Step three: work out which layer the fault is actually in

A website is really several separate systems working together — DNS, the server itself, the application running on it, your browser, and sometimes a CDN or caching layer in between. A fault in one layer often looks identical to a fault in another from the outside, so a small amount of isolation goes a long way.

• Is it everyone, or just you? Test from a different network — mobile data with Wi-Fi off is the fastest way — and ask someone else to check independently. If it fails only for you, the fault is local: your browser, your DNS cache, or your network. If it fails for everyone, it's genuinely on the server or DNS side.
• Is it your browser specifically? Load the page in a private or incognito window. This starts with no cache and most extensions disabled, which rules both out in one step if the page suddenly looks correct.
• Is it the whole site, or one page? A fault affecting every single page points at something global — a plugin, a theme, a server-wide setting. A fault confined to one page points at something specific to that page's content or the code that generates it.
• Does the error message name a status code? A 4xx code (like 403 or 404) generally means something about the specific request was wrong — the wrong address, or access correctly denied. A 5xx code (like 500, 502, 503) means the server tried and failed. They point in genuinely different directions.

Step four: find the actual record of what happened

Guessing is slower than reading. Almost every fault leaves some kind of trace, and finding it turns vague troubleshooting into a specific, solvable problem:

• The error log, available in your hosting control panel, names the exact file and line behind most server-side faults. See our guide on reading a server error log.
• Browser developer tools — the Console and Network tabs — show failed requests, blocked scripts, and JavaScript errors that never reach any server-side log at all.
• Your CMS's own debug output, if it has one, often catches warnings and notices that a general server log doesn't.

Step five: change one thing at a time

When you have a plausible cause but you're not certain, resist changing several things at once to "cover the bases". If three changes fix it together, you still don't know which one actually mattered, which means the next similar fault starts from zero again. Disable one plugin, retest. Comment out one line, retest. Revert one setting, retest. It's slower per step, but far faster overall, because each test genuinely rules something in or out.

Step six: turn on more detail temporarily, if you need to

If the log genuinely isn't telling you enough, most platforms have a debug mode that shows considerably more detail — WordPress's WP_DEBUG is a common example. Turn it on, reproduce the fault, note exactly what it says, and turn it back off again immediately afterwards. Detailed error output frequently includes file paths and other information that shouldn't be left visible on a live, public site any longer than necessary.

Step seven: know when to stop and ask

There's no shame in reaching this point, and it's often the fastest route once you've done the steps above rather than the slowest. Bring exactly what you found: the precise error text, the URL, the time it happens, what changed recently, and what you've already tried. Our guide on reporting a problem so it gets fixed fast covers exactly how to package that up, and it's the difference between a ticket that gets resolved in one reply and one that needs three rounds of back-and-forth just to establish the basics.

Why this order works

Each step narrows the search space before the next one starts. Confirming the exact symptom stops you chasing the wrong problem. Isolating the layer stops you fixing something on the server when the fault is in your browser, or the reverse. Reading the actual log replaces a guess with a fact. And changing one thing at a time means that whatever fixes it, you'll actually know why — which matters far more than it might seem the next time something breaks.

You won't need every step every time. A missing stylesheet is usually solved at step three. A rare, intermittent server fault might need all seven. Either way, working through them in order beats trying everything you can think of simultaneously, which is how most troubleshooting time actually gets wasted. Contact support if you get stuck at any point along the way.