Cómo se satura una página web en WordPress y cómo evitarlo

Actualizado el 18 de agosto de 2026 · Escrito y verificado por Josué Pérez Suay, CEO de OrbitaClick

«Se nos satura la web» es una de las frases que más escuchamos, y casi nunca significa lo que el cliente cree. En la mayoría de los casos no hay un pico de tráfico: hay una web que consume diez veces más recursos de los que debería por cada visita, y un servidor que aguanta hasta que llega un martes cualquiera con cincuenta usuarios a la vez.

Este artículo va de lo segundo. Qué se agota exactamente, cómo comprobarlo con datos en menos de veinte minutos y en qué orden arreglarlo para no gastar dinero en el sitio equivocado.

Qué significa realmente que una web «se satura»

«Saturación» no es un estado técnico: es un síntoma. Y cada síntoma apunta a un recurso distinto agotado. Empieza siempre por identificar cuál, porque el arreglo cambia por completo.

La causa raíz que casi nadie mira: los procesos PHP

Aquí está el 80 % de las «saturaciones» de WordPress, y es puramente aritmético.

Cada visita que no se sirve desde caché ocupa un proceso PHP durante todo el tiempo que tarda en generarse la página. Tu plan de hosting te da un número limitado de esos procesos. Cuando se ocupan todos, la petición número 11 se queda esperando y el usuario ve un 503.

Y ahora la parte que multiplica: si además tienes una caché de página funcionando bien, la mayoría de las visitas no llegan nunca a PHP. Se sirven como HTML estático, en milisegundos, sin ocupar ningún proceso. Con un 90 % de aciertos de caché, solo una de cada diez visitas compite por esos 10 procesos.

Las 8 causas reales, ordenadas por frecuencia

Este es el orden en el que las encontramos auditando WordPress de clientes, no el orden en el que aparecen en los artículos genéricos.

1. Caché de página inexistente o esquivada sin darte cuenta

Tener WP Rocket instalado no significa tener caché funcionando. Hay rutas que por diseño nunca se cachean y que, si reciben tráfico, van directas a PHP:

• Búsquedas internas (?s=…): cada consulta distinta es una página única, imposible de cachear. Un bot que rastrea el buscador te genera miles de peticiones dinámicas.
• URLs con parámetros de campañas o filtros (?utm_…, ?orderby=…, ?filter_…): si no están normalizadas, cada variante es una entrada de caché nueva o un fallo de caché.
• Carrito y checkout de WooCommerce: no se pueden cachear. Con una tienda activa, ese tráfico es 100 % dinámico.
• Usuarios logueados: por defecto se les sirve la página generada. En un sitio con área privada o con muchos administradores, es carga real.

2. wp-cron.php ejecutándose en cada carga de página

WordPress no tiene un cron de verdad: simula las tareas programadas comprobándolas en cada visita. En un sitio con poco tráfico da igual; en un sitio con tráfico, o con muchas tareas encoladas, se convierte en una sobrecarga constante y aleatoria.

La solución que recomienda la propia documentación de WordPress es desactivar el cron por visita y engancharlo al planificador de tareas del sistema:

# En wp-config.php
define( 'DISABLE_WP_CRON', true );

# Y en el cron del servidor, cada 5 minutos:
*/5 * * * * wget -q -O - https://tudominio.com/wp-cron.php?doing_wp_cron

3. admin-ajax.php y la API Heartbeat

Cada pestaña abierta del escritorio de WordPress lanza peticiones periódicas a admin-ajax.php. Cada una es un proceso PHP. Con cinco personas del equipo trabajando a la vez y varios plugins que también usan AJAX, es carga permanente que no genera ni una visita.

4. Bots, crawlers y rastreadores de IA

El tráfico de bots ya no es marginal. A los buscadores clásicos se han sumado los rastreadores de los modelos de lenguaje, y algunos rastrean con mucha más agresividad que Google. Si además caen en el buscador interno o en URLs con parámetros, cada petición es dinámica.

Esto no significa bloquearlos a todos: los rastreadores de IA son justamente los que te citan. Significa controlarlos: robots.txt explícito, bloqueo de las rutas que no aportan nada (buscador interno, filtros infinitos, calendarios) y cortar en el firewall solo los que no aportan tráfico ni citas.

5. Ataques de fuerza bruta a wp-login.php y xmlrpc.php

No hace falta que el ataque tenga éxito para tirarte la web. Cada intento de login es una petición que arranca WordPress completo y consulta la base de datos. Unos cientos por minuto agotan los procesos de cualquier plan compartido.

xmlrpc.php es peor: permite agrupar cientos de intentos en una sola petición. Si no usas la app de WordPress ni Jetpack, desactívalo.

6. Opciones autoload infladas

WordPress carga en memoria, en cada petición, todas las opciones marcadas como autoload. Plugins mal programados dejan ahí cachés, logs y arrays gigantes. Hemos visto tablas wp_options con varios megas de autoload: eso son varios megas leídos y deserializados en cada carga de página.

Desde WordPress 6.6 el core ya no autocarga por defecto las opciones que superan los 150 KB, y añadió un aviso en Salud del sitio. Pero las opciones creadas antes siguen marcadas como estaban, así que hay que limpiarlas a mano.

