TL;DR
Cuando alguien oye “crear un sitio de artículos con IA”, es fácil imaginar esto:
Pido a la IA 100 artículos, los subo y ya está.
No.
Eso es como comprar una fotocopiadora y anunciar que has construido una biblioteca.
Un sitio serio debe seguir siendo comprensible cuando crece. El lector no debe perderse. Una traducción antigua no debe fingir que está actualizada. Los 12 idiomas no deben cruzarse. Los enlaces no deben romperse. Dos automatizaciones no deben sobrescribirse. Y, cuando ocurre un accidente, el sistema debe detectarlo y recuperarse de forma segura.
Por eso la IA no es solo una “máquina de escribir”. Es un equipo de redactores, editores, inspectores, bibliotecarios, constructores de carreteras y mantenimiento.
El sistema completo se puede resumir en diez pasos:
- Define para qué existe el sitio.
- Prepara el terreno y el almacén del contenido.
- Da a cada artículo una identidad estable y una huella de versión.
- Crea primero un buen artículo en un idioma fuente.
- Haz QA antes de traducir.
- Expande a 12 idiomas sin copiar errores.
- Construye enlaces internos y hubs como carreteras y puntos de información.
- Haz funcionar la fábrica por estados, no solo por horarios.
- No llames “publicado” a algo hasta verificar la página real de producción.
- Compara continuamente el sitio con un estado ideal de 100 puntos y repara las diferencias.
Si solo dices “IA, hazme un sitio bonito”, la asociación vecinal de las IA puede construir tres casas iguales y seis carreteras hacia ninguna parte.
Lo importante no es una IA más inteligente.
Es un sistema más seguro.
Modelo mental: sitio = biblioteca + red de carreteras + fábrica
- Artículo = libro
- Sitio = biblioteca
- Categoría = estantería
- Artículo hub = mostrador de información
- Enlace interno = carretera
- URL = dirección
- ID del artículo = número de registro estable
- SHA / hash = huella digital de una versión
- GitHub = almacén de archivos e historial
- QA = corrección con bolígrafo rojo del profesor
- Deploy = abrir de verdad la biblioteca
- Rutina de monitorización = vigilante nocturno
- CAS / actualización condicional = “cámbialo solo si sigue siendo la edición 3”
- Token de etapa = sello que dice “esta versión exacta superó esta etapa”
Con esta imagen, muchas palabras técnicas dejan de dar miedo.
1. Decide qué problema resuelve el sitio
1-1. No uses el número de artículos como objetivo
Mal objetivo:
Publicar 100 artículos al día.
Si 30 responden a lo mismo, los enlaces están rotos y las traducciones son antiguas, no has creado conocimiento.
Has fabricado 100 bolsas de basura a gran velocidad.
Un buen objetivo describe lo que puede hacer el lector:
- encontrar una respuesta rápido
- saber por dónde empezar
- avanzar hacia explicaciones más profundas
- entender cómo se relacionan los artículos
- llegar al mismo significado en su propio idioma
1-2. Define reglas que la IA nunca puede romper
Por ejemplo:
- no exponer datos personales
- no cambiar fechas o cifras sin motivo
- no inventar fuentes
- no tratar traducciones antiguas como actuales
- no publicar URL rotas
- no enviar a un lector japonés a un artículo inglés irrelevante como fallback de contenido
- no dejar que dos workers sobrescriban silenciosamente el mismo trabajo
- no aceptar “la IA dice que terminó” como evidencia
Estas reglas son las vallas de seguridad de la fábrica.
1-3. Escribe el estado ideal de 100 puntos
Cuando el ideal está escrito, el sistema puede preguntar:
¿Cuántos puntos tenemos ahora?
¿Dónde se pierden?
¿Qué se puede reparar de forma segura?
¿Qué puntuación queda después?
Eso es el ciclo básico de QC: definir calidad, observar la diferencia, reparar y volver a verificar.
2. Prepara el terreno y el almacén
2-1. Configuración mínima
Para empezar basta con:
- dominio
- GitHub
- framework web
- hosting
- analítica
Astro, Next.js, Eleventy u otros sirven. La marca importa menos que el principio:
separa los datos del contenido del programa que los muestra.
2-2. Separa el original de los resultados generados
No dejes que todos los procesos automáticos reescriban el archivo fuente.
Conviene separar:
- artículo fuente
- versión editada
- traducciones
- overlays de enlaces internos
- evidencia de QA
- estado de publicación
En una cocina no dejamos que todos los cocineros echen salsa directamente sobre la carne cruda dentro del frigorífico.
Preparación, cocción, emplatado e inspección son etapas distintas.
2-3. Usa Git como máquina del tiempo
La automatización debe:
- hacer cambios pequeños y explicables
- registrar por qué se cambió algo
- evitar force push y sobrescrituras
- guardar checkpoints en lotes largos
3. Da a cada artículo una identidad estable y una huella
3-1. No dependas solo de la URL
La URL y el título pueden cambiar.
Usa un ID lógico estable:
articleFamilyId = article_000123
Las versiones japonesa, inglesa y coreana del mismo contenido comparten ese family ID.
3-2. Trata locale como otra dimensión
article_000123 + ja
article_000123 + en
article_000123 + ko
Así puedes saber:
- inglés está obsoleto
- coreano falta
- japonés cambió hoy
- francés sigue current
3-3. El hash es una huella digital
Si cambia el contenido, cambia la huella.
Entonces puedes responder:
¿De qué versión japonesa salió esta traducción inglesa?
Si el japonés cambió y el inglés aún apunta a la huella antigua, el inglés está stale.
No hace falta discutir con la IA.
La evidencia decide.
3-4. Guarda estados explícitos
Por ejemplo:
- borrador
- QA del original superado
- traduciendo
- QA de traducción superado
- navegación validada
- elegible para publicación
- publicado
- obsoleto
La máquina de estados es la columna vertebral de la automatización.
4. Crea primero un buen original
4-1. No traduzcas un original malo
Traducir un mal original a 11 idiomas es internacionalizar el bug.
Enhorabuena: el error ya tiene distribución mundial.
Termina primero un idioma fuente.
4-2. Mínimos de un buen artículo
- título que deja claro qué resuelve
- comienzo que responde a la duda
- estructura comprensible solo leyendo encabezados
- términos difíciles explicados
- ejemplos concretos
- números, fechas, nombres e incertidumbre preservados
- hechos y opiniones separados
- fuentes cuando hagan falta
- sin datos personales
- poca repetición
- menos prosa genérica de plantilla IA
4-3. El humor debe ayudar a entender
Ejemplo:
Traducir un original roto a 11 idiomas es como clonar una casa torcida once veces.
La broma ayuda a recordar la regla.
Una broma sin relación es un espectáculo callejero en medio de una obra.
5. Haz QA antes de traducir
5-1. Generado no significa terminado
La salida de la IA es una entrega, no una nota aprobatoria.
Comprueba:
- coherencia entre título y cuerpo
- hechos intactos
- fechas, precios y unidades correctos
- URL existentes
- citas y fuentes intactas
- Markdown/HTML válido
- jerarquía de encabezados sensata
- datos personales eliminados
- no se añadió certeza peligrosa
- no duplica la intención de otro artículo
5-2. Guarda evidencia, no solo un semáforo verde
Registra:
- ID
- huella fuente
- huella de salida
- resultado QA
- qué cambió
- qué regla justificó el resultado
“¿Hiciste los deberes?”
“Sí.”
Prueba débil.
“Enséñame el cuaderno.”
Mucho mejor.
5-3. Un fallo no debe parar toda la fábrica
Si 1 de 100 artículos no se puede procesar:
- aplázalo
- guarda la razón
- continúa con otro elegible
Un tornillo suelto no exige apagar toda la ciudad.
6. Expande a 12 idiomas
6-1. Fija la lista de locales
Por ejemplo:
ja / en / ko / zh-Hans / zh-Hant / es / pt-BR / id / th / vi / fr / de
Una lista fija simplifica URL, QA, hreflang, sitemap y enlaces.
6-2. Usa una URL distinta por idioma
/ja/articles/...
/en/articles/...
/ko/articles/...
Usa hreflang para indicar que son variantes lingüísticas del mismo artículo.
6-3. Reutiliza traducciones actuales
- current → reutilizar
- stale → actualizar solo ese locale
- missing → crear
Retraducir todo cada vez cuesta más y crea más oportunidades de error.
6-4. No copies el orden de palabras japonés
Traducir no es sustituir palabras.
Adapta por idioma:
- longitud de frase
- encabezados
- conectores
- bromas
- texto de enlace
- orden de explicación
Conserva el significado, no la forma.
6-5. QA por artículo × locale
Que el inglés pase QA no dice nada sobre el tailandés.
Un fallo local debe poder aplazar solo ese locale.
7. Construye carreteras con enlaces internos y hubs
7-1. No añadas enlaces para llenar una cuota
Un buen anchor explica el destino.
Bueno:
Si eres principiante, empieza por la guía para elegir la concentración de retinol.
Malo:
Haz clic aquí.
Una señal que dice “por allí” no ayuda mucho.
7-2. Separa tipos de enlace
Como mínimo:
- Hub structural — mostrador → artículo detallado
- Body contextual — referencia natural dentro del texto
- Related recommendation — siguiente lectura
- Language alternate — mismo artículo, otro idioma
- Breadcrumb — vuelta por la jerarquía
Si todo es “un enlace”, las reglas acabarán chocando.
7-3. La navegación de contenido debe quedarse en el mismo idioma
Si falta el objetivo japonés, no hagas fallback automático a una página inglesa.
Cambiar de idioma y cambiar de tema son acciones distintas.
7-4. Un hub no es un almacén de URL
Un buen hub explica:
- qué cubre el tema
- para quién es
- por dónde empieza un principiante
- subtemas principales
- qué artículo detallado responde a cada duda
Veinte URL desnudas son un mostrador donde el empleado se fue a casa y dejó un mapa sobre la silla.
7-5. Promueve un artículo amplio existente antes de crear otro hub
Si no, acabas con:
- Guía completa
- Guía definitiva
- Mega guía
- Todo lo que debes saber
peleando por la misma intención.
No es arquitectura de información.
Es battle royale SEO.
7-6. Candidatos automáticos + revisión semántica
La generación de candidatos puede usar:
- significado del texto
- grafo de enlaces
- viajes reales de usuarios
- intención de búsqueda
- riesgo de duplicación
Pero antes de aplicar debe explicar por qué la relación es útil.
8. Haz funcionar la fábrica por estado, no solo por reloj
8-1. El horario es un despertador
Puedes programar:
- minuto 02: hub
- 07: original
- 27: traducción
- 37: enlaces
- 58: publicación
Pero el minuto 27 no demuestra que el original terminó.
El reloj despierta al worker.
El estado le da permiso.
8-2. Mira los sellos de etapas anteriores
Antes de traducir:
- original current
- QA current
- ID correcto
- huella correcta
Antes de enlazar:
- locale current
- route current
- calidad current
Antes de publicar se añaden SEO y validación.
8-3. Usa tokens basados en contenido
done=true es demasiado débil.
Un token fuerte puede representar:
article ID
+ locale
+ content hash
+ route
+ rule version
+ upstream token
Si cambia el upstream, el token downstream antiguo queda stale.
8-4. Usa CAS / actualización condicional
Dos IA leen la versión 3.
A escribe versión 4.
B intenta escribir después basándose en la 3.
Sin protección, B borra el trabajo de A.
Regla segura:
escribe solo si el recurso sigue siendo la versión que leí.
Si no, vuelve a leer o difiere.
8-5. Guarda checkpoints
Si el lote es 50, guarda cada pocos éxitos.
Si se corta en el 20, continúa desde el 21.
Los videojuegos resolvieron esto hace décadas: guarda la partida.
9. Un commit en GitHub no equivale a publicación
9-1. Publicar es una cadena
contenido completo
↓
traducciones current
↓
navegación validada
↓
validation superada
↓
publicación permitida
↓
deploy
↓
HTML real verificado
↓
production verified
9-2. No fuerces locales incompletos
Un locale stale puede esperar.
Los demás podrán avanzar solo si la política formal de publicación lo permite.
9-3. Revisa la fontanería SEO
- title
- description
- canonical
- hreflang
- sitemap
- robots/indexability
- structured data
- 404/redirect
- enlaces internos
Los mapas multilingües se cablean mal con facilidad.
9-4. Descarga la página real de producción
Commit, build y deploy exitosos siguen sin ser prueba completa.
Comprueba en la URL real:
- HTTP 200
- contenido actual
- idioma correcto
- title/meta
- canonical/hreflang
- enlaces funcionando
No declares “entrega completada” porque la comida sigue en la puerta de tu casa.
10. Haz que el sitio vuelva siempre a 100 puntos
10-1. Ciclo QC
observar
↓
puntuar
↓
encontrar diferencias
↓
clasificar causa
↓
reparar con seguridad
↓
volver a probar
↓
volver a puntuar
10-2. Hard gates contra el maquillaje de puntuaciones
Aunque la suma dé 100, no puede declararse 100 si existe:
- enlace roto
- enlace de contenido a locale incorrecto
- traducción stale tratada como current
- miembro hub inexistente
- doble registro de éxito formal
- lost update
- evidencia de validation falsa
10-3. Un incidente repetido debe mejorar la fábrica
Si el mismo problema vuelve:
- ¿falla el contrato?
- ¿falta validator?
- ¿el modelo de estado es débil?
- ¿falta control de concurrencia?
- ¿hay colisión de horarios?
- ¿es infraestructura externa?
La meta pasa de “reparar el producto” a “producir menos defectos”.
10-4. No apagues la monitorización al llegar a 100
Hoy puede estar a 100 y mañana a 98 tras añadir contenido.
Es normal.
La rutina debe devolverlo a 100.
Que ayer no hubiera ladrones no es razón para tirar la cerradura.
El sistema entero en 30 segundos
Humano define objetivo + límites
↓
estado ideal de 100 puntos
↓
IA crea original
↓
QA + evidencia
↓
expansión a 11 idiomas
↓
QA por locale
↓
enlaces + hubs
↓
estado/huella/token
↓
validación
↓
política de publicación
↓
deploy
↓
URL/HTML real
↓
medición de comportamiento
↓
comparación con ideal
↓
reparación segura
└────→ repetir
Diez accidentes clásicos
- 100 artículos, 30 responden a lo mismo
- Un error fuente se distribuye en 12 idiomas
- La traducción existe, pero está stale
- Página japonesa salta a artículo inglés
- Tantos hubs que el mostrador se vuelve el destino
- Todos los anchors dicen “haz clic aquí”
- Dos IA sobrescriben el mismo artículo
- Objetivo 50, un éxito y “completado”
- Confundir commit con producción
- La monitorización encuentra un fallo y alguien apaga la monitorización
El número 10 es como desenchufar la alarma porque detectó humo.
Checklist mínimo
Diseño
- ☐ objetivo del lector
- ☐ estado ideal 100
- ☐ prohibiciones
- ☐ ID estable
- ☐ locale separado
- ☐ hash de contenido
Contenido
- ☐ QA del original
- ☐ privacidad
- ☐ hechos/cifras/URL protegidos
- ☐ ejemplos
- ☐ menos plantilla IA
Multilingüe
- ☐ URL por idioma
- ☐ hreflang
- ☐ huella fuente
- ☐ actualizar solo stale
- ☐ QA por locale
- ☐ sin fallback cross-locale de contenido
Enlaces/hubs
- ☐ hub structural separado de body links
- ☐ anchors descriptivos
- ☐ auditoría orphan
- ☐ broken/self/duplicate/cross-locale
- ☐ comprobar promoción antes de crear hub
- ☐ auditoría de hubs duplicados
Automatización
- ☐ gates por state/hash/token
- ☐ claim/CAS
- ☐ checkpoints
- ☐ exactly-once formal success
- ☐ un fallo no para todo
Publicación
- ☐ validation
- ☐ canonical/hreflang/sitemap
- ☐ política de publicación
- ☐ URL real
- ☐ HTML real
Mantenimiento
- ☐ auditoría periódica 100 puntos
- ☐ hard gates
- ☐ corregir causa raíz
- ☐ monitorizar también después de 100
Lección final
El mejor sitio de artículos con IA no es el que usa el modelo más caro.
Es el que puede detectar errores y volver a un estado correcto cuando la IA se equivoca, el contenido queda viejo, varios procesos corren a la vez o una plataforma externa falla.
El humano define objetivo, ideal, límites y responsabilidad final.
La IA genera, compara, inspecciona, repara y registra.
Y la prueba de finalización vive en:
- hashes
- tests
- historial Git
- URL reales
- HTML real
- comportamiento del lector
Llegados aquí, ya no tienes solo un blog.
Tienes una mini editorial + biblioteca + autoridad de carreteras + fábrica QC funcionando dentro de un repositorio.
Empieza con un artículo.
Ponle ID.
Añade QA.
Añade un idioma.
Añade enlaces seguros.
Añade estados.
Construye capa por capa.
No necesitas una estación espacial el primer día.
Pero tampoco compres 100 fotocopiadoras y declares “estación espacial terminada”.
