El 20% de todas las respuestas web «Ok» que recibe la IA no son correctas

Mis recientes experimentos con la extracción de datos web asistida por IA me han hecho ver hasta qué punto la web se está volviendo cada vez más «cerrada». El motivo de este repliegue, por supuesto, es el crecimiento espectacular de la extracción de datos web mediante IA, cuya demanda implacable de nuevos datos puede acabar dejando sitios web fuera de servicio.

Esto da a los dominios una buena excusa para hacer lo que muchos llevan tiempo queriendo: permitir el acceso a su contenido solo cuando el usuario haya iniciado sesión (aunque, naturalmente, Googlebot suele tener vía libre). Facebook completó la adopción gradual de esta política en 2023, y Twitter/X hizo lo mismo ese mismo año. Reddit la adoptará más adelante este mes.

De este modo, al dominio le resulta algo más fácil cumplir con las normas específicas de cada país sobre la aplicación de restricciones de edad, ya que el usuario ya está registrado. Y, lo que es más importante, los datos del usuario pueden guardarse, utilizarse para análisis locales y, si la legislación local lo permite, venderse a intermediarios de datos y empresas de IA.

Por otra parte, las medidas dirigidas específicamente a defenderse de los bots (en lugar de registrar usuarios) han aumentado más de un 58 % interanual, según Cloudflare; y toda esa creciente actividad de bots lleva naturalmente a los sitios web a examinar con mayor atención las direcciones de VPN y proxy, con la posibilidad de denegar el acceso a usuarios legítimos, junto con el tráfico «malicioso».

La parte anecdótica de esto es que parece que cada vez me encuentro más con respuestas de «bloqueo» o desafíos, hasta el punto de que incluso podría abandonar un sitio que empieza a mostrármelos; y, dado que se ha demostrado que los muros CAPTCHA disuaden a usuarios y posibles clientes, cabe imaginar la presión que lleva a los propietarios de dominios a implementarlos pese a ese inconveniente.

Un CAPTCHA de archive.is, uno de los muchos sitios que han adoptado los desafíos, a menudo como respuesta a un número excesivo de solicitudes automatizadas (en lugar de humanas).

Esta nueva fricción, cada vez mayor, responde en parte a motivos logísticos (porque no todos los dominios pueden resistir la avalancha), pero a menudo también es una especie de táctica de negociación para averiguar si las empresas de IA ofrecerán una remuneración única o colectiva por todos esos datos que tanto ansían y que, hasta ahora, habían sido gratuitos durante mucho tiempo.

Como los rastreadores de IA tienen que operar a gran escala, suelen utilizar instancias «sin interfaz» de Chrome con el marco de trabajo Playwright. Hoy en día, en un número cada vez mayor de dominios, eso devuelve un error 403 («prohibido»; es decir, el servidor sabe que eres tráfico automatizado y te manda a paseo):

Una instalación local de changedetection.io intenta consultar un sitio, pero al sitio no le gusta el navegador detectado que utiliza el marco de trabajo y devuelve una respuesta 403 («Prohibido»).

Lo que se busca es la respuesta de cliente «200» («Correcto»), aunque para conseguirla haya que desembolsar una suma considerable a una red de proxies residenciales, además de recurrir a otros trucos variados y furtivos no humanos.

No hay nada mejor que una respuesta 200; es decir, no existe ningún código de respuesta de cliente con una señal positiva más fuerte. Tampoco es una respuesta ambigua: nunca significa «casi bien», «estará bien más adelante» ni «cada vez está mejor»; significa «¡bien!». Si no está bien, no es una respuesta 200.

¡Hola! Fuera de aquí

Sin embargo, según un nuevo artículo, esta falta de granularidad podría distorsionar considerablemente los conjuntos de datos de IA, las estimaciones estadísticas y la notificación de estados «correctos» cuando no lo son.

El estudio* calcula que alrededor de una quinta parte de las respuestas de la categoría 200 no contienen ningún contenido de página utilizable, sino que muestran estructuras vacías de sitios web, desafíos CAPTCHA, restricciones de acceso o páginas sustitutivas.

