Automatizar un blog con IA es fácil de imaginar y mucho más difícil de conseguir. Quise publicar un artículo al día en cuatro idiomas sin tocarlo; dos semanas después, 91 páginas estaban dañadas. Esto es lo que se rompió, cómo lo reparamos Claude y yo, y qué funciona hoy.

Lo esencial en pocas líneas

  • Un script y la IA Gemini publicaban un artículo al día, en cuatro idiomas, sin que nadie los leyera. A las dos semanas, 91 páginas estaban dañadas.
  • Otra IA, Claude, encontró la causa (la arquitectura mucho más que el modelo) y después auditó y reparó esas 91 páginas en directo en el sitio, con copia de seguridad y vuelta atrás automáticas en cada paso.
  • Se construyó un generador nuevo: una estructura impuesta, una maquetación hecha por un programa, controles que bloquean y borradores en lugar de publicaciones.
  • Lo que queda de mi parte es lo que una máquina no puede decidir: la línea editorial, los hechos que hay que verificar y la renovación de algunas credenciales de acceso.

La apuesta inicial

Una pequeña oficina de agencia con un portátil, un despertador y cuatro bocadillos de diálogo vacíos
La apuesta: un artículo al día, en cuatro idiomas, sin tocarlo.

Dirijo desde 2013 una agencia web con sede en Pondicherry, en la India. Creamos sitios web, tiendas online y aplicaciones móviles, gestionamos las redes sociales de nuestros clientes y somos unas cincuenta personas. Por eso el blog de nuestro propio sitio debería ser el escaparate más cuidado de la casa. Suele pasar lo contrario: en casa del herrero, cuchillo de palo.

A principios de octubre quise arreglar eso de una vez. La idea cabía en una frase: un artículo al día, escrito en inglés y adaptado después al francés, al español y al italiano, y publicado sin que yo tuviera que tocarlo. Leo esos cuatro idiomas. Sé lo que un sitio multilingüe bien hecho puede abrir, y también sé cuántas horas cuesta alimentarlo a mano.

La mecánica parecía sencilla, casi demasiado buena. Un script escrito en Python. La inteligencia artificial de Google, Gemini, para redactar. Una tarea programada en Windows que se dispara cada mañana a las 10:14. Y mi sitio WordPress, con su tema Avada, sus traducciones gestionadas por WPML y su plugin de SEO, para acogerlo todo.

Era demasiado buena, en efecto. Durante unos días todo dio la impresión de funcionar. Los artículos llegaban, las traducciones se colocaban junto al original y el blog se llenaba a una velocidad que ningún equipo humano habría podido mantener. A las dos semanas había veintidós temas en línea, es decir, noventa y una páginas contando todas las traducciones.

Sobre el papel, era un éxito. En la realidad, nadie había leído esas páginas línea por línea. Yo no, ocupado con todo lo demás. El script tampoco, que solo sabe seguir sus instrucciones. Ni la máquina que las había escrito, que no tiene ningún motivo para dudar de lo que produce.

Este texto cuenta lo que vino después. Cómo me di cuenta de que algo fallaba, por qué la situación se volvió crítica, cómo otra inteligencia artificial, Claude, auditó y luego reparó cada una de esas páginas directamente en mi sitio en línea, y cómo reconstruimos el generador para que no vuelva a pasar. He intentado escribirlo de modo que se entienda sin saber una sola línea de código. También te cuento los falsos comienzos, porque fueron los que más me enseñaron.

Lo que ocurre de verdad cada mañana a las 10:14

Una cocina de restaurante donde un cocinero pasa platos a un camarero y nadie prueba nada
Una cocina donde nadie prueba: el error viaja hasta la mesa.

Para entender qué salió mal, hay que mirar la cocina. Imagina un restaurante donde un cocinero muy talentoso prepara los platos, donde un camarero los corta, los endereza y los coloca en los platos, y donde nadie prueba nada antes de que el plato llegue al cliente. Mientras todo va bien, el sistema es de una eficacia temible. En cuanto un eslabón se equivoca, el error viaja hasta la mesa sin que nadie lo haya visto.

Esto es, a grandes rasgos, lo que hacía mi script cada día:

  1. Recorría los titulares de algunos sitios de noticias sobre SEO e inteligencia artificial y le pedía a Gemini que eligiera un tema nuevo.
  2. Le pedía un artículo de dos mil a dos mil quinientas palabras, en inglés, escrito en un lenguaje de marcado sencillo.
  3. Hacía fabricar tres imágenes, una para la cabecera y dos para el cuerpo del texto.
  4. Reclamaba un título y una descripción para los buscadores.
  5. Pasaba el texto por una función de limpieza, encargada de convertirlo en una página web limpia.
  6. Pedía después tres traducciones, al francés, al español y al italiano, con la consigna de no cambiar nada del formato.
  7. Lo depositaba todo en el sitio, transmitía los enlaces entre idiomas gracias a un pequeño puente instalado expresamente en mi WordPress y esperaba al día siguiente.

Enseguida se nota lo que falta: un paso para mirar el resultado. Ninguna revisión, ningún control, ninguna alerta si algo no se parecía a un artículo terminado.

Los primeros signos

