Cómo corregir el error max_execution_time en WordPress

El error max_execution_time en WordPress ocurre cuando un script PHP supera la duración máxima de ejecución configurada a nivel de servidor. PHP termina el script y devuelve un error fatal, que WordPress muestra como una pantalla en blanco, un aviso de tiempo de espera agotado, o un mensaje explícito de "Maximum execution time exceeded".

De forma predeterminada, la mayoría de los entornos de alojamiento compartido aplican un límite de 30 segundos. Operaciones como importar un CSV de productos de WooCommerce, ejecutar una copia de seguridad completa del sitio, o instalar un paquete de plugins de gran tamaño pueden superar fácilmente este límite. Aumentar el límite — mediante php.ini, .htaccess, wp-config.php, o la capa de plugins de WordPress — resuelve el error sin comprometer la estabilidad del servidor cuando se hace correctamente.

Por qué existe el límite y cuándo se convierte en un problema

La directiva max_execution_time de PHP es un mecanismo de protección de recursos, no una restricción arbitraria. Evita que un script descontrolado monopolice el tiempo de CPU en un grupo de procesos compartidos, lo cual es especialmente crítico en infraestructuras multi-tenant.

El límite se convierte en un obstáculo real en estos escenarios:

• Importaciones o exportaciones de bases de datos de gran tamaño mediante phpMyAdmin o WP-CLI que procesan miles de filas
• Instalaciones de plugins o temas que descomprimen archivos de más de 50 MB
• Operaciones masivas de WooCommerce — actualizaciones de precios, sincronizaciones de inventario, exportaciones de pedidos
• Migraciones completas del sitio con herramientas como Duplicator o All-in-One WP Migration
• Tareas cron programadas que agregan datos de APIs externas
• Plugins de optimización de imágenes que procesan cientos de archivos sin optimizar en un solo lote

Un matiz crítico que la mayoría de las guías omiten: max_execution_time mide el tiempo de CPU consumido por el proceso PHP, no el tiempo de reloj. En un servidor con mucha carga, un script puede ejecutarse durante 90 segundos en tiempo real mientras consume solo 28 segundos de tiempo de CPU y nunca activar el límite. Por el contrario, un bucle intensivo en CPU alcanza el límite más rápido de lo esperado. Esta distinción es importante al diagnosticar tiempos de espera intermitentes.

Cómo verificar el valor actual de max_execution_time

Antes de cambiar cualquier cosa, confirme el límite activo. Cree un archivo temporal en la raíz de su WordPress — nunca lo deje accesible públicamente después de las pruebas:

<?php
phpinfo();

Súbalo como phpinfo-test.php, visite https://yourdomain.com/phpinfo-test.php y busque max_execution_time en el resultado. Elimine el archivo inmediatamente después de verificarlo.

Alternativamente, use WP-CLI desde SSH:

wp eval 'echo ini_get("max_execution_time");'

Esto devuelve el valor actualmente activo para las solicitudes de WordPress, que puede diferir del php.ini global del servidor si ya existe una anulación por directorio.

Método 1: Editar el archivo php.ini (Más confiable)

Modificar php.ini es el método más autoritativo porque establece la directiva a nivel del intérprete PHP, sin anular nada ni ser anulado por nada inferior en la jerarquía de configuración — a menos que una llamada posterior a ini_set() lo supere en tiempo de ejecución.

Paso 1: Localizar el archivo php.ini correcto

Aquí es donde la mayoría de los administradores cometen un error. PHP puede cargar múltiples archivos .ini según el SAPI (Server API) en uso:

• CLI SAPI (/etc/php/8.x/cli/php.ini) — usado por WP-CLI y tareas cron
• FPM SAPI (/etc/php/8.x/fpm/php.ini) — usado por stacks Nginx + PHP-FPM
• Apache mod_php (/etc/php/8.x/apache2/php.ini) — usado por Apache con el módulo PHP

Editar el php.ini de CLI solucionará los tiempos de espera de WP-CLI pero no afectará las solicitudes iniciadas desde el navegador. Identifique siempre el SAPI correcto primero:

php -i | grep "Loaded Configuration File"

Para solicitudes web, verifique el resultado de phpinfo() bajo Loaded Configuration File.

