david-samurai/LandingPageSkill

Construyendo una página de aterrizaje en Claude Code

Una configuración funcional para construir, publicar y mejorar páginas de marketing con Claude Code. Cinco elementos hacen la mayor parte del trabajo: un repositorio, un hosting, un kit de marca, rendimiento y datos del embudo. Consigue esos bien y todo lo demás es iteración.

Dos formas de ver la página antes de publicarla (sección 4): un servidor de desarrollo local para ti y Claude, y Claude Design para cualquier persona no técnica. Si usas Design, lee primero la regla estricta de la sección 4 — no hay deshacer allí.

El hilo conductor: el trabajo no termina en el despliegue. Una página que está en vivo y sin seguimiento es una página que no puedes mejorar.

Orden de operaciones

Haz esto en orden. Cada uno hace que el siguiente sea más barato.

1. Repositorio primero — antes de cualquier código. El control de versiones es el botón de deshacer para todo lo demás.
2. Hosting + pipeline de despliegue segundo — mientras el sitio es trivial y un despliegue roto no cuesta nada.
3. Kit de marca tercero — antes de escribir una sola palabra de texto, para que el primer borrador ya esté alineado con la marca.
4. Construye la página — visual/estática primero, interactividad después, seguimiento al final.
5. Publica con seguimiento mínimo el primer día — luego optimiza velocidad y texto contra datos reales.

---

1. Usa un repositorio (GitHub o equivalente)

Si ya estás usando Claude Code, esto es obvio. Si solo estás probando, este es el calentamiento: un repositorio te da control de versiones, una copia de seguridad en la nube y, lo más importante, una estrategia de despliegue.

main es producción y nada llega ahí excepto a través de un pull request que tú fusiones. Pon esa regla explícitamente en CLAUDE.md — consulta starters/CLAUDE.md.

El ciclo

Este es el ciclo completo. Ejecútalo para cada pieza de trabajo, por pequeña que sea.

1. Acuerda un número de versión. Claude recomienda uno, tú lo aceptas — o simplemente dices cuál quieres. De cualquier manera, el número se establece antes de que comience cualquier trabajo, y la decisión es tuya, no de Claude.
2. Claude crea la rama — git checkout -b v1.03.
3. Tú haces el trabajo en la rama. Los commits caen ahí y en ningún otro lugar.
4. Claude sube la rama a GitHub.
5. Claude abre el pull request.
6. Tú revisas y apruebas en GitHub, y lo fusionas. Este es el despliegue. Es el único momento en que la producción cambia, y siempre es una decisión humana.
7. git checkout main luego git pull. No te saltes esto. Tu main local ahora está detrás por exactamente una fusión, y comenzar la siguiente rama desde un main desactualizado es cómo obtienes divergencia, conflictos fantasma y un git pull que se niega a avanzar rápido.
8. Repite desde el paso 1 con el siguiente número de versión.

Claude propone, tú decides, Claude ejecuta. Los números de versión, las fusiones y los despliegues son tuyos; la ramificación, el envío y la creación del PR son de Claude. Si una llamada es ambigua, Claude pregunta.

Nomenclatura de versiones que funciona: v1.0x para parches (copia, configuración, pequeñas correcciones), v1.x para trabajo menor (una nueva página, una nueva característica), v2.x para un rediseño.

Dos puntos de control de revisión que vale la pena mantener:

• Revisa todo el diff de la rama antes de fusionar, no solo cada commit. Commits individualmente buenos pueden combinarse en un error real. Una pasada completa de "leer todo desde el punto de ramificación" — idealmente por un segundo revisor o un agente nuevo — detecta lo que la revisión por tarea estructuralmente no puede.
• Ejecuta una revisión de seguridad antes de cualquier despliegue que recoja datos de usuario. Una revisión en una rama de manejo de formularios detectó una vulnerabilidad real donde un spread de objeto crudo permitía a un visitante enviar valores para campos administrados por el servidor. Trátalo como un punto de control, no un lujo.