El artículo afirma:

«El 20,9 % de las páginas que recibe un cliente estático con estado 200 no contiene el contenido principal de la página: estructuras de aplicaciones, desafíos contra bots, páginas de bloqueo, páginas de error y de marcador de posición, y contenido parcial».

En este sentido, los sistemas automatizados impacientes tropiezan con sus propias limitaciones, ya que se permite equiparar la respuesta «200» con una obtención satisfactoria, incluso cuando la consulta solo devuelve un muro CAPTCHA, un muro de pago u otro obstáculo.

El artículo describe los siete tipos de contenido que suelen complicar una respuesta 200:

Las siete categorías de contenido que no tienen nada de «correcto» en una respuesta 200. Fuente

Durante tres días, el estudio puso a prueba 10.307 direcciones web con un programa básico de recuperación web y un navegador capaz de cargar JavaScript. Las respuestas se clasificaron según el contenido recuperado, no según sus códigos de estado HTTP.

Las categorías más numerosas de respuestas 202 «inservibles» fueron las estructuras vacías de sitios web y las páginas de error o sustitución, que en conjunto representaron más de dos tercios de los fallos.

En el caso de las estructuras vacías de sitios web, un sitio puede mostrar sus menús y elementos de navegación, pero dejar en blanco el artículo o la lista de productos solicitados; en este último caso, puede aparecer una página no relacionada o la página de inicio en lugar del contenido solicitado. Sin embargo, ambas situaciones pueden recibir el mismo estado HTTP 200 que una recuperación correcta con contenido útil y aprovechable.

Como posible solución, el artículo recomienda que las herramientas de recuperación web informen de lo que realmente se recuperó, en vez de basarse en los códigos de estado HTTP, ya que unas comprobaciones sencillas de páginas inusualmente cortas, redirecciones sospechosas y contenido parecido al de páginas inexistentes podrían detectar la mayoría de los fallos.

Después, podrían utilizarse herramientas de navegación más exigentes en recursos solo cuando parezca que una página no se ha cargado correctamente. Además, las evaluaciones de IA podrían comprobar si las fuentes citadas contienen realmente la información esperada, en lugar de dar por hecho que una respuesta HTTP 200 significa que el contenido se recuperó correctamente.

El autor del nuevo trabajo también señala que unas «heurísticas baratas» pueden identificar fácilmente alrededor del 86 % de las respuestas inservibles mediante comprobaciones básicas de la longitud de las páginas, las redirecciones y las similitudes con páginas inexistentes:

Comparación de estrategias de recuperación web: renderizar únicamente las páginas señaladas como sospechosas permitió recuperar un poco más de contenido aprovechable (81,4 %) que renderizar todas las páginas (80,3 %), y redujo el tiempo medio de recuperación de 20,6 a 5,8 segundos por página. 

¿Por qué hay tantas respuestas 200 erróneas?

Desde hace años, en las comunidades de desarrolladores ha habido cierto debate sobre si el error 202 («Aceptado») («Solicitud aceptada, pero aún no completada») podría servir para distinguir estas solicitudes «fallidas» con estado 200. Sin embargo, en realidad, el 202 no abarca todos los casos descritos en el nuevo artículo, y no existe ningún código que pueda hacerlo.

Aunque el artículo no aborda el tema en profundidad, quizá valga la pena investigar más adelante, en trabajos relacionados, por qué los propietarios de dominios permiten errores 200.

Una posible razón es que cualquier respuesta que no sea un 200 constituye, en esencia, algún tipo de página de error u obstáculo, incluidos los errores más comunes, los 404 («no encontrado»), en los que el contenido buscado simplemente no está. Algunos usuarios creen que un exceso de estos errores puede acarrear penalizaciones en SEO (y, presumiblemente, en GEO), aunque Google lo niega.

De hecho, Google considera que los errores 200 erróneos son errores 404 «blandos» y, claramente, es probable que los trate como un problema mayor que los errores 404 comunes, porque, en esencia, son resultados «engañosos», intencionados o no.

