WordPress va lento por cron del servidor cómo optimizar

Cuando wp-cron influye en la lentitud de un sitio, el problema suele estar en cómo se disparan y ejecutan las tareas programadas, no en el cron del servidor por sí solo. En WordPress, muchas acciones internas dependen de eventos programados: publicaciones automáticas, envío de correos, comprobaciones de plugins, tareas de WooCommerce o procesos de mantenimiento. Si esas ejecuciones se acumulan, se lanzan con demasiada frecuencia o se solapan, el sitio puede responder peor, consumir más recursos o empezar a fallar de forma intermitente.

La clave no suele ser “desactivar algo porque sí”, sino diagnosticar qué tareas se ejecutan, con qué frecuencia y desde qué mecanismo. En algunos entornos conviene sustituir WP-Cron por un cron real del servidor; en otros, bastará con corregir plugins, colas de acciones o frecuencias mal definidas. Hacerlo con criterio evita romper publicaciones programadas, pedidos, recordatorios por email o automatizaciones críticas para negocio.

Qué es WP-Cron y por qué puede volver lento WordPress

WP-Cron es el sistema de tareas programadas de WordPress. A diferencia de un cron real del sistema operativo, no depende necesariamente de un servicio del servidor ejecutándose cada cierto tiempo. Por defecto, WordPress intenta lanzar sus eventos cuando recibe una visita y detecta que hay tareas pendientes.

Ese comportamiento tiene una ventaja: funciona incluso en alojamientos básicos donde no se puede gestionar un cron del servidor. Pero también introduce limitaciones importantes:

• La ejecución depende de visitas. Si una web tiene poco tráfico, algunas tareas pueden retrasarse.
• Cada comprobación implica peticiones a wp-cron.php, que pueden añadir carga en momentos de tráfico alto.
• Si hay eventos mal programados o demasiado frecuentes, aumenta el consumo de recursos y el número de procesos concurrentes.
• Cuando una tarea tarda demasiado, puede generar bloqueos o solapamiento de procesos.

No todos los sitios sufren por ello. En una instalación pequeña y estable, WP-Cron puede funcionar sin incidencias visibles. El problema aparece con más frecuencia en webs con caché agresiva, tiendas con WooCommerce, automatizaciones, importaciones, copias de seguridad, plugins de seguridad o mantenimiento, y entornos donde varias tareas en segundo plano compiten entre sí.

Señales de que el problema está en las tareas programadas

Antes de tocar la configuración, conviene identificar indicios concretos. No toda lentitud en WordPress está relacionada con cron. Puede ser base de datos, PHP, consultas de un plugin, caché mal servida o falta de recursos del hosting. Aun así, estas señales suelen apuntar a un problema de tareas programadas:

• Las publicaciones programadas no salen a su hora o aparecen con retraso.
• WooCommerce deja pedidos en estados intermedios, se retrasan correos transaccionales o fallan automatizaciones.
• Se observan muchas solicitudes a wp-cron.php en logs, monitorización o paneles del hosting.
• Hay picos de consumo de CPU o procesos PHP sin una subida clara de tráfico real.
• Plugins de mantenimiento, seguridad, SEO o copias ejecutan revisiones demasiado frecuentes.
• Existen tareas bloqueadas o colas acumuladas que no terminan de procesarse.
• La administración de WordPress responde lenta en momentos concretos, sobre todo al cargar ciertas pantallas o tras recibir visitas.

En tiendas online conviene revisar también Action Scheduler, un sistema muy habitual en WooCommerce y extensiones relacionadas. No es idéntico a todo WP-Cron, pero sí puede aumentar la carga si la cola acumula acciones pendientes, reintentos o tareas masivas.

En la práctica, el diagnóstico suele apoyarse en registros del hosting, herramientas de observabilidad, consultas a la base de datos y revisión de plugins activos. Si se actúa sin comprobar esto, es fácil “optimizar” el disparo del cron pero dejar intacta la causa real: un plugin ejecutando eventos cada minuto, una tarea remota bloqueada o un proceso de mantenimiento mal diseñado.