---

2. Alójalo en algún lugar con un pipeline de despliegue real

AWS Amplify funciona bien: un nivel gratuito que cubre una página de aterrizaje de bajo tráfico y una factura pequeña más allá. Verifica los términos actuales — AWS reestructuró su nivel gratuito en 2025. Netlify, Vercel y Cloudflare Pages te dan la misma forma.

El verdadero beneficio es la ruta de despliegue: fusiona un PR, el sitio se reconstruye y se publica.

Conectar el repositorio al hosting es el paso en el que la gente se estanca, y es una serie de clics, no un archivo de configuración: en la consola del hosting, crea una nueva aplicación web → autoriízala contra tu cuenta de GitHub → elige el repositorio y la rama main → detecta tu especificación de compilación → se ejecuta el primer despliegue. A partir de ahí, se reconstruye en cada push a esa rama. Haz esto mientras el sitio es una sola página de "hola", para que un pipeline roto no te cueste nada depurarlo.

Configura desde el primer día, mientras es barato:

• Despliegue automático desde main.
• Un dominio personalizado con HTTPS.
• Una alarma de facturación. Acabas de poner una tarjeta contra una cuenta en la nube. Establece una alerta de presupuesto en un número que te sorprendería — toma dos minutos, y convierte una sorpresa desagradable de baja probabilidad en un correo electrónico.
• Encabezados de seguridad — los hosts estáticos vienen sin ninguno por defecto.
• Cache-Control de caché larga en los activos de compilación con hash de contenido. Fácil, permanente, y de lo contrario se pospone para siempre porque nunca bloquea nada.

Dominio y DNS, donde las trampas son predecibles:

• Un dominio raíz no puede usar un CNAME — www.example.com sí puede, example.com no puede. Necesitas el registro ALIAS/ANAME de tu proveedor de DNS o la opción de apex del propio hosting. Decide temprano si tu URL canónica tiene el www y redirige la otra a ella.
• El certificado HTTPS necesita un registro DNS para validarse y no se emitirá hasta que ese registro se resuelva. Dale a cualquier cambio de DNS unas horas antes de decidir que está mal — el retraso de propagación se ve exactamente como una falla.

Trampas de despliegue que cuestan tiempo real:

• Sabe exactamente qué partes se despliegan automáticamente y cuáles no. Si alguna pieza de tu stack (una función serverless, un backend, un worker) se despliega mediante un comando manual separado, escríbelo en CLAUDE.md en mayúsculas. El fallo silencioso clásico es fusionar una rama donde el sitio visible se actualiza, el backend no, y todo parece estar bien.
• El despliegue automático elimina tu último punto de control. Con fusión-a-despliegue, la revisión del PR es el punto de control. La verificación tiene que ocurrir antes de la fusión, no después.
• npm ci en el host de compilación es más estricto que tu npm install local. Un archivo de bloqueo sutilmente desincronizado con package.json se instala bien localmente en un npm más nuevo y falla la compilación en el npm más antiguo del host. ¿La compilación falla en el host pero no localmente? Sospecha primero del archivo de bloqueo.
• Fija tu runtime en la especificación de compilación, no solo en un archivo de versión. Un .nvmrc solo no se respeta de manera confiable — invoca el gestor de versiones también en los comandos de compilación.
• Cada nueva variable de entorno necesita agregarse en la consola del hosting, por separado del código que la lee. Esta es una respuesta sorprendentemente frecuente a "por qué está roto".
• Content-Security-Policy es el encabezado que te morderá. Cada origen de terceros con el que tu página realmente habla — análisis, administrador de etiquetas, píxeles, fuentes, endpoints de formularios — debe estar en la lista blanca, en la directiva correcta, o será bloqueado silenciosamente en producción mientras funciona perfectamente en desarrollo local. Síntoma: "el seguimiento funciona localmente, no dispara nada en vivo." Verifica la consola del navegador en busca de violaciones de CSP antes de depurar cualquier otra cosa.
• Verifica contra el artefacto desplegado, no contra el archivo fuente. Confirma una corrección inspeccionando la respuesta de producción real (curl -I, herramientas de desarrollo del navegador), no leyendo la configuración que se suponía que la producía. Lo mismo para "¿mi cambio realmente se desplegó?" — verifica el ID/marca de tiempo de la compilación, no solo que la fusión ocurrió.

