Cuando se habla de automatizar las redes sociales, la conversación suele quedarse en "publicar todos los días a las 9 de la mañana" o "dejar que la IA escriba el texto".
Pero lo realmente difícil no es el botón de publicar.
Repartir solo los artículos correctos. No publicar nada dos veces. Que la caída de un servicio no pare todo lo demás. No saltarse un CAPTCHA a la fuerza. Pasar a una persona solo lo que únicamente una persona puede hacer. Y, después de repartir, usar los resultados para cambiar cómo se reparte la próxima vez.
Cuando todo eso encaja, por fin se puede decir que la distribución está automatizada.
Si manejas 12 idiomas, varias redes sociales y hasta un boletín por correo, la distribución ya no es una función de programar publicaciones. Es un pequeño sistema distribuido.
1. El objetivo no es "sin humanos": es "las personas solo gestionan las excepciones"
Si defines la meta de la automatización como "que nadie toque nada", el diseño se tuerce.
Los servicios externos reales tienen CAPTCHA para comprobar que eres una persona, verificación por SMS, doble factor (2FA), verificación de identidad, aceptación expresa de las condiciones de uso, revisión de apps para desarrolladores... Eso no es una avería. Es un límite que el servicio decidió poner a propósito: "aquí pasa solo el titular".
Así que la forma final es esta:
Generar el artículo → Revisar la calidad → Versión en cada idioma → Publicación en producción → Releer el HTML de producción → Candidato a distribución → Texto de cada idioma → Redes sociales y boletín → Recoger resultados → Decidir la próxima distribución
Si en el camino aparece algo que solo una persona puede resolver, se le pasa únicamente ese caso.
Por ejemplo, si solo el X en japonés pide un CAPTCHA, solo el X en japonés espera. No hace falta dejar a Bluesky en inglés, a Facebook en francés, al boletín, a la analítica y a la generación del siguiente artículo sentados en penitencia.
No hace falta que los 12 idiomas guarden luto por un solo CAPTCHA.
Productos de flujos de trabajo duraderos, como Cloudflare Workflows, también están pensados para conservar estado durante mucho tiempo, reintentar los pasos fallidos y esperar eventos externos o aprobación humana. Lo importante no es usar un producto concreto, sino tratar la espera de una persona como un estado más y no como una parada del sistema.
2. Separar "el artículo está listo" de "ya se puede repartir"
Si conectas la capa de distribución directamente a la generación de artículos, es fácil que haya accidentes.
El Markdown se guardó. La traducción terminó. La compilación pasó.
Nada de eso garantiza que "el lector pueda abrir esa URL ahora mismo y leerla bien".
Por eso la unidad que se puede distribuir no es el nombre del artículo, sino
articleId × locale × contentSha
Y en redes sociales se afina todavía más:
articleId × locale × contentSha × platform × campaignType
Lo importante aquí es contentSha. Aunque la URL sea la misma, si el cuerpo cambia, es otra revisión. No se debe lanzar como anuncio de un texto nuevo una publicación creada para un texto antiguo.
Y la condición para pasar algo a distribución no es "está en GitHub", sino haber releído y comprobado el HTML de producción de ese locale y de ese contentSha.
Lo que necesita la entrada de la publicación automática no es "¿hay un borrador?", sino "¿hay un producto terminado que el lector pueda abrir ahora?".
3. Un tiempo de espera agotado no significa fallo: si te equivocas aquí, nacen las publicaciones gemelas
Lo que da miedo de las API externas no son los errores claros, sino los ambiguos.
Enviaste la publicación a la API. Tu lado agotó el tiempo de espera. No hay respuesta.
En ese momento, si piensas:
"Parece que falló. Lo envío otra vez",
y el primer envío en realidad había funcionado, aparecen dos publicaciones idénticas.
"La API no respondió, así que por si acaso publiqué el mismo artículo tres veces" es la historia de terror de la automatización.
Cloudflare Queues usa por defecto la entrega at-least-once (al menos una vez), y en raras ocasiones un mismo mensaje puede entregarse varias veces. Por eso la documentación oficial recomienda deduplicar con un ID único o una clave de idempotencia (idempotency key).
Así que se crea una clave determinista para cada envío:
sha256(articleId + locale + contentSha + platform + campaignType)
En la tabla de recibos, esa clave se declara UNIQUE.
Ante un tiempo agotado, en lugar de reenviar de inmediato, se sigue este orden:
- Comprobar el registro de recibos
- Si se puede releer desde el proveedor, comprobar si ya se publicó
- Reintentar solo si se confirma que no se publicó
Una cola (Queue) no es "magia que ejecuta exactamente una vez". El diseño consiste en que, aunque haya duplicados, el resultado converja en uno solo.
4. Encerrar las averías en el "ámbito mínimo", no en "todo el sistema"
Lo más desperdiciado en la automatización es convertir un solo error en una avería total.
Como mínimo, el dominio de fallo (failure domain) se divide en
platform × locale × account
Si la autenticación del X en japonés caduca, solo ese queda en BLOCKED.
Si Bluesky en inglés devuelve un 429, solo ese pasa a RETRY_WAIT.
Si una página de Facebook espera verificación de identidad, solo esa pasa a HUMAN_ACTION_REQUIRED.
Los demás siguen funcionando.
Tampoco bastan dos estados, "éxito / fallo". Representa mejor la realidad dividirlos en algo como:
- READY
- ACTIVE
- DEGRADED_BUT_RUNNING
- HUMAN_ACTION_REQUIRED
- BLOCKED_PROVIDER
- RETRY_WAIT
- DISABLED_BY_POLICY
Si de 15 líneas en total 14 funcionan y solo una espera a una persona, el estado global no es "todo parado". Se parece más a DEGRADED_BUT_RUNNING.
Con un 429 no sirve la fuerza de voluntad. Si hay Retry-After, se respeta. Para los 5xx, retroceso exponencial (backoff) con tope. Para 401/403, si existe una vía legítima de renovación de credenciales, se repara una vez; si aun así no funciona, se detiene solo esa cuenta.
Los CAPTCHA y las verificaciones humanas no se meten en un bucle de reintentos automáticos. No hay API que, a golpes, evolucione en humano al cabo de 100 intentos.
5. La cola de traspaso a humanos (Human Handoff Queue) debe ser una orden de trabajo, no un "ayuda"
Si el mecanismo para pasar el trabajo a una persona es chapucero, al final de la automatización queda una montaña de trabajo manual.
Un mal traspaso es este:
"Las redes están paradas. Por favor, revísalo."
¿El qué? ¿Dónde? ¿Solo iniciar sesión? ¿Hay que cambiar ajustes? ¿Qué se hace al terminar?
Un buen traspaso incluye, como mínimo, por cada caso:
- platform
- locale
- account
- blockerType
- hora de detección
- hora en que se puede reintentar
- URL que hay que abrir
- lo que debe hacer la persona
- lo que no debe hacer
- qué volverá a comprobar el sistema automático al terminar
- el ámbito que detiene este bloqueo
- si se puede seguir con el resto del trabajo
Por ejemplo:
"Inicia sesión en la cuenta oficial de este idioma y completa únicamente el CAPTCHA que aparece. No cambies la configuración de publicación ni el perfil. Al terminar, en la próxima ronda el sistema releerá el estado de autenticación y reanudará desde una publicación de prueba (canary)."
Con eso se entiende a la primera.
Y lo importante: no se automatiza la resolución del CAPTCHA.
Usar un solver, falsificar el desafío, esquivarlo por vías no oficiales: eso no es automatizar, es ir hacia romper el límite que puso la otra parte.
A las personas se las saca de la publicación diaria y solo se les deja el límite que la máquina no puede cruzar legítimamente.
Las contraseñas, los tokens OAuth de acceso y de refresco, las cookies de sesión, los códigos SMS/2FA, los códigos de recuperación y los secretos de API privados no se dejan en GitHub ni en los registros normales. En GitHub solo se guarda lo no secreto necesario para reanudar: el handle público, el estado, el error saneado, el ID del recibo, la URL pública de la publicación, etc.
6. No mezclar la publicación automática con los bots de interacción
Que una cuenta oficial publique automáticamente artículos de su propio sitio es un asunto distinto de automatizar los me gusta, los seguimientos, las respuestas y hasta los mensajes directos.
Las Automation Rules de X, en su versión de abril de 2026, permiten las publicaciones automáticas útiles e informativas que cumplan las reglas, pero prohíben eludir los límites de tasa (rate limit) de la API, la automatización sin API que manipula un sitio web con scripts y las publicaciones de spam o duplicadas. Además, los "me gusta" automáticos están prohibidos.
Por eso los valores iniciales pueden ser bastante sobrios:
- AUTO_PUBLISH = true
- AUTO_LIKE = false
- AUTO_FOLLOW = false
- AUTO_UNFOLLOW = false
- AUTO_REPLY = false
- AUTO_DM = false
Primero se limita la responsabilidad a "entregar bien los artículos oficiales".
Bluesky también permite crear publicaciones con su API oficial, y cada publicación puede llevar información de idioma. Es decir, en una operación multilingüe resulta más natural alinear el cuerpo y los metadatos de idioma de cada locale que lanzar el texto en inglés a todas partes.
La automatización del navegador se limita a apoyar situaciones como la configuración inicial de cuentas, donde no hay API oficial o donde las operaciones humanas están permitidas. Para la distribución regular, conviene apoyarse en lo posible en las API oficiales y la autenticación oficial.
Los canales iniciales se deciden por locale, por ejemplo: ja→X, en→X/Bluesky, ko→X, zh-Hans→Weibo, zh-Hant→Facebook/Threads, es・pt-BR・id・th・vi・fr→Facebook, de→Facebook/X. Las superficies centradas en imagen y vídeo, como Instagram, TikTok y Reels, se dejan para una segunda fase, cuando la generación de tarjetas y el control de calidad de medios (media QA) sean estables. Las API, las políticas de automatización y las condiciones de uso de cada plataforma hay que volver a comprobarlas siempre en el momento de implementar.
7. Operar en 12 idiomas no es un "torneo de traducir publicaciones en japonés"
En los sitios multilingües pasa un accidente típico.
Se tradujo el artículo japonés a 12 idiomas. Se creó un único texto de red social en japonés. También se tradujo a 11 idiomas. Listo.
Así, el sentido de haber pasado el cuerpo a 12 idiomas se diluye.
El texto de la publicación se crea leyendo el cuerpo realmente publicado en ese locale, como si la cuenta oficial del sitio en ese idioma soltara un comentario.
La forma básica es corta:
Esto, aunque parezca poco, es lo que más cuesta. 🫠 URL
o bien,
¿Eso también se puede automatizar? 👀 URL
No hacen falta resúmenes largos ni "imperdible", "impactante" o "míralo ya". Y es raro que, siendo una publicación del propio sitio, se fabrique un falso testimonio, como si un tercero lo hubiera encontrado por casualidad y se hubiera emocionado.
La personalidad de marca es común, pero la redacción se hace natural en cada idioma. No se finge que lo lleven personas distintas.
Además, medicina, derecho, inversión, grandes sumas de dinero, desastres, delitos, muertes, autolesiones, violencia, abuso sexual, menores, seguridad, política y elecciones, y los conflictos fuertes pasan al serious mode.
En ese caso, por principio, sin emojis, sin sensacionalismo y sin afirmar más de lo que dice el artículo. Si es un artículo político, no se añade automáticamente un respaldo (endorsement).
El "modo broma a tope" no es un ajuste universal. En un artículo sobre ambulancias no hace falta poner 🫠.
8. El boletín no es la "versión por correo de las redes": es la misma filosofía de distribución sobre otro adaptador
Tampoco el boletín debe enviarse directamente desde la generación del cuerpo.
Como mínimo se guardan
- explicit opt-in
- locale
- topics
- consentAt
- status
- unsubscribeAt
- createdAt
y no se envía el mismo artículo varias veces.
También se separa lógicamente el correo de contacto del sistema de envíos masivos.
Para las respuestas de los lectores se puede usar el buzón actual, pero la base de envío debe ser un adaptador que se pueda cambiar más adelante por un proveedor especializado.
Gmail exige a los remitentes masivos autenticación de envío, evitar el correo basura y no solicitado, y un mecanismo fácil para darse de baja, y trata la baja como un requisito importante en los mensajes de suscripción.
La baja no es "probablemente se detenga en el próximo lote", sino que se saca al instante de los destinatarios.
El valor de un boletín no es reunir direcciones. Es dar la información que el lector pidió, con la frecuencia que pidió, y que pueda dejarlo en cuanto quiera.
9. Si el KPI son los "me gusta", acabas construyendo una máquina que va a por los "me gusta"
Si vas a incorporar mejora automática, lo importante es qué pones como función objetivo.
Si maximizas solo los "me gusta" de las redes, ganan los títulos más estridentes, las afirmaciones extremas y los temas que rozan la polémica.
Pero lo que de verdad quiere un sitio de artículos es otra cosa.
La prioridad puede ser, por ejemplo:
- site visit
- meaningful reading
- next article
- return visit
- newsletter signup
Es decir, se pesa más "¿vino al sitio por esa publicación?", "¿lo leyó de verdad?", "¿pasó al siguiente artículo?" y "¿volvió?".
Las campañas de distribución también se dividen en
- NEW
- UPDATED
- TRENDING
- POPULAR
- EVERGREEN
No se vuelve a publicar con un "¡gran actualización!" por haber corregido una sola letra. UPDATED es solo para actualizaciones materiales.
Para POPULAR y TRENDING, si ya existe una medición real de tráfico, se reutiliza. No hace falta inventar un ranking de popularidad aparte para la distribución y que dos cifras se declaren la guerra.
El horario de distribución tampoco se decide con un prejuicio como "como es japonés, a las 20:00", sino explorando el locale × country × platform × weekday × hour reales. Al principio se prueban varias franjas (slots) y, cuando se acumulan datos, se concentra.
10. Cómo se usa en la práctica: no "publicar", sino hacer avanzar el estado
La operación real se entiende mejor como una secuencia de transiciones de estado.
- Se publica en producción el artículo del locale correspondiente.
- Se relee el HTML de producción del contentSha exacto y se marca como PRODUCTION_VERIFIED.
- Se crea el candidato de distribución con articleId × locale × contentSha × platform × campaignType.
- Se lee el cuerpo de ese locale y se genera un texto corto de publicación.
- Se revisan la prohibición de hype, el serious mode, la longitud, la URL y el idioma.
- Se mete en el outbox con la idempotency key.
- Se envía desde la API oficial del proveedor.
- Además del recibo de la API, si es posible, se relee la publicación pública.
- Se recogen visitas al sitio, lectura completa, siguiente artículo y regreso.
- Se usa para la próxima decisión entre NEW / UPDATED / TRENDING / POPULAR / EVERGREEN.
Si por el camino aparece un CAPTCHA, solo ese ámbito pasa a HUMAN_ACTION_REQUIRED.
Si es un 429, a RETRY_WAIT.
Si el proveedor está caído, a BLOCKED_PROVIDER.
Lo demás avanza.
Tampoco se dispara de golpe a 15 cuentas desde el principio. Con cada adaptador se recorre:
lectura de la autenticación (auth readback) → simulacro (dry run) → canary con un artículo real → recibo → relectura pública (public readback) → comprobación del locale → comprobación de supresión de duplicados → comprobación de la atribución en analítica
y solo después se amplía.
Y la entrada que ve quien opera se reúne en un único current-status.
En la implementación también es más difícil multiplicar las fuentes de verdad si, en vez de crear una segunda fábrica de artículos y un segundo scheduler para la distribución, se conecta al propietario de publicación existente como post-publication child (proceso hijo posterior a la publicación) tras PRODUCTION_VERIFIED, reutilizando el durable runtime y el state store que ya existen.
Si a la pregunta "¿cómo va esto?" hay que hacer que una persona desentierre 15 JSON y registros, en ese momento la automatización le está devolviendo el trabajo a la persona.
Lo más importante de la distribución automática no es "que nada falle".
Es que, aunque falle, se sepa dónde se paró, que el alcance de la parada sea pequeño, que a las personas solo les llegue lo que solo ellas pueden hacer, que el resto avance solo y que, tras recuperarse, se continúe desde donde se quedó sin ejecutar nada dos veces.
Quitar el botón de publicar es solo el prólogo.
La verdadera automatización consiste en automatizar también la operación del día en que algo falla.