Diferencias entre WP-Cron y un cron real del servidor

La diferencia esencial está en quién dispara la ejecución. WP-Cron depende del propio flujo de visitas o peticiones; un cron real del servidor se programa a nivel del sistema o del panel de hosting para ejecutarse con una periodicidad definida.

Eso no significa que el cron real sea automáticamente mejor en cualquier caso. Si se configura con una frecuencia poco adecuada, si llama mal a WordPress, si el hosting impone restricciones o si hay tareas defectuosas dentro del propio sitio, el problema puede persistir o incluso empeorar.

Cuándo conviene desactivar WP-Cron y qué revisar antes

Desactivar WP-Cron suele tener sentido cuando el sitio ya dispone de un cron del servidor fiable o cuando la forma en que se dispara wp-cron.php está generando demasiadas peticiones y carga innecesaria. Es una decisión frecuente en proyectos con tráfico estable, hosting administrado, VPS, servidores dedicados o paneles como cPanel o Plesk donde se puede programar una tarea real.

Antes de hacerlo, conviene revisar estos puntos:

1. Si el hosting permite crear tareas programadas y con qué límites.
2. Si el sitio depende de procesos sensibles al tiempo: pedidos, reservas, membresías, emails, sincronizaciones o publicaciones programadas.
3. Si existe caché de página completa o CDN que altere la frecuencia real con la que WordPress recibe peticiones.
4. Si hay plugins de seguridad, backup o mantenimiento que registren eventos muy pesados.
5. Si WooCommerce o extensiones relacionadas tienen colas pendientes en Action Scheduler.
6. Si el rendimiento lento viene de cron o de otra capa distinta, como base de datos, PHP, disco o consultas externas.

Si tras la revisión se decide sustituir WP-Cron por el cron del servidor, el cambio técnico habitual empieza en wp-config.php añadiendo la constante exacta DISABLE_WP_CRON:

define('DISABLE_WP_CRON', true);

Ese ajuste no optimiza nada por sí mismo si no se acompaña de un cron real bien configurado. Dejar WP-Cron desactivado sin sustitución es uno de los errores más habituales y puede provocar tareas atrasadas o directamente no ejecutadas.

Cómo configurar un cron del servidor para ejecutar WordPress correctamente

Una vez desactivado el disparo interno, el objetivo es que el servidor lance WordPress de forma controlada y periódica. La forma exacta depende del entorno: cPanel, Plesk, cron del sistema en Linux o servicios gestionados con systemd. Por eso conviene hablar de pautas técnicas y ejemplos orientativos, no de un único comando universal.

1. Define una frecuencia realista

No existe una periodicidad válida para todos los sitios. Una web corporativa puede tolerar intervalos mayores que una tienda online con pedidos y correos frecuentes. En general, la frecuencia debe ajustarse a la carga real del proyecto, al tipo de eventos programados y a la capacidad del servidor. Si se programa demasiado a menudo, se añade carga. Si se programa demasiado poco, se retrasan tareas críticas.

2. Lanza la llamada correcta a wp-cron.php

La ejecución suele hacerse llamando a wp-cron.php del sitio correspondiente. Esa llamada puede realizarse por HTTP o desde la línea de comandos, según lo que permita y recomiende el entorno. La ruta exacta, el binario disponible y el método apropiado dependen del servidor, así que conviene adaptarlo con soporte del hosting si hay dudas.

En paneles como cPanel o Plesk, normalmente se configura una tarea programada desde el propio panel. En un servidor administrado, puede usarse cron tradicional o una unidad/temporizador de systemd si el administrador del sistema lo considera adecuado.

3. Comprueba que las tareas realmente se ejecutan

