Una copia de seguridad que no se ejecuta, un correo que no sale, una suscripción que no se renueva o una entrada programada que no se publica pueden tener una causa común: las tareas programadas de WordPress no están funcionando como deberían.

WordPress incluye su propio sistema de tareas, conocido como WP-Cron. Es útil porque permite que el núcleo y los plugins programen acciones sin depender, en muchos alojamientos, de acceso directo al cron del servidor. Pero no funciona exactamente igual que un cron real de Linux: WordPress revisa las tareas pendientes cuando recibe una visita.

Eso tiene una consecuencia importante. En una web con poco tráfico, una tarea prevista para las 02:00 puede no ejecutarse hasta que alguien cargue una página varias horas después. En una web con mucho tráfico, revisar WP-Cron en cada petición también puede añadir trabajo innecesario al servidor.

Índice

  1. Qué tareas dependen de WP-Cron
  2. La diferencia entre WP-Cron y un cron real del servidor
  3. Señales de que hay tareas bloqueadas o retrasadas
  4. Cómo revisar WP-Cron sin tocar producción a ciegas
  5. Cuándo configurar un cron real del servidor
  6. Relación con el rendimiento de WordPress
  7. Conclusión

Qué tareas dependen de WP-Cron

WP-Cron no es una función aislada. Forma parte de muchas operaciones rutinarias que pasan desapercibidas hasta que fallan o se retrasan.

Entre las tareas más habituales están:

  • La Publicación de entradas programadas.
  • Las Comprobaciones de actualizaciones de WordPress, plugins y temas.
  • Las Copias de seguridad automáticas generadas por determinados plugins.
  • Los Envíos de correos diferidos, recordatorios o resúmenes.
  • Las Sincronizaciones con servicios externos, CRM, stock o analítica.
  • Los Procesos de WooCommerce, suscripciones, reservas y colas en segundo plano.
  • Las Limpiezas de datos temporales, cachés y registros.

Que una web cargue no demuestra que sus automatizaciones estén funcionando. Por eso, WP-Cron debería formar parte de las comprobaciones habituales de mantenimiento.

La diferencia entre WP-Cron y un cron real del servidor

El cron del sistema operativo se ejecuta según una frecuencia definida, sin depender de que haya visitantes. WP-Cron, en cambio, se activa a partir de una petición a WordPress y procesa las tareas que ya han vencido.

Esto no siempre es un problema. Para una web corporativa con visitas regulares y pocas automatizaciones, el comportamiento por defecto puede ser suficiente. Sin embargo, hay escenarios donde conviene valorar un cron real:

  • La Web tiene poco tráfico y necesita ejecutar tareas en una hora concreta.
  • La Tienda online depende de stock, pedidos, suscripciones o avisos periódicos.
  • El Sitio acumula muchas tareas de plugins y la ejecución durante visitas afecta al rendimiento.
  • Las Copias de seguridad o sincronizaciones no pueden retrasarse sin riesgo operativo.
  • El Proveedor permite configurar tareas programadas desde el panel o por SSH.

La documentación oficial de WordPress recomienda usar el planificador del sistema para invocar wp-cron.php cuando se necesitan ejecuciones más consistentes. En ese caso, se puede desactivar la ejecución de WP-Cron en cada carga, pero solo después de comprobar que el cron real del servidor se está ejecutando correctamente.

Señales de que hay tareas bloqueadas o retrasadas

No hace falta esperar a que un cliente avise de un fallo. Hay indicios que ayudan a detectar un problema antes de que afecte a una función importante.

Revisa estas señales:

  • Las Entradas programadas aparecen como “programadas” después de su fecha prevista.
  • Los Correos automáticos llegan con retraso o dejan de enviarse.
  • Las Copias de seguridad esperadas no aparecen en su ubicación habitual.
  • Las Tareas de WooCommerce se acumulan en cola o no actualizan su estado.
  • El Panel de administración muestra errores relacionados con procesos en segundo plano.
  • Los Registros del servidor repiten errores de tiempo de espera, memoria o llamadas externas.
  • Las Tareas vencidas siguen apareciendo pendientes durante un periodo prolongado.

