Fix the “Allowed memory size exhausted” error on WordPress

Your WordPress site suddenly shows a white page, a critical error, or a message that looks like this:

Fatal error: Allowed memory size of 268435456 bytes exhausted 
(tried to allocate 20480 bytes) in /home/ton-site/wp-includes/...

The number changes from one site to another (134217728, 268435456, 536870912 depending on your current limit), but the message is always the same: PHP no longer has enough memory to run what your site is asking of it. On recent versions of WordPress, you will sometimes only see “There has been a critical error on your website”, it’s the same cause hidden behind a more polite message.

It almost always happens at the worst moment: while installing a plugin, a WooCommerce import, uploading a heavy image, or just after an update. The server hits its ceiling and stops dead.

I’ve been doing WordPress maintenance for over 10 years and this error comes up every week on at least one site. In 90% of cases, it’s fixed in under 10 minutes once you know where to look. In the remaining 10%, a plugin is running in a loop and the problem is elsewhere. This guide covers both.

Before changing anything, look at what your server already allocates. In your WordPress dashboard, go to Tools > Site Health > Info, then expand the Serversection. Look for the line PHP memory limit.

If you see 64M or 128M, you’ve found your problem. If you already see 512M or more and the error persists, memory is not the cause. A plugin is probably running in a loop and consuming everything you give it, whatever the value. In that case, jump straight to the section “When increasing the memory is not enough”.

To give you a benchmark, here are the values suited to your setup. These values assume you are running PHP 8.1 or higher. If you’re still on PHP 7.4, expect about 20 to 30% more memory consumed for the same site. That’s a good reason to update PHP if you haven’t done so yet.

The method to use depends directly on your host. Not all methods work everywhere, and some are simply ignored depending on the server configuration. Here is what really works, host by host.

This is the most reliable method on o2switch, and it’s the one I use systematically on the client sites I maintain with this host. From your cPanel, type Select PHP Version in the search bar at the top or find it in the Software section. This setting will apply to all the domains of the hosting account. In the Options tab, change the memory_limit value according to the table above.

The change is immediate, no need to clear the cache or restart anything. To check it has been applied, go back to Tools > Site Health > Info > Server in your WordPress. The PHP memory limit line should show the new value.

On OVH shared hosting, you don’t choose the memory limit yourself. OVH states that the php.ini file cannot be modified on its web hosting plans and that the PHP configuration is shared across its entire shared infrastructure.

The .ovhconfigfile, at the root of your hosting, is only used to choose the PHP version, the PHP engine, the environment (production or development) and the server image. A php.memory_limit line added to this file has no effect.

If your plan’s limit is not enough, start by looking for the plugin that consumes too much (see below). If your site really needs more, you have to move to a more powerful plan: ask OVH support for the limit of each plan.

If your host doesn’t offer a dedicated interface, the universal method on shared hosting is the .user.inifile. Create this file at the root of your site (where wp-config.php is located) and simply add:

memory_limit = 256M

This file is read directly by PHP in CGI/FastCGI mode, which is the standard configuration of all shared hosts. The change takes effect within a few minutes.

For other common hosts:

• Hostinger : hPanel > Advanced > PHP Configuration, edit memory_limit directly.
• Infomaniak : admin panel > Web Hosting > PHP > Configuration.
• SiteGround : Site Tools > Devs > PHP Manager, PHP Variables tab.

You’ll often find this solution first in tutorials. It consists of adding to wp-config.php:

define('WP_MEMORY_LIMIT', '256M');

What this line really does: it tells WordPress how much memory it can request from PHP. But PHP cannot exceed the limit your server imposes. If your host limits it to 128M and you put 256M in wp-config.php, WordPress will see 256M in its internal settings but PHP will keep stopping at 128M.

It is therefore useful as a complement to a server-side change, to make sure WordPress uses all the available memory. But it doesn’t replace the methods above.

To also increase the memory in the WordPress admin (useful notably during WooCommerce imports), add below:

define('WP_MAX_MEMORY_LIMIT', '512M');

I regularly work on sites where the client has already raised the memory to 1024M, or even 2048M, with no result. The error keeps coming back. In those cases, it’s not a limit problem: it’s a plugin or script running in a loop and consuming everything you give it, whatever value is configured.

To identify the culprit, the method is simple:

1. Deactivate all your plugins by renaming the folder via SFTP.wp-content/plugins to plugins-off
2. Reload your site. If the error disappears, a plugin is the cause.
3. Put the original folder name back, then deactivate the plugins one by one from the admin until you find the culprit.
4. If the error persists even without plugins, test with a default WordPress theme (Twenty Twenty-Four).

To speed up the diagnosis, enable the WordPress logs and check the file wp-content/debug.log. You’ll see exactly which file triggers the error and on which line. My guide on how to find WordPress logs explains how.

If your site shows another error message, I also explain how to fix the Maximum execution time exceeded error and the 413 Request Entity Too Large error.

To go further, you can consult the WordPress page on the most common errors (in English).

If you have to raise PHP memory to 2 GB just to make a WordPress site work, and the error still comes back regularly despite that, the problem is no longer memory. Three leads to examine in this order:

1. Audit your plugins. A poorly coded plugin can saturate a properly sized server on its own. It’s the most frequent case I come across in maintenance.
2. Check your PHP version. A site on PHP 7.4 consumes noticeably more than a site on PHP 8.2 or 8.3. Updating is often the first lever before changing host.
3. Only then, look at your host. If you’re on low-cost shared hosting and your site is an active WooCommerce store, you may have reached the plan’s structural limits. In that case, moving to a plan with more allocated resources (o2switch’s Cloud, for example) will solve the problem at the root.

In short: before paying more, check what is really consuming memory on your current site.

And if you want to avoid going through this kind of situation at every update, take a look at my WordPress maintenance. That’s exactly why it exists.

Once the error is fixed, a few habits to avoid it coming back:

• Limit the number of active plugins. Each plugin adds weight. Deactivate the ones you don't really use.
• Optimise your images before uploading them. Uncompressed images consume a lot of memory when PHP processes them. A tool like Squoosh or a plugin like Imagify does the job.
• Update PHP. Versions below 8.0 consume noticeably more memory than recent versions. See my guide to update PHP on WordPress.
• Clean your database regularly. A database weighed down by revisions, expired transients or plugin logs can cause memory spikes at load time.
• Watch your updates. A failed plugin or theme update is often the trigger for the first appearance of this error.