When a PrestaShop site goes down, the risk is not only the outage itself. The real problem is often a poor first reaction: clearing caches at random, changing several settings at once, or re-running an update on an already unstable store.
This article helps you triage quickly. As of 15 September 2026, here are 10 common causes of a PrestaShop site outage, ordered by observed frequency for this type of incident, with two handy pointers for each: the typical symptom and a 1–5 minute check to run before more technical remediation.
You’ll also learn to distinguish a real outage from a false positive: active maintenance mode, misleading CDN cache or a wrong admin URL. Often that quick check saves the most time.
Start by distinguishing a real outage from a false positive
Before hunting for the root cause, secure the shop and rule out simple cases that look like an outage. On PrestaShop, an intentionally disabled front office, an external cache or a wrong admin URL can waste time if you immediately assume a server issue.
Put the shop in a safe state without making the incident worse
If the shop is responding inconsistently, the right reflex is to protect visitors first. PrestaShop's maintenance mode temporarily disables the front office from the back office (Shop Parameters > General > Maintenance).
If you cannot access the back office, PrestaShop documents, for versions from 1.7, a toggle via app/config/parameters.php by changing maintenance_mode from false to true. There is also a database toggle using PS_SHOP_ENABLE, but that should be a last resort. Do not use that without a recent backup.
If you prefer to avoid ad‑hoc edits on a production store, the page on monthly maintenance for a PrestaShop store describes a cleaner intervention framework.
Rule out maintenance mode, cache and the admin URL first
First quick check: is the shop really down or just disabled? Leaving maintenance mode active after work is a common oversight. Second check: test in a private browser window and, if you can, temporarily bypass Cloudflare, any CDN and server cache. PrestaShop recommends this to rule out a false access or display incident in its help on back‑office login.
Third check: verify the exact /adminXXXX folder URL. If that folder was renamed or removed, the old URL will naturally return a 404 or a blank page. If the issue is primarily admin access, start with a diagnosis for an inaccessible PrestaShop back office rather than heavier fixes.
The 10 most common causes of a PrestaShop site outage
Here’s the core triage. The list below is ordered by observed frequency for these incidents. For each cause, follow the same method: spot the dominant symptom, then run a short verification. If that check is positive, you’ve already narrowed the diagnosis considerably.
Causes 1 to 5 to check first
- A module was just updated, installed or enabled.
Typical symptom: the outage happens immediately after a change, often with an error 500, a white page or a back office that fails to load.
Quick check: review the exact chronology of recent actions. PrestaShop notes that error 500s frequently follow theme or module updates, and that obsolete or incompatible modules after a core upgrade can break the shop. If the main symptom is a 500, also see PrestaShop 500 error diagnosis. - The theme was changed or updated.
Typical symptom: the front office becomes inaccessible or displays incorrectly while the server may still be reachable.
Quick check: check what changed shortly before the outage: theme update or visual edit. If the outage coincides with that change, keep this as your primary suspect. - Maintenance mode is active.
Typical symptom: the front office appears unavailable while the back office remains accessible.
Quick check: verify maintenance mode status in PrestaShop first. It’s a very quick control. - An external cache is showing a stale or failing state.
Typical symptom: one workstation shows the outage while another does not; back‑office access loops or behaves differently between browsers.
Quick check: test in private mode, then bypass Cloudflare, CDN or server cache if possible. If the display changes with context, don’t conclude it’s a code outage yet. - The back‑office URL is no longer correct.
Typical symptom: 404 or blank page at/adminXXXX, even though the shop is not entirely down.
Quick check: compare the requested URL with the actual admin folder name on the server. A rename is enough to appear as an access outage.
Causes 6 to 10 to check next
- PHP version is incompatible with your PrestaShop branch.
Typical symptom: the outage appears after a host change, migration or attempted update that won’t start.
Quick check: compare the active PHP version with the one required by your PrestaShop version. As of 15 September 2026, PrestaShop 9 system requirements state that branch 9.0 supports PHP 8.1–8.4 and recommends PHP 8.4, while 9.1 supports PHP 8.1–8.5 and recommends PHP 8.5. - The
.htaccessfile contains an error.
Typical symptom: error 500 after a change related to the shop URLs.
Quick check: ask whether.htaccesswas edited just before the incident. Its syntax is strict; a single mistake can break access. - The server stops execution before completion.
Typical symptom: the outage occurs during a heavy task: CSV import, backup, translations upload, import/export or thumbnails regeneration.
Quick check: check whether the incident started during a resource‑heavy operation. PrestaShop cites server timeouts as a frequent cause of 500s for such operations. - Code and database schema are out of sync.
Typical symptom: an update refuses to start, or the shop behaves oddly after an incomplete migration or upgrade.
Quick check: see if an update was interrupted. PrestaShop’s update FAQ explains that a mismatch between deployed code and the schema version stored in the database can block processes. - The issue is with CSS or JavaScript assets, not the server itself.
Typical symptom: the shop looks broken or unusable visually while the server still responds.
Quick check: during a theme or display diagnosis, disable CCC options that combine and minify CSS/JS. PrestaShop 9 documentation recommends this to avoid false display problems.
For the technical details of a 500, a broken .htaccess or a timeout, the official help on resolving a PrestaShop 500 error confirms that the module is not the only trail to follow: server and configuration matter too.
Then check what changed just before the outage
A shop that suddenly goes down often has a trigger very close in time. The most useful approach is not to check everything, but to find the event that preceded the incident by a few minutes or hours.
Application changes to check first
Start with the application layer: module update, theme change, attempted PrestaShop upgrade, migration or emergency hotfix. If the outage follows one of these changes immediately, you already have the main suspect.
This is even more important before a major upgrade. If you’re preparing a move to the latest branch, review what to check before upgrading to PrestaShop 9: module and environment compatibility remains the primary filter.
Environment changes that can break a shop without warning
On the hosting side, two checks come up frequently: the active PHP version and available resources. As of 15 September 2026, PrestaShop 9 compatibility ranges are precise, and a PHP version that is too low or too high can block an upgrade. PrestaShop 9 system documentation also recommends a memory_limit of at least 512M per script.
Also review hosting settings changed by the provider or during a migration. The same docs note, for example, that allow_url_fopen should be enabled because remote file access is required by some processes such as payment integrations. It’s not the first check to run, but a serious lead when nothing in the code has changed.
Avoid actions that cloud the diagnosis
During a real outage, the time is often lost less on searching than on bad tests. The goal is not to do many actions, but to do few actions that are traceable.
Don’t leave debug mode or temporary changes enabled in production
Debug mode can help understand an incident, but it must not remain enabled on a production shop. PrestaShop documentation notes it significantly impacts performance and should be disabled after diagnosis. In practice, it can also reveal errors to visitors.
Another often‑forgotten point: if you edit parameters.php, the documentation states you must manually clear the cache in /var/cache/(dev|prod). Otherwise you risk testing a configuration that is not actually loaded by the shop.
Don’t multiply simultaneous changes
Avoid chaining multiple changes at once: disabling a module, switching PHP versions, purging cache, editing .htaccess and then touching the database. After a few minutes you won’t know which action had an effect.
Avoid direct database edits without a recent backup. PrestaShop documents this as risky and a last resort. Finally, don’t assume a cache purge will solve most cases: official causes also include PHP, database schema, .htaccess, timeouts and incompatible modules.
If the site remains down after these checks, move to the right intervention level
After this triage you should be able to answer three simple questions: is the outage real or apparent, which change probably triggered it, and which symptom truly dominates. If you don’t have those three answers, continue triaging. If you do, stop ad‑hoc tests.
Signs that require immediate remediation
Don’t waste more time if the site is totally inaccessible, the back office is down, the error recurs after every simple test, or the outage follows a clearly identified update, migration or environment change. At this stage, the right reflex is to prioritise bringing the site back online before exhaustively searching for every secondary cause.
If availability is your priority, opt for an emergency PrestaShop intervention rather than a long series of live experiments.
Access and information to prepare to save time
Prepare the PrestaShop version, active PHP version, incident start time, last action performed before the outage, and the exact symptom: error 500, white page, back office inaccessible, front in maintenance mode, broken display or timeout during a specific task. These items save time in the first minutes.
If you’ve completed these checks, the next step is bringing an inaccessible PrestaShop site back online. KLN‑WEB provides troubleshooting, emergency support and maintenance for PrestaShop, with a free diagnosis and a clear scope before any work.
Frequently asked questions
Why does my PrestaShop site show an error 500 just after a module or theme update?
Because this is a frequent cause documented by PrestaShop. A module or theme update can introduce an incompatibility, especially after a core upgrade. The correct first step is to check the timeline: what was changed, installed or enabled right before the error, and which exact PrestaShop version you are running.
What should I check first if the front office won’t load but I haven’t identified the cause?
Start by ruling out false positives. First check whether maintenance mode is active. Then test in a private browser window and, if possible, bypass Cloudflare, any CDN and server cache. Finally, see whether the back office is still accessible. These three quick checks avoid jumping prematurely to a server outage diagnosis.
How do I know if my host’s PHP version is incompatible with my PrestaShop version?
Compare the PHP version actually running on the host with the supported range for your PrestaShop branch. As of 15 September 2026, PrestaShop 9.0 supports PHP 8.1–8.4 and 9.1 supports PHP 8.1–8.5. A PHP version that is too low or too high can block an upgrade or cause an outage after an environment change.
How do I put the shop into maintenance if the PrestaShop back office is inaccessible?
For versions from 1.7, PrestaShop documents a toggle via the file app/config/parameters.php by switching maintenance_mode from false to true. There is also a database method using PS_SHOP_ENABLE, but it should remain a last resort. In both cases, have a recent backup before acting.
Why does my back office return a 404 or a blank page at /adminXXXX?
The first hypothesis to check is that the requested URL is no longer correct. If the admin folder was renamed or removed, the old address will not work. This is commonly documented by PrestaShop and often leads to a false full‑site outage diagnosis when the issue is only admin access.
Can Cloudflare, server cache or a CDN make it look like my PrestaShop site is down?
Yes. PrestaShop explicitly recommends testing without CDN cache, without server cache or in a private browser when back‑office access is problematic. An external cache can keep an old error state, a redirect loop or a broken display. Always check whether behaviour changes with the browsing context before concluding the site is actually down.