WordPress Memory Exhausted Error

What this error means & how to recognize it

• A fatal error includes wording similar to Allowed memory size of 134217728 bytes exhausted (tried to allocate ... bytes).
• The entire site may fail, or the problem may be limited to the dashboard, one plugin screen, an import, a migration, or a bulk action.
• The error can begin after installing or updating a plugin or theme, starting a large data operation, or moving the site to hosting with a lower PHP memory limit.
• The homepage may load normally while an import, page-builder screen, product synchronisation, or other memory-intensive task fails.
• Increasing memory may appear to fix ordinary pages while the original operation continues to fail.

Root causes, ordered by likelihood

1. The PHP memory_limit is too low for the site or request. WordPress core, the active theme, plugins, the current request, and the data being processed can exceed a conservative hosting default.
2. A plugin or theme has high memory usage. Page builders, import/export tools, backup software, caching tools, and broad SEO or marketing suites may use substantially more memory during particular tasks.
3. A large operation is processing too much data at once. Media imports, product synchronisation, migrations, and search-and-replace tasks can exceed the limit even when normal page loads work.
4. The active plugin set has high combined baseline usage. Several moderate consumers can exceed the limit together.
5. Configuration layers do not agree. wp-config.php, the hosting panel, php.ini, .user.ini, and applicable .htaccess settings may produce different effective values for web requests.
6. A component has an inefficient processing path or memory leak. This becomes more likely when a specific action fails with a modest workload or after repeated use, rather than only during a predictably large operation.

How to fix it

1. Identify the failing request

Copy the complete fatal-error message if available. Record whether the failure affects every page, only the dashboard, one plugin screen, or a particular operation such as an import or bulk edit. This distinction helps separate a generally low limit from a workload-specific problem.

2. Request more memory from WordPress

Before editing files, make a backup or confirm that you can restore the current configuration. Using SFTP or your host’s file manager, open wp-config.php and add this line above /* That's all, stop editing! */:

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

This asks WordPress to use 256 MB where the server permits it. If the constant already exists, edit that definition instead of adding a second one. Some administrative tasks can use a separate admin memory setting, so a dashboard-only failure may need additional investigation.

3. Check the PHP limit used by the website

WP_MEMORY_LIMIT cannot raise PHP above the server’s own memory_limit. Check the hosting control panel or the php.ini used by the PHP version serving the site. On a VPS, changing the relevant PHP configuration may require restarting PHP-FPM or the applicable PHP service; do this only with the necessary access and authorization.

Some Apache configurations using mod_php permit a setting such as:

php_value memory_limit 256M

in .htaccess. This does not apply to PHP-FPM and may cause a server configuration error where the directive is not permitted. Use the hosting panel or ask the host before adding it. A command-line PHP setting may differ from the configuration used by web requests.

4. Repeat the exact failing action

Retry the import, bulk edit, plugin operation, or page request that produced the error. Loading the homepage alone is not sufficient because an ordinary page may use much less memory than the failed task. If the task succeeds, monitor it and avoid raising the limit further unless the same operation still needs more memory.

5. Reduce the operation’s peak memory use

For imports, migrations, synchronisations, or bulk edits, lower the tool’s batch size or split the work into smaller groups. This is often safer than assigning a very high limit to every PHP request. Running large jobs during a quieter period may reduce operational risk, but it does not lower the request’s peak memory requirement.

6. Isolate the likely plugin or theme

If 256M or 512M is still insufficient, or the issue began after a change, test the component associated with the failing screen or task. Use a staging copy when possible. On a live site, make a backup first and deactivate plugins one at a time. If the dashboard is inaccessible, use SFTP or the file manager to temporarily rename the suspected plugin directory so WordPress cannot load it.

Prioritise the recently changed component and the plugin linked to the failure, followed by page builders, import/export tools, backup tools, caching tools, and large all-in-one suites. If front-end pages fail, test with a default theme as well. Restore unaffected components after each test so you know which configuration was tested.

7. Compare effective configuration values

If changing WP_MEMORY_LIMIT has no visible effect, compare the WordPress request with the PHP value used by web requests. Review the hosting panel, php.ini, .user.ini, and applicable .htaccess settings, along with any host-imposed ceiling. Ask the host which PHP configuration applies if you cannot verify it yourself.

8. Confirm the lasting fix

Run the original failing operation again, then check important front-end and administrative pages. If the site works only after a very large limit is set, treat that as a diagnostic clue and continue investigating the responsible plugin, theme, query, or batch size rather than considering the issue permanently resolved.

Prevention & how to verify the fix

• Use a deliberate, host-supported WordPress memory value rather than waiting for a production task to fail.
• Remove unused plugins and periodically review the active plugin set because baseline memory use is cumulative.
• Keep import, migration, synchronisation, and bulk-edit batches within the available PHP memory.
• Test large operations on staging or with a limited data set before processing the full site.
• After plugin or configuration changes, repeat the operation that previously failed and verify both front-end and admin pages.
• Record which PHP configuration applies to web requests so future memory changes are made in the correct place.

Frequently asked questions