El stack tecnológico de Claude Code para un sitio web agéntico

Respuesta rápida: un sitio web agéntico es un sitio de marketing que agentes de IA ayudan a crear, operar y mejorar, mientras las personas aprueban los cambios importantes. El stack que mejor le encaja mantiene todo lo que toca un agente en archivos que este puede leer: un framework de sitios estáticos como Astro, un CMS headless con sus esquemas en código como Sanity, un hosting con vistas previas de despliegue y funciones programadas como Netlify, y Claude Code trabajando mediante pull requests.

La mayoría de los equipos de SaaS B2B ya usa IA para escribir textos. Muchos menos dejan que un agente modifique el propio sitio web, y quienes lo intentan suelen descubrir el motivo por las malas: una plataforma pensada para hacer clic en un editor visual no le da al agente nada que leer, nada que probar ni un lugar seguro donde experimentar. La solución es un stack y un conjunto de reglas diseñados para el agente desde el principio.

Esta guía presenta ese stack, las barreras de seguridad que protegen un sitio en producción y los flujos de trabajo de agentes que se ejecutan sobre él. Está escrita a partir de la reconstrucción de saas-hackers.com, que funciona con Astro, Tailwind, Sanity y Netlify y se creó con Claude Code. Si aún estás decidiendo qué debe lograr tu sitio web, empieza por nuestra guía de estrategia de sitios web para SaaS B2B y vuelve aquí para la construcción.

¿Qué es un sitio web agéntico?

Un sitio web agéntico es un sitio donde los agentes de IA se encargan de buena parte de la construcción y el mantenimiento, dentro de reglas fijadas por personas y con comprobaciones que se ejecutan siempre. Los agentes escriben páginas, corrigen enlaces, actualizan contenido y abren cambios de código. Las personas deciden para qué sirve el sitio, aprueban todo lo que implique riesgo y revisan los resultados.

Esto es distinto de un creador de sitios web con IA, que genera un sitio una sola vez a partir de un prompt. En un sitio web agéntico, el agente sigue trabajando después del lanzamiento, como lo haría un desarrollador o un editor de contenidos, y cada cambio que hace pasa por la misma revisión que el de una persona.

Tres cosas hacen que un sitio sea agéntico y no solo asistido por IA:

• El agente puede leer todo lo que define el sitio. Las plantillas de página, los tipos de contenido, los design tokens, las redirecciones y las propias reglas viven en un repositorio de código, no solo en un panel de control.
• Todo cambio se puede probar antes de salir en producción, con una compilación que falla si hay una página rota, un enlace de vista previa para cada cambio y una ejecución de prueba para cada script de contenido.
• Las personas conservan las llaves importantes. Fusionar código, publicar contenido sensible y cualquier cosa que cueste dinero quedan en manos de una persona concreta.

¿Por qué importa más el stack cuando los agentes hacen el trabajo?

El stack importa más porque un agente solo puede trabajar con seguridad con lo que puede ver y comprobar. Una persona nota en un editor visual que una página se ve mal. Un agente necesita que ese conocimiento esté escrito: como un esquema que rechaza un campo vacío, una comprobación que hace fallar la compilación o una regla en un archivo que lee antes de cada sesión.

Un stack pensado para agentes tiene cuatro propiedades:

1. Texto en lugar de clics. La configuración, los modelos de contenido y los estilos son archivos del repositorio, así que un agente puede leerlos, modificarlos y explicarlos.
2. Respuestas rápidas y sinceras. Una compilación o una prueba que falla de forma clara le dice al agente que se ha equivocado antes de que lo note un visitante.
3. Un lugar seguro donde probar. Las ramas, los borradores y los enlaces de vista previa permiten al agente mostrar su trabajo sin tocar el sitio en producción.
4. Una única puerta de revisión. Cada cambio de código llega como un pull request que una persona puede leer, fusionar o rechazar.

Con todo esto en su sitio, la elección del modelo pesa menos. Sin ello, hasta un agente cuidadoso acabará rompiendo algo, porque nada le avisa de que lo ha hecho.

¿Cuál es el stack tecnológico de Claude Code para un sitio web agéntico?

El stack tiene cinco capas: un framework de sitios estáticos, un CMS headless, un hosting, el agente y la puerta de revisión entre ellos. Cada capa está ahí porque le da al agente algo que leer o algo que comprobar.