Un aviso aislado no siempre significa que WP-Cron esté roto. Puede deberse a una API externa lenta, a una tarea demasiado pesada o a un error propio del plugin. Lo importante es comprobar si el comportamiento se repite y qué proceso concreto está implicado.

Cómo revisar WP-Cron sin tocar producción a ciegas

Antes de desactivar, borrar o modificar tareas, conviene entender qué hay programado y cuál es su origen. Una herramienta de diagnóstico como WP Crontrol permite ver los hooks programados, su próxima ejecución y el plugin o componente relacionado, pero no sustituye una revisión técnica.

Un proceso prudente sería:

  • Identificar Las tareas vencidas, repetidas o con una frecuencia inesperada.
  • Relacionar Cada hook con el plugin, tema o integración que lo ha creado.
  • Revisar Los registros de PHP, WordPress y del servidor alrededor de la hora del fallo.
  • Confirmar Si el sitio recibe tráfico suficiente para activar WP-Cron con normalidad.
  • Comprobar Si una tarea manual se completa sin generar errores.
  • Validar Si las credenciales, API externas o límites del hosting intervienen en el proceso.

No elimines una tarea solo porque su nombre no resulte familiar. Algunas extensiones usan hooks con nombres técnicos para procesos críticos; borrarlos puede retrasar más el diagnóstico o provocar pérdidas de funcionalidad.

Cuándo configurar un cron real del servidor

Un cron del servidor es especialmente recomendable cuando la web depende de automatizaciones frecuentes o de tiempo sensible. La configuración exacta depende del hosting, Plesk, cPanel, VPS o infraestructura disponible, por lo que no existe una única orden segura para todos los proyectos.

La secuencia correcta es:

  • Configurar Una llamada periódica y controlada a wp-cron.php desde el servidor.
  • Registrar El resultado y comprobar que el proceso devuelve una respuesta válida.
  • Verificar Durante varios ciclos que las tareas vencidas se ejecutan y vuelven a programarse.
  • Desactivar La ejecución de WP-Cron durante cada visita solo cuando el cron real esté validado.
  • Monitorizar Las automatizaciones críticas después del cambio.

Desactivar WP-Cron sin un sustituto funcional no optimiza nada: deja las tareas sin un mecanismo fiable para ejecutarse. También conviene evitar frecuencias demasiado agresivas si el sitio tiene procesos pesados, porque pueden solaparse ejecuciones y aumentar la carga.

Relación con el rendimiento de WordPress

En una web con muchas visitas o muchos plugins, cada comprobación de WP-Cron puede sumar procesos que compiten con las peticiones de usuarios. En una web con poco tráfico ocurre lo contrario: faltan peticiones para disparar tareas en el momento previsto.

El objetivo no es desactivar WP-Cron por norma, sino escoger una forma de ejecución adecuada al proyecto. Una web sencilla puede funcionar correctamente con la configuración estándar. Una tienda, un portal de reservas o un WordPress con integraciones externas suele necesitar más control, registros y monitorización.

Esta revisión encaja dentro de un mantenimiento WordPress profesional, junto con actualizaciones probadas, copias de seguridad verificadas y supervisión de incidencias. Detectar una cola bloqueada antes de que afecte a pedidos o formularios suele ser mucho más barato que reaccionar cuando ya hay datos o ventas comprometidas.

Conclusión

WP-Cron permite que WordPress automatice tareas esenciales, pero su ejecución ligada a las visitas tiene límites. Si una función depende de que algo ocurra a una hora concreta, es necesario comprobar cómo se dispara, qué errores aparecen y si el servidor ofrece una alternativa más estable.

La mejor configuración es la que ejecuta las tareas de forma verificable, sin añadir carga innecesaria y sin poner en riesgo las automatizaciones que sostienen el negocio.