En mi servidor de hosting de Opus Growth
[server name], crea una web de aterrizaje para la app móvil
[app name]. App:
[what it does, who it is for], plataformas y versiones mínimas:
[iOS and Android versions]. Las cuatro funciones principales y lo que muestra cada pantalla:
[feature, one-sentence description, items on the screen]. Planes y precios: [plan name, price, period, included features, trial length; VAT included or not]. Enlaces a las tiendas:
[App Store link],
[Google Play link]. Preguntas de soporte: [real answers on account deletion, cancellation, data export and so on]. Empresa y contacto:
[company name],
[address],
[support email],
[phone]. Dominio:
[domain]. Capturas reales:
[links or "none, draw them in HTML"].
Páginas: inicio (/: hero, historia de funciones guiada por el teléfono #ozellikler, quién la usa, precios #fiyatlar, preguntas frecuentes, llamada a la acción de descarga #indir), soporte (/destek/: preguntas frecuentes y contacto de soporte), privacidad y KVKK (/gizlilik/: cubre tanto la app como el sitio; las tiendas piden una URL de política de privacidad) y 404.html. La sección de precios lleva tarjetas de planes y, debajo, una comparativa con una `<table>` real; no le pongas min-width a la tabla, porque en la demo un ancho mínimo fijo empujaba las columnas fuera de la pantalla en móvil.
Estilo: una landing de app cálida y de confianza. Fondo crema, un color de marca oscuro y un único acento brillante usado solo como fondo. Una tipografía display redondeada y amigable de Fontshare (por ejemplo Chillax) y una tipografía de texto legible (por ejemplo Manrope). Dibuja el marco del teléfono en CSS (aspect-ratio 9/19, esquinas redondeadas, un notch) y construye las pantallas en HTML y CSS en lugar de archivos de imagen; las tarjetas de pantalla son decoración aria-hidden y el texto de al lado describe la función. Para una app real, descarga a tu propio servidor las insignias oficiales de Apple y Google para los botones de las tiendas y sigue sus directrices; añade la nota de marcas registradas al pie de página.
Reglas de movimiento (la parte más difícil, síguelas al pie de la letra):
1. Librerías: solo el núcleo de GSAP 3.13 y ScrollTrigger, solo en la página de inicio. NO se cargan Lenis, SplitText, Swiper, Lottie ni vídeo; en las páginas de soporte y privacidad no hay ningún script.
2. Cada sección de función lleva en el HTML su propio teléfono pequeño y su pantalla. En móvil, sin JS y con movimiento reducido, cada función se muestra con su propia pantalla, apiladas (una al lado de otra en pantallas más anchas); ese estado debe ser completo por sí solo.
3. A partir de 1024 px de ancho, cuando el movimiento está permitido, JS copia las pantallas de las secciones al único teléfono de la columna derecha, añade una clase `has-phone` a la sección y oculta los teléfonos pequeños. No escribas las pantallas dos veces en el HTML. Como la sección de funciones queda por debajo de la primera vista, este cambio de clase no cuenta para el desplazamiento de diseño; la demo midió CLS 0.
4. Mantén el teléfono en su sitio con CSS `position: sticky` (top: calc(50vh - la mitad de la altura del teléfono)) en lugar de un pin de ScrollTrigger. No se añade pin-spacer, funciona sin JS y la página no da saltos.
5. Cambio de pantalla: para cada sección de función usa ScrollTrigger.create con start "top 55%", end "bottom 55%" y onToggle; muestra la pantalla activa con autoAlpha de gsap y oculta la anterior con autoAlpha 0. No uses solo opacity; las pantallas ocultas deben estar en visibility:hidden para que la auditoría de accesibilidad no las lea. El título de la sección activa cambia de color (sin desvanecerse con opacity) y unos puntos junto al teléfono indican qué función está activa.
6. Las tarjetas y las cajas de precios aparecen con data-reveal, deslizándose 20 px hacia arriba al hacer scroll; vacía las pantallas copiadas en la función revert de matchMedia para que el diseño no se rompa al estrechar la ventana.
Configuración y trampas conocidas (cada una restó puntos o rompió algo en la medición de la demo, no te saltes ninguna):
1. Si ya hay un sitio en producción en el servidor, avísame primero, porque la configuración inicial sobrescribe index.html y la carpeta assets. Haz una vista previa de scaffold_site con confirm=false y llama con confirm=true tras mi aprobación. Después lee site_design_guide y site_seo_guide. Antes de escribir código, pon la dirección de diseño (tipografía, color, rejilla, elemento distintivo, lenguaje de movimiento y las librerías que NO se cargarán) en un breve ART.md fuera de assets y muéstramelo.
2. Compila Tailwind, no lo cargues desde el CDN. Instala `npm i -D tailwindcss@3` con site_run_command y background=true, y vigílalo con site_command_status. Las rutas content de `tailwind.config.js` deben cubrir todos los archivos HTML, todas las plantillas y todos los archivos JS que escriban clases. `_src/tw.css` contiene una línea `@import "../assets/app.css";` y las tres líneas `@tailwind`; compílalo en un solo archivo con `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Elimina el script cdn.tailwindcss.com y el tailwind.config en línea de las páginas y enlaza solo `/assets/site.css`. Recompila después de cada cambio de HTML.
3. Aloja las fuentes tú mismo. Primero comprueba que la familia de Fontshare que elijas tenga las letras turcas (ş, ğ, ı, İ, ç, ö, ü): en la demo Tanker no tenía la ı sin punto y Outfit no tenía ş, ğ ni İ, así que esas letras habrían caído en otra fuente en los títulos. Descarga el woff2 de cada peso por separado con site_fetch en `assets/fonts/`, escribe las reglas @font-face con `font-display: swap` en `assets/app.css` (design-check busca ahí la fuente personalizada) y comprueba el nombre de font-family en el CSS que descargaste. Precarga las fuentes de títulos y de texto usadas en la parte visible sin hacer scroll en cada página con `<link rel="preload" as="font" type="font/woff2" crossorigin>`, antes de la hoja de estilos; no precargues más de dos archivos, porque precargar un tercer peso en la demo alargó 0,2 segundos el LCP móvil. La mayoría de las fuentes de Fontshare no tienen el signo ₺, así que escribe "TL" en los precios.
4. Haz que el menú y el pie de página sean HTML estático. No cargues chrome.js ni site.config.js en las páginas. Escribe un pequeño `chrome-stamp.mjs` que lea la lista de navegación de site.config.js y estampe `_src/header.tpl` y `_src/footer.tpl` entre los marcadores `<!-- nav:start --><!-- nav:end -->` y `<!-- footer:start --><!-- footer:end -->` en cada página, añadiendo aria-current="page" al enlace activo. Las plantillas no deben terminar en .html y deben usar marcadores como `
[[NAV]]` en lugar de `{{...}}`. Construye el menú móvil sin JS con `<details>`. Deja el nombre de la organización, la dirección y el teléfono como texto plano en el pie de página, y haz que cada objetivo táctil mida al menos 44x44 px, incluidos los enlaces del pie y de las migas de pan.
5. Convierte las imágenes al descargarlas con site_fetch: escribe la misma foto con resize="480x", "800x" y "1200x", image_format="webp", quality=65 en archivos separados. site_fetch nunca recorta; cuando una foto de Unsplash necesite otra proporción, descarga la versión recortada añadiendo parámetros como `?w=1600&h=1200&fit=crop` a su URL. Da a cada `<img>` srcset, sizes y un width y height que coincidan con la proporción real. La imagen principal de la parte visible sin hacer scroll lleva fetchpriority="high" y no es lazy; las demás llevan loading="lazy" decoding="async". Si la imagen principal llena la pantalla en móvil, sirve un recorte más pequeño con `<picture>`.
6. Escribe la versión SVG del logotipo como favicon.svg con site_write_file y añade `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` a cada página. Sin favicon el navegador registra un 404 y Best Practices baja a 96.
7. Reglas del validador HTML: empieza con un `<!DOCTYPE html>` en mayúsculas, usa ` ` para los espacios del texto visible de los enlaces tel:, no uses nunca un atributo style="", da a cada botón type="button" y no pongas un `<details>` dentro de una `<figure>` después de su figcaption.
8. Descarga las librerías de movimiento (GSAP, ScrollTrigger) de jsdelivr a `assets/vendor/` con site_fetch, fija la versión y cárgalas solo en la página de inicio. No uses `<script defer>`; pon al final de la página un pequeño cargador que espere al evento load, dos llamadas a requestAnimationFrame y después a requestIdleCallback, y añada los scripts en orden con async=false. Un script de una línea en `<head>` añade la clase `js` a `<html>` y la clase `anim` salvo que prefers-reduced-motion sea "reduce"; sin `anim` el cargador no descarga nada. Define los estados iniciales ocultos solo bajo `.anim` y añade una animación CSS como red de seguridad que revele todos los elementos ocultos a los 2,5 segundos por si la librería nunca llega. En demos anteriores las librerías con defer llevaron el LCP móvil a 3,2 segundos; con este cargador las páginas midieron de 99 a 100. Llama data-reveal al atributo de los elementos que aparecen al hacer scroll; design-check solo reconoce el movimiento por ese nombre.
SEO, AEO y GEO:
1. Usa URLs tipo directorio con barra final (/destek/, /gizlilik/). Rellena el bloque seo de site.config.js y ejecuta `node seo-stamp.mjs`. Escribe el schema específico de cada página (inicio: WebPage, MobileApplication (operatingSystem, applicationCategory, ambas URLs de las tiendas como downloadUrl, los planes que te di como offers con precios en TRY; NO añadas aggregateRating, porque la valoración de una tienda no es una reseña recogida en tu sitio) y FAQPage; soporte: WebPage y FAQPage; privacidad: WebPage; BreadcrumbList en las páginas interiores. Para una empresa de software sin tienda física, localBusiness:false en site.config.js) en bloques `<script type="application/ld+json">` separados y enlázalos con el grafo base por @id. No anides BreadcrumbList dentro de @graph; mantenlo en su propio bloque, porque es la única forma en que seo-check lo ve.
2. Mantén los títulos en 60 caracteres o menos (seo-check marca como error todo lo que pase de 65), las descripciones entre 120 y 158 caracteres, un h1 por página y ningún nivel de encabezado saltado (un h3 justo después del h1 bajó la accesibilidad a 98). Cada página necesita al menos 150 palabras de contenido principal; las páginas de contacto y privacidad suelen quedarse cortas.
3. El primer párrafo de cada página responde directamente a la pregunta de la página. Escribe preguntas frecuentes propias de cada página con `<details>` y márcalas como FAQPage. Muestra la organización editora y una fecha de "Última actualización" en `<time>`.
4. En robots.txt, anota y justifica tu decisión para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot y CCBot, y apunta al sitemap. Da a sitemap.xml fechas lastmod reales. llms.txt contiene un resumen exacto del sitio en dos frases, los datos clave y una lista de las páginas importantes.
5. Sin inventar: no escribas reseñas, valoraciones, premios, número de clientes, certificados, horarios, coordenadas ni precios sin preguntarme. Deja fuera del schema cualquier campo que no conozcas.
Puertas de calidad (en orden; no digas "hecho" hasta que todas pasen):
1. Con site_run_command ejecuta `node chrome-stamp.mjs`, la compilación de Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 errores, 0 advertencias), `node design-check.mjs` (0 errores; justifica cualquier advertencia restante) y `npx html-validate "**/*.html"` (0 errores).
2. Revisa cada página con site_preview usando view="mobile" y view="desktop". site_preview captura la página con el movimiento desactivado (reduced-motion); si falta contenido en esa captura, el estado sin movimiento está roto. Las imágenes lazy más abajo pueden salir en blanco en la captura de página completa; no lo cuentes como error, pero comprueba sus rutas.
3. Ejecuta core_web_vitals con strategy="mobile" y strategy="desktop" para cada página. Criterio de aceptación: en móvil, Performance de al menos 95 y Accessibility, Best Practices y SEO en 100; en escritorio, las cuatro de al menos 95. Si una página no llega, encuentra el archivo lento con resources=true, corrígelo y vuelve a medir. Después ejecuta seo_audit en la página de inicio con strategy="mobile" y runs=2. No debe quedar ninguna dirección fuera de tu propio dominio en la lista de peticiones de red.
4. Sin scroll horizontal a 360, 390, 768 y 1440 px, objetivos táctiles de al menos 44 px y ningún error en la consola. El sitio también debe verse impecable dentro de un marco de 390x790 y otro de 1440x898, como en las páginas de prompts.
Comprobación del movimiento: site_preview no puede mostrar movimiento, así que dime qué mirar en mi propio navegador. En escritorio, al llegar a la sección Funciones, el teléfono debe quedarse fijo en el centro de la pantalla a la derecha, su pantalla debe cambiar a cada función cuando el título llegue a la mitad, el título debe tomar color y el punto de al lado debe avanzar. En un móvil y con movimiento reducido activado, cada función muestra su propia pantalla pequeña y nada queda fijo. Los botones de las tiendas deben abrir la tienda correcta.
Tras publicar: haz una vista previa con site_headers de la regla `/assets/* Cache-Control: public, max-age=31536000, immutable` y aplícala con mi aprobación; a partir de ahí, versiona el nombre del archivo cada vez que cambien el CSS o el JS (site-v2.css y así sucesivamente). Envía sitemap.xml con gsc_submit_sitemap y comprueba la página de inicio con gsc_url_inspect. Por último, entrégame: una tabla de puntuaciones por página (página, cuatro puntuaciones móviles, cuatro de escritorio, LCP, CLS), los resultados de las puertas de calidad, el resultado de las interacciones que probaste en un navegador y la lista de correcciones que aplicaste.
