Cómo automatizamos una web de noticias con n8n e IA (caso real)

Esta web publica cada mañana una noticia sobre inteligencia artificial sin que nadie la escriba a mano. Un sistema montado en n8n vigila una serie de canales de YouTube, elige qué merece la pena contar, lo redacta con un modelo de lenguaje, lo publica y genera su imagen. Aquí contamos cómo está hecho y, sobre todo, cómo ha fallado. Los tutoriales enseñan el flujo que funciona a la primera; lo útil de verdad son los meses siguientes.

Una aclaración antes de empezar: que las noticias las redacte una IA no es un secreto. Lo explicamos en nuestra página de uso de la inteligencia artificial. Las guías, como esta, las escribimos y revisamos nosotros.

La arquitectura, en una tabla

La web está hecha con Next.js y se sirve desde Vercel. Los artículos se guardan en un WordPress que funciona solo como gestor de contenidos: nadie lo visita directamente. n8n corre en un servidor propio y es quien lo mueve todo:

El reparto tiene una lógica: la IA solo entra donde hay que leer o escribir texto. Todo lo demás (horarios, lectura de feeds, guardar datos, publicar) es automatización clásica, que es más barata y más previsible. Si nunca has montado algo así, la guía de automatizar tareas con IA explica ese principio con un ejemplo pequeño.

Cómo decide qué publicar

La parte más importante del sistema no es la que redacta, sino la que elige. Cada mañana hay varios vídeos candidatos, y publicarlos todos fue un error que tardamos en ver. Hoy el publicador pasa cada candidato por estos filtros:

1. Puntuación por tema.Suma si el vídeo trata de un modelo o una herramienta concreta, y más si es de nicho y no de una gran marca; resta si es de “gana dinero con IA”, listas genéricas o tutoriales de negocio. Por debajo de un mínimo, fuera.
2. Duplicados. Si dos vídeos cuentan la misma noticia, sobrevive el de más puntuación. Se compara dos veces: antes de redactar, por el título del vídeo, y después, por el titular ya escrito en español, porque dos vídeos en idiomas distintos no se parecen hasta que están traducidos.
3. Saturación. Si ya hemos publicado dos artículos sobre la misma entidad en los últimos siete días, un tercero no entra, aunque traiga otro ángulo.
4. Nota de calidad. El propio modelo, al redactar, puntúa el resultado y dice si es publicable. Si no lo es, el artículo se guarda como borrador y no sale.
5. Máximo uno al día. Si ningún candidato pasa, ese día no se publica nada.

Un detalle técnico que nos costó dos intentos: para detectar duplicados, comparar palabras con el índice de Jaccard no sirve cuando los títulos tienen longitudes muy distintas. En un caso real con el modelo Kimi 3 daba 0,27, por debajo de cualquier umbral útil. Lo que funcionó fue medir qué parte del título más corto está contenida en el otro: 0,43 en ese mismo par, mientras que dos noticias distintas de Anthropic se quedaban en 0,17.

Cómo le pedimos que escriba

El modelo (gpt-4.1) recibe la transcripción y devuelve siempre la misma estructura: titular, descripción, dirección de la página, categoría, cuerpo, nota de calidad y si es publicable. Pedir un formato fijo es lo que permite que el resto del flujo no dependa de cómo le haya dado por redactar ese día. Tres reglas del prompt salieron de errores concretos:

• No inventar fechas, versiones ni nombres en clave. Un artículo salió con una fecha de lanzamiento y un nombre interno que no estaban en la fuente. Ahora el prompt lo prohíbe expresamente: si un dato no está en la transcripción, se omite.
• Extensión flexible, no mínima. Exigir 800 palabras como mínimo empujaba al modelo a rellenar, y rellenar es inventar. Ahora pide entre 700 y 1.100 palabras, y si para llegar habría que inventar, debe bajar su propia nota de calidad.
• Un glosario de nombres propios. Ver el error 3, más abajo.

Los siete errores que más nos enseñaron

1. Un flujo que leía un canal de diecisiete

Síntoma: del 10 al 15 de julio no se publicó nada. Causa: el código que procesaba los feeds solo leía el primer elemento de la lista, así que de diecisiete canales entraba uno. Además, si un feed fallaba, abortaba la ejecución entera. Y la cuota del servicio de transcripciones se había agotado a mitad de mes. Arreglo: recorrer todos los feeds, tolerar los que fallan y limitar las transcripciones diarias. Regla: un flujo que termina con éxito sin haber publicado nada no ha tenido éxito.

2. Cinco semanas sin enlaces internos

Síntoma: durante agosto, 54 artículos se publicaron sin un solo enlace a otros artículos de la web. Causa: el paso que consultaba los artículos ya publicados estaba en una rama paralela del flujo, y n8n ejecuta las ramas según su posición en el lienzo: corría después de publicar, no antes. El error lo capturaba un try/catch puesto para que el flujo no se rompiera, así que no avisó nunca. Arreglo: convertirlo en un paso obligatorio de la cadena principal. Regla: un catch que devuelve un valor razonable convierte un fallo en invisible. Si lo pones, deja rastro de que se ha activado.

3. Uno de cada cinco artículos, con el nombre mal escrito

Síntoma:32 de 154 artículos llevaban nombres propios mal escritos, 17 de ellos en el titular: “Cloud Code” por Claude Code, “Antropic”, “Quen” por Qwen. Causa:los subtítulos automáticos transcriben a oído, y el modelo copiaba lo que leía. Un artículo sobre Qwen acumuló 199 apariciones en Google en posición 9,9 sin un solo clic: nadie busca “Quen”. Arreglo: un glosario en el prompt y la corrección de los artículos ya publicados. Regla:ojo al corregir. A veces la grafía “mala” es la que busca la gente, como nos pasó después con “grockbot”: mira qué se busca antes de cambiar un nombre que ya funciona.

