El Retorno del 402 Payment Required: Qué Revelan los Códigos de Estado HTTP Sobre el Tráfico de Bots
Los códigos de estado HTTP llevan más señal de la que aprovechan la mayoría de las herramientas de analítica. Así ayuda el análisis de estado en el servidor a separar humanos de bots sin rastrear a nadie.
La mayoría de las decisiones de analítica web ocurren en el lado del cliente, después de que la página ha cargado y el JavaScript se ha ejecutado. Ese modelo asume, silenciosamente, que toda solicitud que llega a tu servidor merece ser contada. No es así. Una gran parte del tráfico bruto nunca renderiza nada, nunca pertenece a un humano y nunca debería llegar a tus paneles. La señal más clara y temprana para filtrarlo es algo que ya generas en cada solicitud: el código de estado HTTP.
Los códigos de estado son una señal de analítica de primer nivel
La especificación de semántica HTTP (RFC 9110) define los códigos de estado como un entero de tres dígitos que describe el resultado de una solicitud, agrupados en cinco clases: 1xx informativo, 2xx éxito, 3xx redirección, 4xx error de cliente y 5xx error de servidor. Como Monoid se ejecuta en el edge de Cloudflare, vemos el código de estado que el origen (o el propio edge) devuelve antes de que se ejecute cualquier script del cliente. Ese orden importa. Una vista de página registrada por un beacon del navegador solo puede existir si el documento realmente se sirvió con un 2xx y se analizó. Pero el flujo de solicitudes incluye mucho más que documentos exitosos.
Considera lo que un origen típico devuelve a lo largo de un día: documentos HTML exitosos, respuestas 304 Not Modified a solicitudes condicionales, redirecciones 301/308 por canonicalización, 404s de escáneres en sondeo y ráfagas de 5xx durante incidentes. Contar solo los documentos renderizados con éxito e ignorar el resto descarta contexto que explica anomalías en tu curva de tráfico.
Dónde se esconden los bots en la distribución de estados
Los clientes automatizados se comportan de forma distinta a los navegadores, y los códigos de estado exponen esa diferencia a bajo costo. Los escáneres de vulnerabilidades generan agrupaciones densas de respuestas 404 y 403 al sondear paneles de administración y rutas conocidas de CMS. Los rastreadores agresivos ignoran el 429 Too Many Requests —definido en la RFC 6585 como la respuesta para la limitación de tasa— y siguen insistiendo, produciendo una firma que ninguna sesión humana genera. Los scrapers ingenuos suelen seguir cadenas de redirección que un navegador real cortaría mediante bfcache o historial.
El código 402 Payment Required resulta instructivo aquí. La RFC 9110 señala explícitamente que está reservado para uso futuro y no tiene semántica estandarizada, pero recientemente ha recibido atención renovada para el acceso medido a APIs y agentes. Si tu origen empieza a emitir 402s, ese tráfico es casi con certeza programático, no una persona navegando. Un pipeline consciente del estado puede etiquetarlo en consecuencia en lugar de inflar silenciosamente una métrica.
Por qué la analítica solo de cliente se equivoca aquí
Una herramienta solo en JavaScript literalmente no puede observar la mayor parte de esto. Si una solicitud devuelve 403, no se ejecuta ningún script de analítica, así que el evento es invisible —pero la carga sobre tu infraestructura es real, y la intención detrás de ella (reconocimiento, credential stuffing, scraping) suele ser justo lo que quieres saber. Por el contrario, las herramientas que cuentan líneas de log del servidor sin discriminar por estado sobreestiman, tratando cada salto 301 y cada sondeo 404 como un "hit".
El punto medio útil es la clasificación de estado a nivel de edge alimentando un modelo de conteo privacy-first:
- 2xx text/html con una navegación real es una vista de página candidata.
- 3xx debe atribuirse al destino, no contarse dos veces.
- 4xx es diagnóstico, no audiencia —muéstralo por separado.
- 5xx pertenece a un panel de fiabilidad, correlacionado con cualquier caída en vistas exitosas.
Cómo hacer esto sin rastrear a nadie
Nada de esto requiere identificar a un visitante. El código de estado, el método, la clase de respuesta y una temporización gruesa son propiedades del intercambio solicitud-respuesta, no de una persona. Monoid nunca establece cookies, nunca lee localStorage y nunca hace fingerprinting de dispositivos. No necesitamos un identificador estable para saber que una ráfaga de 429s a las 03:00 UTC vino de automatización y no de una audiencia —la distribución de estados lo dice por sí sola. Esto es la minimización de datos jugando a nuestro favor: la señal menos personal también es una de las más honestas para la calidad del tráfico.
También hay un beneficio de cumplimiento. Filtrar el tráfico no humano en el edge significa que entran menos eventos espurios al almacén de analítica, manteniendo los datos registrados más ajustados a su finalidad declarada. Bajo los principios de limitación del almacenamiento y limitación de la finalidad del GDPR (Artículos 5(1)(c) y 5(1)(e)), no recolectar basura es estrictamente mejor que recolectarla y luego descartarla.
Conclusiones prácticas
Si construyes o evalúas analítica, haz tres preguntas. ¿Ve el código de estado, o solo documentos renderizados? ¿Separa las señales de fiabilidad (5xx) de las señales de audiencia (2xx)? ¿Y logra filtrar bots sin un identificador? Un pipeline que responda sí a las tres te da números más limpios y una superficie de privacidad más pequeña al mismo tiempo —que, por una vez, son la misma decisión.
Comments
Loading comments…