Leo los cuatro idiomas, lo que es a la vez una ventaja y una maldición: lo veo todo. Esto es lo que noté primero y lo que la auditoría confirmaría después:

  • Los fragmentos de código habían desaparecido o llegaban hechos jirones, incluso en artículos técnicos en los que eran el corazón del texto.
  • Había signos parásitos por todo el texto: asteriscos, almohadillas, emojis, flechas dibujadas con guiones.
  • Algunas traducciones se detenían a mitad de una idea, a veces a mitad de una frase.
  • En italiano, la pequeña preposición “ai”, que significa “a los”, se escribía “AI”, como la inteligencia artificial, decenas de veces.
  • Las unidades y las siglas perdían sus mayúsculas, y los precios ya no coincidían de un idioma a otro.
  • Todos los artículos apuntaban a la misma palabra clave principal, “Digital Strategy”, justo lo que no hay que hacer en SEO.

Tomado por separado, cada uno de estos defectos se arregla en cinco minutos. Multiplicados por veintidós temas y cuatro idiomas, formaban una obra que ya no podía ignorar. La situación se había vuelto crítica: el blog de una agencia web, que debería demostrar nuestra seriedad, mostraba sus propios defectos a todos los visitantes, en cuatro idiomas.

Primero intenté arreglarlo con el propio Gemini, enseñándole el problema y pidiéndole que corrigiera su propio script. Le dediqué mucho tiempo y salí con la sensación de que cada corrección creaba otra. Fue entonces cuando comprendí que quizá estaba mirando en la dirección equivocada.

Gemini solo era culpable a medias

Una cinta transportadora que lleva páginas de texto a través de una máquina borradora demasiado aplicada
El limpiador demasiado aplicado borraba todo lo que parecía código.

Cuando un plato llega frío, se culpa al cocinero. A veces es el camarero quien lo olvidó en la ventanilla. Al leer el script de principio a fin, Claude recorrió la cadena eslabón por eslabón, y el veredicto me sorprendió: la mayor parte de los daños no venía de lo que Gemini había escrito, sino de lo que le ocurría después.

El limpiador demasiado entusiasta

La función encargada de convertir el texto en página web tenía una misión razonable: evitar que fragmentos de código o esquemas mal formados ensuciaran los artículos. Para ello, eliminaba todo lo que se parecía a código. En concreto, borraba cada línea que contuviera ciertas palabras, como “import” o “class”, y todo lo que estuviera entre tres acentos graves. En un artículo para principiantes, el código de verdad es la excepción. En un artículo técnico es la razón de ser del texto, y desaparecía sin ningún mensaje de error.

El límite invisible

A Gemini se le pedía que redactara de dos mil a dos mil quinientas palabras, pero el script le concedía un margen de respuesta limitado a 8192 “tokens”, la unidad de medida del texto para una IA. Es justo. Y sobre todo, el script nunca comprobaba si la respuesta había llegado hasta el final. Un texto cortado en seco se publicaba como si fuera un texto terminado.

La traducción de un solo golpe

Las traducciones se pedían de una vez, con la consigna de conservar el formato “exactamente”. Ninguna regla propia de cada idioma, ningún léxico de nombres de marca que no se debían tocar, ninguna convención de mayúsculas. El resultado era fluido en la superficie y estaba lleno de pequeños errores en el fondo, como el famoso “AI” italiano.

Títulos y descripciones aproximados

El título y la descripción para los buscadores se extraían buscando la palabra “title:” en la respuesta. Si faltaba, el script recurría a un texto genérico, el mismo para todos. Además, el código recortaba el título SEO a cincuenta caracteres, fuera cual fuese la frase.

Y lo que Gemini tenía realmente sobre su conciencia

Su parte no es nula. Cuando se le pide un artículo de actualidad, a veces inventa una cifra o una característica para parecer preciso. Le gustan los emojis, las listas con casillas y las tablas decorativas. Pero son inclinaciones, no averías, y un buen sistema está diseñado para encuadrarlas.

La lección

Un modelo de lenguaje es un redactor excelente y un controlador malísimo de sí mismo. Lo que yo había construido se parecía a una fábrica sin departamento de calidad. El problema no era encontrar una IA mejor. Había que cambiar la arquitectura que la rodeaba.

Cambié de interlocutor

El día que abrí una conversación con Claude, tenía una petición en dos partes y la formulé con la franqueza de quien ya no puede más: Gemini solo me creaba problemas, había sufrido demasiado y quería saber dos cosas. Primero, qué fallaba en mi script. Después, y sobre todo, cómo reparar todos los artículos publicados desde el 1 de octubre, traducciones incluidas, con la lista de identificadores como apoyo.

No tenía ninguna garantía de que funcionara. Comprendí enseguida que el camino sería largo, y no solo por el trabajo en sí.

Primer obstáculo: el sitio cerraba la puerta

Claude trabaja en un entorno informático aislado, en algún lugar de la nube. Cuando intentó consultar mi sitio, este respondió con una negativa. Nada grave: es el comportamiento normal de un sitio protegido. Pero el permiso de acceso se configura en los ajustes de mi cuenta de Claude, donde hay que añadir el nombre de dominio de mi sitio a una lista de sitios autorizados. Respondí que no veía la opción, porque estaba en el plan gratuito. Acto seguido pasé al plan Pro y la opción apareció.

Segundo obstáculo: las credenciales

Para modificar artículos hacen falta permisos de escritura. En lugar de pegar contraseñas en una conversación, las reuní en un archivo de configuración en mi ordenador, que Claude utilizó después para trabajar, con un acceso específico que puedo revocar en cualquier momento. Este hábito es una de las reglas que recomiendo al final de este texto.