Un framework de sitios estáticos: Astro

Astro genera las páginas por adelantado. Por defecto, prerrenderiza cada página, ruta y endpoint como HTML estático en el momento de la compilación, y puedes activar el renderizado bajo demanda en rutas concretas cuando lo necesiten (Astro, 2026). Para un agente, la salida estática es una ventaja enorme: tras la compilación todo el sitio existe como archivos, de modo que un script puede revisar cada página antes de que nada salga en producción.

SaaS Hackers renderiza todas las páginas de forma estática. La única página que se renderiza bajo petición es la vista previa de borradores, que los editores abren desde el CMS para ver cambios sin publicar. Todo lo demás se comprueba en la compilación, y el contenido está en el HTML desde la primera carga, incluido cada elemento de una lista filtrada.

Un CMS headless con esquemas en código: Sanity

Un CMS headless mantiene el contenido separado del diseño del sitio y se lo sirve mediante una API. Lo que importa para los agentes es dónde vive el modelo de contenido. En Sanity, un esquema describe los tipos de documentos y campos que los editores pueden crear, y se define en código en la configuración de Studio (Sanity, 2026).

Como los esquemas son código, un agente puede leer exactamente de qué se compone una entrada de blog o un perfil, añadir un campo mediante un pull request y escribir contenido con scripts que el esquema valida. Los editores siguen teniendo un editor visual. SaaS Hackers mantiene todos los esquemas en el repositorio y nunca solo en el panel de control, una de las reglas de su archivo de proyecto.

Un hosting con vistas previas y funciones: Netlify

El hosting le da al agente dos cosas: una vista previa de cada cambio y un lugar donde ejecutar tareas pequeñas. Netlify genera automáticamente una vista previa de despliegue cuando se abre un pull request en un repositorio conectado, en su propia dirección, y le añade una cabecera noindex para que los buscadores la ignoren (Netlify, 2026). Ese enlace de vista previa es la forma en que una persona comprueba el cambio de un agente en una página real antes de fusionarlo.

Las funciones programadas de Netlify se ejecutan como un cron job con un horario fijo en UTC, solo en el despliegue de producción publicado, con un límite de 30 segundos por ejecución (Netlify, 2026). Las tareas cortas y programadas encajan bien con el mantenimiento agéntico: comprobar si algo ha cambiado y decidir después si hay que recompilar.

Claude Code: CLAUDE.md, skills, hooks y MCP

Claude Code es el agente. Cuatro de sus funciones convierten un modelo capaz en un miembro fiable del equipo:

• CLAUDE.md. Los archivos CLAUDE.md son archivos Markdown que dan a Claude instrucciones persistentes para un proyecto, y Claude los lee al inicio de cada sesión (Anthropic, 2026). Compartido mediante control de versiones, el archivo del proyecto contiene los comandos de compilación, los estándares y las reglas con las que trabaja todo el equipo.
• Skills. Una skill es un SKILL.md archivo de instrucciones que Claude añade a sus herramientas y utiliza cuando es relevante. A diferencia de CLAUDE.md, el contenido de una skill solo se carga cuando se usa, así que los procedimientos largos casi no cuestan nada hasta que se necesitan (Anthropic, 2026). Nuestro artículo explicativo sobre las Claude Skills para equipos de marketing cuenta cómo funcionan para redactar textos.
• Hooks. Los hooks son comandos de shell que Claude Code ejecuta en momentos determinados, lo que te da un control determinista: ciertas acciones siempre ocurren, sin depender de que el modelo decida hacerlas (Anthropic, 2026). Úsalos para reglas que nunca deben flexibilizarse, como bloquear la edición de un archivo de secretos.
• Servidores MCP. El Model Context Protocol es un estándar de código abierto para conectar herramientas de IA con otros sistemas, y los servidores MCP dan a Claude Code acceso a tus herramientas, bases de datos y APIs (Anthropic, 2026). Así es como un agente lee directamente analítica, posiciones o un CMS, en lugar de trabajar con lo que tú le pegas. Nuestra guía sobre agentes de IA de marketing y MCP explica qué herramientas de marketing puedes conectar.

Sesiones en la nube y tareas programadas

