Analizamos qué ocurre cuando una fuente de contenido bloquea técnicamente la recopilación automática y por qué eso no siempre significa que el proyecto haya perdido el material.
Tarde o temprano, esto le ocurre a cualquiera que configure la recopilación automática de contenido desde fuentes externas: ayer el feed traía artículos con normalidad y hoy la fuente, de repente, guarda silencio. El primer pensamiento suele ser de pánico: «la fuente se ha roto, todo ha fallado y el piloto automático se ha detenido». En la práctica, nueve de cada diez veces no se trata de una avería, sino de una protección del sitio: simplemente ha detectado que no había un navegador humano, sino una solicitud automática, y ha decidido no entregar el contenido.
La diferencia entre «la fuente realmente no está disponible» y «la fuente se está protegiendo temporalmente contra los bots» es fundamental. En el segundo caso, el sistema no debe rendirse tras el primer intento fallido, porque detrás de un mismo bloqueo puede haber cualquier cosa: desde un simple tiempo de espera hasta un sistema antibot avanzado que comprueba el comportamiento del navegador. En Telematic diseñamos la recopilación de contenido teniendo precisamente en cuenta este tipo de situaciones, y no un mundo ideal en el que cada sitio siempre devuelve HTML limpio en la primera solicitud.
A continuación explicamos cómo funciona internamente y qué significa para quien solo quiere que cada día llegue material nuevo al proyecto, en lugar de encontrarse con un sinfín de errores en el registro de ejecuciones.
La mayoría de los sitios, especialmente los de noticias y los especializados, llevan años sometidos a la presión de los bots: unos roban contenido, otros inflan el tráfico y otros simplemente sobrecargan el servidor con solicitudes frecuentes. La respuesta de la industria es una protección multinivel: desde simples límites de solicitudes por IP hasta comprobaciones complejas que analizan si el «visitante» se comporta como un navegador real: si ejecuta JavaScript, mueve el cursor y carga las fuentes y las imágenes en el orden correcto.
Para un sistema de recopilación automática, esto significa que no se puede depender de un único método para obtener la página. Lo que funcionó ayer puede bloquearse mañana, no porque la fuente haya cerrado, sino porque la protección se ha vuelto más estricta o el sistema ha detectado un patrón de solicitudes y lo ha marcado temporalmente como sospechoso.
Por eso, la recopilación de contenido en Telematic no se detiene después del primer intento fallido, sino que pasa sucesivamente por varios niveles de obtención de la página antes de considerar que la fuente realmente no está disponible:
Solo si no es posible obtener el material mediante ninguno de estos niveles, la fuente se marca como temporalmente no disponible, y no como «averiada para siempre». Esto es fundamental: un fallo puntual de red o un bloqueo temporal no debe invalidar una fuente que había funcionado correctamente durante meses.
Obtener la página es solo la mitad del trabajo. A continuación entra en juego el filtro temático de contenido: si el proyecto tiene una temática configurada, el sistema descarta, a nivel de proyecto, los materiales que formalmente proceden de la fuente, pero que no son pertinentes —por ejemplo, si un feed sectorial publica de repente un comunicado de prensa publicitario o un material que no corresponde al tema del canal—. Esto ocurre antes de que el contenido pase por el costoso procesamiento de IA, lo que ahorra tanto tokens como la atención de la persona que, de otro modo, tendría que revisar borradores «fuera de tema».
Lo que supera el filtro se comprueba después mediante los umbrales de análisis automático: el sistema decide por sí mismo qué materiales cumplen con suficiente confianza los criterios del proyecto para continuar automáticamente por el flujo de trabajo y cuáles deben quedarse como borradores para una revisión manual. No se trata de un interruptor binario de «confiar o no en la fuente», sino de un umbral de confianza configurable que permite automatizar los casos evidentes y dejar las situaciones dudosas en manos de una persona.
Durante las pruebas tuvimos un caso ilustrativo: uno de los sitios especializados que había proporcionado material de forma estable durante varias semanas dejó de entregar cualquier contenido de un día para otro, salvo una página de bloqueo con un captcha. La primera reacción fue dar la fuente por perdida y eliminarla del proyecto. Sin embargo, al comprobarlo descubrimos que el sitio simplemente había activado una protección más estricta después de una oleada de scraping masivo por parte de algunos servicios externos: todos los que accedían automáticamente al sitio se vieron afectados, incluidos nosotros.
Precisamente el enfoque multinivel resolvió la situación: la solicitud simple había dejado de funcionar, pero la emulación del navegador seguía obteniendo la página con normalidad, porque la protección bloqueaba principalmente las solicitudes más primitivas, sin indicios de un navegador real. Si el sistema se hubiera rendido después del primer nivel, la fuente habría pasado a clasificarse como «no disponible» sin ninguna justificación, mientras el material seguía recopilándose tranquilamente.
También puede ocurrir lo contrario: en algún momento la fuente activa una protección tan estricta que no supera ninguno de los niveles. En esos casos, el sistema registra honestamente la fuente como no disponible, en lugar de llamar interminablemente a una puerta cerrada y gastar recursos en ello. También es una decisión consciente: es mejor mostrar claramente en el registro de ejecuciones que la fuente requiere atención que ocultar el problema con repeticiones silenciosas infinitas.
La conclusión práctica es sencilla: si en el registro de ejecuciones de una fuente ve un fallo aislado hoy, todavía no hay motivo para entrar en pánico, trasladar todo el feed a otro servicio o volver a comprobar manualmente la configuración. El sistema ya ha recorrido el camino desde la solicitud simple hasta la evasión avanzada antes de informar del problema; es decir, cuando aparece el error, realmente conviene observar la fuente con más atención.
Es recomendable configurar el filtro temático con la mayor precisión posible desde el principio. Esto no solo ahorra tiempo de moderación manual, sino también tokens que, de otro modo, se gastarían en procesar materiales que no corresponden al tema. En cuanto a los umbrales de análisis automático, es mejor configurarlos de forma conservadora al principio y flexibilizarlos gradualmente a medida que compruebe que el contenido aceptado automáticamente cumple realmente sus expectativas. Así, el piloto automático gana confianza poco a poco, en lugar de hacerlo mediante un cambio brusco.
En última instancia, el objetivo de este mecanismo es liberar a la persona de la tarea rutinaria de «comprobar si la fuente sigue activa», dejándole únicamente las decisiones de contenido: si el material merece publicarse, si el tono es adecuado o si necesita una edición manual. Todo lo relacionado con la disponibilidad técnica del sitio, el sistema intenta resolverlo por sí mismo antes de molestar al propietario del proyecto.
Contenido que conoce al lector: cómo la personalización mediante IA está cambiando las reglas del juego
Autoarchivo de borradores: un proyecto limpio sin tareas de limpieza manual
