PrestaShop 500 error: how to diagnose and fix it

A 500 error on PrestaShop can take your entire shop offline. Sometimes it only appears in the back office, on a product page, in the cart or during checkout. The problem is that the message Internal Server Error alone tells you almost nothing.

The right approach is not to change everything at once. First find the real error message, then test in a logical order: debug mode, logs, recent changes, modules, cache and server environment. At the end of this guide you will know what to check, in which order, and when to stop experimenting to avoid making the outage worse.

What a 500 error on PrestaShop really means

Status code 500 is a generic symptom. Before touching files or the server, start by defining the exact scope of the outage.

Why the 500 code alone is not enough

According to MDN, on 20 October 2026, HTTP 500 means the server encountered an unexpected condition and could not return a more specific 5xx code. In other words, 500 is not a cause. It is the visible symptom of a more precise error you must find in debug mode or in the logs.

The same symptom can come from an incompatible module, stale cache, PHP version change, invalid .htaccess, insufficient memory or incorrect permissions. If you restore everything too early you may waste time and create a heavy rollback when a targeted fix would have sufficed.

Identify whether the outage affects the whole site, the back office or a specific action

Before any test, note precisely what is failing:

• the whole shop;
• only the front office;
• only the back office;
• a specific action: opening a product page, adding to cart, placing an order, generating a PDF, etc.

This step saves time, because you will not look in the same place if the entire site is down or if only one step in the funnel fails. If you want to broaden the diagnosis beyond the 500 itself, you can also consult the common causes of a PrestaShop site outage.

Reveal the real error with debug mode and the logs

Until you have the actual message, you are working blind. The goal of this step is simple: make PrestaShop speak, then cross-check with PHP and web server logs.

Enable debug mode if the back office is inaccessible

By default, PrestaShop hides errors on the front end. The official documentation states, on 20 October 2026, to enable debug mode by setting _PS_MODE_DEV_ to true in /config/defines.inc.php, or from the back office if it is still accessible: PrestaShop 9 documentation.

Only enable this temporarily while diagnosing. The same documentation warns that debug mode significantly impacts performance and must be disabled after analysis. The aim is to obtain the precise message, the file name, the class, the module or function at fault, then revert to normal configuration.

If your administration is completely unresponsive, the diagnosis quickly goes beyond simple error reading. In such cases you can compare your symptoms with the page for an inaccessible PrestaShop back office.

Read the useful logs: PrestaShop, PHP, Apache or Nginx

Debug mode helps, but logs often provide the actionable cause. Reproduce the error, note the exact time, then read the matching entries in:

• the application logs available within PrestaShop;
• PHP logs;
• the web server error logs, Apache or Nginx depending on your host.

The PHP manual reminds that in production you should not display errors, and that log_errors lets you record them to the file defined by error_log. Server error logs are major diagnostic assets. What you are looking for is not a long history but the first useful error at the exact moment you reproduce the 500.

Concretely, note the file involved, the module named, a memory error, a version incompatibility, a denied directive or a syntax error. Without that precise line you risk fixing a secondary effect instead of the root cause.

Check the most recent change made to the shop first

The right question is often simple: what changed immediately before the outage? This is frequently the best entry point, well before general hypotheses.

Test modules installed or updated just before the 500

The PrestaShop help centre states, on 18 July 2025, that a 500 error after installing or updating a module can result from module-to-module incompatibilities, an incompatibility with the PrestaShop version, stale cache, code conflict or an incomplete update: PrestaShop help on 500 error after module update.

Start with the recent changes list:

• module installed immediately before the outage;
• module partially updated;
• manual changes inside a module's files;
• a combination of modules touching the same area.

The useful method is simple: check the declared compatibility, then disable recently installed or updated modules one by one to find the culprit. If you must pick a single priority after reading the logs, start with the last modified module. To avoid this kind of outage in future, you can also read how to spot a badly coded PrestaShop module before installation.

Clear the cache properly before going further

Clearing the cache can be enough if the outage appeared after an install, update or code change that was not correctly picked up. PrestaShop recommends either deleting the ./var/cache/prod folder via FTP or doing it from the back office when that remains accessible.

However, do not make this a universal reflex. If your logs clearly show a PHP incompatibility, a memory error or an invalid server directive, clearing the cache will not fix the cause. Use it as a targeted test, not as an automatic remedy for every 500.

Check the server base: .htaccess, PHP version, memory and permissions

If the outage is not caused by a recent module, move up a level: the runtime environment. Many errors appear after a hosting change or a server configuration update.

Check the .htaccess file without treating it as a universal cause

PrestaShop lists a misconfigured .htaccess among possible causes of a 500, notably around URL rewriting and Friendly URLs. But this check is only relevant if your shop runs on Apache. PrestaShop system documentation reminds, on 20 October 2026, that PrestaShop can run on Apache or on Nginx.

On Apache the .htaccess syntax is strict. A disallowed directive or a syntax error can cause a 500, usually visible in the error log. If the outage started right after a rewrite change, rule paste or reckless regeneration, check that file quickly. If you are on Nginx, do not waste time here: look at the server configuration and its logs instead.

Compare the PHP version and available memory with PrestaShop requirements

A PHP version change can break a shop that worked yesterday. This often happens after a hosting switch, a panel version change or an unverified PHP upgrade.

According to PrestaShop 9 system requirements, on 20 October 2026, PrestaShop 9.0 supports PHP 8.1 to 8.4. Branch 9.1 supports PHP 8.1 to 8.5, with PHP 8.5 recommended for 9.1. The same documentation recommends a minimum memory_limit of 512M.