Paso 2: Editar o crear php.ini en la raíz web

En alojamiento compartido donde no tiene acceso root, puede colocar un php.ini a nivel de usuario en el directorio raíz de su sitio (public_html). Acceda a él mediante el Administrador de Archivos de cPanel, FTP o SSH:

nano ~/public_html/php.ini

Añada o actualice la directiva:

max_execution_time = 300

300 segundos (5 minutos) es suficiente para la mayoría de las operaciones. Para migraciones extremadamente grandes, considere 600 segundos temporalmente y revierta una vez que la tarea se complete.

Paso 3: Verificar que el cambio tuvo efecto

Después de guardar, vuelva a ejecutar la verificación de phpinfo() o el comando WP-CLI anterior. Si el valor no ha cambiado, su proveedor puede estar aplicando un límite fijo mediante max_execution_time en un php.ini a nivel de servidor que supera su archivo de usuario. En ese caso, proceda al Método 4.

Paso 4: Reiniciar PHP-FPM (VPS y servidores dedicados)

En un VPS o servidor dedicado donde controla el entorno, se requiere un reinicio de PHP-FPM para que el cambio se propague a las solicitudes web:

sudo systemctl restart php8.2-fpm

Reemplace php8.2-fpm con su versión de PHP instalada. Apache con mod_php requiere una recarga de Apache en su lugar:

sudo systemctl reload apache2

Método 2: Editar el archivo .htaccess (Solo Apache)

El método .htaccess funciona exclusivamente en servidores Apache donde AllowOverride permite directivas de configuración PHP. No funciona en Nginx, LiteSpeed con ciertas configuraciones, ni en ningún stack donde PHP se ejecuta como FastCGI/FPM con AllowOverride None.

Paso 1: Mostrar y acceder al archivo .htaccess

El archivo .htaccess está oculto de forma predeterminada. En el Administrador de Archivos de cPanel, haga clic en Configuración en la esquina superior derecha y active Mostrar archivos ocultos (dotfiles). El archivo se encuentra en public_html.

Mediante SSH:

nano ~/public_html/.htaccess

Paso 2: Añadir la directiva PHP

Inserte la siguiente línea. La posición importa — colóquela fuera de cualquier bloque <IfModule> para asegurarse de que se aplique globalmente:

php_value max_execution_time 300

Si su servidor ejecuta PHP-FPM (identificable por PHP/x.x.x (fpm-fcgi) en phpinfo()), esta directiva causará un Error 500 de Servidor Interno porque php_value no es válido en ese contexto. Use php_admin_value solo si el proveedor lo permite explícitamente, o cambie al Método 1.

Paso 3: Verificar errores 500

Después de guardar, cargue inmediatamente su página de inicio. Un error 500 significa que la directiva es incompatible con la configuración de su servidor. Elimine la línea y use un método alternativo.

Método 3: Editar wp-config.php usando set_time_limit()

La función set_time_limit() restablece el temporizador de ejecución desde el punto en que se llama. Esta es una llamada en tiempo de ejecución de PHP, no una directiva de configuración, lo que significa que funciona independientemente de si el servidor permite anulaciones de php.ini o .htaccess — siempre que la lista disable_functions de PHP no la incluya.

Paso 1: Localizar wp-config.php

El archivo se encuentra en la raíz de la instalación de WordPress, un nivel por encima de public_html en algunas configuraciones de servidor, o directamente dentro de ella en otras.

find ~/public_html -maxdepth 2 -name "wp-config.php"

Paso 2: Añadir la directiva

Abra wp-config.php y añada la siguiente línea antes del comentario /* That's all, stop editing! Happy publishing. */:

set_time_limit(300);

Llamar a set_time_limit(0) desactiva el límite completamente para esa solicitud. Use esto solo como medida de diagnóstico temporal — nunca en producción — porque elimina la red de seguridad contra bucles infinitos.

Advertencia importante: set_time_limit() afecta solo la ejecución del script actual. No cambia la configuración PHP de todo el servidor. Si un plugin genera internamente un subproceso o realiza una solicitud HTTP bloqueante, ese subproceso no está cubierto por esta llamada.