Tercer obstáculo: el sitio solo respondía a mi ordenador

Incluso con el dominio autorizado, mi sitio seguía desconfiando del entorno de Claude. La solución llegó desde un ángulo inesperado: mi propio portátil, que el sitio conoce y acepta. Abrí la aplicación de escritorio de Claude, que puede conectarse a mi equipo. Después Claude preparó para mi PC un pequeño programa, una especie de ventanilla, que yo pongo en marcha y que ejecuta una a una las tareas que Claude deja en una carpeta y le devuelve los resultados. Claude escribe las instrucciones y las comprueba, mi ordenador habla con el sitio y el resultado vuelve a subir.

Quedaba la única pregunta que de verdad importaba: ¿hasta dónde dejarle llegar? Lo resolví sin matices. Quería que interviniera directamente en el sitio en línea, que publicara él mismo sus correcciones y que me demostrara, en lugar de prometérmelo, que estaba a la altura. Añadí que, si necesitaba más potencia, tenía que decírmelo. No la necesitó.

También puse una condición, que repito con gusto a cualquiera que confíe un trabajo a una IA: “te toca a ti verificar lo que haces”. Guió cada una de las etapas siguientes.

La auditoría: noventa y una páginas bajo la lupa

Una lupa gigante sobre una cuadrícula de miniaturas de páginas con marcas verdes y puntos naranjas
La auditoría: noventa y una páginas examinadas una por una.

Primera decisión, y me la impuso el sentido común más que las ganas: no reparar hasta haber medido. No tenía una lista fiable de los defectos, solo impresiones. Así que le pedí a Claude que lanzara su propia auditoría, con datos recientes leídos directamente del sitio, sin fiarse de los que yo tenía a mano.

Una auditoría es, sencillamente, una revisión metódica, pero hecha por una máquina que no se cansa. Para cada página, el programa comparaba el título, la estructura de los intertítulos, los párrafos, las listas, las tablas, los bloques de código, las imágenes, los enlaces, la información destinada a los buscadores, el idioma empleado y la presencia del botón de contacto. Ochenta y ocho páginas se repartían en veintidós grupos de cuatro idiomas. Otras tres traducciones flotaban por su cuenta, sin padre oficial: duplicados de un mismo artículo, que clasificamos como “huérfanas”.

Cuando nada parece responder

Tuve un momento de duda. Pasado un rato, escribí que el script que había lanzado me daba la impresión de girar en el vacío. Unos minutos después me corregí: giraba de verdad, pero muy despacio. La razón es sencilla y un poco humillante para la impaciencia humana: consultar noventa y una páginas, en varios idiomas, varias veces cada una, lleva tiempo, sobre todo cuando el sitio se cuida de no dejarse desbordar.

Entonces di la única consigna que vale en este tipo de situación. No necesitaba que fuera rápido. Necesitaba que el resultado final fuera perfecto, y no importaba cuánto tiempo llevara. Esa frase cambió la manera de trabajar: Claude dejó de optimizar la velocidad para optimizar la fiabilidad.

Lo que reveló la auditoría

Lo que encontramos Un ejemplo concreto Lo que hicimos
Código ausente o roto Ejemplos de configuración desaparecidos de artículos técnicos Reconstruidos en los cuatro idiomas, con comentarios en inglés
Formato parásito Asteriscos, almohadillas, emojis, esquemas hechos de guiones y flechas Limpiados; comparaciones dibujadas con caracteres convertidas en tablas de verdad
Traducciones truncadas Conclusiones ausentes, frases cortadas Completadas y revisadas
Errores de mayúsculas y de idioma “ai” convertido en “AI” en italiano (35 veces); kW y kHz en minúsculas Corregidos en todas partes
SEO La misma palabra clave para todos, títulos demasiado largos (90 de 91) Títulos, descripciones y palabras clave rehechos página por página
Duplicados y enlaces Tres traducciones huérfanas, un enlace externo roto Huérfanas limpiadas, enlace sustituido

Tomado por separado, el balance no era dramático, pero en conjunto era enorme. Y definía la obra: no retocar tres frases, sino rehacer cada página con reglas idénticas, comprobar el resultado página por página y no suponer nunca que “debe de estar bien”.

La obra: trabajar en directo sin romper el sitio

Un funambulista con una caja de herramientas sobre una red de seguridad
Trabajar en directo en el sitio, con una red debajo.

En toda reparación llega un momento en que hay que elegir entre prudencia y eficacia. Le escribí a Claude que necesitaba irme a dormir y que quería que trabajara de forma autónoma. Después, unos mensajes más tarde: “go”. Auditar, corregir y volver a publicar todos los artículos creados desde el 1 de octubre, directamente en el sitio en línea.

La frase puede parecer temeraria. Confiar a una IA la escritura en un sitio que recibe visitantes, sin releer uno mismo cada modificación, es el tipo de decisión que da escalofríos. Lo que la hizo razonable no fue mi confianza. Fue la red de seguridad que Claude montó antes de escribir una sola línea.

La red de seguridad

Para cada artículo, el procedimiento era siempre el mismo, en este orden:

  1. Guardar el estado actual de la página, en un archivo conservado en mi ordenador.
  2. Escribir la versión corregida en el sitio.
  3. Releer lo que el sitio ha guardado realmente y compararlo con lo que debía haber guardado.
  4. Abrir la página pública como lo haría un visitante: tiene que responder, no mostrar código técnico por error, contener las frases esperadas y mostrar el botón de contacto.
  5. Volver atrás automáticamente, sin esperar mi opinión, si alguna de estas comprobaciones fallaba.