4. YouTube dejó de responder a nuestro servidor

Síntoma:el alimentador recibía errores de “no encontrado” en canales que existían. Causa: YouTube bloqueaba las peticiones que salían de la IP de nuestro servidor. Reintentar más veces no bastó. Arreglo: pedir el feed desde otro servidor (una ruta propia de la web, protegida con clave para que no sirva de proxy abierto) y cambiar el horario, porque de madrugada también fallaba desde ahí. Regla:“tarda más” no es “funciona”. Dimos el problema por resuelto porque la ejecución pasó de 21 segundos a 4 minutos, pero tardaba más porque reintentaba más. Mide lo que importa (cuántos canales responden), no la duración ni el color de la ejecución.

5. Artículos reales servidos como página no encontrada

Síntoma: tras un despliegue, la página con más visitas de la web devolvía un 404 con la etiqueta de no indexar. Causa:WordPress limita mucho las peticiones a su API; cuando respondía “demasiadas peticiones”, la web lo interpretaba como “este artículo no existe” y guardaba ese 404 en caché. Arreglo: si el gestor de contenidos falla, la web lanza un error y sigue sirviendo la última versión buena en lugar de concluir que el artículo no existe. Regla:“no he podido comprobarlo” y “no existe” son cosas distintas; que tu código no las confunda.

6. La misma noticia, dos y tres veces

Síntoma: en julio salieron tres artículos sobre el mismo lanzamiento en una semana, y dos el mismo día sobre otro. Causa: cada artículo se comparaba con lo ya publicado, pero nunca con sus hermanos del mismo lote. Arreglo:la doble comparación que contábamos arriba. Y aun así, en septiembre, un modelo llamado Jev llegó en dos vídeos: uno lo transcribió “Jev” y el otro “Jeev”, y salieron dos artículos con dos segundos de diferencia. Ahora dos nombres que difieren en una letra cuentan como el mismo. Regla: los duplicados vuelven por donde no miras; cada caso nuevo es un caso de prueba.

7. Una fecha y un nombre en clave inventados

Síntoma: un artículo sobre un modelo nuevo incluía una cronología y un nombre interno que no aparecían en la fuente. Causa: al investigar en la web, el modelo mezcló la noticia con información anterior y completó con datos plausibles lo que no sabía; la extensión mínima empujaba en la misma dirección. Arreglo: las reglas del prompt que contábamos antes. Regla: un modelo de lenguaje prefiere inventar a dejar un hueco, salvo que le digas explícitamente que el hueco es mejor.

Lo que aprendimos sobre el contenido

Más allá de la técnica, el sistema nos ha enseñado qué funciona en Google para una web pequeña de noticias:

• Publicar más no es publicar mejor. Llegamos a publicar tres artículos al día. Los artículos genéricos no se indexaban o se quedaban en posiciones donde nadie hace clic, y restaban calidad al conjunto. Hoy publicamos uno como máximo, y retiramos del índice los que no aportaban.
• Lo que funciona es llegar primero a un nombre nuevo. Los mejores días de la web han sido siempre por un modelo o una herramienta recién salidos, contados en español antes que nadie.
• Pero las noticias caducan. Esos picos duran unos tres días. Por eso estamos añadiendo guías como esta, que responden preguntas que la gente sigue haciendo meses después.

Las reglas que nos llevamos

1. Mide el resultado, no la ejecución: que acabe en verde no significa que haya hecho algo.
2. Si un paso necesita datos de otro, hazlo depender de él de verdad; no confíes en el orden.
3. Todo catch deja rastro. Un fallo silencioso dura semanas.
4. Pide a la IA formatos fijos y valídalos antes de usarlos.
5. Prohíbe inventar de forma explícita, y dale permiso para dejar huecos.
6. La parte que elige importa más que la que redacta.
7. Un día sin publicar es mejor que publicar algo que resta.
8. Verifica cada arreglo en el resultado publicado, no en el código.

Preguntas frecuentes

¿Google penaliza el contenido escrito con IA?

Google dice que valora el contenido por su utilidad, no por cómo se ha producido. Lo que sí persigue es el contenido publicado a escala sin valor añadido. En la práctica, nuestra experiencia coincide: los artículos genéricos no llegaban a ninguna parte, y lo que funciona es lo que aporta algo que no está ya en otros sitios.

¿Qué partes de un sistema así cuestan dinero?

El modelo de lenguaje (se paga por volumen de texto), el servicio de transcripciones, el servidor donde corre n8n y el alojamiento de la web y del gestor de contenidos. La lección cara fue la de las transcripciones: el plan básico tenía un límite mensual que se agotó a mitad de mes y contribuyó a dejar el sistema parado varios días. Mira los límites de cada servicio antes de decidir cuántas ejecuciones harás al día.

¿Por qué n8n y no Make o Zapier?

Por dos motivos: necesitábamos código propio en varios pasos (la puntuación, los filtros de duplicados) y el volumen de pasos por ejecución habría encarecido mucho una herramienta que cobra por tarea. Para algo más pequeño, cualquiera de las tres sirve; lo comparamos en la guía de automatizar tareas con IA.

¿Se puede montar algo así para otro sector?

Sí. El esquema (vigilar fuentes, elegir con criterio, redactar con un formato fijo, publicar y medir) sirve para cualquier sector con información que cambia a menudo. Si quieres algo parecido para tu negocio, escríbenos desde la página de contacto.