Cómo se envía realmente el formulario

El hosting estático no tiene backend. Un <form> simple en una página estática no hace nada útil — esto sorprende a la gente el primer día, y es todo el punto de la página. Tres opciones realistas:

Opción	Buena cuando	Cuidado con
Un servicio de formularios alojado	Quieres que funcione esta tarde	Costo mensual por volumen; su marca; tus datos viven con ellos
Una función serverless (Lambda, Netlify/Cloudflare Functions)	Quieres control y costo casi cero	Ahora tienes validación, spam y CORS
El formulario incrustado o webhook de tu CRM	El lead necesita llegar a un CRM de todos modos	Peso de la incrustación y límites de estilo; a menudo lento de cargar

Cualquiera que elijas:

• CORS será tu primer error. Un endpoint serverless en un origen diferente al de tu página debe permitir explícitamente ese origen en la lista blanca, o el navegador bloquea la solicitud antes de que se envíe. Agrega también localhost a la lista blanca, o no podrás probar localmente.
• Agrega un campo honeypot (una entrada oculta que los humanos nunca llenan y los bots sí) y rechaza cualquier cosa que lo llene. El filtro de spam más barato que existe.
• Nunca extiendas un cuerpo de solicitud crudo directamente en tu escritura de base de datos. Así es como un visitante termina estableciendo campos que pretendías controlar del lado del servidor. Selecciona los campos que deseas, explícitamente.
• Mantén el endpoint caliente si puedes. Una función serverless que se inicia en frío hace que el momento más importante de la página — presionar enviar — se sienta roto.

---

3. Dale a Claude un kit de marca — y oblígalo a cargarlo

Esto es lo de mayor apalancamiento en la lista. Como mínimo, el kit contiene:

tu oferta · tu mercado objetivo / perfil de cliente · tu estrategia de mensajería · tus colores · tus fuentes · tu logotipo

Ponlo en una carpeta (brand/). Plantilla: starters/brand-kit/brand.md.

Luego haz que se cargue automáticamente. Una instrucción en CLAUDE.md que diga "lee el kit de marca" es consultiva — se sigue de manera inconsistente. Un hook SessionStart que cat los archivos en el contexto no es opcional y no se salta. Ese único cambio es la diferencia entre "a veces alineado con la marca" y "alineado con la marca por defecto." Consulta starters/settings.json.

Carga al inicio de la sesión: el kit de marca, un breve documento de arquitectura (cómo está construido, alojado y desplegado el sitio), y el registro de sesión más reciente.

Estructurándolo bien:

• Divide "cómo se ve la marca" de "cómo habla la marca". Mantén el archivo siempre activo ligero — paleta, fuentes, logotipos, oferta, audiencia. Apunta a material más profundo de voz/mensajería como "léelo cuando hagas trabajo de texto." Todo lo cargado automáticamente cuesta contexto en cada sesión, para siempre.
• Asigna roles a los colores, no solo códigos hex ("acento primario — usado para el CTA principal"). Los roles son lo que evita que Claude invente un color cuando lo necesita. Enuncia la regla claramente: ningún color fuera del kit aparece en ninguna parte. Los colores fuera de marca de plantillas y generadores se cuelan silenciosamente de otra manera.
• Dos o tres ejemplos de tono antes/después enseñan la voz más rápido que cualquier lista de adjetivos.
• Si tu mensajería es comercialmente sensible, haz gitignore pero aún así haz referencia a ella desde CLAUDE.md — obtienes una carga consistente sin publicar estrategia o precios en un repositorio.
• Los documentos de marca sincronizados externamente se vuelven obsoletos. Si un documento de voz o audiencia se copia de un disco compartido, vuelve a verificarlo contra su fuente antes de una pasada de copia — las decisiones de marketing se toman en conversaciones que nunca vuelven al documento.

