Cuando WordPress consume mucha CPU, la solución más rápida suele parecer ampliar el servidor. A veces es necesario, pero no debería ser el primer diagnóstico. Duplicar recursos puede esconder un bot agresivo, una tarea programada mal configurada, una consulta lenta o un proceso PHP bloqueado que seguirá creciendo hasta ocupar también el servidor nuevo.
La CPU es un síntoma. Para actuar con criterio hay que descubrir qué proceso la está consumiendo, cuándo ocurre y qué lo dispara.
Esta guía separa las causas habituales para recoger evidencias antes de cambiar de plan, desactivar plugins al azar o culpar a WordPress.
Índice
- Empieza por confirmar cuándo ocurre el pico.
- Distingue tráfico real de rastreadores y bots.
- Mira qué responde el servidor: no todo consumo proviene de WordPress.
- Revisa PHP-FPM: cola, límites y procesos bloqueados.
- Comprueba si WP-Cron está concentrando trabajo.
- Identifica consultas lentas y crecimiento de la base de datos.
- Comprueba tareas externas e integraciones.
- Revisa intentos de ataque sin asumir que todo es un ataque.
- Decide si necesitas más recursos después del diagnóstico.
- Qué evidencias conviene guardar antes de cambiar nada.
Empieza por confirmar cuándo ocurre el pico
Un gráfico de CPU alto no explica por sí mismo qué está pasando. Antes de intervenir, anota la hora de los picos y compárala con el tráfico, los logs y las tareas programadas.
Busca patrones como estos:
- Picos constantes durante todo el día.
- Picos concentrados a una hora concreta.
- Subidas coincidiendo con campañas, newsletters o publicaciones.
- Picos que aparecen sin aumento visible de visitas.
- Consumo que se dispara solo en el administrador o en una URL determinada.
Una web con tráfico real suele mostrar cierta relación entre visitas, peticiones y consumo. Si la CPU sube a las tres de la madrugada sin usuarios, probablemente hay un trabajo automático, un bot o un proceso interno que revisar.
Guarda al menos un intervalo de varias horas. Un único pico puede coincidir con una caché vaciada, una copia de seguridad, un escaneo o una actualización puntual.
Distingue tráfico real de rastreadores y bots
No toda petición web viene de un visitante. Los buscadores, monitores, crawlers comerciales, scrapers y bots maliciosos pueden cargar muchas páginas o pedir recursos caros de forma repetitiva.
Revisa los logs de acceso del servidor o del CDN con estas preguntas:
- Qué URLs reciben más peticiones.
- Qué direcciones IP o rangos concentran el tráfico.
- Qué agentes de usuario aparecen con más frecuencia.
- Qué códigos HTTP devuelven esas peticiones.
- Si piden páginas de búsqueda, feeds, XML-RPC, login o endpoints de API.
- Si hay muchas peticiones iguales desde una misma IP en pocos segundos.
Un aumento de tráfico legítimo suele repartirse entre varias páginas, sesiones y direcciones. Un crawler problemático a menudo repite parámetros, URLs de búsqueda internas o páginas con muchas combinaciones posibles. Un intento de fuerza bruta puede concentrarse en wp-login.php o xmlrpc.php.
No bloquees una IP solo porque aparece muchas veces. Primero confirma que el patrón es abusivo y que no corresponde a un buscador identificado, a un monitor contratado o a una integración del propio negocio.
Mira qué responde el servidor: no todo consumo proviene de WordPress
La CPU alta puede coincidir con Nginx, Apache, PHP-FPM, MariaDB/MySQL, un compresor de copias o una tarea del sistema. Saber cuál está ocupado cambia por completo el diagnóstico.
En un VPS o servidor gestionado, las preguntas iniciales son:
- Qué proceso utiliza CPU en el momento del pico.
- Cuántos procesos PHP se están ejecutando y cuánto tiempo llevan activos.
- Cuánta memoria usan y si el servidor está usando swap.
- Si la base de datos tiene consultas activas o bloqueadas.
- Si hay procesos de backup, antivirus, indexación o compresión.
- Si el disco muestra espera elevada, aunque la CPU no esté al 100 %.
Una CPU alta con muchos procesos PHP cortos puede indicar volumen de peticiones. Pocos procesos PHP que llevan minutos activos pueden apuntar a una llamada externa bloqueada, una consulta pesada o código que no termina. Si la base de datos está saturada, ampliar PHP puede empeorar la competencia por recursos en lugar de resolverla.
Revisa PHP-FPM: cola, límites y procesos bloqueados
PHP-FPM ejecuta gran parte del trabajo dinámico de WordPress. Cuando sus procesos se agotan o se quedan esperando, la web puede consumir CPU, responder lentamente o devolver errores 502/504.
Conviene comprobar:
- El Número de procesos activos y en espera.
- Los Límites de procesos configurados para el pool.
- La Cola de solicitudes pendiente.
- Los Avisos de procesos lentos o terminados por tiempo máximo.
- Los Errores PHP registrados durante el pico.
- La Versión de PHP y extensiones cargadas.
No ajustes pm.max_children por intuición. Aumentarlo permite atender más solicitudes simultáneas, pero cada proceso consume memoria. Si no hay RAM suficiente, el servidor empezará a usar swap y la respuesta puede empeorar.
Los logs lentos de PHP-FPM, cuando están disponibles, ayudan a identificar qué script o ruta se estaba ejecutando. Úsalos con prudencia: una ruta lenta no demuestra automáticamente que el código de WordPress sea el único responsable; puede estar esperando una base de datos, una API externa o un recurso de red.
Comprueba si WP-Cron está concentrando trabajo
WordPress ejecuta tareas programadas mediante WP-Cron. En muchos sitios, esas tareas se activan cuando llega una visita. Si se acumulan eventos, una petición normal puede acabar lanzando importaciones, envío de correos, limpieza de transitorios o sincronizaciones.
Revisa:
- Qué eventos están programados y cada cuánto se ejecutan.
- Si hay eventos vencidos acumulados.
- Qué plugins registran tareas frecuentes.
- Si las copias, importaciones o sincronizaciones se ejecutan en horas de tráfico.
- Si WP-Cron se dispara en cada visita en lugar de mediante una tarea del servidor controlada.
Mover tareas pesadas a un cron real del sistema puede hacer el consumo más predecible, pero no es una receta universal. Hay que validar qué necesita cada plugin y evitar ejecutar dos veces el mismo mecanismo.
Identifica consultas lentas y crecimiento de la base de datos
WordPress puede generar muchas consultas por una página compleja, pero una consulta lenta sostenida suele requerir revisar índices, tablas grandes, filtros, metadatos o código de terceros.
Las señales habituales son:
- La CPU sube junto con la actividad de MySQL o MariaDB.
- Las Páginas dinámicas tardan mucho aunque los archivos estáticos carguen rápido.
- El Administrador se vuelve lento al buscar pedidos, usuarios o entradas.
- Un Informe, filtro o importación coincide con el pico.
- El Registro de consultas lentas muestra operaciones repetidas.
En WooCommerce, búsquedas de pedidos, variaciones, informes y extensiones de sincronización pueden ampliar mucho las tablas de metadatos. En webs editoriales, una búsqueda interna sin límites o una consulta personalizada sin índice puede producir el mismo efecto.
Antes de borrar transitorios, optimizar tablas o añadir índices, toma una copia y reproduce el problema cuando sea posible. La optimización sin un patrón medido puede ocultar temporalmente el síntoma sin arreglar el origen.
Comprueba tareas externas e integraciones
Una página puede parecer sencilla, pero al cargarse o al ejecutar una tarea puede consultar un CRM, una pasarela de pago, un ERP, un servicio de correo, un mapa o una API. Si esa llamada responde despacio, cada proceso PHP queda ocupado esperando.
Busca en los registros y en los cambios recientes:
- Webhooks repetidos o que devuelven error.
- Sincronizaciones de catálogo, stock o contactos.
- Llamadas a APIs con tiempos de espera altos.
- Plugins de seguridad, analítica o caché con errores.
- Importaciones programadas.
- Conexiones salientes fallidas.
Una integración problemática no siempre provoca un error visible en la web. Puede dejar procesos esperando hasta agotar el pool de PHP. Por eso es útil cruzar la hora del pico con los logs de aplicación y no limitarse al gráfico del proveedor.
Revisa intentos de ataque sin asumir que todo es un ataque
La fuerza bruta, el scraping o los escaneos de vulnerabilidades pueden elevar el número de peticiones. Pero también es posible que una configuración legítima produzca tráfico intenso.
Revisa con especial atención:
- Intentos repetidos en
wp-login.php. - Peticiones masivas a
xmlrpc.php. - Exploración de rutas de plugins, temas y archivos conocidos.
- Solicitudes con parámetros extraños o cadenas muy largas.
- Errores 404 repetidos en URLs inexistentes.
- Peticiones a la API REST que no encajan con el uso normal de la web.
Si confirmas un patrón abusivo, aplica una medida proporcionada: límites en CDN o WAF, protección del acceso, bloqueo temporal bien documentado o reglas específicas para una ruta. Bloquear a ciegas puede afectar a usuarios, buscadores o integraciones válidas.
Decide si necesitas más recursos después del diagnóstico
Ampliar CPU o RAM tiene sentido cuando la carga es legítima y sostenida, y cuando el servidor actual no puede atender el volumen esperado. Por ejemplo, una tienda en crecimiento, una campaña planificada o un proceso de negocio que ya ha sido optimizado pueden necesitar más capacidad.
No es la primera respuesta si observas:
- Un Bot que solicita miles de URLs inútiles.
- Un Proceso PHP bloqueado por una API.
- Una Tarea cron duplicada o acumulada.
- Una Consulta lenta identificable.
- Una Configuración de caché rota tras un cambio.
- Un Error de aplicación que genera reintentos continuos.
Primero corrige o limita el origen. Después, mide de nuevo. Si el consumo sigue siendo legítimo y el margen del servidor es insuficiente, la ampliación estará justificada y podrás dimensionarla con datos.
Qué evidencias conviene guardar antes de cambiar nada
Una intervención rápida es más segura cuando deja un rastro mínimo de lo observado. Guarda:
- El Intervalo horario del pico.
- Las Métricas de CPU, RAM, disco y carga.
- Una Muestra de los logs de acceso y error.
- Los Procesos principales durante la incidencia.
- Los Eventos cron relevantes.
- Las Consultas lentas o errores de PHP, si existen.
- Los Cambios recientes de plugins, tema, PHP o configuración.
Con esta información puedes comparar el estado antes y después de una corrección. También evitarás tomar decisiones costosas basadas en una interpretación incompleta del panel de hosting.
Si tu WordPress necesita observabilidad, ajustes de PHP-FPM, protección ante bots o revisión de infraestructura, puedes consultar el servicio de servidores y VPS gestionados. Y si el problema comenzó tras instalar o actualizar una extensión, revisa también la guía sobre cómo encontrar un cuello de botella tras instalar un plugin.
La CPU alta no es un diagnóstico. Es la señal para empezar a medir.
—