"Allowed Memory Size Exhausted": Raising the WordPress Memory Limit Properly

"Fatal error: Allowed memory size of 134217728 bytes exhausted." It is one of the more decipherable WordPress errors — something needed more memory than it was allowed, and PHP stopped rather than continue.

Raising the WordPress memory limit is straightforward. The part worth thinking about is why the site suddenly needs more than it did last month.

What the limit actually is

PHP caps how much memory a single script may use. This exists to stop one runaway process consuming the whole server and taking every site on it down.

WordPress has its own limit on top of PHP's, which is why there are two places to change it and why changing one sometimes appears to do nothing.

The important rule: WordPress cannot exceed what PHP allows. If PHP is capped at 128M, setting WordPress to 512M achieves nothing at all.

Where to set it

1. wp-config.php — try this first

Add this above the line that says to stop editing:

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

The admin area is handled separately and defaults higher. If the error only appears in the dashboard, set that too:

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

2. php.ini — if the above has no effect

This is PHP's own ceiling. Many hosts let you edit it through the control panel:

memory_limit = 256M

3. Ask your host

On managed hosting you often cannot change PHP settings yourself, and the limit is enforced above your account. A support ticket is usually the fastest route — this is a routine request and they will not find it unusual.

How much is reasonable

Some rough guidance rather than rules:

• 128M — fine for a simple brochure site
• 256M — sensible default for most business sites, including WooCommerce
• 512M — a busy store, a large media library, or a heavy page builder
• Beyond 512M — usually a symptom rather than a requirement

If a site genuinely needs more than 512M to load a page, the problem is rarely the limit. Something is doing far more work than it should.

When it appears

The timing narrows the cause considerably.

During updates or imports. Very common and fairly harmless — these are genuinely memory-hungry operations. Raise the limit temporarily and move on.

In the admin only. Often a plugin loading heavy data into a dashboard screen, or a media library with thousands of items.

On specific pages. Points at whatever is unique to those pages — a particular block, a query pulling too many results, or a slider loading everything at once.

Suddenly, everywhere, with no changes. This is the one to take seriously. It is covered below.

Raising it is a workaround, not always a fix

It is worth being clear about this, because the error is easy to silence and the underlying cause is easy to ignore.

Increasing the limit is entirely correct when the site has grown, when you have added legitimate functionality, or when a one-off import needs headroom.

It is masking a problem when the requirement appeared overnight, when you keep having to raise it, or when a simple page needs hundreds of megabytes to render.

In those cases you are giving more resources to something that should not need them, and the site will get slower as it consumes them.

Finding what is actually consuming it

If the increase feels unjustified, investigate rather than keep raising the ceiling.

1. Deactivate all plugins, confirm the error stops, then reactivate one at a time. Crude but effective
2. Switch to a default theme temporarily — heavily customised themes are frequent culprits
3. Check the error log, which often names the file and line where memory ran out
4. Look at your media library size — tens of thousands of images make admin screens expensive
5. Check for runaway queries, particularly plugins loading every post or product into memory at once

The common offenders are page builders, sliders, related-post plugins that query without limits, backup plugins running during a page load, and statistics plugins storing data in the WordPress database.

The security angle

Worth ruling out when the jump is sudden and unexplained.

Compromised sites are frequently used for work you did not ask for — sending spam in bulk, mining cryptocurrency, or serving files to other people. All of it consumes memory and CPU that your visitors need.

Treat it as suspicious if memory use rose sharply with no changes on your side, if your host mentions unusual resource consumption, if the site also slowed noticeably, or if the error log points to files you do not recognise.

Our guides to why WordPress sites get slow and removing malware cover what to check next. Raising the memory limit on a compromised site simply gives the attacker more room to work.

A sensible sequence

1. Set WP_MEMORY_LIMIT to 256M in wp-config.php
2. If nothing changes, raise PHP's memory_limit or ask your host to
3. Confirm the error has gone and the site works
4. Ask whether the increase was justified by real growth
5. If not, find what is consuming it rather than raising again
6. If it appeared suddenly with no changes, check for compromise

When it is really a hosting question

If your host will not go above 128M, or you are repeatedly hitting limits on a modestly sized site, the constraint is the plan rather than the code.

Budget shared hosting sets these limits low deliberately. That is fine for a small brochure site and genuinely limiting for anything busier. Our guide to choosing WordPress hosting covers when moving is the honest answer.

If you would rather not chase this

Memory errors are usually a symptom — of growth, of an inefficient plugin, of hosting that has been outgrown, or occasionally of something worse. Raising the number stops the message without answering which.

Our WordPress error fixing service finds what is actually consuming the memory and addresses that, rather than moving the ceiling and waiting for the next occurrence.

Send us your web address and the error text, and we will tell you what we find.