7. Consultas lentas y tablas sin mantenimiento

Revisiones de entradas acumuladas durante años, transients caducados que nadie borra, wp_postmeta con cientos de miles de filas huérfanas de plugins desinstalados, tablas de logs que crecen sin límite. Ninguna de esas cosas tira la web por sí sola; todas juntas suben el TTFB, y el TTFB es el divisor de la ecuación de capacidad.

8. Plugins que ejecutan en cada petición

Constructores visuales pesados, sliders, «entradas relacionadas» que hacen una consulta sin índice, plugins de estadísticas que escriben en la base de datos en cada visita, contadores de visitas. El patrón siempre es el mismo: trabajo hecho en tiempo de petición que debería estar precalculado o directamente no hacerse.

Diagnóstico en 20 minutos

Sin datos no hay diagnóstico. Este es el recorrido mínimo, en orden:

1. Mira el uso de recursos por horas en tu panel de hosting. Busca si los picos coinciden con tráfico real, con la hora de los backups o con nada en absoluto. Si es «con nada», el culpable es un bot o una tarea programada.
2. Mide tu TTFB con caché y sin caché. Abre la web en el navegador, mira el tiempo de la primera petición del documento en el panel de red y compáralo con una recarga forzada y con una URL con un parámetro aleatorio (que esquiva la caché). La diferencia entre ambos es lo que te está costando cada fallo de caché.
3. Analiza el log de acceso. Es el paso que más gente se salta y el que más rápido da la respuesta:

   # Top 20 IPs que más peticiones hacen
   awk '{print $1}' access_log | sort | uniq -c | sort -rn | head -20
   
   # Top 20 user agents (aquí salen los bots)
   awk -F'"' '{print $6}' access_log | sort | uniq -c | sort -rn | head -20
   
   # Cuánto te están golpeando en login y XML-RPC
   grep -c "wp-login.php" access_log
   grep -c "xmlrpc.php" access_log
   
   # Peticiones al buscador interno (nunca se cachean)
   grep -c "/?s=" access_log

4. Comprueba el peso de las opciones autoload:

   SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS mb, COUNT(*) AS num
   FROM wp_options
   WHERE autoload IN ('yes','on','auto','auto-on');
   
   SELECT option_name, ROUND(LENGTH(option_value)/1024, 1) AS kb
   FROM wp_options
   WHERE autoload IN ('yes','on','auto','auto-on')
   ORDER BY LENGTH(option_value) DESC
   LIMIT 20;

   Como referencia práctica: por debajo de 1 MB no suele ser tu problema; por encima de 3-4 MB es una de las primeras cosas que arreglar.

5. Instala Query Monitor (solo mientras diagnosticas) y carga la página más lenta. Te dice cuántas consultas hay, cuáles son las lentas y qué plugin las lanza. Es la herramienta que convierte «va lento» en «este plugin hace 340 consultas en la portada».
6. Revisa la cola de tareas programadas. Con WP-CLI, wp cron event list te muestra si hay tareas atascadas o duplicadas. Y wp transient delete --expired limpia lo caducado.
7. Contrasta con las estadísticas de rastreo de Search Console. Si Google reporta picos de tiempo de respuesta o errores de servidor en las mismas fechas, tienes la confirmación externa y además sabes que te está costando indexación.

Plan de contención cuando la web ya está caída

Si estás en el incidente ahora mismo, el orden es contener primero y diagnosticar después:

1. Confirma que es saturación y no malware ni un fatal error. Mira el error_log. Un 500 repetido con la misma traza es un plugin, no un pico de tráfico.
2. Activa el nivel de caché más agresivo que tengas disponible y purga. Si tu hosting tiene caché a nivel de servidor (LiteSpeed, Varnish, NGINX FastCGI), asegúrate de que está sirviendo, no solo activado.
3. Corta el sangrado obvio: bloquea las IPs y user agents que dominan el log, desactiva xmlrpc.php y protege wp-login.php con limitación de intentos.
4. Desactiva temporalmente los plugins no críticos, empezando por los de estadísticas, sliders y «relacionados». Uno a uno, midiendo, no todos a la vez.
5. Sube el límite de recursos de forma temporal si tu hosting lo permite, para recuperar el servicio mientras arreglas la causa. Temporal significa temporal.
6. Solo cuando la web está estable, haz el diagnóstico completo del apartado anterior y arregla la causa. Si te quedas en el paso 5, esto vuelve a pasar el mes que viene.

Cuándo el hosting sí es el problema

Hay casos en los que ampliar es lo correcto. La forma de saberlo es esta: si tu TTFB con caché es bueno, tu tasa de acierto es alta, no hay bots descontrolados y aun así tocas el techo de recursos, entonces el plan te queda pequeño. Ahí sí toca mover.

Qué NO es saturación (aunque se parezca)

Errores que vemos una y otra vez

Preguntas frecuentes

Escrito y verificado por

Josué Pérez Suay, CEO y fundador de OrbitaClick, agencia de marketing digital en Alicante desde 2018. Citado en 25 artículos de Computer Hoy como fuente experta.

Ver perfil profesional y CV completo