Kinsta analizó más de 10.000 millones de solicitudes HTTP en toda su infraestructura de alojamiento y descubrió que los bots accedieron a las URLs de añadir al carrito de los sitios de WordPress 7,67 millones de veces en un solo periodo de 24 horas. Solo un rastreador generó 550 millones de solicitudes en 30 días antes de que una regla lo detuviera.
Ninguna de esas solicitudes se convirtió en venta. Ninguna de ellas redirigió a ningún visitante de vuelta al sitio web. Simplemente seguían llegando a través de páginas de carrito, URLs de productos filtrados, consultas de búsqueda y endpoints AJAX, y cada una de ellas obligaba al servidor a ejecutar PHP, realizar una consulta a la base de datos y gestionar una sesión para un tráfico que nunca se convertiría en un cliente.
Los sitios que absorbían esta carga no se caían. Las páginas se cargaban. El proceso de pago funcionaba. Según todos los indicadores habituales, parecían estar en perfecto estado. Ese es precisamente el problema del que trata este artículo.
El tráfico de bots ya no es solo ruido de fondo
En 2025, los bots representaban el 53 % de todo el tráfico web, lo que supuso la primera vez que el tráfico automatizado superó al humano en un año natural. En junio de 2026, Cloudflare Radar situaba esa cifra en el 57,5 %, un punto de inflexión que, según el propio director general de Cloudflare, se produjo años antes de lo que él había previsto.
Para los que gestionáis WordPress, el cambio en la práctica va más allá de un simple porcentaje. El tráfico de bots de hoy en día no se limita a los rastreadores de búsqueda que hacen su trabajo. Incluye rastreadores para entrenar IA, herramientas de scraping, bots de auditoría SEO, monitores de disponibilidad, agentes de usuario falsos y herramientas de IA con comportamiento similar al de un agente que siguen los enlaces de forma mucho más agresiva de lo que jamás podría hacerlo un rastreo tradicional.
Algunos indexan contenido. Otros lo extraen. Otros prueban endpoints. Y otros tratan cada combinación de parámetros de URL como una página distinta y rastrean cada una de ellas.
Este último comportamiento resulta especialmente costoso para WordPress. Una página de producto con filtros de color, talla, orden, paginación y existencias se ve como una sola página para un visitante humano. Un bot puede ver cientos de URLs únicas y rastrearlas todas.
El tráfico generado por bots basados en IA se disparó un 300 % en un año. A finales de 2025, los bots de IA representaban 1 de cada 31 visitas web en la red de TollBit, frente a 1 de cada 200 a principios de año. La tendencia está clara. Lo que todavía no se valora lo suficiente es cuánto cuesta realmente ese tráfico.
El ancho de banda es el coste más obvio
El ancho de banda son los datos que transfiere tu sitio web cuando alguien solicita una página, una imagen, un script, un archivo u otro recurso. Los visitantes humanos lo usan. Los bots también, y además no compran nada después.
Un rastreador que visita una entrada de blog una sola vez no supone ningún problema. Sin embargo, un bot que rastrea repetidamente archivos, páginas de etiquetas, recursos de imagen, feeds, scripts y URLs filtradas puede consumir ancho de banda real sin generar ningún valor comercial.
Según los datos de Cloudflare de 2025, citados en el Informe sobre tráfico de IA y bots de Kinsta, el 80 % de la actividad de rastreo de la IA se destina al entrenamiento de modelos, en lugar de a búsquedas o consultas iniciadas por los usuarios, y no genera tráfico de referencia hacia el sitio web. En el caso de los sitios de WordPress con mucho contenido, esta dinámica convierte las páginas de gran valor en activos de alto coste.
Lo más engañoso es que el desperdicio de ancho de banda suele acumularse sin que se note ningún problema visible de rendimiento. El sitio sigue cargándose. El servidor sigue respondiendo. Pero el consumo no deja de subir porque el tráfico automatizado sigue solicitando páginas y recursos que ningún visitante humano necesita.
Para cuando el coste del ancho de banda se hace evidente, puede que el sitio ya lleve días o semanas atendiendo un tráfico que nunca ha ayudado al negocio.
La carga del backend es el coste más difícil de detectar
No todas las solicitudes tienen el mismo coste de gestión. Una entrada de blog almacenada en caché es relativamente barata, ya que el servidor devuelve una versión guardada y sigue adelante. Las solicitudes dinámicas funcionan de otra manera.
Cuando un bot accede a una acción del carrito de WooCommerce, una página de productos filtrada, una URL de búsqueda, una página de inicio de sesión o un endpoint AJAX, el servidor no puede recurrir a la caché. Tiene que procesarlo cada vez:
- Ejecución de PHP — se reserva un hilo durante todo el tiempo que dura la solicitud
- Consultas a la base de datos — la página consulta la base de datos cada vez que se carga, sin caché que lo absorba
- Gestión de sesiones — las páginas del carrito y de pago crean o validan una sesión por cada solicitud, incluso para bots que nunca van a completar una compra
- Lógica de los plugins — cualquier plugin que se enganche a estas solicitudes ejecuta su código cada vez que se accede a ellas
- Omisión de la caché — la solicitud nunca entra en la caché, por lo que futuras solicitudes idénticas volverán a suponer el mismo coste
Aquí es donde el tráfico de bots resulta más caro de lo que parece. El problema no es solo la cantidad de datos que descarga un bot, sino todo el trabajo que realiza la infraestructura antes de devolver esos datos.
Los datos de infraestructura de Kinsta ponen de manifiesto la magnitud del problema: los bots accedieron a las URLs de «añadir al carrito» 7,67 millones de veces en un solo periodo de 24 horas, incluyendo 3,75 millones de solicitudes solo de ClaudeBot. Cada una de ellas se trató como una nueva solicitud del lado del servidor. Cada una activó la ejecución de PHP y una consulta a la base de datos. Ninguna de ellas atendió a un cliente.
Como dijo el director técnico de Kinsta, Daniel Pataki, en el lanzamiento: «La mayoría de los consejos sobre gestión de bots se reducen a “bloquearlo todo” o “dejarlo estar”. Ninguna de las dos opciones funciona a gran escala».
Por qué decir que «no hemos tenido tiempo de inactividad» no da en el clavo
El tiempo de actividad significa que la web sigue online. No significa que la web funcione de forma eficiente.
Una web de WordPress puede absorber una cantidad significativa de tráfico innecesario antes de que los visitantes noten que algo va mal. Las páginas siguen cargándose. El proceso de pago sigue funcionando. Las pantallas de administración siguen respondiendo. Pero la infraestructura sigue procesando cada solicitud de bot que llega a un endpoint dinámico, y ese procesamiento conlleva un coste real, incluso cuando el sitio parece estable.
Ese coste se manifiesta de formas más sutiles que una caída del servicio:
- Un mayor uso de ancho de banda que se acerca poco a poco a los límites de tu plan
- Más presión sobre los workers PHP y las conexiones a la base de datos
- Menos margen cuando los picos de tráfico real exigen esos mismos recursos
- Analíticas distorsionadas que mezclan las sesiones de los bots con la interacción de los usuarios
- Resultados de pruebas A/B y tasas de conversión sesgados por un tráfico que nunca tuvo la intención de convertir
- Decisiones sobre la infraestructura basadas en datos que no reflejan el comportamiento real de la audiencia
- Mayor dificultad para solucionar problemas cuando el ruido de la actividad de los bots oculta la señal de los problemas reales de rendimiento
Por eso, el hecho de que «no haya tiempo de inactividad» puede dar a los equipos una falsa sensación de seguridad. El sitio parece estable porque la infraestructura absorbe el trabajo extra. Absorber el desperdicio sigue teniendo un coste; simplemente no se nota a simple vista.
Por qué las agencias deberían abordar esto antes de que los clientes se den cuenta
Las agencias suelen enterarse del tráfico de bots cuando ya ha creado un problema visible. Un cliente nota un mayor consumo de alojamiento, pantallas de administración más lentas, retrasos en el proceso de pago, patrones de tráfico inusuales o estadísticas que ya no coinciden con sus resultados empresariales. Llegados a ese punto, la conversación ya es reactiva. La agencia tiene que explicar qué ha pasado, por qué es importante y qué cambios hay que hacer.
El tráfico de bots permite a las agencias mantener una conversación proactiva.
No hace falta que el enfoque sea alarmista. Puede ser muy práctico:
- «Puede que tu sitio funcione bien, pero es posible que parte de ese tráfico no provenga de visitantes reales».
- «Hay bots que son útiles, como los rastreadores de búsqueda o las herramientas de monitorización, pero otros solo consumen recursos».
- «Podemos reducir el desperdicio sin afectar al tráfico que realmente importa».
- «Hacerlo bien protege el margen de rendimiento y ayuda a que el uso sea predecible».
Esto vincula la gestión de bots con las preocupaciones que los clientes ya comprenden: coste, eficiencia y fiabilidad. Además, reposiciona a la agencia, pasando de ser un solucionador de problemas reactivo a un asesor proactivo en materia de infraestructura, lo que supone una relación más duradera.
El objetivo no es bloquear todos los bots
Es importante tener en cuenta que no todo el tráfico de bots es malo. Los rastreadores de búsqueda ayudan a que las páginas aparezcan en los resultados de búsqueda. Las herramientas de monitorización comprueban el tiempo de actividad. Las plataformas de SEO auditan las páginas. Los proveedores de pagos, las integraciones, las API y las automatizaciones de WordPress también pueden necesitar acceder al sitio para realizar su trabajo legítimo.
Los rastreadores de IA son más complicados. Puede que algunos propietarios de sitios web quieran aparecer en experiencias basadas en IA. Otros pueden pensar que el rastreo con IA genera más gastos que beneficios, sobre todo cuando rastrea grandes bibliotecas de contenido sin aportar a cambio un tráfico de referencia significativo.
Por eso, el objetivo no es bloquear todas las solicitudes automatizadas. Bloquear en exceso puede causar problemas de SEO, romper integraciones, interrumpir la monitorización o interferir en los flujos de trabajo normales de WordPress.
Es mejor optar por un control selectivo:
- Deja pasar el tráfico útil
- Bloquea la automatización claramente innecesaria
- Analiza el tráfico sospechoso
- Protege las rutas de alto coste
- Monitoriza los resultados
Esto les da a los equipos más control sin tratar a todos los bots por igual. La idea es reducir el desperdicio sin dejar de mantener el tráfico, las herramientas y los flujos de trabajo que siguen siendo útiles para el negocio.
Cómo funciona en la práctica la Protección contra Bots de Kinsta
Cuando el tráfico de bots se convierte en un problema de infraestructura, la respuesta tiene que adaptarse a la situación real del sitio.
La Protección contra Bots de MyKinsta está diseñada teniendo en cuenta esa variabilidad. Está incluida en todos los planes sin coste adicional, funciona a nivel de entorno y entra en vigor de inmediato cuando cambias la configuración.
Niveles de protección
Ve a Sitios > nombre del sitio > Protección contra bots > Cambiar para elegir entre cuatro niveles preestablecidos, cada uno de los cuales se aplica de forma independiente por entorno, de modo que los entornos de staging, desarrollo y producción puedan utilizar configuraciones diferentes.
- Bloquea el tráfico malicioso — es la configuración predeterminada en todos los sitios. Se encarga de mitigar los ataques DDoS y bloquea las direcciones IP y los endpoints relacionados con patrones de ataque conocidos. Todos los sitios de Kinsta ya tienen esta función activada.
- Automatizaciones de bloqueo — el punto de partida recomendado para la mayoría de las webs que sufren tráfico de bots. Bloquea el tráfico automatizado y malicioso confirmado, al tiempo que deja pasar a los bots verificados y a los visitantes reales. Es eficaz para las webs que reciben visitas repetitivas en URLs dinámicas y no quieren restringir el tráfico de usuarios reales.
- Desafía a los bots — añade un paso de verificación para los posibles bots y el tráfico no clasificado. Un visitante que supere el desafío no volverá a ser desafiado durante diez días desde el mismo navegador e IP. Útil durante picos de tráfico, campañas de rebajas o períodos de scraping intensivo, en los que hay que ajustar con mayor precisión el equilibrio entre el bloqueo y la fricción.
- Desafiar a todos — la configuración más estricta, diseñada para un uso a corto plazo durante un ataque activo o un abuso continuado. Se desafía todo el tráfico no verificado, incluidos los que probablemente sean humanos. No es una configuración permanente.
Antes de elevar el nivel por encima de Bloquear tráfico malicioso, comprueba que tus integraciones críticas para el negocio aparezcan en el directorio de bots verificados de Cloudflare. En el nivel Desafiar a los bots o superior, cualquier herramienta que se conecte a tu sitio de forma programada y que no esté verificada será sometida a un desafío o bloqueada.
Bloquear rastreadores de IA
El botón Bloquear rastreadores de IA es un control independiente del nivel de protección. Se centra específicamente en los rastreadores de IA, incluidos los verificados como GPTBot, sin afectar a Googlebot ni a Bingbot. La indexación de tus búsquedas sigue con normalidad.
En el caso de sitios web con mucho contenido, editoriales, bibliotecas de documentación y plataformas de contenido premium en las que los rastreadores de IA acceden repetidamente a páginas de artículos, páginas de archivo y recursos no almacenados en caché en grandes cantidades, esta opción elimina esa carga sin afectar a la visibilidad en las búsquedas.
La disyuntiva es real y vale la pena mencionarla: bloquear los rastreadores de IA reduce la frecuencia con la que tu contenido aparece en las respuestas y resúmenes generados por IA. Para los sitios en los que la visibilidad en la IA es una prioridad estratégica, quizá te convenga más optar por Bloquear automatizaciones o Desafiar a los bots, ya que filtran los comportamientos más problemáticos sin dejar de ser indexables. Para los sitios en los que el coste de los recursos del servidor y el uso del plan importan más que la visibilidad en la IA, bloquear es la opción más clara.
Permitir las automatizaciones típicas de WordPress
Cuando subas el nivel de protección por encima del predeterminado, activa al mismo tiempo la opción Permitir automatizaciones típicas de WordPress.
Esto activa una lista blanca gestionada de rutas y servicios habituales de WordPress, como las solicitudes de la API REST, las rutas de WooCommerce, las tareas en segundo plano, los trabajos programados y las integraciones de plugins, para que un filtrado más estricto de los bots no interrumpa sin que te des cuenta los flujos de trabajo de los que depende tu sitio.
Actívalo cada vez que pases a Bloquear automatizaciones o a un nivel superior. El objetivo es reducir el tráfico innecesario, no interrumpir las operaciones legítimas.
Permitir siempre
Hay algunos servicios que nunca deben ser bloqueados, independientemente del nivel de protección. La sección «Permitir siempre» te permite añadir hasta 50 excepciones personalizadas por dirección IP, ruta URL o agente de usuario.
Úsalo para:
- Webhooks de proveedores de pago (Stripe, PayPal)
- Servicios de monitorización de confianza (UptimeRobot, Pingdom)
- Integraciones con socios conocidos o usuarios de la API
- Rangos de direcciones IP de desarrolladores u oficinas
- Rutas específicas de WordPress como /wp-json/* o /wp-admin/admin-ajax.php, si aún no están incluidas en la lista de permitidos de las automatizaciones de WordPress
Solicitar el desglose y los resultados de la Protección contra Bots
Es difícil optimizar el tráfico de bots cuando los equipos no pueden ver cómo se clasifican o gestionan las solicitudes.
Antes de ajustar cualquier configuración, echa un vistazo primero a la pantalla de Protección contra Bots. El gráfico de desglose de solicitudes muestra todas las solicitudes realizadas a tu sitio en las últimas 24 horas, clasificadas en siete categorías: Probablemente humanos, Bots verificados, Probablemente bots, Rastreadores de IA, Rastreadores de IA con frecuencia excesiva, Tráfico sin clasificar y Tráfico automatizado.
La pregunta ha cambiado
El alojamiento web siempre se ha evaluado en función de una breve lista de resultados visibles: ¿El sitio está online? ¿Se carga rápido? ¿Pueden los visitantes hacer lo que han venido a hacer?
Esas preguntas siguen siendo importantes. Pero ya no cuentan toda la historia.
Un sitio puede seguir online aunque esté malgastando ancho de banda. Puede cargarse rápido mientras los bots consumen los hilos de PHP y las conexiones a la base de datos que necesitan los visitantes reales. Puede pasar una prueba de velocidad un martes por la tarde y luego colapsarse bajo la carga del lanzamiento de una campaña el jueves, porque el margen que debería haber estado disponible ya se había gastado procesando tráfico que nunca ayudó al negocio.
La pregunta ya no es solo «¿Puede el sitio web soportar la carga?», sino «¿Qué parte de esa carga debería soportar el sitio web?».
El tráfico de bots no tiene por qué dejar tu sitio offline para que te salga caro. Solo tiene que seguir accediendo a las rutas que requieren un procesamiento real y hacerlo con un volumen que, en todos los paneles de control, parezca actividad normal.
Conseguir visibilidad sobre ese tráfico y disponer de los controles necesarios para actuar en función de lo que ves es lo que cambia la situación. No puedes gestionar lo que no ves, y tampoco puedes actuar en función de lo que ves si tus únicas opciones son bloquearlo todo o dejarlo tal cual.
Para los equipos de WordPress que gestionan sitios web con mucho contenido, tiendas de WooCommerce o grandes portfolios de clientes, el alojamiento administrado para WordPress de Kinsta pone esos controles en MyKinsta, sin coste adicional, y se pueden ajustar por entorno sin necesidad de abrir un ticket de soporte. Empieza con el Informe de tráfico de IA y bots para tener una visión completa de lo que está afectando a la infraestructura de WordPress y cuánto cuesta.