Two practical points:

• if the 500 appeared immediately after a PHP change, compare the active version with the one required by your PrestaShop release;
• if the logs report exhausted memory or the outage happens during heavy operations, check the memory_limit.

Do not mix PrestaShop 9 requirements with those of another branch. Correct diagnosis depends on your actual version.

Check permissions without opening rights too widely

The PrestaShop help centre also lists incorrect permissions among possible causes of a 500. The important point is to be measured: overly restrictive rights block execution, but overly permissive rights degrade security.

If the outage appears after a manual deployment, FTP transfer, migration or file edit, compare what changed. And do not take chmod 777 as a standard fix. Expected permissions depend on the server and its configuration. Again, the server log is often the best judge here.

Proceed in the right order depending on the area affected

You do not need the same diagnostic path depending on whether the whole shop fails or only a single action does. Here is the most efficient order to avoid detours.

If the whole shop returns a 500

When the entire site is affected, follow this order:

1. reproduce the error and note the exact time;
2. briefly enable debug mode to reveal the true message if possible;
3. read the PHP and server logs for the same time window;
4. check the last change: module, update, PHP change, server intervention;
5. clear the cache only if the context justifies it;
6. then check .htaccess, PHP version, memory and permissions.

Avoid restoring a backup as a first reflex without identifying the cause. That is a heavy rollback, not a diagnostic tool. As long as you lack a precise clue, focus on the logs and the last change made.

If only one area breaks: back office, product page, cart or checkout

When the 500 affects only one area, diagnosis is faster. Reproduce exactly the action that fails, then look for the log entry that matches that moment. A 500 on a product page does not point to the same components as a 500 during payment.

Some simple pointers:

• back office only: prioritise recent changes affecting administration, then logs at the time of the login or failing action;
• product page or category: trace back to the module or code added on that area;
• cart or checkout: target modules and overrides that act in the checkout funnel, then reproduce the full scenario.

If the error appears only during ordering, the outage can cost revenue immediately. You can compare your symptoms with the page about PrestaShop cart or checkout bugs.

When to hand over so the shop is restored without worsening the outage

The right moment to stop testing is when no new information is emerging. From that point on, it is better to pass a tidy dossier than to multiply risky tests.

Signals that justify immediate technical intervention

Stop further manipulations if you are in one of these situations:

• the whole shop returns a 500;
• the back office is inaccessible and you lack clear log access;
• the cart or payment process is failing;
• the outage appeared after a server or PHP change you do not control;
• you have already disabled the last modified module, cleared cache and read logs without understanding the real cause;
• you are starting to test at random.

At this stage the risk is no longer only wasted time. You can also conceal the original cause, create a second failure or delay the return to normal service.

The minimal checklist to pass on to save time

If you hand over the diagnosis, send at least:

• the area affected: whole shop, front, back office or a specific action;
• the URL or the exact step that triggers the 500;
• the time when you reproduced the error;
• the last change made before the incident;
• the message shown by debug mode, if any;
• the relevant extract from PHP and server logs;
• your PrestaShop and PHP versions if known.

With these elements, the diagnosis can start immediately in the right direction.

If you need an intervention, the page diagnosis and fix for a PrestaShop 500 error describes the scope of work. And if the shop is down or the checkout is blocked, you can also request an urgent PrestaShop support: free diagnosis, response within 24 hours, quote within 24 working hours and a transparent rate of €70 excluding VAT per hour.

Frequently asked questions

How do I enable PrestaShop debug mode if the back office is inaccessible?

If the back office is unresponsive you can enable debug mode directly in the shop files. PrestaShop 9 documentation indicates switching the constant _PS_MODE_DEV_ to true in /config/defines.inc.php. Do this only for diagnosis: the aim is to get the real error message, then disable debug mode once analysis is complete.

Where are the useful logs for a 500 error: PrestaShop, PHP, Apache or Nginx?

Start with the logs that match the exact moment you reproduce the error. The most useful are PHP logs and the web server logs, Apache or Nginx depending on your host. If PrestaShop shows a message in debug mode, cross-check it with these logs. Look for the first actionable error: file, module, memory, syntax or denied directive.

Can a 500 error be caused by a module installed or updated just before it appeared?

Yes. The PrestaShop help centre lists possible causes such as incompatibility with your PrestaShop version, conflicts between modules, stale cache, code conflicts or an incomplete update. The right test is to start from the last change, verify compatibility, then disable recently installed or updated modules one by one.

How can I tell if .htaccess is responsible for the 500 error?

The .htaccess file is a useful lead only if your shop runs on Apache. On Apache a syntax error or a disallowed directive can trigger a 500, usually visible in the error log. If you are on Nginx, this file is not the right angle to investigate. Check your server type before spending time on .htaccess.

Can the PHP version break a PrestaShop shop overnight?

Yes, especially after a hosting change or a server-side PHP update. If your shop or a module is incompatible with the active PHP version, a 500 error can appear immediately. On 20 October 2026 PrestaShop 9 documentation states that branch 9.0 supports PHP 8.1 to 8.4 and branch 9.1 supports PHP 8.1 to 8.5.

Can insufficient PHP memory (memory_limit) cause a 500 error?

Yes. If a process runs out of memory during a heavy action, the request can fail and return a 500. The safest way to confirm this is in the logs or with the message from debug mode. For PrestaShop 9, official documentation recommends a minimum memory_limit of 512M as of 20 October 2026.