Una sesión en la nube es una sesión de Claude Code que se ejecuta en infraestructura en la nube en lugar de en tu portátil, y sigue funcionando después de que cierres la tapa (Anthropic, 2026). Las ejecuciones programadas y las activadas por eventos empiezan cada una como una sesión en la nube. Eso permite que un agente publique una entrada de blog a las 01:43 o mida posiciones un martes por la mañana sin nadie frente al teclado.

Los pull requests de GitHub como puerta de revisión

Cada cambio de código que hace un agente va a una rama y llega como pull request. La vista previa del despliegue se genera a partir de ella, las comprobaciones se ejecutan sobre ella y una persona la fusiona o no. En SaaS Hackers la regla es sencilla: los agentes abren pull requests y Darren las fusiona. Ningún agente fusiona su propio trabajo.

¿Cómo evitas que un agente rompa un sitio web en producción?

Para evitar que un agente rompa un sitio en producción, haz que el camino seguro sea el único: una copia de seguridad antes de cualquier escritura, una simulación que muestre el cambio, comprobaciones en cada compilación y límites sobre lo que puede cambiar por sí solo. Ninguna de estas medidas depende de que el agente se acuerde de ser cuidadoso. Están escritas en scripts, esquemas y en la propia compilación.

Copia de seguridad, simulación y después escritura

Todos los scripts que modifican contenido publicado en SaaS Hackers funcionan igual:

1. Copia de seguridad. npm run backup exporta todo el conjunto de datos a un archivo con fecha antes de que cambie nada.
2. Simulación. El script se ejecuta sin --write, lo comprueba todo y genera un informe de lo que cambiaría.
3. Lee la simulación. El agente, o una persona, lee ese informe antes de continuar.
4. Escritura. Solo entonces se ejecuta el mismo script con --write.
5. Comprobación. El sitio se compila a partir del contenido publicado y se ejecutan las comprobaciones de rutas y de esquema.

El informe de traspaso tras cada tarea indica la copia de seguridad que se hizo, de modo que cualquier cambio se pueda revertir.

Bloqueos en el CMS

Algunos errores es más barato prevenirlos en el CMS que detectarlos después. En el Studio de SaaS Hackers, el slug se bloquea cuando se publica el documento, así que una dirección activa no puede cambiar por accidente. No se puede publicar una página en una dirección que tenga una redirección activa, ni publicar imágenes nuevas sin texto alternativo. Los scripts despublican en lugar de eliminar y no tocan los borradores de otras personas.

Comprobaciones en cada compilación

La compilación es el crítico más sincero del agente. En SaaS Hackers, npm run build se detiene si falla cualquiera de estas comprobaciones:

• tokens de diseño desactualizados, colores o tamaños usados fuera de los tokens, o texto que no cumple el contraste;
• un bloque de sección del CMS sin su componente de página correspondiente;
• datos estructurados que no se pueden interpretar o que no cumplen el esquema de su tipo de página, o una página que no tiene exactamente un H1;
• enlaces de idioma (hreflang) que no se apuntan de forma recíproca.

Tras una compilación, la comprobación de rutas confirma que todas las direcciones activas incluidas devuelven un 200, y la comprobación de paridad compara títulos, descripciones, canonicals, encabezados y esquema con el sitio en producción. La velocidad también forma parte de las comprobaciones: nuestra entrada del manual sobre Core Web Vitals explica las métricas que conviene vigilar.

Los secretos no entran en el repositorio

Los tokens y las claves viven en un archivo local .env que git ignora, y en las variables de entorno del host. El repositorio solo guarda una lista con sus nombres. Un agente puede usar una clave que está en su entorno sin escribirla nunca en un archivo, un commit o un informe.

Límites sobre lo que un agente puede cambiar por sí solo

Decide de antemano qué puede hacer un agente sin preguntar, déjalo por escrito y aplícalo en el código siempre que puedas. Así lo reparte hoy SaaS Hackers:

• Las entradas del blog se publican de inmediato, una vez superadas las comprobaciones del script, y una persona las revisa después.
• Los textos de las páginas, los títulos y los enlaces internos cambian a través del agente de SEO, dentro de límites fijos por ejecución.
• Los cambios de código van a una pull request que fusiona una persona.
• Las solicitudes de perfil de las agencias esperan a que una persona pulse Aprobar en Slack.
• Las puntuaciones, reseñas y rankings nunca los cambia un agente ni se modifican a petición.