Disciplina de texto que el kit de marca debe imponer:

• Nunca prometas "sin registro / sin correo electrónico requerido" en una página cuyo trabajo es capturar un correo electrónico. Se lee como reducción de fricción hasta que aparece el formulario, y luego es una contradicción en el momento exacto en que necesitas confianza. En su lugar, tranquiliza sobre tiempo, costo y beneficio — "2 minutos · gratis · tu resultado enviado por correo inmediatamente."
• Vuelve a auditar el microcopy de tranquilidad cada vez que la oferta cambie. Se copia entre variantes de página y sobrevive a la oferta para la que fue escrito, precisamente porque suena útil.
• La promesa del anuncio, la promesa de la página y la solicitud real del formulario deben estar de acuerdo. Una discrepancia se manifiesta como una caída en el paso donde llega la verdad, no en el paso donde se introdujo la discrepancia. Cuando un paso pierde, sospecha del paso anterior.

---

4. Velo antes de publicarlo

Dos formas de ver una página sin desplegarla. Usa ambas — son para diferentes personas.

Servidor de desarrollo local

Para ti y Claude, durante la construcción. Claude puede iniciar el servidor de desarrollo, manejar un navegador real, capturar la pantalla del resultado y leer los registros de la consola y la red — por lo que "¿esto se renderiza correctamente?" se responde mirando, no inspeccionando el código.

• Nunca ejecutes dos servidores de desarrollo para el mismo proyecto a la vez. Verifica primero si hay un proceso existente y mátalo antes de iniciar otro — especialmente si agentes paralelos podrían iniciar cada uno uno.
• Limita los bucles de reintento automático a ~3 intentos. Un bucle abierto de "sigue recargando e intentando diferentes tiempos hasta que funcione" envuelto alrededor de un servidor de desarrollo más automatización del navegador es un riesgo genuino de agotamiento de recursos, no solo una molestia — ha bloqueado una máquina por completo.
• Verifica la limpieza en lugar de confiar en ella. "Detuve el servidor y cerré las pestañas" es una afirmación no verificada como cualquier otra — verifica la lista de procesos.
• Espera que local difiera de producción por diseño. Cualquier cosa bloqueada detrás de un ID de análisis real o un endpoint de API en vivo es típicamente una no operación localmente. Eso es comportamiento esperado, no un error — documéntalo para que no se rediagnostique cada pocas semanas.
• Mantén tus pruebas de extremo a extremo apuntando a localhost por defecto, con apuntarlas a la URL desplegada real siendo un acto deliberado y separado — de lo contrario, una ejecución de prueba rutinaria realiza una presentación real contra producción.

Claude Design (claude.ai/design)

Para todos los demás. Claude puede enviar una página a un proyecto de Claude Design, dándote una URL compartible donde un cliente, un diseñador o un socio no técnico puede editar texto y diseño visualmente en el navegador sin configuración local. Excelente para la aprobación antes de que una página se conecte al sitio real.

La única regla estricta: nunca escribir a ciegas en Design

Antes de escribir cualquier cosa en un proyecto de Claude Design, Claude debe obtener la versión remota actual, hacer un diff y verificar contigo antes de sobrescribir. Cada vez.

No hay historial de versiones, ni deshacer, ni papelera en el lado de Design — un archivo de lienzo es más frágil que uno local sin seguimiento. Una sobrescritura a ciegas de las ediciones de un colaborador es permanentemente irrecuperable, y ya ha costado una noche completa de texto escrito a mano.

• Crea la página como HTML/CSS/JS estático autocontenido. El D

…

[truncado para traducción]