"Fatal error: Allowed memory size of 67108864 bytes exhausted" — esto significa que WordPress se quedó sin memoria PHP. Es común tras agregar nuevos plugins o cuando tu base de datos de WordPress crece mucho.
Causas más comunes que diagnosticamos:
Proceso sistemático, rápido y seguro:
Añade estas líneas antes de "¡Eso es todo, deja de editar!": define("WP_MEMORY_LIMIT", "256M"); define("WP_MAX_MEMORY_LIMIT", "512M");
Añade php_value memory_limit 256M al archivo .htaccess.
Usa Query Monitor para identificar qué plugins consumen más memoria y encuentra alternativas más ligeras.
Nuestro experto WordPress responde en minutos.
Mínimo 128M, recomendado 256M, y para tiendas WooCommerce o sitios con muchos plugins: 512M.
Con límites altos, el problema generalmente es un plugin específico con una fuga de memoria.
Es el memory_limit de PHP asignado por petición. El default WordPress es 40M; los sitios modernos necesitan 256M o más. El error ocurre cuando una sola petición (carga de página, proceso de plugin) intenta asignar más memoria que este límite.
Las páginas más pesadas (admin, importar datos, generar reportes) asignan más memoria. Una página con consulta compleja, procesamiento de imagen grande, o un plugin mal codificado puede exceder el límite mientras páginas más simples permanecen debajo.
Hasta cierto punto. Los planes de hosting limitan la memoria por proceso (256M-1024M típico). Más allá, el problema usualmente es una fuga de memoria, no necesidad legítima. Perfilamos uso de memoria para arreglar la causa raíz en lugar de solo subir el límite.
Varios lugares, en orden de prioridad: a nivel PHP (php.ini), .htaccess (php_value memory_limit), WordPress (define WP_MEMORY_LIMIT en wp-config.php). El menor de estos gana. Verificamos cuál aplica realmente tu hosting.
Sí. Un plugin cargando los 50,000 posts en memoria de una vez, o un loop infinito mal escrito, puede agotar 512M instantáneamente. Usamos Query Monitor para encontrar qué plugin es el devorador de memoria.
Los cron jobs corren múltiples plugins simultáneamente y pueden incluir tareas pesadas (backups, regeneración de imágenes). Su uso combinado de memoria suele exceder cargas normales. Dividimos tareas cron o las corremos vía cron de sistema real con límites más altos.
Sí — común con fotos de alta resolución. WordPress genera múltiples tamaños de miniatura durante la carga, cada uno requiriendo memoria proporcional a las dimensiones de la imagen. Subimos WP_MEMORY_LIMIT y usamos ImageMagick en lugar de GD para menor uso de memoria.
Sí. WP_MEMORY_LIMIT es para front-end (default 40M, recomendado 256M). WP_MAX_MEMORY_LIMIT es para admin y cron (default 256M, recomendado 512M). Configurar ambos correctamente maneja diferentes tamaños de carga de trabajo.
Indirectamente. El caché de objetos (Redis/Memcached) reduce las consultas DB, lo que reduce la memoria PHP necesaria por petición. Sitios con caché de objetos suelen necesitar 30-50% menos memoria PHP.
Sí. Si display_errors está desactivado (bueno para producción), un agotamiento de memoria puede producir página en blanco o 500 sin razón visible. Siempre revisamos logs de error buscando 'Allowed memory size exhausted'.
Sitios WooCommerce con 1000+ productos y Elementor: 512M mínimo. Tiendas pesadas con suscripciones, marketplaces o membresías: 768M-1024M. Medimos uso pico y ajustamos correctamente.
Sí. MySQL tiene su propio pool de memoria (innodb_buffer_pool_size). Cuando MySQL agota memoria, las consultas fallan y WordPress muestra errores de conexión DB. Afinamos memoria MySQL además de PHP.
A veces — si las tablas de datos del plugin crecieron infladas con logs o transients. Limpiamos transients expirados, archivamos logs viejos y optimizamos tablas de plugin antes de asumir que el plugin es inherentemente pesado de memoria.
¿Tu sitio muestra un error crítico? Lo diagnosticamos y reparamos rápido, sin pérdida de datos.
Respuesta en minutos. Sin pérdida de datos. Sin cargo por diagnóstico.
wpfix.blimx.com