Con este dispositivo, el peor escenario ya no era una página rota en línea, sino una página rechazada y restaurada tal como estaba, con un mensaje de error que explicaba el motivo.

Cómo se repararon las páginas

Claude no retocaba los artículos al azar. Reconstruía cada página a partir de su contenido, con las mismas reglas para todos los idiomas: formato limpio, código restablecido, mayúsculas corregidas, títulos y descripciones reescritos, botón de contacto conservado, enlaces comprobados. Después, un segundo conjunto de controles, independiente de la reparación, revisaba el resultado. La idea es la misma que en un equipo humano: quien corrige no es quien valida.

Las oleadas

El trabajo avanzó por oleadas sucesivas, cada vez más finas. La primera trató ochenta y siete páginas: ochenta superaron todos los controles a la primera y siete fueron rechazadas y corregidas después. La segunda volvió a publicar las noventa y una páginas con textos más pulidos, y todas pasaron los controles. Una tercera retomó once páginas por detalles pendientes. Pero lo más difícil estaba aún por llegar.

Mientras tanto, los tres borradores que yo no quería ver modificados de ninguna manera siguieron intactos, como se había acordado: el perímetro de la obra estaba fijado y se respetó.

El misterio de las llaves

Un detective que inspecciona un filtro en forma de embudo que se traga símbolos de llaves
El misterio de las llaves: un filtro que se tragaba el contenido.

Es la parte del relato que más me gusta, porque parece una novela policíaca y porque demuestra por qué no basta con “tiene buena pinta”.

Pasadas las primeras oleadas, Claude siguió mirando las páginas públicas como un visitante, en particular las que contenían código. Algo fallaba, de forma sutil. Algunos fragmentos superaban todos los controles internos pero se mostraban mal en el sitio: habían desaparecido trozos, otros se habían transformado.

Un detalle técnico, explicado con sencillez

En una página web, ciertos caracteres están reservados: el signo “menor que” sirve para abrir una etiqueta. Para mostrarlo como un simple símbolo, se escribe en una forma codificada, una “entidad”, por ejemplo <. El navegador la lee y muestra el signo. Es un mecanismo muy corriente, y lo usábamos en todos los bloques de código.

Primera hipótesis: el error venía de nuestro lado. Así que Claude escribió la entidad en una forma reforzada, para que sobreviviera a una decodificación adicional. Se volvió a publicar una oleada entera sobre esa base. Los controles de entonces se superaron, lo cual demuestra una cosa: a veces un control solo mide lo que fue diseñado para medir.

Porque el síntoma persistía, y tenía una particularidad inquietante. Solo aparecía en los artículos cuyo código contenía llaves, esos signos { y } que se encuentran en casi todos los archivos de configuración. Los artículos sin llaves se comportaban perfectamente.

Experimentos que no dejan rastro

Para entenderlo, Claude hizo lo que haría un buen investigador: reproducir el fenómeno en condiciones controladas. En un solo artículo puso una versión de prueba, observó la página pública y restauró la versión original. Volvió a empezar con variantes. Cada prueba era reversible y cada resultado quedó anotado.

Las conclusiones caben en tres líneas:

  • Cuando un artículo contiene una llave, un filtro del sitio borra todo lo que hay entre una llave de apertura y su cierre: texto, configuración y ejemplos incluidos.
  • En esos mismos artículos, el filtro decodifica una vez las entidades, de modo que <title> se convertía en una etiqueta de verdad, invisible en pantalla.
  • Los artículos sin llaves se libraban de todo esto.

No pude identificar al culpable. Mi sitio ejecuta numerosos plugins y fragmentos de código, y el que aplica esta regla no se delató. Claude revisó lo que se podía leer, sin modificar nada, y no encontró ninguna pista clara. Habrá que volver sobre ello, y lo anoto entre mis tareas pendientes.

La solución: rodear el obstáculo en lugar de combatirlo

En lugar de esperar a dar caza al filtro, Claude buscó una escritura que el filtro no reconociera. Probó varias codificaciones de las llaves. Algunas fallaban; otras funcionaban pero daban un resultado inutilizable. Solo una superó todas las pruebas: una entidad con nombre del lenguaje de las páginas web, { para la llave de apertura y } para la de cierre. El filtro no las ve como llaves, y el navegador las muestra exactamente como tales.

Quedaba aplicarla. La sexta oleada reescribió las setenta páginas afectadas, tres traducciones huérfanas incluidas, con esta convención, y cada bloque de código se comparó con su fuente, signo por signo, en la página pública, con vuelta atrás automática ante la mínima diferencia. Resultado: setenta éxitos de setenta, ninguna vuelta atrás.

Hubo un último detalle curioso. Un plugin de enlaces internos inserta automáticamente enlaces en mis artículos, incluso, por exceso de celo, dentro de los bloques de código. De momento es inofensivo, pero no es limpio, y ahora está en la lista de lo que voy a hacer excluir.

Verificar de verdad

Pasada la última oleada, la tentación de proclamar la victoria era grande. Claude hizo lo contrario: lanzó una auditoría final de las noventa y una páginas, con una lógica actualizada para tener en cuenta el descubrimiento de las llaves. El programa examinó cada página desde tres ángulos: lo que el sitio guardó, lo que el sitio entrega a los programas que lo consultan y lo que ve realmente un visitante.