Deriva de citas

Si todo esto parece una discusión puntillosa, hay que tener en cuenta la escala de petabytes de los datos que se recopilan habitualmente (o se intenta recopilar) para entrenar modelos de IA. Si una quinta parte de esos datos es poco fiable o directamente engañosa, es difícil restar importancia a las consecuencias posteriores y considerarlas una especie de «imprecisión colateral»; por el contrario, esas respuestas falsas podrían afectar de forma significativa y perjudicial a la distribución de los conjuntos de datos y a los resultados del entrenamiento de modelos de IA con esos datos.

Por ejemplo, un problema destacado relacionado con las respuestas 200 erróneas es la «deriva de citas»: una respuesta generada por IA deja de estar respaldada por la página web citada originalmente como prueba. Es decir, es posible que la página haya cambiado, que se haya eliminado el texto pertinente o que el enlace ahora lleve a otro sitio.

El nuevo estudio descubrió que la aparente deriva de citas aumentó del 5,8 % al 21,9 % cuando todas las respuestas HTTP 200 se aceptaron como recuperaciones correctas, sin importar lo que contuvieran.

Esto significa que podría juzgarse erróneamente que una fuente ha cambiado, desaparecido o dejado de respaldar una afirmación generada por IA, simplemente porque, en lugar del material original, se recuperó un CAPTCHA, una página vacía u otro obstáculo.

¡Basta con decir que sí!

El problema también quedó demostrado en pruebas con direcciones web deliberadamente inexistentes. Cuando se solicitaron rutas aleatorias inventadas en sitios web, el 13,1 % de los que respondieron devolvió un estado 200 («OK»), aunque las páginas solicitadas no existían^†.

«El 13,1 % de los sitios que respondieron a la prueba de rutas aleatorias devolvió un estado 200 (S1: 10,5 %, S2: 13,3 %, S3: 17,3 %, S4: 13,7 %, S5: 13,1 %). Por definición, todas estas respuestas son errores 404 blandos, pero no todas lo indican.»

«En un análisis exploratorio de las 172 respuestas de error 404 suave, quien etiquetó los datos clasificó 98 como errores o páginas sustitutivas, 32 como estructuras vacías y 28 como contenido: una página de inicio o un listado servido en una ruta aleatoria parece una página normal».

Conclusión

Si el problema se reconociera en un nivel superior, la IANA podría, en teoría, crear un nuevo código de estado HTTP más adecuado, como [X] («La solicitud se completó correctamente, pero no se entregó el contenido solicitado»). Aunque esto describiría realmente lo que está ocurriendo, naturalmente requeriría un grado de comprensión de la transacción por parte del host que resulta poco probable.

Ya existen códigos similares, aunque ninguno encaja del todo: el 451 («No disponible por razones legales») es ambiguo y bastante alarmante (!); el 206 («Contenido parcial») es técnicamente adecuado, pero está pensado para datos incompletos (recuperaciones); y el sorprendente 203 («Información no autoritativa»), que fue creado en 1997 y solo guarda una relación periférica con el caso de uso en cuestión.

Quizá el candidato más cercano sea, en realidad, el 103 («Avisos preliminares»), cuyo nombre resulta poco intuitivo y que indica que aún no se han cargado todos los recursos de la URL (aunque esto sería claramente una interpretación muy errónea de la intención del código).

* Titulado «Cuando 200 OK no es una respuesta: fallos silenciosos de recuperación en la adquisición de contenido web agéntico». Tenga en cuenta que el artículo está escrito, al parecer, principalmente para que lo lean máquinas, quizá para que lo consulte una IA, y que no es fácil de leer por sí mismo.

^†Disculpen la cita mecanicista, pero todo el artículo está escrito de esta manera, como señalo arriba, para que sea «legible por máquinas» y no interpretable por seres humanos, aunque no llega a presentarse en formato JSON.

Publicado por primera vez el miércoles 4 de noviembre de 2026