Si marketing necesita pedirle a ingeniería cada cambio en el sitio, un agente de programación ofrece una salida atractiva. Puede leer el código, modificar el contenido y preparar una vista previa para que alguien la revise. Esa posibilidad abre una discusión más difícil que la de cómo construir una página: ¿qué tiene que cambiar en el sitio para que marketing pueda operarlo todos los días?
Dos empresas de software llegaron a respuestas distintas. Vellum, que desarrolla herramientas de IA, salió de Webflow y conservó un sistema de gestión de contenidos (CMS). Sentry, que ayuda a equipos de ingeniería a detectar y diagnosticar errores en sus aplicaciones, trasladó el contenido a archivos y reconstruyó el flujo de publicación alrededor del código. Las dos ampliaron lo que podía hacer un agente. Cada una dejó la edición, los permisos y la publicación en lugares distintos.
¿Dónde queda el contenido cuando marketing trabaja con un agente?
Vellum cambió el sitio y conservó el editor
En mayo de 2026, Anita Kirkovska contó cómo Vellum migró su sitio de Webflow, una plataforma visual para crear y gestionar sitios. El equipo reconstruyó el sitio público con el framework Next.js, adoptó Sanity para gestionar el contenido y usó Postgres como base de datos. Según Kirkovska, la migración llevó una semana y el CTO trasladó la mayor parte del contenido durante un fin de semana.
Sanity es un headless CMS. Guarda el contenido por separado y el sitio público lo consulta para mostrarlo. Así, marketing pudo seguir trabajando con un editor y campos estructurados, mientras que los asistentes conectados al CMS podían proponer cambios sobre ese mismo contenido. Cambiar una página y cambiar la manera en que el sitio la muestra son operaciones que el equipo puede manejar por separado.
Kirkovska dice que Vellum dejó de pagar unos US$30.000 anuales a Webflow y que multiplicó por diez su velocidad de publicación. El relato aporta el costo de la suscripción que se ahorraron. Para estimar el ahorro neto faltan los costos de infraestructura, servicios y trabajo técnico. También menciona problemas para reproducir diseños con precisión y mantener la coherencia entre páginas. El equipo podía publicar más rápido, pero seguía necesitando reglas compartidas para que cada landing encajara con el resto del sitio.
Sentry pasó el contenido a archivos y reconstruyó la publicación
En el sitio de marketing de Sentry, los agentes podían modificar el código, pero el contenido del CMS quedaba fuera de ese circuito. Matt Henderson explica que esa separación complicaba los pedidos que involucraban las dos cosas en su relato de la migración.
El equipo reemplazó Gatsby por Astro, otro framework web, y trasladó el contenido del CMS a archivos. Según el relato técnico de Eli Lennox, migraron unas 2.500 páginas con 2,5 desarrolladores en una ventana de dos meses. También redujeron unas 200 páginas hechas a medida a tres plantillas.
Sentry informó que el tiempo para compilar el sitio bajó de catorce minutos a menos de cuatro y que los fallos de compilación en el entorno de pruebas cayeron un 95 %. El equipo cambió a la vez el framework, las plantillas y la gestión del contenido. Con esos datos no se puede aislar el efecto de haber eliminado el CMS.
Lo más revelador es qué tuvieron que construir para que el sitio siguiera siendo editable. El equipo preparó instrucciones reutilizables para que los agentes pidieran los campos necesarios, validaran imágenes y generaran vistas previas. Los cambios pasan por verificaciones automáticas y revisión humana antes de incorporarse, y el sitio conserva controles técnicos sobre su política de seguridad de contenido. Lo que antes resolvía la plataforma quedó repartido entre el repositorio, las herramientas y quienes aprueban los cambios.
¿Qué muestran otras migraciones?
En Prefect, una empresa de software que coordina flujos de trabajo de datos, el VP de Producto reconstruyó el sitio en el equivalente a una semana de trabajo, repartida en sesiones a tiempo parcial. Los pedidos de cambio pasan de Slack a Linear, donde el equipo gestiona tareas, y de ahí a Devin, un agente de programación que prepara la primera versión para revisión humana. Cuando se publicó el caso, el sitio llevaba alrededor de una semana en producción. El relato permite ver cómo se tramita un pedido, con poco recorrido todavía para evaluar su mantenimiento.
StackOne, una empresa que ofrece integraciones para productos de software, pasó de Webflow a Astro en dos semanas. Pasó a escribir el contenido en MDX, un formato que combina Markdown con componentes web, y desplegó el sitio en Cloudflare Pages. Trabajaron dos fundadores y una persona de marketing de producto. Después encontraron redirecciones que habían quedado afuera y problemas de indexación, caché y consentimiento. Optimizar el rendimiento llevó más tiempo que migrar. La empresa reportó que el puntaje móvil de Lighthouse, una prueba de laboratorio, subió de 42 a 92. Tomó la medición antes de reinstalar el banner de cookies, así que el puntaje describe esa configuración puntual.
En Cursor, que desarrolla un editor de código con IA, Lee Robinson relata que el equipo trasladó el contenido de un CMS a código y Markdown en tres días y gastó US$260,32 en uso de agentes. La cifra pone precio al consumo de los modelos. El presupuesto completo también tendría que incluir el trabajo del equipo, que siguió gestionando permisos, recursos multimedia y versiones por idioma.
El alcance también cambia mucho entre proyectos chicos. Pauline Narvas, que trabaja en Vercel, una plataforma para desplegar sitios y aplicaciones, cuenta que migró 367 publicaciones y cinco páginas desde WordPress a MDX en unas cuatro horas. Su sitio público ya corría sobre Next.js, así que el trabajo consistió en cambiar dónde se gestionaba el contenido. En la migración bilingüe que documentó Rory Miller, en cambio, hubo cinco semanas de trabajo a tiempo parcial, 49 rutas y 53 propuestas de cambio. Parte del trabajo fue reorganizar una plantilla de más de 1.100 líneas, corregir problemas de idioma y recuperar fragmentos que el agente había parafraseado sin que se lo pidieran.
Estos relatos ayudan a anticipar qué puede salir bien y qué trabajo aparece después. Encontramos varios de estos casos en los recursos públicos de No Devs Were Harmed, una comunidad de Slack para equipos de marketing que quieren reconstruir sus sitios con Claude, el asistente de Anthropic. Para entender cada migración recurrimos al relato de quienes la hicieron. Es una muestra en la que abundan equipos con acceso a ingeniería y personas que ya programaban. Quedan abiertas preguntas sobre cuántas migraciones se revierten, cuánto cuesta operar el nuevo sitio al cabo de un año y qué tiempos puede esperar un equipo con menos apoyo técnico.
¿Se puede conectar un agente al CMS que ya usa el equipo?
Sí. Acá usamos CMS agéntico para describir un flujo en el que un agente puede actuar sobre contenido estructurado y el equipo conserva permisos, estados editoriales y un registro de cambios. Ese flujo puede apoyarse en archivos, en un CMS separado del sitio público o en una plataforma visual.
Sanity describe cómo conecta agentes con su CMS mediante MCP, un protocolo que permite que un modelo use herramientas externas. El agente puede consultar, modificar y preparar contenido sin perder las referencias entre documentos. La explicación viene del propio proveedor. Por su parte, las herramientas MCP de Webflow para gestionar contenido permiten leer, crear y actualizar entradas del CMS sin abrir el editor visual. Guardar un borrador y publicarlo son operaciones separadas.
Esa separación importa si el problema del equipo es, por ejemplo, que actualizar veinte fichas de producto lleva demasiado tiempo. Se puede probar si el agente prepara los cambios en el CMS actual y deja la publicación en manos del editor. El criterio para elegir un creador de sitios con IA suele ser qué permite construir. Para elegir cómo operar el sitio también hay que ver cómo se revisa y se corrige lo que ya está publicado.
¿Qué trabajo queda después de migrar?
El sitio sigue teniendo dependencias, credenciales, servicios y despliegues que alguien debe mantener. Para un equipo de medios de marca, eso incluye conservar el archivo, sostener los enlaces y poder corregir una nota publicada. También hay que saber quién puede tocar un formulario, reemplazar una imagen o actualizar todas las versiones de una página sin mezclar idiomas.
Si cambian las direcciones, la documentación de Google Search sobre migraciones con cambios de URL indica que hay que mapear las direcciones viejas y nuevas, configurar las redirecciones permanentes que correspondan y revisar los enlaces internos, las etiquetas canónicas y las referencias entre versiones de idioma. Google también advierte que la visibilidad en búsquedas puede fluctuar durante la transición. Si el plan es conservar las URLs, comprobá que las páginas mantengan sus direcciones y sigan siendo indexables.
Cuando cambian juntos el framework, las plantillas y el contenido, cuesta más averiguar qué provocó una caída de tráfico o por qué dejó de funcionar un formulario. Del mismo modo, para saber si la nueva arquitectura conviene económicamente hay que contar el trabajo que lleva publicar un cambio correcto. Sumá la preparación, el consumo del agente, la revisión, las correcciones, los servicios y el mantenimiento. Una suscripción menos puede venir acompañada de más horas de la persona que conoce el repositorio.
¿Cómo probar qué arquitectura conviene?
| Situación del equipo | Qué vale la pena probar | Qué hay que sostener |
|---|---|---|
| Un sitio principal, componentes que se repiten y apoyo técnico | Contenido en archivos y cambios revisados en el repositorio | Estructura del contenido, accesos, vistas previas y despliegues |
| Varios editores, idiomas o contenidos que se referencian entre sí | Sitio propio con un CMS separado y conectado a agentes | Modelo de contenido, coordinación entre editores y permisos |
| Un CMS que funciona y demoras en tareas puntuales | Darle al agente acceso a unas pocas operaciones del CMS actual | Límites de la plataforma y control sobre quién publica |
En un entorno de prueba, pedile a quien va a operar el sitio que cree una landing, corrija una publicación, actualice un dato compartido y revierta un cambio. Hacé los mismos ejercicios con el flujo actual y con el propuesto. Anotá quién interviene y cuánto tarda el cambio en quedar aprobado.
| Qué probar | Qué tiene que poder hacer el equipo |
|---|---|
| Datos compartidos | Actualizar un dato y comprobar en qué páginas cambió |
| Permisos | Dejar que el agente prepare un borrador y reservar la publicación para la persona autorizada |
| Vista previa | Revisar qué cambió, incluidos formularios, enlaces y versiones de idioma |
| Historial | Identificar quién pidió, modificó y aprobó el cambio |
| Recuperación | Volver a una versión anterior sin reconstruir el pedido original |
| Continuidad | Editar y corregir el sitio si el modelo deja de estar disponible |
Durante la prueba, revisá también la accesibilidad y el comportamiento de los formularios. Hacé que los permisos técnicos reflejen quién tiene autoridad para publicar. Si el cambio llega antes a producción y el equipo puede revisarlo, corregirlo y revertirlo, el piloto aporta una razón para adoptar el flujo. Si cada corrección termina de nuevo en el escritorio de ingeniería, conviene incluir ese tiempo en el costo de la migración.
Preguntas frecuentes
¿Qué es un CMS agéntico?
Es un flujo de gestión de contenidos en el que un agente puede consultar o modificar contenido con permisos definidos. El equipo puede distinguir un borrador de una publicación, revisar los cambios y recuperar versiones anteriores. Ese flujo puede apoyarse en archivos, un headless CMS o una plataforma visual.
¿Se puede migrar de Webflow con IA y seguir usando un CMS?
Sí. Vellum reconstruyó su sitio público con Next.js, adoptó Sanity como CMS y conectó asistentes al contenido. Webflow también ofrece operaciones para que un agente prepare cambios dentro de su propio CMS. La elección depende de qué parte del flujo necesita cambiar el equipo.
¿Qué hay que cuidar del SEO al migrar un sitio con IA?
Si cambian las URLs, prepará un mapa de direcciones, configurá redirecciones permanentes donde correspondan y revisá enlaces internos, etiquetas canónicas y hreflang. Después del lanzamiento, seguí la indexación. Si las URLs se mantienen, comprobá que sigan respondiendo y que las páginas conserven sus señales de indexación.
¿Para qué equipos tiene sentido operar el sitio con agentes?
Vale la pena probarlo cuando hay pedidos recurrentes, componentes reutilizables y una manera clara de revisar y revertir cambios. Si el sitio depende de varios editores, idiomas o relaciones entre contenidos, probá esas operaciones con quienes van a sostenerlas antes de elegir una arquitectura.