# 500 error or blank page: where the failure comes from > A 500 error is not a diagnosis, it is a polite admission of failure. The server received the request, started the programme, and the programme stopped before producing a valid response. A fully blank page comes from the same mechanism, simply displayed differently. The real reason was written somewhere — not on screen, for security reasons. Until you have read it, anything you try is guesswork. - Source canonique : [https://allaux.fr/en/problemes/erreur-500-d-ou-vient-elle](https://allaux.fr/en/problemes/erreur-500-d-ou-vient-elle) - Langue : EN - Dernière mise à jour : 2026-09-30 ## Direct answer > Read the error_log of the hosting account, at the site root or in the panel logs folder: the timestamped line from your last attempt names the file and the line number. Add var/logs/ on PrestaShop, or wp-content/debug.log on WordPress once WP_DEBUG and WP_DEBUG_LOG are set to true in wp-config.php. If the whole site returns 500, rename .htaccess: the answer is immediate. ## What the 500 code already rules out Before searching, it helps to note everything this code eliminates. The domain name resolves correctly, otherwise nothing would have answered. The web server is working, since it produced the error page itself. The network is fine. The hosting account is not suspended. The field of causes therefore narrows to running the site: server configuration for this site, application code, or the resources allocated to that specific execution. That is good news, because those three families are distinguished by simple clues, and none of them requires waiting for a third party to reply. This page describes the mechanism shared by every platform. On a PrestaShop shop, the exact locations — var/logs, the _PS_MODE_DEV_ constant, the override/ folder — and the platform’s own causes are covered on the page dedicated to the PrestaShop 500 error. On WordPress, the same symptom shows up as the WordPress critical error. ## The causes I meet, in order of frequency - Configuration: one invalid directive in a configuration file read by the server is enough to return a 500 on every page, even before the CMS starts. A line added by a cache or security module is often the origin. - Application code: a call to a removed function, a module incompatible with the PHP version, an override written for an earlier core version, a compiled cache referring to files that no longer exist, or plainly a syntax error introduced by editing a theme file directly — one missing brace or semicolon is enough. - Resources: insufficient memory allocated for the requested page, a process limit reached, a full disk preventing temporary files from being written. - Permissions: a file or directory whose permissions are refused by the server, notably when they are too open under some shared hosting configurations. ## Finding the real message 1. **Note the scope first** — The whole site, one page, only the admin, or only certain records? A global error points at configuration or the server; a targeted error points at one module or one piece of data. 2. **Open the server error log** — That is where the full message sits, with the file and the line. With most hosts it is reachable from the panel, with no support ticket needed. 3. **Look for the application log too** — The CMS keeps its own log, separate from the server’s. The two complement each other: the first gives the technical error, the second the functional context. 4. **Enable debug mode for one attempt** — It brings the message back on screen. Turn it off immediately afterwards: left on, it exposes paths and table names to every visitor. 5. **Set the suspect configuration file aside** — If the error affects the whole site, temporarily renaming the configuration file read by the server tells you in one second whether it is the origin. 6. **Link it to the last intervention** — An update, a module install, an edited theme file: the failure almost always follows an action, even one taken by someone else, and even days earlier if a cache delayed its effect. ## Do not confuse 500, 502, 504 and a blank page > A 500 comes from the site itself: the programme started and then failed. A 502 or 504 comes from an intermediary that got no valid response or waited too long for one. A blank page is often the same cause as a 500, displayed differently depending on server configuration. Confusing these sends you to the wrong log. ## When the same failure shows up as a blank page Depending on server configuration, the same fatal error produces a 500 error screen on one setup and a fully blank page on another. A blank page is therefore not an absence of response: the server answered, the programme stopped partway, and the message went into a log. The method above applies unchanged. One extra move halves the field of causes: view the page source. If the window is empty, execution stopped before writing anything — a fatal PHP error or a memory limit, exactly the same ground as a 500. If there is HTML but nothing visible, the programme worked and it is the display that is broken: a stylesheet that failed to load, an empty template, a script hiding the content. That second case is not read in the server log, but in the browser console. Then there is the in-between case, the most informative of all: the page renders halfway then stops mid-sentence. Execution was interrupted while writing, and the exact point of the cut names the block of the page at fault. ## The error that only affects part of the site This is the most informative case, and the most often wasted. A 500 limited to one page means the faulty code only runs there. What distinguishes that page from the others is therefore the direct lead: a module hooked to that location alone, a particular record, an empty field, a malformed variant. On the admin only: almost always a module loaded on the admin side, or a page listing too many records. On a few product pages only: look for what those pages have in common, not what separates them from each other. At order validation: the field of causes narrows to the checkout and the payment or shipping modules. Intermittently: that is a resource limit, not a code defect. ## Carry on with the right page - **PrestaShop 500 error** — The full PrestaShop diagnosis, from debug mode to overrides. ([/prestashop/erreur-500](/prestashop/erreur-500)) - **Critical error on WordPress** — The same symptom on WordPress and WooCommerce, with its own causes. ([/wordpress-woocommerce/erreur-critique](/wordpress-woocommerce/erreur-critique)) - **Reading error logs** — How to read an error trace without being a developer. ([/guides/lire-logs-erreurs-prestashop](/guides/lire-logs-erreurs-prestashop)) - **The 500 error explained** — The definition of the code and its place among other server responses. ([/glossaire/erreur-500](/glossaire/erreur-500)) - **Enabling debug mode on PrestaShop** — The exact steps to bring the hidden message back on screen. ([/guides/activer-mode-debug-prestashop](/guides/activer-mode-debug-prestashop)) ## FAQ ### Does a 500 error mean my data is lost? No. It signals an interrupted execution, not destruction. The data stays in the database, and in the vast majority of cases the site returns to normal as soon as the cause of the interruption is removed. ### Why is the error message not shown directly? Because a production site is configured never to expose a file path, a table name or an identifier. That would be usable information. The detail therefore goes to a log, accessible only to you. ### Is a 500 error a hosting problem? Rarely in the strict sense. The server works, since it returns that page. Hosting is involved when the cause is a memory limit, a full disk or an imposed PHP version change — but the fix usually still sits on the site side. ### Can I just disable modules one by one? A valid method with file access and a prior backup. It becomes risky when deactivation has to go through the database, where a rough edit costs more than the outage. ### The error appeared with nobody touching the site. Possible? Yes: a PHP version change decided by the host, a saturated disk, a database quota reached, or an expired key used by a module. None of these needs any action from you. ### Should I reinstall everything to get out of it? Almost never. A reinstall destroys customisations and does not fix a version incompatibility, which comes straight back on the first load. Reading the error message costs minutes and avoids a reset there is no way back from.