Límites de coste

Los agentes pueden gastar dinero rápido, así que el coste también es una barrera de protección. SaaS Hackers llegó a recompilar con cada publicación, y cada despliegue en producción cuesta 15 créditos de Netlify. Ahora las recompilaciones se limitan a una al día: una función programada se ejecuta a las 05:17 UTC y recompila solo si se ha publicado algo desde la última compilación en producción. Además, las instrucciones del agente de SEO le indican que nunca lance un despliegue por su cuenta.

¿Qué flujos de trabajo de agentes se ejecutan en un sitio web agéntico?

Una vez montados el stack y las barreras de protección, los agentes pueden encargarse del trabajo repetitivo que suele quedarse sin hacer: publicar, medir, actualizar y traducir. Cada flujo de trabajo tiene unas instrucciones por escrito, un calendario, límites y un informe.

Publicar una entrada de blog cada dos días

Una tarea programada escribe y publica una entrada del backlog de contenidos cada dos días a las 01:43 UTC, antes de la recompilación diaria. Escribe con una skill de copywriting, revisa la pieza con una skill de auditoría de contenido y después un script de publicación rechaza la entrada si encuentra una raya, un marcador de posición, un slug incorrecto, una meta descripción demasiado larga, menos de tres enlaces internos o algún enlace interno que no esté activo. Solo crea entradas nuevas y nunca modifica una existente.

Un agente de SEO que mide y actúa dos veces por semana

Los martes y viernes a las 06:41 UTC, una sesión nueva mide las posiciones, puntúa el sitio según sus objetivos y recorre una lista priorizada de acciones. Cada ejecución puede modificar como máximo 8 páginas, crear 1 lista nueva y añadir 30 enlaces internos, con límites en las consultas de datos de pago y en el gasto de traducción. Registra cada cambio con una copia previa para poder revertirlo, envía los cambios de código a pull requests e informa en el canal de Slack del equipo. Nuestra comparativa de Claude Code y AirOps para equipos de contenido analiza cuándo una configuración así supera a una herramienta no-code.

Mantener actualizados los perfiles del directorio

Un script mensual revisa el sitio web de cada agencia y registra si funciona, si ha cambiado de dirección o si está roto. Un rastreo trimestral lee el propio sitio de cada agencia y guarda los datos que declara, añadiendo etiquetas de servicios y sectores que el sitio menciona, pero sin quitar nunca ninguna. Ninguno de los dos toca las puntuaciones, las reseñas ni los rankings.

Solicitudes aprobadas en Slack

Las agencias pueden solicitar la actualización de su perfil o pedir que las incluyan en el directorio. Cada solicitud se confirma por correo electrónico, Claude la comprueba con el sitio web de la propia agencia, se guarda como borrador en el CMS y se envía a Slack como una tarjeta. Solo una persona autorizada puede pulsar Aprobar, cada clic se verifica con la firma de solicitud de Slack y cada solicitud solo puede resolverse una vez.

Traducir todas las páginas

Todas las páginas de SaaS Hackers se generan también en alemán, francés, español, neerlandés, japonés y portugués de Brasil. Claude Sonnet 5.5 tradujo el sitio mediante la Batch API por 91,35 $ en total, y las ejecuciones posteriores solo envían el texto que ha cambiado. Las citas y lo que las agencias dicen en sus propios sitios web se mantienen en inglés, palabra por palabra.

¿Cómo se construyó SaaS Hackers con este stack?

SaaS Hackers se reconstruyó desde Webflow a Astro, Tailwind, Sanity y Netlify con Claude Code, por fases, cada una como una pull request que revisó y fusionó una persona de SaaS Hackers. El archivo del proyecto fijaba el orden, las reglas y los comandos, y una especificación escrita definía qué significaba «terminado» en cada fase. La parte de diseño de esa reconstrucción está en nuestra guía para crear un sitio web con Claude Code.

