Cómo crear un sitio web con Claude Code que no se vea horrible

Respuesta rápida: Puedes crear con Claude Code una web que parezca diseñada y no generada, pero solo si evitas que recurra a sus valores por defecto. Dale un sistema de diseño real en forma de tokens, escribe tus reglas en un archivo CLAUDE.md y en una especificación, construye en fases pequeñas que una persona valide y añade comprobaciones de contraste, tokens, accesibilidad y velocidad que hagan fallar la compilación cuando algo se desvíe.

A la mayoría de los marketers que lo prueban les pasa lo mismo. La primera página llega enseguida y, a primera vista, parece correcta. Entonces te fijas en la fuente Inter, el degradado morado, el titular centrado sobre dos botones y tres tarjetas idénticas, y te das cuenta de que has visto esta misma web muchas veces.

Esta guía es para marketers y fundadores que quieren crear o rehacer una web de marketing con Claude Code y conseguir algo que se parezca a su marca. Explica por qué las webs creadas con IA resultan genéricas, qué darle a Claude antes de que escriba una línea, cómo mantenerlo bajo control mientras construye y cómo sustituir una web antigua sin perder tráfico de búsqueda. El caso práctico es el propio saas-hackers.com, rehecho desde Webflow con Claude Code en noviembre de 2026. Todos los resultados citados de ese proyecto proceden de sus propios registros.

¿Se puede crear con Claude Code una web que se vea bien?

Claude Code es una herramienta de programación con IA que lee tu proyecto, escribe y edita el código, ejecuta comandos y revisa su propio trabajo. En una web de marketing, eso significa que puede configurar el framework, construir los componentes, conectar un CMS y ejecutar las pruebas, mientras tú decides cómo debe ser la web y si cada paso es lo bastante bueno.

Sí, si haces el trabajo adecuado a su alrededor. Claude Code es bueno en la parte de ingeniería y rápido en las tareas repetitivas de una construcción. No conoce tu marca, a tus compradores ni las decisiones que tu equipo tomó en una reunión, y rellenará esos huecos con la opción más común que haya visto. El trabajo que decide si la web se ve bien es el que haces antes y durante la construcción: el sistema de diseño, las reglas escritas y las comprobaciones.

Si aún no has decidido qué debe aportar la web a tu pipeline, empieza por nuestra guía de estrategia web para SaaS B2B. Esta guía da por hecho que ya sabes qué páginas necesitas y quieres construirlas bien.

¿Por qué todas las webs creadas con IA se parecen?

Las webs creadas con IA se parecen porque los modelos de lenguaje eligen la siguiente opción más probable, y en diseño web la opción más probable es la segura. Anthropic lo llama convergencia distribucional: las decisiones de diseño seguras dominan los datos de entrenamiento, así que, sin indicaciones, el modelo muestrea de ese centro de alta probabilidad (Anthropic, 2025).

El propio equipo de frontend de Anthropic describe el resultado sin rodeos. Si se le pide crear una landing page sin orientación, un modelo «casi siempre se ajustará a fuentes Inter, degradados morados sobre fondos blancos y animaciones mínimas» (Anthropic, 2025). Su argumento es que esto debilita la identidad de marca y hace que las interfaces creadas con IA sean fáciles de reconocer y de descartar.

Las señales son fáciles de detectar cuando las conoces:

• Inter, Roboto o fuentes del sistema por todas partes, con pesos que apenas cambian entre los titulares y el cuerpo del texto
• Degradados morados o violetas y titulares con relleno degradado
• Un hero centrado con una etiqueta en forma de píldora, un titular, un subtítulo y dos botones
• Tres tarjetas idénticas bajo el hero, sea cual sea el contenido
• Las mismas esquinas redondeadas y la misma sombra gris suave en todo
• Emojis o iconos de línea genéricos junto a cada punto

La misma investigación muestra la salida. Claude es muy orientable: dile qué valores por defecto debe evitar y qué usar en su lugar, y el resultado mejora de inmediato (Anthropic, 2025).

Anthropic empaquetó esa orientación como una skill de diseño frontend y un plugin de Claude Code, y señala que puedes crear tu propia skill a partir del sistema de diseño de tu empresa. Esa última parte es la que importa en una web corporativa.

Los consejos generales sobre «fuentes interesantes» te dan otra web genérica distinta. Tu propio sistema de diseño te da la tuya.