Llegó el veredicto: noventa y una páginas de noventa y una conformes. Todas las páginas responden, tienen un único título principal, muestran el título correcto, la descripción correcta, el botón de contacto, ningún código técnico visible por error, e intertítulos y párrafos idénticos a la fuente. Mil sesenta y dos bloques de código, repartidos en setenta y cuatro artículos, salen idénticos en las páginas públicas. Se probaron ochenta y dos enlaces distintos; solo uno estaba realmente roto y se sustituyó.

La falsa alarma que dice mucho

La primera auditoría completa terminó, sin embargo, en un aparente fracaso: uno de los controles señalaba ochenta y cuatro artículos. Comparaba el contenido en bruto guardado en el sitio con el que se había enviado y encontraba diferencias.

En lugar de declarar la alerta sin importancia, Claude se puso a entenderla. La causa era benigna: el propio sitio reescribe las direcciones de los enlaces internos en una forma más corta, lo que modifica el texto en bruto sin cambiar la página. Una vez tenida en cuenta esa reescritura, las noventa y una páginas eran, efectivamente, idénticas a su fuente.

Lo importante no es el resultado final, sino el método: una alerta que no se entiende no se suprime, se explica. Eso es lo que separa un “terminado” verificado de un “terminado” declarado.

La obra en cifras

Para los aficionados a los números, este es el balance de la reparación:

  • 91 páginas reparadas: 22 temas en cuatro idiomas, más 3 traducciones huérfanas.
  • 1062 bloques de código comprobados uno por uno, repartidos en 74 artículos.
  • 82 enlaces probados, de los cuales solo uno estaba roto.
  • 70 páginas reescritas para sortear el problema de las llaves, sin una sola vuelta atrás.
  • Más de 30 reglas de control en el nuevo generador, y 10 pruebas automáticas que no tocan el sitio.
  • 6 minutos aproximadamente para producir, enlazar y verificar cuatro borradores en la prueba real.

Reconstruir en lugar de remendar

Un taller de tres puestos con un robot redactor, un ensamblador y un inspector
Reconstruir: un puesto para escribir, otro para ensamblar y otro para revisar.

Reparar noventa y una páginas no resolvía nada si al día siguiente, a las 10:14, el generador producía una nueva tanda de defectos. Había que tratar la causa. Y la causa, como habíamos visto, no era un fallo que corregir, sino una forma de diseñar: un sistema en el que un modelo escribe texto libre, que un script limpia a golpe de expresiones regulares, sin que nadie mire el resultado.

Claude propuso no remendar ese script, sino escribir uno nuevo, construido sobre tres principios sencillos.

Tres principios

Pedir una estructura, no un texto maquetado. En lugar de reclamar un artículo en lenguaje de marcado, que el script tendría que limpiar después, se le pide a la IA que entregue el artículo dividido en bloques identificados: un párrafo, un intertítulo, una lista, una tabla, un bloque de código. Cada bloque se verifica uno por uno. Ya no hay nada que “limpiar”, así que ya no hay nada que borrar por error.

Separar la escritura de la maquetación. La IA nunca escribe una línea de página web. Un programa clásico, que siempre hace lo mismo de la misma manera, convierte los bloques en páginas con el formato de mi tema. Por una buena razón: una máquina que redacta es creativa, y por tanto variable. Una máquina que maqueta tiene que ser aburrida, y por tanto fiable.

No publicar nunca sin control. Entre la redacción y el sitio se interpone una inspección de calidad independiente, que puede bloquear la operación.

El recorrido de un artículo hoy

  1. Elección del tema. El programa consulta los artículos ya publicados, así como los borradores, y sus palabras clave, para no competir nunca consigo mismo. Por defecto elige un tema duradero en lugar de uno de actualidad, porque los datos de actualidad son los que una IA inventa con más facilidad.
  2. Redacción en inglés, en forma de bloques, con una palabra clave principal precisa.
  3. Control de calidad. Una treintena de reglas, cada una de las cuales corresponde a un defecto realmente encontrado en las páginas reparadas: texto cortado al final del artículo, emojis, restos de formato, unidades sin mayúscula, “AI” en un texto que no está en inglés, idioma dudoso, palabra clave ausente del primer párrafo, código inválido, enlace a un artículo inexistente. Si hay un error, se pide una corrección dirigida, dos veces como máximo.
  4. Adaptación al francés, al español y al italiano. No una traducción palabra por palabra: una adaptación, con una guía de estilo por idioma, una lista de nombres de marca que no se traducen y la obligación de conservar exactamente la misma estructura. Los bloques de código no se vuelven a traducir nunca: simplemente se copian del original.
  5. Segundo control, idioma por idioma, con una comparación añadida con la versión inglesa.
  6. Maquetación, hecha por el programa, y fabricación de las imágenes.
  7. Depósito como borradores en el sitio, enlace de los cuatro idiomas y relectura de cada borrador para asegurarse de que el sitio ha guardado lo que debía.
  8. Informe, en un archivo, con todo lo ocurrido y cualquier advertencia.

Si una etapa se bloquea, no se crea nada. Mejor ningún artículo que un artículo estropeado.

Cuatro idiomas, cuatro maneras de equivocarse

Decir “traducimos a tres idiomas” da la impresión de un trabajo mecánico. Es falso, y es una de las razones por las que el antiguo script se equivocaba con tanta discreción: cada idioma tiene sus trampas, y se acumulan.

