Solucionar "Allowed Memory Size Exhausted" en WordPress

Si tu sitio muestra Fatal error: Allowed memory size of 268435456 bytes exhausted, añade esta línea en wp-config.php por encima del comentario /* That's all, stop editing! */: define( 'WP_MEMORY_LIMIT', '256M' );. Con eso la mayoría de los sitios vuelven a estar en línea en menos de un minuto. Pero lee el resto de esta página antes de irte, porque subir el límite es un diagnóstico, no una cura. Si el fallo vuelve a aparecer con un número más alto, el problema real es código que consume memoria sin control, y un techo más alto solo le da más cuerda.

Qué significa realmente el error

PHP lleva la cuenta de cuánta memoria ha reservado cada petición. Cuando una sola petición intenta reservar más allá del memory_limit fijado en php.ini (o sobrescrito por WordPress), PHP mata la petición al instante con un error crítico e imprime el número de bytes en el que murió. 268435456 bytes son 256M. 134217728 son 128M. 536870912 son 512M. El número que aparece tras “tried to allocate” te indica el tamaño de la gota que colmó el vaso, no el tamaño del problema.

WordPress añade sus propios límites por encima de los de PHP. WP_MEMORY_LIMIT (por defecto 40M, o el límite de PHP si es mayor) gobierna la parte pública. WP_MAX_MEMORY_LIMIT (por defecto 256M) gobierna las operaciones del administrador, como la biblioteca de medios y las actualizaciones de plugins, que legítimamente necesitan más. WordPress llama a ini_set('memory_limit', ...) al cargar según estas constantes, pero solo si tu hosting permite ini_set, y solo hasta el tope máximo que fije tu hosting. Esa última parte es la razón por la que editar wp-config.php a veces parece no hacer nada.

Solucionarlo, por orden

1. Sube el límite de WordPress en wp-config.php. Es lo primero que hay que probar porque es reversible y no toca nada más.

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

Si no tienes claro dónde van estas líneas o quieres dejar bien puestas las demás constantes habituales al mismo tiempo, nuestro generador de wp-config escribe un bloque limpio que puedes pegar. La ubicación importa: cualquier cosa por debajo de la línea “stop editing” se ignora.

2. Si eso no hace nada, tu hosting está limitando PHP. Sube memory_limit a nivel de PHP. En php.ini:

memory_limit = 256M

En muchos hostings compartidos no puedes editar php.ini directamente. Prueba con un archivo .user.ini en la raíz de tu web, o defínelo mediante .htaccess en una configuración Apache/mod_php:

php_value memory_limit 256M

Ten en cuenta que php_value en .htaccess lanza un error 500 en nginx o en configuraciones PHP-FPM, porque es una directiva de Apache/mod_php. Si obtienes un 500 tras añadirlo, esa es la causa: quítalo y usa .user.ini.

3. Confirma el valor que realmente está activo. No te fíes de lo que editaste; fíate de lo que reporta PHP. Coloca un archivo de una sola línea en la raíz de tu web:

<?php echo ini_get('memory_limit');

Cárgalo en un navegador, lee el valor y luego borra el archivo. Si sigue diciendo 128M después de que fijaras 256M, tu hosting te está sobrescribiendo y tendrás que contactar con ellos o usar el ajuste de su panel de control.

La parte que la mayoría de las guías se saltan

Subir el límite es diagnóstico. Así se interpreta el resultado.

Si fijas 256M y el sitio se mantiene en pie con el tráfico normal, tenías un techo legítimo que era demasiado bajo, algo común en sitios con bibliotecas de medios grandes, WooCommerce o maquetadores de páginas. Has terminado.

Si fijas 256M y vuelve a caer, luego 512M y vuelve a caer, deja de subirlo. Una petición normal de WordPress no necesita 512M. Cuando el uso de memoria sube sin techo, algo está en bucle o acumulándose: un plugin que carga una tabla entera de la base de datos en un array, un add_action que se dispara a sí mismo de forma recursiva, una rutina de importación que mantiene todas las filas en memoria a la vez, o dos plugins peleándose dentro del mismo hook. Subir el límite no arregla un bucle sin control: solo mueve el fallo unos segundos más adelante y lo hace más difícil de reproducir.

Para encontrar al culpable, desactiva todos los plugins y cambia a un tema por defecto como Twenty Twenty-Four. Si el error para, reactívalos de uno en uno hasta que vuelva. Activa el debug log para capturar dónde muere:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

La línea del fatal error en wp-content/debug.log nombra el archivo y el número de línea que reservó el último bloque. Eso suele ser el bucle, o está a una llamada de función de distancia de él.

Qué no hacer

No pongas WP_MEMORY_LIMIT a -1 o 1024M y te olvides. La memoria ilimitada no arregla una fuga; deja que una petición descontrolada se coma el servidor entero, lo que puede tumbar el resto de sitios de la misma máquina y hacer que tu hosting te llame. Un techo es una medida de seguridad. Mantén uno.

No pegues ini_set('memory_limit', '512M') en functions.php como solución principal. Se ejecuta demasiado tarde para algunos fallos: si el fallo ocurre durante la carga del núcleo de WordPress, antes de que se ejecute el functions.php de tu tema, la línea nunca llega a ejecutarse. wp-config.php carga antes y es el lugar correcto.

No des por hecho que es un problema del hosting y mejores tu plan. A veces es genuinamente un hosting demasiado justo. A menudo el mismísimo fallo te persigue hasta el plan más grande porque la causa viajó con tus plugins. Descarta primero el bucle; es gratis.

No subas memory_limit para arreglar un error de max_execution_time. Son límites distintos con mensajes distintos. El agotamiento de memoria dice “Allowed memory size … exhausted.” Un tiempo de espera dice “Maximum execution time … exceeded.” Subir el que no toca te hace perder una tarde.

¿Sigues atascado?

Si has confirmado que el límite activo es genuinamente de 256M o más, has probado con todos los plugins desactivados y un tema por defecto, y aun así se queda sin memoria, tienes una fuga real que merece perseguir en el debug log, no un techo que merezca subir. Captura la línea del fatal error, anota en el directorio de qué plugin apunta, y ese es tu informe de bug. Deja bien puestas primero las constantes base de tu wp-config.php con el generador de wp-config para saber que los límites están fijados donde crees que están, y luego ve a leer el log.