Empieza por un sistema de diseño, no por un prompt

Un sistema de diseño para una construcción con IA es un conjunto de decisiones con nombre que Claude puede leer: colores, fuentes, tamaños de texto, espaciado, radio de las esquinas y breakpoints, cada uno con una función. Escritos como design tokens en un archivo, se convierten en los únicos valores que la web puede usar.

La diferencia con un PDF de guía de marca es que los tokens los puede leer una máquina. Un PDF dice que tu color de acento es el naranja. Un archivo de tokens dice brand.flame es #df4e32 y se usa para el logotipo, las flechas, los filtros activos y el foco de los campos, y para nada más. Claude puede seguir lo segundo al pie de la letra, y un script puede comprobar que lo hizo.

Qué contiene un sistema de diseño útil para una construcción con Claude Code:

• Tokens de color con función. Fondo, texto, titulares, texto atenuado, bordes, un color de señal y los temas (por ejemplo, uno oscuro y otro claro) que los combinan.
• Tipografía. Las fuentes de la marca como archivos que tienes licencia para alojar tú mismo, una escala tipográfica con saltos de tamaño reales y los pesos que usa cada nivel.
• Espaciado, radio y breakpoints. Una escala de espaciado, un radio por función (botones, tarjetas, secciones) y los anchos de pantalla en los que cambia el diseño.
• Componentes con un solo nombre. Un botón, una tarjeta o un hero se llama igual en el archivo de diseño, en el código y en el CMS, para que nadie tenga que traducir.

¿De dónde sale? Si tienes un diseñador o una biblioteca de Figma, exporta los tokens desde ahí.

Si tienes una web que te gusta, los tokens se pueden leer de su hoja de estilos, que es lo que se hizo en el rediseño de SaaS Hackers. Si no tienes ninguna de las dos cosas, paga a un diseñador por esta parte antes de construir nada. Un día de decisiones de diseño sale más barato que una web igual a las de todos.

Una decisión técnica hace que el sistema se mantenga. Si usas Tailwind CSS, no importes su tema por defecto. Genera el tema a partir de tu archivo de tokens, de modo que los únicos colores, tamaños y fuentes del proyecto sean los tuyos. Claude no puede recurrir a un morado genérico que no existe.

¿Cómo se escriben las reglas para Claude?

Claude Code lee un archivo llamado CLAUDE.md al comienzo de cada sesión, así que ahí es donde pones las reglas del proyecto. Un CLAUDE.md de proyecto vive en el repositorio y se comparte con todos los que trabajan en él mediante el control de versiones (documentación de Claude Code, 2026).

La guía de Anthropic para escribirlo es práctica. Mantén cada CLAUDE.md por debajo de unas 200 líneas, porque los archivos más largos consumen más contexto y reducen lo bien que Claude los sigue.

Haz las instrucciones lo bastante concretas como para poder comprobarlas: «Ejecuta npm test antes de hacer commit» en lugar de «prueba tus cambios». Agrupa las reglas bajo títulos y elimina las que se contradigan entre sí (documentación de Claude Code, 2026).

Tampoco tienes que empezar de cero: el /init comando genera un archivo inicial a partir de tu código.

Para construir una web, el CLAUDE.md que funciona cubre cinco aspectos:

1. Qué estás construyendo y con qué. El stack, el alojamiento y dónde está el contenido.
2. La lista de prohibiciones. Lo que no debe ocurrir: cambiar una URL en producción, subir secretos al repositorio, añadir un servicio de pago o un script de terceros sin preguntar, escribir en el proyecto de CMS equivocado.
3. Estándares. Ningún color, tamaño o fuente fuera de los tokens. Un único nombre de componente en todas partes. Salida estática por defecto. WCAG 2.2 AA. Inglés británico o estadounidense.
4. Reglas de redacción para cualquier texto que añada Claude. Lenguaje claro, sin copy inventado y un marcador imposible de pasar por alto (las palabras COPY NEEDED en mayúsculas, más lo que falta) donde todavía no existan los textos.
5. Comandos. Cómo ejecutar el servidor de desarrollo, la compilación y cada comprobación. Las buenas prácticas de Anthropic consideran que el comando que ejecuta tus comprobaciones es la línea más útil del archivo (documentación de Claude Code, 2026).