En francés, la inteligencia artificial se escribe “IA” y no “AI”, los dos puntos, los signos de interrogación y las comillas francesas se separan de la palabra con un espacio, y un título lleva mayúscula solo en su primera palabra y en los nombres propios. El español y el italiano también usan la sigla “IA”. En italiano, “ai” es además una palabra de uso diario, una preposición: es justamente la que el antiguo script transformaba en “AI”, treinta y cinco veces. En español, el botón de contacto tuvo que pasar al tuteo para alinearse con el tono del resto del sitio.

En todas partes se aplican otras reglas: los nombres de marcas y productos no se traducen jamás, las unidades de medida tienen una caja que importa (un kW no es un kw) y la palabra clave principal debe sonar natural en cada idioma en lugar de traducirse al pie de la letra. Ninguna de estas reglas existía en el antiguo script. El nuevo da a cada idioma su propia guía de estilo, su léxico de marcas y sus propios controles. Este trabajo es invisible cuando sale bien, y justo ese es el objetivo.

Las salvaguardas

El nuevo programa se detiene solo a los noventa minutos. Se niega a lanzarse dos veces a la vez. Solo crea un artículo al día. Lleva un diario. Se apoya en diez pruebas automáticas que verifican su comportamiento sin tocar el sitio, incluido un sitio falso que simula averías. Por último, las contraseñas ya no se escriben en el código, sino que se guardan en un archivo aparte.

La trampa escondida de las 10:14

Un reloj de pared sin números junto a un enorme botón de pausa
La pausa que nunca terminaba: nadie para pulsar una tecla.

El nuevo generador existía, superaba sus pruebas e incluso había tenido éxito en un ensayo en seco con el Gemini de verdad. Quedaba conectarlo a mi tarea programada, y fue entonces cuando le pedí a Claude que se asegurara de que el archivo principal de mi script, el que Windows lanza cada día, estaba perfecto para generar los próximos artículos. El trabajo merecía algo más que un simple copiar y pegar, y Claude descubrió dos cosas.

Una pausa que no terminaba nunca

La primera: mi tarea, llamada “Rédaction post lcwa”, lanzaba un pequeño archivo de arranque cuya última línea contenía un comando “pause”. Espera a que se pulse una tecla, lo cual es práctico cuando se lanza el script a mano y se quiere leer el resultado. Pero en una tarea automática ya no hay nadie para pulsar nada.

Resultado: el script había terminado su trabajo en unos minutos, pero la tarea seguía apareciendo como “en curso”. Y Windows, por defecto, se niega a lanzar una nueva ejecución mientras la anterior no haya terminado. La activación del día siguiente se habría ignorado sin ruido. Sin error, sin alerta, simplemente un artículo que nunca habría llegado.

Claude suprimió el comando, añadió un archivo de arranque aparte para mis pruebas manuales y terminó la ejecución que llevaba bloqueada desde la mañana. La tarea volvió al estado “lista”, con su próxima ejecución programada para el día siguiente a las 10:14.

Un borrador todavía a la antigua

El segundo descubrimiento me hizo sonreír con amargura. La ejecución de la mañana se había hecho con el antiguo script, y por tanto había creado cuatro borradores en los cuatro idiomas, con todos los defectos de siempre. No estaban publicados, lo que los hacía inofensivos, pero me recordaron que el calendario de un proceso automático no se detiene porque estés reparando algo.

La prueba real

Para comprobarlo, no hay sustituto de un ensayo de verdad. Antes de llegar a él, una primera comprobación de conexión había fallado, por cierto, de forma instructiva: Claude le había pedido a Gemini una respuesta minúscula para probar el enlace, y el modelo había agotado su presupuesto de respuesta pensando sin escribir nada. El nuevo programa detectó esa salida interrumpida en lugar de dejarla pasar. Es exactamente lo que el antiguo script jamás habría hecho.

La prueba real tuvo lugar después en el sitio, como borrador. El programa eligió un tema, “The Essential Website Maintenance Checklist for Small Businesses”, redactó el artículo, lo adaptó a los otros tres idiomas sin errores bloqueantes, fabricó las imágenes y depositó los cuatro borradores, enlazados entre sí. Todo duró unos seis minutos.

Después, una auditoría independiente revisó los cuatro borradores en el sitio: títulos, descripciones, imagen destacada, dos imágenes en el texto con sus textos alternativos, cuatro enlaces internos que apuntaban a artículos publicados en el idioma correcto, botón de contacto, estructura idéntica a lo enviado. Ningún problema. Un nuevo lanzamiento inmediato del programa fue, por su parte, rechazado al instante: ya se había creado un artículo ese día, y la protección antiduplicados hizo su trabajo.

Lo que la IA no hace por mí

Una persona y un robot que se dan la mano junto a una balanza y un cartel indicador
Algunas decisiones siguen siendo humanas: la máquina propone, yo decido.

El informe que Claude me entregó al final de la reparación contiene un apartado entero titulado “Decisiones que te corresponden”. Dice mucho sobre el reparto de papeles. Una máquina puede comprobar que un enlace funciona, que un fragmento de código está intacto, que un título es idéntico a su fuente. No puede decidir lo que mi agencia quiere contar, ni los riesgos que acepta correr. Esto es lo que quedó sobre mi mesa.

Las decisiones editoriales

