My shop has a problem: where to start
Your shop no longer behaves the way it did yesterday, and you don't yet know why. This section gathers thirty failures sorted by what you actually see on screen rather than by technical cause: you start from the symptom, the page leads you to the likely origin.
Who this section is for
You are here because something is wrong and the error message, when there is one, tells you nothing. Checkout no longer completes, the admin refuses to open, a page stays blank, or the site answers in ten seconds when it used to answer in one. At that moment the question is not which supplier to hire: it is where the failure comes from.
These pages are written for someone who has no diagnosis yet. They start from what can be seen — a screen, a behaviour, a warning email from the host — and work back towards the possible causes, most frequent first. None of them assumes you can read code.
How the section is organised
The thirty pages fall into four families. Display failures: blank page, missing images, theme broken after an edit, mobile layout gone wrong. Functional failures: payment impossible, checkout blocked, emails not received, imports and exports failing, a sync that stopped. Infrastructure failures: 500 error, 504 error, database connection refused, domain no longer pointing anywhere, expired certificate. And management situations: a site left without maintenance, an unreachable previous supplier, a failure that appeared right after an update or a hosting change.
If your symptom is in the list below, go straight to that page. If you hesitate between several, start with the one that separates a site failure from a hosting failure: it is the first fork in the diagnosis, and it stops you searching on the wrong side.
Display or server: the distinction that saves time
A display failure still lets the server answer: a page does come back, it is simply empty, wrong or badly styled. A server failure prevents the answer from existing at all: the browser gets a 500, 502 or 504, or waits until it times out. In the first case the cause is nearly always in the theme, a module, the cache or a file path. In the second it sits with PHP, the database or the hosting configuration.
Either way the reflex is the same: open the error log before touching anything. On PrestaShop the useful information is in var/logs/ and in the host's own log; on WordPress the WP_DEBUG_LOG constant writes to wp-content/debug.log. A single line there often names the offending file. Changing the site before reading it means erasing the trace that held the answer.
The four most useful pages first
-
Site or hosting: where the failure comes from
The first sort to make. It points you at the code or at the server and stops hours of looking on the wrong side.
-
500 error or blank page
The most common and least talkative message, plus its silent variant. What they actually cover and how to surface the PHP error hiding behind them.
-
My site doesn't respond at all
The browser spins and never shows the site. The four checks that separate a hosting failure from an application failure.
-
Reading PrestaShop error logs
The step-by-step way to find and read the logs, before opening a single theme file.
Frequently asked questions
I can't name my symptom, where do I start?
Do I need FTP or SSH access to follow these pages?
Do these pages apply to both PrestaShop and WooCommerce?
My shop is down right now, do I really have to read first?
The site is working again on its own, should I still investigate?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.