Método 4: Usar un plugin de WordPress

Para usuarios que prefieren no editar archivos del servidor directamente, varios plugins exponen los valores de configuración PHP a través de la interfaz de administración de WordPress. Este enfoque es apropiado para propietarios de sitios no técnicos en alojamiento administrado.

Opciones recomendadas:

• WP Maximum Execution Time Exceeded — apunta específicamente a este error e intenta múltiples métodos de anulación
• PHP Settings — proporciona una vista del panel de las directivas PHP activas y permite anulaciones seguras donde el proveedor lo permite

Para instalar: navegue a Plugins > Añadir nuevo en el panel de WordPress, busque el nombre del plugin, instálelo y actívelo. Siga la página de configuración del plugin para establecer el tiempo de ejecución deseado.

Limitación: Los plugins solo pueden llamar a set_time_limit() o ini_set() en tiempo de ejecución. Si el proveedor ha bloqueado max_execution_time mediante restricciones de open_basedir o una configuración de servidor codificada, el plugin fallará silenciosamente al intentar aumentar el límite. Verifique siempre el cambio usando phpinfo() después de activarlo.

Método 5: Contactar a su proveedor de alojamiento

Si ninguno de los métodos anteriores produce un cambio verificado en el resultado de phpinfo(), el límite está aplicado a nivel de servidor por su proveedor. Esto es común en planes de alojamiento compartido de nivel básico donde el proveedor establece un límite fijo para proteger los recursos compartidos.

Al contactar al soporte, proporcione:

• El mensaje de error exacto y la acción de WordPress que lo desencadena
• El valor actual de max_execution_time obtenido de phpinfo()
• El valor que necesita (por ejemplo, 300 segundos) y el motivo (por ejemplo, importación masiva de WooCommerce)

Los proveedores de confianza ajustarán el límite para su cuenta o le indicarán una opción del panel de control (como un selector de PHP en cPanel) donde puede configurarlo usted mismo.

Comparación de los cinco métodos

Diagnóstico de tiempos de espera persistentes después de aumentar el límite

Si ha confirmado que el nuevo límite está activo en phpinfo() pero el error persiste, es probable que el cuello de botella no sea max_execution_time. Considere estas causas alternativas:

Directivas de tiempo de espera de FastCGI o Nginx — Nginx tiene su propia directiva fastcgi_read_timeout, independiente de PHP:

fastcgi_read_timeout 300;

Esto debe configurarse en el bloque de servidor de Nginx y requiere una recarga de Nginx.

Directiva TimeOut de Apache — El propio tiempo de espera de conexión de Apache puede terminar una solicitud antes de que se alcance el límite de PHP:

TimeOut 300

request_terminate_timeout de PHP-FPM — En la configuración del pool de PHP-FPM (/etc/php/8.x/fpm/pool.d/www.conf), esta directiva elimina independientemente los procesos worker:

request_terminate_timeout = 300

wait_timeout y interactive_timeout de MySQL — Las consultas de base de datos de larga duración pueden provocar que la conexión MySQL se interrumpa a mitad de la ejecución, lo que PHP muestra como un fallo del script en lugar de un error de base de datos. Verifique con:

SHOW VARIABLES LIKE '%timeout%';

Tiempos de espera a nivel de WooCommerce o plugins — Algunos plugins implementan su propia lógica de tiempo de espera interna usando set_time_limit() de PHP con un valor inferior, lo que restablece el contador y puede anular su configuración.

Consideraciones de rendimiento y mejores prácticas

Aumentar max_execution_time es una solución específica, no una solución arquitectónica permanente. Si una operación específica supera rutinariamente los 30–60 segundos, el proceso subyacente debe optimizarse o reestructurarse:

• Procesamiento por lotes: Divida las importaciones grandes en fragmentos más pequeños usando fragmentación basada en AJAX (como hace WP All Import de forma nativa) en lugar de procesar todo en una sola solicitud HTTP
• Procesamiento en segundo plano: Use WP-Cron o una cola de tareas adecuada (Action Scheduler, usado por WooCommerce) para mover el trabajo de larga duración fuera del ciclo de vida de la solicitud web
• WP-CLI para operaciones masivas: La ejecución por CLI no está sujeta a los tiempos de espera del servidor web y es la herramienta correcta para importaciones de bases de datos, operaciones de búsqueda y reemplazo, y procesamiento masivo de medios
• Optimizar consultas lentas: Use el plugin Query Monitor para identificar consultas de base de datos que consumen tiempo de ejecución desproporcionado
• Actualizar el nivel de alojamiento: Si su carga de trabajo requiere consistentemente tiempos de ejecución extendidos, un VPS con cPanel le da control total sobre la configuración PHP y recursos dedicados que no compiten con otros inquilinos

Para cargas de trabajo de alto cómputo como recomendaciones de productos basadas en IA o pipelines de procesamiento de imágenes a gran escala, el alojamiento GPU descarga el cómputo intensivo completamente de la capa PHP.

Lista de verificación práctica para la toma de decisiones

Use esta lista de verificación antes y después de aplicar cualquier corrección:

• Confirme el valor actual de max_execution_time mediante phpinfo() o WP-CLI antes de realizar cambios
• Identifique su stack de servidor (Apache + mod_php, Apache + FPM, Nginx + FPM) antes de elegir un método
• Aplique solo un método a la vez — acumular cambios en php.ini, .htaccess y wp-config.php simultáneamente hace imposible la depuración
• Después de aplicar un cambio, vuelva a verificar el valor activo en phpinfo() — no asuma que el cambio funcionó
• Pruebe reproduciendo la acción fallida original, no solo cargando la página de inicio
• Si el error se resuelve, considere si la operación subyacente puede optimizarse para ejecutarse dentro del límite original
• Establezca un recordatorio en el calendario para revertir cualquier aumento temporal del límite (por ejemplo, set_time_limit(0)) después de que la tarea puntual se complete
• En alojamiento compartido, documente lo que el proveedor confirmó como el valor máximo permitido para su plan
• Si los tiempos de espera persisten después de confirmar que el límite PHP está aumentado, audite fastcgi_read_timeout de Nginx, TimeOut de Apache y request_terminate_timeout de PHP-FPM de forma independiente

Preguntas frecuentes

¿Cuál es el valor más seguro para establecer max_execution_time en WordPress?

300 segundos (5 minutos) cubre la gran mayoría de las operaciones intensivas en recursos de WordPress, incluyendo instalaciones de plugins grandes, importaciones de WooCommerce y actualizaciones de temas. Los valores superiores a 600 segundos deben tratarse como temporales y revertirse después de que la tarea específica se complete.

¿Por qué mi cambio en max_execution_time no aparece en phpinfo() después de editar php.ini?

Lo más probable es que esté editando el archivo php.ini incorrecto. PHP carga diferentes archivos de configuración para CLI, Apache mod_php y PHP-FPM. Ejecute php -i | grep "Loaded Configuration File" para CLI y verifique la fila Loaded Configuration File en una página phpinfo() accesible desde el navegador para identificar el archivo correcto para las solicitudes web.

¿Aumentar max_execution_time afecta a todos los usuarios de mi servidor?

En un servidor compartido, editar un php.ini a nivel de usuario en la raíz web afecta solo a su cuenta. Editar el php.ini global del servidor (que requiere acceso root) afecta a todos los procesos PHP en ese servidor. En un servidor dedicado, usted controla la configuración global y asume plena responsabilidad por su impacto.

¿Funcionará el método .htaccess en un servidor Nginx?

No. El archivo .htaccess es un mecanismo específico de Apache. Nginx no procesa archivos .htaccess. En stacks Nginx + PHP-FPM, debe editar la configuración del pool de PHP-FPM o el php.ini a nivel de servidor, ambos requieren acceso SSH.

¿Puede un plugin de WordPress aumentar max_execution_time de forma permanente?

No. Los plugins se ejecutan dentro del tiempo de ejecución de PHP y solo pueden llamar a set_time_limit() o ini_set(), que afectan únicamente a la solicitud actual. No pueden escribir en php.ini ni persistir cambios de configuración entre solicitudes. Para un aumento permanente, debe modificar php.ini, .htaccess, o un archivo de configuración del pool de PHP-FPM a nivel de servidor.