CLAUDE.md es una guía, no una obligación. Claude lo trata como contexto y puede decidir que una pauta no aplica. Para todo lo que deba ocurrir siempre, como ejecutar el formateador o no leer nunca un archivo de secretos, Claude Code ofrece hooks y reglas de permisos que la propia herramienta aplica (documentación de Claude Code, 2026).

Pon el briefing más largo en un archivo de especificaciones aparte. Anthropic sugiere pedirle a Claude que te entreviste hasta que pueda redactar la especificación, guardarla como SPEC.md y empezar después una sesión nueva para construir a partir de ella, de modo que la construcción arranque con un contexto limpio y una definición escrita de lo que significa «terminado» (documentación de Claude Code, 2026). Para las reglas de marca y diseño que solo importan de vez en cuando, una skill las mantiene fuera de en medio hasta que hacen falta; nuestra guía sobre Claude Skills para equipos de marketing explica cómo funcionan.

Construye en fases pequeñas que una persona valide

Un sitio web creado con Claude Code falla de la misma manera que uno creado por un desarrollador junior: demasiadas cosas a la vez y nadie que mire hasta el final. La solución también es la misma. Divide la construcción en fases, revisa cada una y no empieces la siguiente hasta que se haya aprobado la anterior.

Un orden de fases que funciona para un sitio de marketing:

1. Puesta en marcha. Framework, estilos, CMS y alojamiento conectados, con una página vacía que se despliega en un enlace de vista previa.
2. Modelo de contenido y migración. Esquemas del CMS y contenido existente trasladado como borradores.
3. Sistema de diseño. Tokens, fuentes y todos los componentes, mostrados en una única página de catálogo.
4. Plantillas y páginas. Cada tipo de página construido con los componentes y rellenado con contenido real.
5. SEO. Etiquetas del head, datos estructurados, sitemap, redirecciones y comprobaciones frente al sitio antiguo.
6. Publicación. Vistas previas, flujo de trabajo del editor y todo lo que reconstruye el sitio cuando cambia el contenido.

Cada fase termina con una pull request y un enlace de vista previa por el que una persona pueda navegar. La pull request indica qué se construyó, qué se comprobó y qué se encontró, qué supuestos hizo Claude y qué queda pendiente. Ese último apartado es donde afloran las dudas sin resolver en lugar de acabar resueltas con suposiciones a ciegas.

Por qué importa un catálogo de componentes

El catálogo es una página que muestra cada componente en cada estado: cada estilo de botón, cada tarjeta, el encabezado abierto y cerrado, los campos de formulario con errores, cada bloque de sección con contenido de ejemplo. Es donde das el visto bueno al aspecto antes de que lo use ninguna plantilla. Corregir una tarjeta una vez en el catálogo cuesta mucho menos que descubrir que está mal en 200 páginas. Mantén el catálogo fuera del sitemap y márcalo como noindex.

Mira el catálogo en ancho de móvil además de en escritorio. La mayoría de las construcciones con IA de aspecto genérico se desmoronan primero en el móvil: texto demasiado pequeño, tarjetas apretadas, menús que se solapan.

¿Qué comprobaciones mantienen la fiabilidad de una web creada con IA?

Las comprobaciones son lo que evita que un buen comienzo derive en un resultado genérico. Las buenas prácticas de Anthropic lo resumen con sencillez: Claude se detiene cuando el trabajo parece terminado, así que dale algo que devuelva aprobado o suspendido y podrá corregir sus propios errores antes de que los veas (documentación de Claude Code, 2026).

Para un sitio de marketing, estas son las comprobaciones que merece la pena incorporar. Haz que la propia construcción las ejecute, de modo que un fallo detenga el despliegue en lugar de sumarse a una lista de tareas pendientes.