La migración trasladó 233 entradas y 172 perfiles de expertos a Sanity, primero como borradores, y los comparó con las páginas en producción antes de publicar nada. La fase de SEO añadió una comprobación de que los datos estructurados de cada página se interpretan correctamente, además de una comprobación de paridad con el sitio en producción. Cuando el nuevo sitio sustituyó a Webflow, la comprobación de rutas devolvió 494 de 494 direcciones activas, una compilación de 3.936 páginas (inglés, la versión para EE. UU. y seis idiomas) tardó 8,5 minutos y el rendimiento móvil en Lighthouse fue de 99 a 100 en las páginas probadas en producción.

El mismo stack sostiene ahora los flujos de trabajo con agentes descritos arriba. Tres cosas lo hicieron posible: un archivo de proyecto que lee cada sesión, scripts que rechazan datos incorrectos y una persona que fusiona el código. Si quieres conocer el lado de operaciones de marketing de este panorama, nuestra guía de operaciones de marketing para SaaS B2B cubre los datos y las herramientas que rodean al sitio.

¿Cuáles son los beneficios de un sitio web agéntico?

Los beneficios vienen de que el trabajo repetitivo se haga a tiempo, siempre, y con un registro de lo que ha cambiado:

• El mantenimiento se hace a tiempo. Los enlaces rotos, los datos obsoletos y las meta descripciones que faltan se corrigen según un calendario, en lugar de en una limpieza anual.
• Los cambios se pueden deshacer. Las copias de seguridad, las copias previas y las pull requests permiten rastrear y revertir cualquier cambio de un agente.
• Hay menos traspasos. Un mismo agente puede cambiar contenido, plantillas y comprobaciones en la misma pull request, en lugar de pasar el trabajo entre un redactor, un desarrollador y un especialista en SEO.
• Los costes de funcionamiento pueden ser bajos con el stack adecuado. La propia revisión de costes de SaaS Hackers no encontró ninguna cuota adicional de hosting para el nuevo sitio, y el principal coste a vigilar son los créditos de Netlify por los despliegues.

Problemas habituales de los sitios web agénticos y cómo resolverlos

El agente comete el mismo error dos veces. No recuerda la sesión anterior. Escribe la regla en CLAUDE.md o en una skill en cuanto lo corrijas, para que todas las sesiones futuras empiecen con ella.

Los cambios parecen correctos en el código, pero se ven mal en la página. Sin una vista previa, nadie ve la página hasta que ya está en producción. Exige un enlace de vista previa del despliegue en cada pull request y revisa la propia página antes de fusionar.

Las comprobaciones pasan, pero el sitio sigue desviándose. Las comprobaciones solo detectan lo que se prueba. Cuando algo se cuela, añade una comprobación para ello a la compilación y así no volverá a ocurrir.

Los costes se disparan poco a poco. Cada recompilación, rastreo y llamada a la API tiene un coste. Pon un límite en las instrucciones de cada agente, agrupa las recompilaciones e incluye el gasto en el informe de cierre de cada ejecución.

Nadie sabe qué ha cambiado el agente. Pide un informe de cierre después de cada tarea: qué cambió, la copia de seguridad que hizo, las comprobaciones que ejecutó y lo que no pudo hacer.

Qué buscar si contratas ayuda para construir uno

Si contratas a una agencia o a un desarrollador para crear un sitio web agéntico, pide ver las barreras de seguridad, no solo el diseño. Un buen socio te mostrará:

• un archivo de instrucciones del proyecto y las reglas que contiene;
• scripts de contenido con simulación previa y un paso de copia de seguridad;
• comprobaciones de compilación que fallan ante problemas reales, con los comandos para ejecutarlas;
• una separación clara entre lo que los agentes pueden cambiar y lo que debe aprobar una persona;
• los costes de funcionamiento por escrito, incluidos los despliegues y el uso de la API.

Puedes comparar especialistas en nuestra lista de las mejores agencias de diseño web para SaaS B2B.

Acerca de SaaS Hackers

SaaS Hackers es una comunidad de especialistas en SaaS B2B que comparten conocimientos prácticos, creada por las personas que impulsan el crecimiento: marketers, estrategas y desarrolladores. Publica guías, un manual y listas de los mejores, y gestiona un directorio de agencias y expertos de marketing para SaaS B2B. SaaS Hackers está gestionado por Team 4, una agencia de marketing para SaaS B2B que figura y está clasificada en el directorio.