El tráfico de bots suele considerarse un problema de seguridad o de SEO. Pero en la infraestructura de alojamiento para WordPress, se manifiesta como un problema de rendimiento, concretamente uno que se concentra en un conjunto muy concreto de URLs.
No todas las solicitudes son iguales. La diferencia entre una página estática almacenada en la caché y un endpoint dinámico no es solo una pequeña diferencia de rendimiento. Es la diferencia entre una solicitud que casi no cuesta nada y otra que reserva un hilo de PHP, activa una consulta completa a la base de datos y genera una sobrecarga de sesión, independientemente de si el visitante es un cliente real o un bot que nunca convierte.
Entender por qué algunos endpoints son mucho más caros que otros es lo que distingue una estrategia de gestión de bots que realmente funciona de otra que bloquea demasiado o demasiado poco.
No todas las peticiones son iguales
Cuando un visitante accede a una página típica de WordPress, como una entrada de blog, una lista de productos o una página de «Acerca de», el servidor casi siempre sirve esa respuesta desde la caché.
La caché de página completa de Kinsta se encarga de esto en el edge, por lo que la solicitud nunca activa el PHP del servidor ni su base de datos.
Pero cuando una solicitud llega a un endpoint que no se puede almacenar en caché, el servidor tiene que ponerse manos a la obra. Se asigna un hilo PHP que se mantiene activo durante toda la solicitud, y se consulta la base de datos. Si la página incluye el estado del carrito, sesiones de usuario o contenido personalizado, la gestión de sesiones añade otra capa. Nada de esto se puede almacenar en caché, porque la respuesta es única para cada solicitud.
En un sitio web que funciona bien y con visitantes principalmente humanos, esto está bien. Tus endpoints dinámicos atienden a clientes reales que añaden artículos a su carrito, realizan el pago y buscan productos. La carga es proporcional al uso real.
El tráfico de bots rompe este modelo. Un rastreador no añade productos al carrito ni realiza conversiones, pero activa la misma secuencia de acciones en el servidor de la misma forma que lo haría un cliente real, a un ritmo que ningún humano podría mantener.
Los endpoints concretos en los que esto afecta
En una tienda de WooCommerce, los siguientes patrones de URL y endpoints no se pueden almacenar en caché por diseño, y son precisamente los que suelen recibir más tráfico de bots.
?add-to-cart=
Este es el ejemplo que más recursos consume de todos los que hemos documentado en nuestro informe sobre tráfico de IA y bots. Añadir un producto al carrito requiere la ejecución de PHP, una escritura en la base de datos y la creación o validación de una sesión. No hay una versión en caché de esta respuesta, ya que cada solicitud supone trabajo nuevo.
Para que te hagas una idea de la magnitud: los datos de la infraestructura de Kinsta registraron en una ocasión 7,67 millones de visitas de añadir al carrito procedentes de cinco bots en un periodo de 24 horas.
Eso supone más o menos una solicitud cada 11 milisegundos, día y noche, cada una de las cuales requiere la ejecución completa de PHP y la base de datos, ninguna genera información útil para el rastreador y ninguna atiende a un cliente.
/cart and /checkout
Estas páginas están excluidas de la caché de páginas por defecto en WooCommerce. Contienen datos de sesión en tiempo real, el estado personalizado del carrito y (en el caso de checkout) la lógica de procesamiento del pago.
Un bot que pulsa /checkout una y otra vez no está haciendo nada útil, pero el servidor no lo sabe. Procesa cada solicitud como si fuera una transacción real.
?s= (Search queries)
Las consultas de búsqueda de WordPress y WooCommerce se ejecutan en tu base de datos con cada solicitud. No hay ninguna capa de caché que pueda almacenar una cadena de búsqueda concreta.
Un rastreador que recorre variaciones de URL parametrizadas o que simplemente sigue todos los enlaces de búsqueda que encuentra puede generar una larga serie de consultas únicas y costosas a la base de datos.
Navegación por facetas y parámetros de filtro
Aquí es donde el problema se agrava. Un catálogo de productos típico de WooCommerce genera URLs como:
/shop/?color=blue
/shop/?color=blue&size=M
/shop/?color=blue&size=M&orderby=price
/shop/?color=blue&size=M&orderby=price&paged=2Para una persona, se trata de pequeñas variaciones de la misma página. Para un bot que sigue enlaces, cada uno es una URL única que merece la pena rastrear, y cada uno obliga al servidor a ejecutar una consulta filtrada en la base de datos desde cero.
La documentación de Google señala explícitamente que la navegación por facetas es una fuente de ineficiencia en el rastreo, ya que los rastreadores exploran variaciones casi infinitas del mismo contenido. Pero el problema no es solo que esto desperdicie el presupuesto de rastreo. Cada variación consume recursos reales del servidor para generarse.
Interacciones basadas en AJAX
Muchos plugins de WordPress, como las listas de deseos, las comprobaciones de disponibilidad, las actualizaciones de precios en tiempo real y las vistas de calendario, se basan en peticiones AJAX que eluden por completo la caché de la página.
Un bot que activa estas interacciones, aunque sea de forma indirecta al cargar una página que las desencadena, genera una carga en el servidor que no aparece como una «solicitud de página» en tus analíticas, pero sí se refleja en el uso de hilos de PHP.
Qué ocurre cuando se agotan los hilos PHP
Cada vez que se accede a un endpoint dinámico, se ocupa un hilo PHP durante toda la duración de esa solicitud. Este detalle puede parecer insignificante por sí solo, pero la capacidad de los hilos es finita, y los bots no esperan pacientemente en la cola.
Kinsta asigna un número fijo de hilos PHP por cada sitio de WordPress, y cada solicitud no almacenada en la caché reserva uno durante todo el tiempo que dura.
En condiciones normales de tráfico, esto rara vez supone un problema. Las solicitudes llegan, se procesan rápidamente y los hilos se liberan.
Cuando hay una carga constante de bots en los endpoints dinámicos, los hilos se reservan y se mantienen ocupados. Cuando todos los hilos están ocupados, las nuevas solicitudes que llegan quedan en espera en una cola. Los clientes reales que intentan añadir un producto a su carrito o completar el proceso de pago se encuentran con cargas de página lentas, tiempos de espera agotados o errores HTTP 504.
Esta es la realidad en cuanto a la infraestructura que hace que el tráfico de bots en endpoints dinámicos sea sustancialmente diferente del tráfico de bots en páginas almacenables en caché.
El problema del bucle: Cuando los bots se atascan
Gran parte del tráfico de bots que detecta el equipo de infraestructura de Kinsta no es fruto de un ataque intencionado. Se debe a que los rastreadores siguen todos los enlaces de cada página sin ningún mecanismo que les permita darse cuenta de que están dando vueltas en círculo.
Así es como se ve un bucle de cadena de consulta en la práctica:
- Un bot llega a
/shop/ - La página contiene un enlace a
/shop/?color=blue(una vista filtrada) - Esa página contiene un enlace a
/shop/?color=blue&size=M - Esa página contiene un enlace a
/shop/?color=blue&size=M&orderby=price - Esa página contiene un enlace para añadir algo al carrito:
/shop/?add-to-cart=123 - Cada una de ellas genera enlaces ligeramente diferentes que el bot aún no ha visitado
El bot va detrás de todos. No tiene ni idea de que «ya he visto esta página de producto con un filtro diferente». Cada URL le parece nueva, la solicita y llega al servidor como si fuera la primera vez.
Este patrón concreto de bots que recorren variaciones de cadenas de consulta en endpoints dinámicos es uno de los problemas más comunes que detectamos en nuestro informe. Una sola regla de bucle activada por un patrón anómalo filtró 550 millones de solicitudes en 30 días en la infraestructura de Kinsta. No se trata de un ataque, sino de una automatización ineficaz a gran escala, que se agravó porque nadie lo detectó a tiempo.
Cómo es una buena gestión de bots a nivel de los endpoint
Para las tiendas de WooCommerce y los sitios de WordPress con funcionalidad dinámica, hay algunos principios que son válidos independientemente de tu configuración específica.
- Robots.txt es una señal, no un escudo. Puedes (y debes) prohibir el acceso de rastreadores a las rutas
/cart,/checkouty?add-to-cart=en turobots.txt. Googlebot lo respeta. Sin embargo, el cumplimiento delrobots.txtes voluntario. Una parte cada vez mayor de los rastreadores de entrenamiento de IA no lo comprueban o no lo respetan. No permitir una ruta enrobots.txtcomunica tu intención; hacerla cumplir requiere una regla de nivel WAF. - Refuerza la generación de parámetros de URL. La configuración predeterminada de WooCommerce genera una larga cola de variantes de URL a través de tokens de sesión, parámetros de cantidad y combinaciones de filtros. Reducir la proliferación de parámetros en el origen mediante etiquetas canónicas, estructuras de permalink consolidadas y reglas
Disallowen robots.txt sobre variantes de parámetros reduce el número de bucles en los que se atascan los rastreadores. - Monitoriza a nivel de endpoint, no solo el volumen total de solicitudes. Un pico en el tráfico general podría deberse a una campaña. Un pico en las solicitudes a
?add-to-cart=procedentes de un agente de usuario que no sea un navegador es un problema de bots. Los registros del servidor y las herramientas de analítica que muestran la distribución de las solicitudes por patrón de URL y agente de usuario marcan la diferencia entre detectar esto en cuestión de horas o de días. - Protege la capacidad de los hilos de PHP como métrica principal. Si tus hilos de PHP funcionan habitualmente al límite de su capacidad y no se produce un aumento correspondiente en las sesiones de usuarios reales, es casi seguro que el tráfico de bots en los endpoints dinámicos es un factor que contribuye a ello. La herramienta APM de Kinsta muestra las transacciones PHP más lentas por endpoint, así que, si el problema está en el carrito o en el proceso de pago, lo verás directamente en lugar de tener que adivinarlo.
Cómo se ve esto en los distintos tipos de sitios
El problema de los endpoints dinámicos es más grave en las tiendas de WooCommerce, pero se da en distintos tipos de sitios web de diversas formas.
- Las tiendas de WooCommerce corren el mayor riesgo porque sus endpoint más importantes, como el carrito, la página de pago y las páginas de productos filtrados, son precisamente las que los bots suelen encontrar al seguir enlaces de forma habitual. Las consecuencias son directas: el agotamiento de los hilos PHP durante los picos de actividad de los bots empeora el rendimiento del proceso de pago para los clientes reales.
- Los sitios de contenido y los blogs están menos expuestos en lo que respecta al pago, pero pueden verse afectados significativamente por los bots que rastrean archivos paginados, páginas de etiquetas y resultados de búsqueda. Cada consulta de búsqueda única supone una nueva consulta a la base de datos. Un rastreador agresivo que recorra sistemáticamente un archivo de gran tamaño puede generar una carga sostenida en la base de datos, incluso sin tocar ninguna función de la «tienda».
- Los sitios web de empresas y servicios están más expuestos en los endpoints de los formularios (formularios de contacto, de solicitud de presupuestos y de reserva), que implican la gestión de sesiones y, a menudo, escrituras en la base de datos. Los datos de formularios enviados por bots suponen un problema distinto (contaminación del CRM, esfuerzo comercial desperdiciado), pero el mecanismo subyacente es el mismo: endpoints dinámicos que consumen recursos reales con cada visita.
- Las aplicaciones web y los productos SaaS son el caso más delicado. Sus endpoints API, rutas de paneles de control y lógica de aplicación no se pueden almacenar en caché en absoluto, y cualquier tráfico de bots que llegue a la capa de aplicación elude por completo la infraestructura de caché. La respuesta adecuada en este caso suele ser un bloqueo total de todo el tráfico no autenticado hacia las rutas
/apiy/app, con una lista de permitidos explícita para las integraciones legítimas.
Profundizando: todo lo que hay que saber sobre el tráfico de bots
El problema de los endpoints dinámicos forma parte de un cambio más amplio en la forma en que el tráfico de bots afecta a la infraestructura de WordPress. Los rastreadores basados en IA han aumentado considerablemente en volumen y han cambiado de comportamiento: siguen los enlaces de forma más agresiva, son más propensos a ignorar las directivas de rastreo y generan más tráfico precisamente en los endpoints cuyo servicio resulta más costoso.
Si quieres conocer al detalle qué ha cambiado, los datos que lo respaldan y un framework para tomar decisiones sobre la gestión de bots en función del tipo de sitio web y tus prioridades, el informe completo de Kinsta sobre La realidad del tráfico de bots y la IA lo explica todo, incluyendo un análisis de más de 10.000 millones de solicitudes en la infraestructura administrada por Kinsta.
Si estás listo para poner en práctica lo que has leído aquí, la protección contra bots de Kinsta se encarga automáticamente de los patrones más comunes, incluida la protección de endpoints dinámicos de alto coste. Activa el nivel de protección que desees en MyKinsta y el sistema se encargará del resto.
También puedes ponerte en contacto con el equipo de soporte si necesitas alguna aclaración.