• Tokens actualizados. La hoja de estilos generada coincide con el archivo de tokens, de forma que nadie editó uno sin el otro.
• Contraste. Cada par de colores de texto, campo de formulario y foco en cada tema cumple WCAG 2.2 AA. Eso significa al menos 4,5:1 para el texto normal y 3:1 para el texto grande (W3C, 2023). El anillo de foco y los bordes que delimitan un control también necesitan 3:1.
• Lint de tokens. Un script que falla ante cualquier color, tamaño o fuente del código que no sea un token: sin códigos hexadecimales, sin rgb(), sin tamaños en píxeles escritos en un componente, sin nombres de fuentes.
• Nombres de componentes. Cada bloque de sección del CMS tiene un componente con el mismo nombre, y viceversa.
• Análisis de accesibilidad. Un análisis automatizado como axe en cada tipo de página, más una comprobación con teclado: ¿puedes llegar a cada menú, filtro y formulario y usarlo sin ratón?
• Velocidad. Lighthouse en móvil para la página de inicio y las plantillas principales, ejecutado más de una vez. Nuestra guía sobre Core Web Vitals explica qué miden las puntuaciones de velocidad.
• Maquetación en anchos reales. Capturas de pantalla o un análisis de desbordamiento en anchos de móvil, tableta y escritorio, para detectar texto que se sale de su caja.

Pide a Claude pruebas cada vez: el comando que ejecutó y el resultado. Un simple «todas las comprobaciones pasan» dice muy poco, y leer el resultado es más rápido que volver a ejecutarlo tú mismo (documentación de Claude Code, 2026).

Después, revisa las páginas con tus propios ojos. Las comprobaciones automáticas detectan lo medible. No pueden decirte que una página parece una plantilla.

¿Cómo se sustituye una web existente sin perder tráfico de búsqueda?

Sustituir un sitio en producción es una migración, y el riesgo es perder posicionamiento más que verse mal. La regla que te protege es que cada URL que existe en el sitio antiguo conserve exactamente la misma dirección en el nuevo, o tenga una redirección permanente a la página correcta.

Claude Code es muy adecuado para las comprobaciones, porque son repetitivas y exactas. En una reconstrucción, prepara tres comprobaciones antes de hacer el cambio:

• Comprobación de rutas: cada dirección del sitemap antiguo devuelve un 200 en la nueva vista previa, y una dirección desconocida devuelve un 404.
• Comprobación de paridad: para cada dirección, compara el título, la meta descripción, la canonical, el H1 y los datos estructurados con la página en producción, y falla ante cualquier cosa que se haya perdido.
• Comprobación de redirecciones: se recrea cada redirección que tenía la plataforma antigua, se eliminan las cadenas y ninguna redirección apunta a una página que a su vez redirige.

No dejes que Claude cambie un slug «para ordenarlo». Incluye «nunca cambies una URL que exista en el sitio en producción» en la lista de prohibiciones. Nuestra guía de estrategia SEO cubre el panorama completo. Si el sitio es grande o el tráfico es muy importante, una agencia de nuestra lista de agencias de migración SEO puede encargarse del plan de migración mientras Claude hace la construcción.

En la práctica: cómo se rehízo SaaS Hackers con Claude Code

SaaS Hackers (gestionado por Team 4) pasó de Webflow a Astro, Tailwind CSS, TypeScript, Sanity y Netlify en noviembre de 2026, y Claude Code se encargó de la construcción. El briefing era muy claro sobre el aspecto: reconstruir el diseño actual, sin rediseñar. No había archivo de Figma ni sistema de diseño, así que el sistema de diseño se construyó a partir del sitio en producción.

Eso condicionó el enfoque. Los colores, las fuentes, los espaciados y el radio se extrajeron de la hoja de estilos en producción a un archivo de tokens, que acabó con 26 tokens de color y tres temas (oscuro, negro y claro). La fuente de visualización de la marca, Heming, tiene licencia para alojarse en servidor propio, e Inter es de código abierto, así que ambas se alojaron por cuenta propia.

No se importó el tema predeterminado de Tailwind, de modo que los tokens eran los únicos valores disponibles. El encabezado, el pie de página, las tarjetas, las partes del perfil de experto, los campos de formulario, el cuerpo de las publicaciones y 14 bloques de sección se construyeron con sus bloques equivalentes en el CMS y se mostraron en un catálogo de componentes.

Las cuatro comprobaciones de diseño (tokens, contraste, lint de tokens y nombres de componentes) se ejecutan al inicio de cada construcción y la detienen si alguna falla. Los componentes se aprobaron en ancho de móvil y de escritorio antes de que ninguna plantilla los usara.

Los propios registros del proyecto muestran cómo resistió:

• axe no encontró ninguna infracción en 13 páginas cuando se terminaron las plantillas.
• Las 409 direcciones incluidas en el alcance devolvieron un 200 en la vista previa en esa misma fase.
• Las 409 direcciones superaron a las páginas de Webflow en producción en la comprobación de paridad (título, descripción, canonical, H1 y schema), sin pérdidas.
• Lighthouse en móvil sobre producción, con tres ejecuciones en cada caso para la página de inicio en inglés y en alemán, una publicación y un perfil de experto, dio entre 99 y 100 en rendimiento y 100 en accesibilidad y buenas prácticas.
• Un análisis de desbordamiento de 11 tipos de página en 7 idiomas y 4 anchos de pantalla no encontró ningún problema.

Lo que marcó la diferencia fue sencillo. Claude nunca tuvo que elegir un color ni una fuente, porque el archivo de tokens ya lo había hecho. Y una persona revisó cada fase antes de que empezara la siguiente, así que los problemas se encontraron en el catálogo y no en las páginas en producción. Lo que Claude hizo más rápido que un equipo fue la parte repetitiva: la migración de contenido, las 134 redirecciones listas para el lanzamiento y la repetición de las mismas comprobaciones tras cada cambio. Cómo funciona el sitio en el día a día, con sus agentes y sus barreras de seguridad, se explica en nuestra guía sobre el stack tecnológico de Claude Code para un sitio web con agentes.

Errores habituales y cómo evitarlos

La mayoría de las construcciones web con IA que fracasan lo hacen por uno de unos pocos motivos. Cada uno tiene una solución sencilla.

Empezar con «hazme una página de inicio». Claude rellena cada vacío con valores predeterminados, y la página de inicio marca el aspecto de todo lo que viene después. Escribe primero el sistema de diseño y el CLAUDE.md, luego construye los componentes y después las páginas.

Describir la marca con adjetivos. «Atrevida, moderna, de confianza» no significa nada que un modelo pueda aplicar. Dale tokens, archivos de fuentes y una captura de una página que te guste. La documentación de Anthropic sugiere pegar la captura del diseño directamente en el prompt.

Construirlo todo en una sola sesión. Las sesiones largas pierden el hilo de las decisiones iniciales. Trabaja por fases, empieza sesiones nuevas a partir de la especificación y mantén cada cambio lo bastante pequeño para poder revisarlo.

Fiarte de un «hecho». Claude informa de lo que cree. Haz que la compilación ejecute las comprobaciones, pide el resultado y revisa tú mismo la vista previa en ancho de móvil antes de aprobar nada.

Dejar que aparezca texto de la nada. Una compilación con IA escribirá titulares y testimonios verosímiles para rellenar huecos. Prohíbe el texto inventado en CLAUDE.md y usa marcadores de posición visibles, para que nada falso llegue al sitio en producción. Nuestra guía sobre cómo usar Claude para redactar textos explica cómo escribir el texto real.

¿Cuándo conviene recurrir a un diseñador o a una agencia?

Claude Code sustituye gran parte del tiempo de desarrollo. No sustituye el criterio de diseño. Recurre a un diseñador cuando no tengas un sistema de diseño, cuando la propia marca necesite trabajo o cuando el sitio sea la principal forma en que los compradores te evalúan y «correcto» no sea suficiente.

Una división sensata es pagar a un diseñador por el sistema y los diseños de las páginas clave, y dejar que Claude Code construya a partir de ellos bajo las comprobaciones anteriores. Además, un diseñador te da algo con lo que comparar: una maqueta con la que contrastar el trabajo de Claude siempre es mejor que una descripción. Consulta nuestra lista de diseñadores web para marcas B2B SaaS para encontrar freelancers que puedan encargarse de esta parte.

Recurre a una agencia cuando necesites que alguien se encargue de todo: estrategia, diseño, desarrollo, migración y un responsable cuando algo falle. Pregunta cómo usan la IA en su proceso de desarrollo y qué comprobaciones se ejecutan antes de publicar nada. Si prefieres delegar todo el proyecto, compara las mejores agencias de diseño web para B2B SaaS antes de enviar un briefing a nadie.

Acerca de SaaS Hackers

SaaS Hackers es una comunidad de especialistas en B2B SaaS que comparten conocimientos prácticos, creada por quienes están detrás del crecimiento. Publica guías prácticas, plantillas y un directorio seleccionado de agencias y expertos con experiencia demostrada en marketing digital B2B SaaS. SaaS Hackers está dirigido por Team 4, y este sitio se reconstruyó con Claude Code siguiendo el enfoque descrito en esta guía.