Después del cambio, verifica publicaciones programadas, envío de correos, tareas de WooCommerce, colas pendientes y registros de errores. Si el sitio deja de mostrar síntomas de carga excesiva pero aparecen retrasos funcionales, la frecuencia elegida o la forma de invocar wp-cron.php puede no ser la adecuada.

4. Revisa si hay tareas anómalas, no solo el disparo

Sustituir el mecanismo de ejecución no corrige por sí solo un plugin que programa eventos cada minuto, una sincronización externa ineficiente o una cola que reintenta acciones fallidas sin control. Si WordPress sigue consumiendo recursos, toca analizar qué eventos cron están ocupando tiempo, cuántos se acumulan y cuáles deberían espaciarse o corregirse.

Errores frecuentes al optimizar el cron en WordPress

• Desactivar WP-Cron sin cron alternativo. Es el fallo más común. El sitio parece estable durante unos días y después empiezan los retrasos en publicaciones, correos o tareas internas.
• Usar una frecuencia inadecuada. Una periodicidad demasiado agresiva puede aumentar procesos concurrentes; una demasiado amplia retrasa automatizaciones importantes.
• No revisar WooCommerce ni Action Scheduler. En eCommerce, el cuello de botella puede estar en colas de acciones, renovaciones, webhooks o emails, no solo en el disparo de WP-Cron.
• Ignorar tareas bloqueadas o reintentos continuos. Si una acción falla y se vuelve a programar una y otra vez, el cron se convierte en síntoma, no en causa.
• Confiar ciegamente en plugins de optimización. Algunos ayudan a visualizar eventos, pero no sustituyen una revisión técnica del servidor, los logs y la arquitectura del sitio.
• No tener en cuenta caché y tráfico real. En sitios con caché de página completa, muchas visitas no disparan PHP del mismo modo, así que el comportamiento de WP-Cron cambia.
• Aplicar la misma receta a todos los hostings. Las limitaciones de recursos, los comandos permitidos y la forma de programar tareas varían bastante entre proveedores.

Preguntas frecuentes

¿Desactivar WP-Cron mejora siempre el rendimiento?

No siempre. Puede ayudar cuando el disparo por visitas genera demasiadas peticiones o poca regularidad, pero el resultado depende del hosting, del tráfico, de la caché y de las tareas programadas existentes.

¿Puede afectar a WooCommerce?

Sí, para bien o para mal. Un cron real bien ajustado puede dar más estabilidad a pedidos, correos y automatizaciones. Una mala configuración puede retrasar procesos o dejar colas sin atender.

¿Cómo sé si el problema es wp-cron.php o un plugin?

Hay que revisar eventos programados, registros del servidor, tareas repetidas, tiempos de ejecución y colas pendientes. Muchas veces wp-cron.php solo está lanzando tareas ineficientes definidas por un plugin o integración externa.

Conclusión: cómo mejorar el rendimiento sin romper tareas críticas

Si WordPress va lento por cron, lo más habitual es que el origen esté en la forma de disparar las tareas programadas, su frecuencia real o el volumen de procesos pendientes. WP-Cron no es “malo” por definición, pero en ciertos entornos puede volverse ineficiente o poco predecible. Desactivarlo y pasar a un cron del servidor puede ser una buena decisión cuando se hace con análisis previo, frecuencia adecuada y comprobación posterior.

El error más común es simple: desactivar WP-Cron sin asegurar una ejecución alternativa fiable. El siguiente paso razonable es auditar qué eventos se están ejecutando, qué plugins generan más carga y si el hosting en España donde está alojado el sitio permite una configuración estable del cron. Si tu web depende de pedidos, correos o automatizaciones y no quieres arriesgarte a romper procesos críticos, tiene sentido apoyarte en un servicio de mantenimiento WordPress o soporte WordPress para ajustar el cron con criterio técnico real.

Fuente oficial

• Documentación oficial de WordPress sobre WP-Cron: developer.wordpress.org/plugins/cron/