Los duplicados. Tres traducciones “huérfanas” (en francés, español e italiano) son duplicados de baja calidad de un artículo sobre meta descripciones que ya estaba en el sitio. Claude las limpió y las volvió a publicar, pero me advirtió de que lo más limpio sería redirigirlas al artículo principal o retirarlas. Conservar, redirigir o despublicar: es una decisión de SEO, por tanto, una decisión de jefe.

La actualidad. Entre los artículos de Gemini, algunos comentaban la actualidad de grandes marcas: un fabricante de coches, plataformas de streaming, gigantes tecnológicos. Contienen cifras y afirmaciones que nadie ha verificado en la fuente, y Claude me recomendó una revisión humana de los hechos. Estos temas, además, están muy lejos de mi oficio, lo que devuelve a una pregunta más sencilla: ¿de verdad necesito hablar de ellos?

La competencia entre mis propios artículos. Varios artículos apuntan a palabras clave muy cercanas (las meta descripciones, los títulos generados por IA, el contenido escrito por IA). Cuando dos páginas de un mismo sitio responden a la misma búsqueda, Google tiene que elegir, y no siempre elige la que uno habría preferido. Fusionar, diferenciar o impulsar uno de los dos: me toca arbitrar a mí.

Los títulos y las imágenes. Una vez añadido el nombre de la agencia, 90 títulos de 91 superan los sesenta caracteres, y Google puede cortarlos en sus resultados. En una imagen fabricada por la IA hay una palabra mal escrita; en otro artículo falta una imagen. Son defectos menores, pero afectan a la imagen de la agencia: yo decido cómo tratarlos.

Publicar o no publicar

El nuevo generador deposita sus artículos como borradores, igual que el antiguo. Una opción permitiría publicarlos solos cuando todos los controles estén en verde; no la he activado, y los temas de actualidad se quedarían de todos modos en borrador. Un solo ensayo completo con artículos de verdad no basta para confiar el escaparate de la agencia a un automatismo. Decidiré después de observar varios días de producción.

Lo que sigue siendo imperfecto

Prefiero ser honesto sobre lo que no está resuelto. El filtro del sitio que borraba todo lo que había entre llaves está sorteado, pero no explicado: sabemos cómo es y cómo evitarlo, no qué elemento del sitio lo aplica. Es como fregar una fuga sin haber encontrado la tubería. Un módulo de enlaces internos inserta además enlaces en los bloques de código, donde no pintan nada; no es grave, pero sigue pendiente de arreglar. Por último, por higiene, hay que renovar algunos accesos al sitio. Es un trabajo de seguridad, me corresponde a mí, y de hecho Claude se abstuvo de tocarlo: no diré más aquí.

Nada de esto es un fracaso de la IA. El día que un asistente te anuncie que todo es perfecto, es hora de desconfiar. Este me entregó la lista de lo que no lo es.

Manual de uso: diez reglas para automatizar un blog con IA sin caer en trampas

Si tienes un blog, aunque sea modesto, y piensas confiar parte del trabajo a una IA, esto es lo que me ha enseñado esta aventura. No son principios teóricos: cada una de estas reglas corresponde a un incidente real de este relato.

  1. No publiques nunca sin que nadie haya mirado. Mi generador publicaba cada mañana sin ningún control humano. Hizo falta una auditoría completa para medir la magnitud de los daños. Un borrador cuesta un minuto de revisión; un artículo roto en línea cuesta la confianza de los lectores.
  2. Separa la escritura, la maquetación y el control. La IA redacta, un programa previsible fabrica la página, una tercera capa verifica. Cuando una sola herramienta lo hace todo, se controla a sí misma, y eso no es un control.
  3. Pide una estructura, no un texto ya maquetado. En lugar de reclamar un artículo para convertirlo después, se piden bloques identificados (títulos, párrafos, listas, tablas, código) que el programa ensambla por sí mismo.
  4. Convierte cada defecto en una regla. La palabrita italiana “ai” convertida en la sigla “AI” en treinta y cinco sitios no solo se corrigió: dio origen a un control automático. El generador aplica hoy más de treinta.
  5. Prueba de verdad, pero de forma reversible. Antes de cada modificación del sitio en línea, una copia de seguridad; después, una relectura y una vuelta atrás automática si algo falla.
  6. Verifica como un visitante, no como un desarrollador. Mirar lo que contiene la base de datos no basta: hay que abrir la página pública. Fue comparando lo que el sitio mostraba de verdad con lo que le habíamos enviado como apareció el misterio de las llaves.
  7. Empieza con borradores. Te dejan el derecho a equivocarte y el último minuto para enmendar un error.
  8. Vigila los textos cortados. Una IA puede detenerse a mitad de una frase sin avisar. El generador comprueba ahora que cada respuesta ha terminado con normalidad, y rechaza un artículo que no acaba bien.
  9. Prefiere los temas duraderos y verifica los datos. Una guía práctica envejece bien. Un artículo de actualidad exige cifras exactas, que una IA a veces inventa con un aplomo perfecto.
  10. Mantén tus contraseñas fuera del código y exige rastros de lo que hacen tus tareas automáticas. Los accesos están ahora en un archivo aparte. Y cada ejecución deja un diario y un código de salida legibles, porque fue una simple pausa olvidada al final de un archivo de arranque la que había bloqueado la tarea de la mañana.

Ninguna de estas reglas está reservada a los desarrolladores. Todas se reducen a la misma idea: conseguir que el error sea visible antes de que llegue al lector.

Una memoria para lo que viene

