tmj-90/landing-page-generator

Generar páginas de aterrizaje de alta conversión

Entrega una página real: componentes TSX funcionales, estructura de copy real y rendimiento medido. Deben coincidir con el framework, estilo y convenciones de componentes del repositorio existente, usando solo las dependencias que ya tiene: una entrega nunca instala una nueva (el hook de seguridad lo bloquea). Un bootstrap desde cero sin stack elegido puede usar por defecto Next.js + Tailwind; en cualquier otro caso, si la página realmente necesita una dependencia faltante, llama a mark_ticket_blocked nombrándola.

Objetivos (Core Web Vitals "bueno", p75 de campo): LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1. También cumplir con WCAG 2.2 AA: contraste de texto ≥ 4.5:1, anillo de enfoque visible, inputs etiquetados y página operable con teclado.

Framework de copy (elige uno por página)

Framework	Estructura	Mejor para
PAS	Problema → Agitación → Solución	Tráfico consciente del problema
AIDA	Atención → Interés → Deseo → Acción	Tráfico frío, nueva categoría
BAB	Antes → Después → Puente	Ofertas de resultado/transformación

Las plantillas y las cinco objeciones de la FAQ están en references/copy-frameworks.md. La habilidad copywriting cubre la redacción de titulares y CTA.

Plano de secciones

1. Hero: un titular de resultado (≤ ~10 palabras), un subtítulo de una oración sobre cómo, un CTA principal y una señal de prueba (un conteo, logos o una calificación). Sin carrusel.
2. Problema: el costo del status quo, en palabras del cliente.
3. Solución / beneficios: 3–6 beneficios, cada uno con una explicación de una línea y un visual opcional.
4. Prueba social: testimonios con nombre, rol, empresa y resultado; logos.
5. Precios (si aplica): 2–4 niveles con el recomendado resaltado.
6. FAQ: las cinco objeciones. Usa <details>/<summary> nativos o un acordeón accesible. El marcado FAQPage es opcional porque Google ya no muestra resultados enriquecidos de FAQ.
7. Footer CTA: repite la acción principal con mínima fricción (p. ej., solo correo electrónico).

Pasos

1. Recolecta los inputs. Nombre del producto, audiencia, dolor clave, resultado principal, CTA principal y su destino, la prueba disponible y la dirección de estilo. Lee el ticket, BRAND.md/tokens y las páginas existentes primero. Cuando no estés supervisado, no te detengas a preguntar: usa lo que existe y marca las brechas como [TODO: …] en el copy. Nunca inventes testimonios, logos, conteos de clientes o calificaciones.

2. Elige el framework según la fuente de tráfico y el nivel de conciencia. Escribe el copy antes del layout. Redacta cinco titulares y quédate con el más claro.

3. Construye las secciones como componentes separados en el directorio de componentes del repositorio. Pon el copy en props o en un objeto de contenido, no disperso en el JSX. Mantén la página mayormente renderizada en el servidor, con componentes de cliente solo donde la interacción los necesite.

4. Metadatos SEO. Establece un <title> único, una meta descripción, un canonical, etiquetas Open Graph y Twitter, y un <h1>. En Next.js App Router, usa la exportación metadata.

5. Rendimiento.

   • Carga la imagen hero/LCP con avidez usando fetchpriority="high". En Next.js 16+ usa <Image preload> (o loading="eager" + fetchPriority="high"); priority es la forma de Next.js ≤ 15, obsoleta en 16. Nunca la cargues con lazy loading.
   • Carga con lazy loading las imágenes debajo del pliegue.
   • Cada imagen obtiene width/height explícitos y AVIF/WebP.
   • Las fuentes usan font-display: swap (o next/font) con solo los pesos necesarios.
   • Sin scripts de terceros arriba del pliegue.

6. Formulario (captura de leads). Usa inputs etiquetados con el type y autocomplete correctos, validación en línea y un resumen de errores que conserve lo que el usuario escribió. Muestra un estado de éxito, desactiva el doble envío y envía al endpoint real nombrado en el ticket.

7. Verifica. Ejecuta y registra cada verificación:

   • el type check (npx --no -- tsc --noEmit, que falla en lugar de descargar) y el lint del repositorio;
   • el script de build del repositorio (p. ej., npm run build);
   • una prueba de componente que renderiza la página y afirma el h1, el href del CTA principal y los estados de éxito y error del formulario;
   • Lighthouse (móvil) como verificación de laboratorio, registrando LCP, CLS, TBT y el puntaje de accesibilidad, solo si ya está instalado (npx --no -- lighthouse);
   • una verificación de viewport a 375 px, 768 px y 1440 px por desbordamiento y por el CTA arriba del pliegue, a través del ejecutor de pruebas del navegador del repositorio si lo tiene.

   Nunca instales ni descargues una herramienta para ejecutar una verificación. Nombra cualquier verificación que no hayas podido ejecutar en tu evidencia en lugar de afirmarla.

Hecho cuando

• La página se compila, pasa el type-check y sus pruebas de componente.
• El hero establece un resultado y el CTA principal está arriba del pliegue a 375 px y 1440 px (verificado por una prueba de viewport, o nombrado como no verificado).
• Cuando Lighthouse o axe están disponibles, la ejecución de laboratorio muestra LCP ≤ 2.5 s y CLS ≤ 0.1 en móvil y sin violaciones de accesibilidad automatizadas; de lo contrario, la evidencia dice que no se midieron.
• Sin prueba inventada. Cada brecha está marcada como [TODO] y listada en el informe.

Anti-patrones

• Una imagen hero cargada con lazy loading, o cambio de layout debido a medios sin tamaño o fuentes tardías.
• Varios CTAs de igual peso, o navegación completa del sitio en una página de campaña paga.
• Lorem ipsum o copy de relleno genérico dejado en la compilación. El único marcador de posición permitido es una brecha explícita [TODO: …] que el informe lista.
• Carruseles y video con reproducción automática en el hero.