The site went down at eleven in the morning. Your developer says the server is struggling. Your host’s support chat says the hosting looks fine and it must be a plugin. Both are pointing away from themselves, and you are the one with a customer on the phone asking why the booking page will not load.
Working out whether you have a WordPress bug or hosting problem is less about technical skill than about collecting the right evidence. A few tests, all of them read-only, will usually tell you which side owns the fault. Once you know that, you can send the right person a message they cannot bounce back.
Why a WordPress bug or hosting problem looks the same from outside
WordPress is a set of PHP files and a database. The hosting is the machine that runs PHP, serves files and keeps the database alive. When a page fails, you only see the end result: a blank screen, an error code or a spinner. The same blank screen can come from a plugin that crashed inside PHP or from a server that ran out of memory before PHP finished. From the outside they look identical.
There is also a grey zone. A plugin that runs a slow database query on every page is a code problem, but it shows up as a hosting problem because the server hits its limits. A host that quietly changes the PHP version is a hosting change, but it shows up as a plugin error. Keep that overlap in mind. When you ask whether you have a WordPress bug or hosting problem, the goal is to find where the fault starts, not to win an argument about blame.
Is it WordPress or the server? Five read-only tests
None of these change anything on the site. Do them in order and write down each result with the time.
1. Load a plain file that does not run PHP
Every standard WordPress install has a file called readme.html and another called license.txt in its main folder. Open yoursite.com/license.txt in a browser. This file is served straight from disk, without PHP or the database.
- If license.txt loads quickly but your pages fail, the web server is up and answering. The problem is somewhere in PHP, WordPress or the database. That leans towards a bug, a PHP setting or a database fault.
- If license.txt also fails or times out, the problem sits before WordPress: the server, the network, DNS or a firewall. That is the host’s territory, or your domain settings.
Some hosts or security setups remove those two files. If both return “not found”, try any image you know exists in your media library by opening its direct address. An image is also a static file.
2. Read the exact error code
The wording on the screen narrows things down more than people expect.
| What you see | Where it usually starts |
|---|---|
| “There has been a critical error on this website” | PHP code inside WordPress, usually a plugin or theme |
| “Error establishing a database connection” | Database credentials, or the database service on the host |
| 502, 503 or 504 | Mostly the hosting stack, sometimes a slow plugin pushing it over |
| 500 Internal Server Error | Either side; the server error log decides |
| Browser says the site cannot be reached | DNS, domain, server down or a network block |
| Page loads but one feature is broken | Almost always WordPress: a plugin, the theme or custom code |
The gateway errors are explained in more depth in what 502, 503 and 504 mean on a WordPress site, including why a busy plugin can trigger them.
3. Check whether wp-admin behaves differently
Try to open yoursite.com/wp-admin/. If the public site fails but the dashboard opens, the fault is probably in something that only runs on the front end, such as the theme or a front-end plugin. If both fail in the same way, look at things they share: PHP, the database, memory or the server itself.
4. Look for a pattern in time
Faults caused by code tend to be consistent. The same page breaks every time, on every device, until someone changes something. Faults caused by resources tend to come and go. The site is fine at night and falls over at lunchtime, or it fails for a minute and recovers on refresh.
If you have uptime monitoring, its history will show this pattern clearly. If you do not, refresh the failing page a few times over ten minutes and note the result each time.
5. Compare with anything else on the same hosting
If your hosting account holds more than one website, or the host runs a status page, check those. Two unrelated WordPress sites failing at the same moment points firmly at the server. One site failing while its neighbour on the same account works points back at that one site’s code or settings.
Signs that point at WordPress
- The problem started right after an update to a plugin, the theme or WordPress itself.
- An error message names a file path containing wp-content/plugins/ or wp-content/themes/.
- Only one page, one form or one feature is broken, and the rest of the site is quick.
- WordPress sent the admin email address a message about a fatal error with a recovery mode link.
- The fault is the same on every attempt and every device.
That file path is the most useful clue of all. When PHP stops on a fatal error, the log line names the file and line number where it happened. The folder name inside plugins tells you which plugin. Our guide on finding and reading the WordPress error log shows where that line usually lives and how to read it without getting lost.
Signs that point at the hosting
- Static files fail, or the whole domain cannot be reached.
- The fault is intermittent and gets worse at busy times.
- Your hosting control panel shows resource limits being hit: CPU, memory, processes or I/O, depending on what the host measures.
- The host sent an email about maintenance, a migration, a PHP change or an account suspension.
- Several sites on the same server fail together.
- Database errors appear even though nobody has touched wp-config.php.
One caution about resource limits. A graph showing the account at its memory ceiling proves the server is under strain. It does not prove why. A badly written plugin, a bot hammering your search page or a backup job running at noon can all fill the same graph. The host can usually tell you which process or which address was busy, so ask them for that detail rather than just a yes or no.
The grey zone: problems that belong to both
A few common faults genuinely sit between the two, and knowing them saves a lot of back-and-forth.
PHP version changes
Hosts retire old PHP versions. When they move your account to a newer one, a plugin written for the old version can stop working. The trigger was the host; the broken code is in WordPress. The fix is normally to update or replace the plugin, not to ask the host to switch back for ever. You can see the current version under Tools, then Site Health, then Info, in the Server section.
Memory limits
WordPress can request more memory, but only up to the ceiling the host allows. A site that suddenly needs much more memory than it used to usually has a plugin doing something heavy. Raising the limit may hide it for a while. Finding what changed is the real fix.
Security rules
A host’s firewall or ModSecurity rule can block a perfectly normal WordPress request, such as saving a page that contains certain code. To you it looks like a WordPress bug: the save button fails. In reality the server refused the request. A 403 on save, rather than an error inside the editor, is the hint.
What to send each side
The fastest way to end the blame loop is to send evidence, not opinions. Write a short message with:
- The exact address that fails and the exact error text or code.
- The time it started, in your time zone, and whether it is constant or intermittent.
- The result of the static-file test.
- Anything that changed in the previous day: updates, new plugins, DNS edits, a hosting renewal.
- Any error log lines you found, copied as text.
To the host, ask specific questions: “Were there resource limit hits on my account between 11:00 and 11:20? Was the PHP version or server configuration changed this week? Is anything in the server error log for this domain at that time?” Questions like these are hard to answer with a generic “everything looks fine”.
To a developer, send the same list plus a login, or at least the error log lines. A developer who can see a fatal error naming a plugin file has a starting point. One who only hears “the site is slow” has to start from nothing. If you have never had to explain a fault like this before, the wider map of common WordPress errors helps you name what you are seeing.
Mistakes that make the diagnosis harder
- Restoring a backup straight away. If the fault is on the server, the restored site will fail too, and you will have overwritten any orders or form entries since the backup.
- Switching hosts in a panic. A plugin bug moves with the site. You will pay for the move and keep the problem.
- Changing several things at once. If you raise the memory limit, update three plugins and clear the cache together, you will never know which step mattered.
- Testing only while logged in. Logged-in users often skip the page cache, so you may see a different site from your visitors. Check in a private window too.
When to stop and hand it over
Stop testing and get help when the error log points to code you cannot read, when the host and the developer have each blamed the other with no evidence, or when the site takes money and every hour offline costs you. It is also time to step back if the fault keeps returning after each fix, because a repeating fault usually means a structural cause that nobody has looked at yet.
If the trail leads into WordPress itself, that is the wordpress bug fixing work we do: reading the logs, finding the plugin or setting at fault and explaining it in plain terms. If it leads to the server, our help with hosting and domain issues covers server, DNS and hosting faults.
Whichever way it goes, the static-file test and a timed note of each failure will settle more arguments than opinions will. Start with those, and the right owner of the problem is usually clear before anyone has to argue about it.
Next in this series: WordPress Shortcode Not Working? Read the Symptom