Última petición de esta serie, y no la menor: le pedí a Claude que conservara una memoria de todo lo que hemos hecho, para recurrir a ella cada vez que creemos artículos nuevos. Un artículo más no parte, pues, de cero: hereda lo que los anteriores han enseñado a este sitio.

En concreto, esta memoria retiene cinco cosas:

  • las reglas editoriales aprendidas a las malas (las mayúsculas italianas, el tuteo español, las marcas que no se traducen);
  • la organización del generador y de sus archivos;
  • el funcionamiento de la tarea de las 10:14 y sus trampas;
  • el historial de incidentes, con su causa;
  • la lista de lo que queda por decidir.

No contiene, en cambio, ni contraseñas ni claves: esos secretos no tienen nada que hacer en una memoria. El hábito sirve para cualquier proyecto. Después de una obra, pídele a tu asistente que anote lo que conviene recordar: quince días de tanteos se convierten así en un saber hacer, en lugar de quedarse en una simple anécdota.

Qué ha cambiado desde el 1 de octubre

Un escritorio por la mañana con un portátil, un café, una pila de borradores y un pequeño robot que saluda
Mañana a las 10:14: me esperará un nuevo borrador.

El 1 de octubre tenía un blog que publicaba cada día gracias a un script que yo creía bajo control. El 15 tengo noventa y una páginas auditadas y reparadas una a una, verificadas en el sitio en línea como lo haría un visitante; un generador completamente reconstruido; una tarea programada que ya no se queda bloqueada; y una primera prueba real que produjo cuatro borradores enlazados en cuatro idiomas, controlados incluso antes de que yo los abriera.

Lo que hay que retener: Gemini sigue escribiendo los artículos de la mañana. Lo que ha cambiado no es el nombre del modelo: es todo lo que hay alrededor. Una estructura impuesta, un ensamblaje previsible, controles que bloquean, borradores, un diario, copias de seguridad. No he aprendido que una IA sea mejor que otra. He aprendido que a una IA se la dirige como a cualquier colaborador: le explicas lo que esperas, verificas lo que te entrega y montas el sistema que permite enmendar el error.

También he aprendido a pedir. Lo que de verdad me sirvió fue exigir un análisis detallado antes de actuar, una verificación real después y un informe que diga lo que queda por hacer. El resultado es mejor, pero sobre todo ahora sé por qué lo es.

Esta es la clase de rigor que intento aportar a los proyectos de mis clientes: sitios web, automatizaciones, contenidos. Si tienes un blog que publica solo y que nadie ha leído nunca entero, o si quieres automatizar sin perder el control, hablemos. Miraremos juntos lo que es sólido, lo que lo es menos y qué conviene hacer primero.

Mañana a las 10:14 se generará un nuevo artículo. Me esperará como borrador, y me parece muy bien así.

Anexo: pequeño glosario para no perderse

Algunas palabras vuelven una y otra vez en este relato. Aquí están, sin jerga.

  • Script: un pequeño programa, escrito aquí en Python, que ejecuta una serie de instrucciones sin intervención humana.
  • Tarea programada: un despertador para ordenadores. Windows lanza el programa a la hora fijada, haya o no alguien delante de la pantalla.
  • Gemini, Claude: dos asistentes de inteligencia artificial, el primero creado por Google y el segundo por Anthropic.
  • Token: la unidad de medida del texto para una IA, más o menos un trozo de palabra. La longitud de una respuesta se limita en tokens.
  • WordPress, Avada, WPML: WordPress es el software que hace funcionar mi sitio; Avada, su tema, es decir, su aspecto; WPML, el módulo que gestiona las versiones en varios idiomas y vincula cada página con sus traducciones.
  • Plugin: un módulo que se añade a WordPress para darle una función suplementaria (SEO, traducción, enlaces internos…).
  • Borrador: un artículo guardado en el sitio pero invisible para el público, a la espera de revisión.
  • Lenguaje de marcado (HTML, Markdown): el HTML es el lenguaje de las páginas web. Markdown es una escritura simplificada, con asteriscos y almohadillas, que luego se convierte en HTML; cuando la conversión falla, esos signos quedan visibles en el texto.
  • Entidad: una manera de escribir un carácter reservado en una página web. El signo “menor que” se escribe <.
  • Expresión regular: una fórmula de búsqueda y sustitución, muy potente y muy frágil, que el antiguo script usaba para “limpiar” el texto.
  • SEO: el conjunto de prácticas que ayudan a que una página aparezca en los resultados de Google.
  • Palabra clave principal: la expresión con la que una página busca posicionarse en los resultados. Cuando dos páginas apuntan a la misma, compiten entre sí: es la canibalización.
  • Auditoría: una revisión metódica y cuantificada, aquí realizada por un programa.
  • Código de salida: el pequeño número que devuelve un programa al terminar, cero si todo ha ido bien, otra cosa en caso contrario. Es lo que permite a una tarea automática señalar un fallo.
  • Vuelta atrás: el regreso automático a la versión anterior de una página cuando una verificación falla.

¿Te falta alguna palabra? Dímelo y la añadiré a este glosario.

¿Listo para escalar tu infraestructura digital?

No dejes que los cuellos de botella técnicos frenen tu crecimiento. Habla de tu proyecto en torno a Cuando mi generador rompió 91 páginas: la historia de una reparación directamente con nuestros expertos sénior de Low Cost Web Agency.

💬 Contáctanos por WhatsApp (+919786495150)