A memory limit error stops PHP mid-request, so the page returns blank or half-rendered. The message names a number and a file, and both are misleading: the file is usually where memory ran out rather than where it was consumed.
What the limit actually is
PHP allows one request a maximum amount of memory. Exceeding it terminates that request.
It is per request, not for the whole site, so a limit of 256 MB does not mean the site may use 256 MB in total. Ten simultaneous requests can each take that much, which is why raising it without thinking has consequences on a small server.
Raise it, in the right place
WordPress has its own constant, in wp-config.php:
define('WP_MEMORY_LIMIT', '256M');
And a separate one for the admin area, which legitimately needs more:
define('WP_MAX_MEMORY_LIMIT', '512M');
Those cannot exceed the server's own PHP limit. If PHP is set to 128 MB, asking WordPress for 256 achieves nothing, raise the PHP value in cPanel first. For that, see How to Configure PHP Settings in cPanel.
256 MB is generous for a normal site. If 512 is not enough, something is wrong rather than large.
Read the error properly
The message says how much was allocated, how much was requested, and in which file.
The file is a clue in place of the answer. Memory is consumed gradually and the error appears wherever the next allocation happened to fail, often in a core file, having been filled by a plugin.
What is informative is when it happens. Always on one page points at what that page does. Only in the admin points at a plugin's admin screen. Only during an import points at the import.
The usual causes, in order
Image processing. A large photograph is decompressed into memory to be resized. A 20-megapixel image needs far more memory than its file size suggests. This is the most common cause of an upload failing after it appeared to complete, and resizing before uploading avoids it entirely. How to Optimize Images and the Media Library goes into the habit.
A plugin loading everything at once. Every product, every order, every user: instead of processing in batches. This appears as a site that works until the catalogue grows.
Imports and exports, which hold the whole dataset in memory in many implementations.
Too many plugins, each modest, adding up. Less common than people assume and not impossible.
Find it rather than raising the limit again
Raising the limit is the right first move and a poor only move. A site that needed 128, then 256, then 512 has a growing problem, and the next step is a crash instead of a page.
Deactivate plugins in halves on a staging copy and reproduce the error each time. Twenty minutes identifies the culprit exactly. There is more on judging the replacement in How to Choose and Vet WordPress Plugins.
Then check the error log, which records the failure with a timestamp even when the page showed nothing. There is more on finding it in Understanding cPanel Error Logs and Troubleshooting.
Distinguish it from the other blank page
A white screen has two common causes and they need different fixes.
Memory exhaustion; the log names an allowed size and a requested size.
A fatal error: the log names a function or a class, usually in a plugin.
Both look identical in the browser when error display is off, which it should be on a live site. The log is the only thing that distinguishes them, and guessing between the two wastes the most time. How to Fix Common WordPress Errors walks through the second.
On a small server, the limit protects you
Worth stating, because the instinct is to raise it as far as possible.
On a VPS, PHP workers each holding a large limit can exhaust the machine's memory, at which point the kernel kills the largest process, which is the database. The site then fails in a way that looks unrelated to PHP entirely.
Keep the limit generous rather than enormous, and size the number of workers against the memory you actually have. For that arithmetic, see How to Configure Swap and Memory on a VPS.
If you cannot raise it
On some shared plans the limit is fixed. That is a constraint instead of an obstacle.
Resize images before uploading. Import in smaller batches. Remove the plugin doing the expensive thing, or replace it with one that processes incrementally.
Each of those addresses the consumption instead of the ceiling, which is the fix that keeps working as the site grows.
Find out what the limit currently is
The value applies from several places and the effective one is not always the file you edited.
php -i 2>/dev/null | grep -i memory_limit
wp eval 'echo ini_get("memory_limit"), "\n";' 2>/dev/null
grep -rn 'memory_limit' ~/public_html/.htaccess ~/public_html/php.ini ~/public_html/wp-config.php 2>/dev/null
The command line and the web request frequently run under different configurations, which is why a value read in a shell is not the one the site uses.
Read the value from inside the application rather than from a configuration file. That is the number that matters, and it accounts for anything the application sets for itself.
Read what was being done when it failed
The error names the file where the allocation happened, which is rarely the file responsible.
grep -i 'allowed memory size' ~/logs/example.com.error.log | tail -5
grep -i 'allowed memory size' ~/logs/example.com.error.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head
Group the failures by where they occurred. A single file appearing repeatedly is a genuine lead; a spread across many files means the memory was already exhausted before any of them ran.
The request address matters more than the file. A failure that only happens on one screen, or during one operation, identifies the cause far more precisely than the file name does.
Raising it is a diagnosis, not a fix
Increasing the limit makes the error stop, and it does not make the consumption reasonable.
A site that needs several times the normal allowance to display a page is doing something that will fail again as the data grows. The limit bought time rather than solving anything.
wp db size --tables --human-readable 2>/dev/null | head -6 wp db query "SELECT COUNT(*) FROM wp_options WHERE autoload='yes';" 2>/dev/null
The usual causes are a query returning far more rows than intended, a plugin loading everything into memory to filter it, or a large amount of data loaded on every request. Each is fixable, and each returns once the limit is reached again.