Symptom checker

Match the problem you are experiencing with the correct technical solution.

A white screen requires a different approach than a slow checkout. Select the issue that closely matches your current situation, and we will show you exactly how we fix it.

Diagnosis guide

How to diagnose a WordPress issue before you hire help.

When something goes wrong with a website, the symptom is rarely the root cause. A slow website is a symptom. The cause might be a massive uncompressed image, a bloated database table, or a failing server hard drive. By gathering the right information before you engage a developer, you drastically reduce the time it takes to resolve the issue.

Isolating the symptom

The first step in any technical triage is reproducing the error. "The site is broken" is not a helpful diagnostic statement. "When I click 'Submit' on the contact form using Safari on my iPhone, the page refreshes but no email is sent" is incredibly helpful.

When you encounter a problem, ask yourself these four questions:

  1. Does it happen on every device? Try to reproduce the error on your phone via a cellular network (not Wi-Fi). If the site loads fine on your phone but fails on your computer, the issue is likely a local browser cache or a DNS problem on your specific Wi-Fi network, not a server crash.
  2. Does it happen when you are logged in or logged out? Caching plugins frequently bypass logged-in administrators. If the site looks broken to you but fine in an Incognito window, your caching system is likely serving stale CSS files to logged-in users.
  3. What was the exact last action taken? Did you just click "Update" on WooCommerce? Did you change your DNS records to point to Cloudflare? Did you edit a `functions.php` file? Identifying the catalyst is the fastest way to reverse the damage.
  4. What is the exact text of the error? If you see a PHP error on the screen, take a screenshot of the entire text. That string of text tells a developer the exact file name and line number where the code failed.

The difference between hosting issues and application issues

Site owners frequently blame their hosting provider when a website goes down. While hosting providers are sometimes at fault, the vast majority of website crashes are application-level issues (meaning, a problem with WordPress, a theme, or a plugin).

If you see a "502 Bad Gateway" or "503 Service Unavailable" error, the server is struggling to process the PHP requests. This usually means your application (WordPress) is running an incredibly heavy query—like a poorly optimized WooCommerce database search—that is exhausting the server's CPU or memory. Upgrading your hosting plan might temporarily mask the issue by throwing more hardware at it, but the correct solution is to optimize the query.

If you see a "White Screen of Death," this is almost exclusively an application issue. It means PHP encountered a fatal error while trying to execute your code, usually due to a plugin conflict. Contacting your host for a white screen is generally ineffective; you need a developer to read the error logs and disable the conflicting plugin.

Gathering Diagnostic Evidence

Before reaching out for support, try to gather your Site Health Information. Go to your WordPress Dashboard > Tools > Site Health > Info. Click the "Copy site info to clipboard" button. Pasting this raw data to your developer provides them with your exact PHP version, server architecture, and active plugin list instantly.

Why patching symptoms creates technical debt

If your website is running slowly, the worst thing you can do is install three different "speed optimization" plugins simultaneously. They will inevitably conflict with one another, duplicating caching efforts and potentially breaking the front-end layout entirely. This is called patching a symptom.

If a pipe is leaking in your house, you do not put a bucket under it and call it fixed. You replace the pipe. The same logic applies to web development. If a slider plugin is causing a fatal error, the solution is not to write a hacky script to suppress the error message; the solution is to remove the slider plugin and replace it with a lightweight, native Gutenberg block.

Every time you patch a symptom instead of fixing the root cause, you accumulate technical debt. Eventually, the site becomes so brittle that updating a single line of text risks bringing the entire system down. Our approach is always to trace the symptom back to the root cause and eradicate it permanently at the architectural level.

Get professional diagnosis

Stop guessing. Let us identify the root cause.

If you are experiencing an issue not listed above, describe the symptom and provide the URL. We will review the site and tell you exactly what is required to fix it permanently.

Request technical triage