App Landing SEO — ficha store → páginas de keywords

Página de Aterrizaje SEO para Aplicaciones

Flujo de trabajo completo para convertir la ficha de una aplicación en una página de aterrizaje de alta conversión y optimizada para SEO, con páginas guía de palabras clave long-tail. Pila por defecto: Vite + React con prerenderizado en tiempo de compilación (arquitectura en la Fase 3). Si el repositorio ya tiene un framework web (Next.js, Astro), construye dentro de ese y adapta las rutas de salida. Cada fase termina con verificación.

Esta habilidad depende de la habilidad gpt-image instalada por separado en el mismo repositorio. Cuando se necesiten imágenes de guía, carga esa habilidad y sigue sus instrucciones. No asumas que su helper vive dentro del directorio de esta habilidad.

Fase 1 — Obtener la ficha de la tienda (fuente de verdad)

1. Obtén los metadatos completos de la API de búsqueda de iTunes (sin necesidad de autenticación):

   curl -s "https://itunes.apple.com/lookup?id=<APP_ID>&country=us"
   

   Extrae: nombre, bundleId, descripción, precio/condiciones IAP, géneros, número de valoraciones, capturas de pantalla, icono, versión, vendedor. Verifica también si hay una ficha en Google Play (play.google.com/store/apps/details?id=<bundleId>) — no asumas que es solo para iOS.

2. Descarga los activos en alta resolución reescribiendo el sufijo de miniatura de mzstatic:

   • Icono: reemplaza 512x512bb.jpg con 1024x1024bb.png
   • Capturas de pantalla: reemplaza 392x696bb.jpg con 1284x2282bb.png (falla con gracia; verifica con file)

3. Lee cada captura de pantalla con la herramienta Read. Los pies de foto, temas de la guía y el texto de la página de aterrizaje deben describir lo que las pantallas muestran realmente. También extrae la paleta de marca y el estilo tipográfico de ellas.

4. Escribe app.md en la raíz del repositorio: tabla de identidad, descripción textual, lista de características derivada de la ficha + capturas, manifiesto de activos, luego la investigación de palabras clave (Fase 2) y el mapa de colocación. Este archivo es el contrato para todo lo que sigue.

Fase 2 — Investigación de palabras clave que convierten

• Si las herramientas MCP de astro están conectadas, usa get_keyword_suggestions y search_app_store para la popularidad/dificultad de la App Store y el ranking actual. Registra dónde se encuentra la aplicación hoy.
• Usa WebSearch para validar las palabras clave long-tail del lado de Google (la página de aterrizaje posiciona en Google, no en la App Store).
• Estructura la salida en app.md:
  • Palabras clave primarias (3–5 términos principales) → etiqueta title, H1, texto del héroe, meta description
  • Secundarias → H2 de secciones, texto de características
  • Long-tail (6–10 frases de pregunta/tarea) → una página guía cada una
• Reglas que importan:
  • Cada palabra clave long-tail debe mapearse a un problema que la aplicación resuelva demostrablemente — idealmente uno visible en una captura de pantalla. Eso es lo que hace que el tráfico convierta.
  • Verifica los SERP reales para cada término principal y omite los envenenados (por ejemplo, "tracker de acciones" devuelve aplicaciones del mercado de valores; "software de gestión de inventario" devuelve proveedores empresariales).
  • Prefiere frases de "cómo hacer" donde los blogs posicionan — una página de aplicación con esquema HowTo/FAQ puede vencerlos.

Fase 3 — SEO en la página de aterrizaje

Arquitectura SSG con Vite + React (por defecto)

Una SPA es invisible para los rastreadores sin renderizado JS, así que entrega HTML estático prerenderizado. No se necesita un framework SSG — un script de prerenderizado de ~30 líneas lo hace, y las páginas generalmente necesitan cero JS del cliente (los acordeones de FAQ son elementos <details> nativos; no hidrates lo que no tiene interactividad):

landing/
  package.json          # build: vite build --ssr src/entry-server.tsx --outDir dist-ssr && node scripts/prerender.mjs
  vite.config.ts        # plugins: [react()], ssr: { noExternal: true }  ← empaqueta react en dist-ssr para que prerender.mjs lo importe standalone
  index.html            # shell solo para desarrollo: <div id="root"> + /src/entry-client.tsx
  public/               # style.css, assets/ (copiado textualmente en dist/)
  src/
    data.ts             # TODO el contenido: entradas FAQ, cuerpos de guía, títulos, descripciones. Fuente única de verdad.
    seo.ts              # Tipo PageMeta + constructores JSON-LD (homeJsonld, guideJsonld, breadcrumbJsonld) leyendo de data.ts
    components.tsx      # Header, Footer, StoreBadge, FaqItem, GuideCard, CtaCallout
    pages/              # Home.tsx, GuidePage.tsx, GuidesIndex.tsx
    routes.tsx          # ROUTES: [{ meta: PageMeta, element }] — una entrada por página, las guías se obtienen de data.ts
    entry-server.tsx    # renderRoute(route): cadena HTML completa — etiquetas head + JSON-LD + renderToStaticMarkup(body)
    entry-client.tsx    # solo desarrollo: matchRoute(location.pathname) → createRoot().render()
  scripts/prerender.mjs # importa dist-ssr/entry-server.js; escribe dist/<path>/index.html por ruta + sitemap.xml + robots.txt; cpSync public/ → dist/

Decisiones clave integradas en esta forma:

• renderToStaticMarkup, no renderToString — sin marcadores de hidratación, HTML limpio, ya que no se envía ningún paquete del cliente.
• URLs limpias: las rutas terminan en / (/guides/<slug>/) y el prerenderizado escribe <path>/index.html. Los enlaces internos son absolutos del sitio (/guides/…/), lo que también hace que la navegación del servidor de desarrollo funcione.
• Experiencia de desarrollo: vite sirve entry-client.tsx con HMR; la entrada del cliente nunca se envía a producción.
• esc() para valores de atributos en la plantilla head construida a mano; JSON-LD mediante JSON.stringify (sin problemas de escape).
• El atributo de React es fetchPriority (camelCase) — fetchpriority en minúsculas muestra una advertencia.

Reglas en la página (cualquier pila)

Secciones: héroe, descarga, capturas de pantalla, cómo funciona, guías, FAQ, CTA, pie de página.

• Exactamente un H1, que lleve la palabra clave principal. Los encabezados de sección son H2 (los encabezados de estilo "Disponible en" no deben ser H1).
• <title> ≈ "Marca — Palabra Clave Principal para la Audiencia" (≤60 caracteres). Meta description ≤155 caracteres con la palabra clave principal y los principales diferenciadores.
• URL canónica por página, tarjetas OG + Twitter, meta apple-itunes-app (banner inteligente de aplicación). En la configuración de Vite, estos viven en entry-server.tsx; Next.js: metadataBase, alternates.canonical, plantilla title, itunes.appId.
• JSON-LD en la página de inicio: SoftwareApplication (con offers, installUrl; omite aggregateRating por debajo de ~50 valoraciones), FAQPage, WebSite. Construye los objetos en seo.ts desde data.ts para que el esquema y la copia visible compartan una fuente.
• Badges de tienda/CTA de descarga sobre el pliegue, más una sección CTA repetida más abajo.
• Las capturas de pantalla obtienen texto alt con palabras clave que describe la pantalla real. Recomprime los PNG de la tienda (a menudo de 1–2 MB cada uno) a JPEGs de ≤200 KB (sips -Z 1386 -s format jpeg -s formatOptions 80); conserva los originales en public/assets/full/.
• FAQ: 8–10 preguntas, cada una es una consulta de búsqueda real, respondidas en 2–3 frases, cada una con un enlace "Aprende más →" a su guía correspondiente. El JSON-LD FAQPage debe contener el mismo texto de Q/A que el FAQ visible — ambos se renderizan desde el mismo array de data.ts.
• sitemap.xml + robots.txt: generados por scripts/prerender.mjs desde la lista de ROUTES, para que nuevas guías aparezcan automáticamente.

Fase 4 — Páginas guía (una por palabra clave long-tail)

Almacena el contenido de la guía en el módulo de datos único (src/data.ts en la configuración de Vite; lib/guides.ts en Next.js) y renderízalo a través de un único componente de plantilla para que el esquema, las tarjetas, los enlaces del pie de página y el sitemap se deriven de la misma lista. Modela cada guía como datos estructurados, no como fragmentos HTML: { slug, title, description, h1, intro, featureImage: { src, alt, width, height }, howto?, sections: [{ h2, paras, cta?, figure? }], faq, related } — la llamada CTA y las figuras se convierten en componentes, y los párrafos siguen siendo cadenas buscables (HTML en línea de nivel <em> mediante dangerouslySetInnerHTML está bien).

Flujo de trabajo de imagen de característica con GPT Image

Cada artículo guía obtiene su propia imagen de característica horizontal. Carga y usa la habilidad gpt-image, que llama a gpt-image-2 de OpenAI; no sustituyas con imágenes de stock, degradados CSS, capturas de pantalla u otro modelo de imagen a menos que el usuario lo pida explícitamente. Si gpt-image no está instalado, detente antes de la generación de imágenes y dile al usuario que instale la habilidad hermana desde este repositorio.

1. Después de que los títulos y slugs de las guías estén finalizados, haz un resumen de imagen por guía a partir de su intención de búsqueda, tema concreto y la identidad visual de la aplicación capturada en app.md. Los conceptos deben ser significativamente diferentes, no intercambios de paleta de una misma composición.
2. Indica una imagen de característica editorial en la paleta de la marca de la aplicación. Describe el sujeto, entorno, composición, iluminación, materiales, cámara/punto de vista, y dónde debe estar el espacio de respiro visual. Termina cada indicación con: Imagen de característica editorial horizontal, composición 3:2. Absolutamente sin texto, palabras, letras, números, marcas de agua, etiquetas de interfaz ni logotipos. No pidas al modelo que renderice el título del artículo.
3. Resuelve GPT_IMAGE_SKILL_DIR al directorio instalado que contiene el SKILL.md de la habilidad gpt-image, luego ejecuta su generador con un destino determinista:

   "$GPT_IMAGE_SKILL_DIR/scripts/generate_image.py" "<indicación específica de la guía>" \
     --model gpt-image-2 \
     --aspect-ratio 3:2 \
     --quality high \
     --background opaque \
     --format webp \
     --output "<directorio-público-del-sitio>/assets/guides/<slug>-feature.webp"
   

   Esto produce una fuente horizontal de 1536×1024. Crea el directorio de destino cuando sea necesario. Preserva la fuente generada; usa el pipeline de imágenes del framework para variantes responsivas más pequeñas en lugar de recomprimirla repetidamente.
4. Inspecciona cada imagen a tamaño completo antes de conectarla. Verifica la presencia de texto/glifos accidentales, objetos malformados, UI de aplicación copiada, logotipos no intencionados, material irrelevante y mala seguridad de recorte en proporciones de escritorio y tarjeta. Regenera solo las imágenes fallidas, cambiando la indicación para abordar el defecto observado; detente después de dos regeneraciones fallidas para la misma guía e informa del problema restante en lugar de gastar tiempo indefinidamente.
5. Añade la imagen al registro estructurado de la guía con width: 1536, height: 1024, y texto alt descriptivo conciso basado en lo que realmente contiene la imagen. Renderízala como la imagen de característica sobre el pliegue del artículo, la miniatura de la tarjeta de guía y las imágenes og:image/twitter:image de la página. Añádela al JSON-LD Article.image como una URL absoluta. No uses la palabra clave de búsqueda como texto alt de relleno cuando no describa los píxeles.

Por guía:

• Slug de URL = la palabra clave (/guides/how-to-keep-track-of-inventory-small-business)
• Apertura que responde primero: el primer párrafo responde directamente a la pregunta buscada (cebo para fragmento destacado), luego el cuerpo enseña la tarea con la aplicación integrada como la herramienta — enseña primero, promociona después.
• Los H2 llevan frases secundarias de la palabra clave. 600–900 palabras de sustancia, sin relleno.
• Una captura de pantalla relevante de la aplicación con un pie de foto descriptivo, una llamada CTA a mitad de página y un FAQ de 2 preguntas único para esa guía (no dupliques preguntas del FAQ de la página de inicio — duplicación de esquema).
• JSON-LD: Article + BreadcrumbList + FAQPage, más HowTo cuando la guía está orientada a pasos.
• Enlaza las guías entre sí y de vuelta a las secciones de la página de inicio.
• El activo de imagen generado por GPT Image está presente, es único para el artículo y está conectado al héroe, la tarjeta, los metadatos sociales y el JSON-LD Article.image. Usa srcset responsivo/optimización de imágenes del framework y establece dimensiones explícitas para evitar el desplazamiento del diseño; no cargues perezosamente la imagen de característica sobre el pliegue.

Fase 5 — Desplastificar la copia (Wikipedia: Señales de escritura por IA)

Ejecuta esta pasada en TODO el contenido que escribiste (guías, respuestas del FAQ, copia del héroe/sección) antes de enviarlo. Las señales, en orden de contundencia:

1. Rayas em — la señal #1. Presupuesto: un puñado en todo el sitio, no por párrafo. Reemplázalos con puntos, comas, dos puntos, paréntesis.
2. Paralelismos negativos — "No es X, es Y", "no solo X sino Y", "X, no Y". Máximo uno por sitio, y solo si se gana su lugar.
3. Regla de tres — "sin A, sin B, sin C", "adj, adj, adj". Divídelos en pares o listas reales.
4. Estructura formulaica — aperturas idénticas en las páginas (por ejemplo, cada guía comenzando con la misma plantilla de tesis en negrita). Varía: respuesta directa, escenario, afirmación simple.
5. Cadencia contundente uniforme — frase tras frase corta que remata con un golpe de efecto. Varía la longitud de las frases; deja que algunas frases solo transmitan información.
6. Lista negra de vocabulario: ahondar, tapiz, testimonio, fundamental, crucial, vibrante, sin fisuras, sin esfuerzo, presume, apalancar, elevar, robusto, meticuloso, paisaje, subrayar, mostrar, fomentar, transformador, revolucionar, empoderar, agilizar, "característica asesina", "fuente única de verdad", "con confianza", repetido "Así es cómo/Aquí está el...".
7. Evitación de cópula — "sirve como", "se presenta como", "representa" cuando "es" funciona. Usa "es".
8. Participios de análisis superficial — cláusulas "...destacando", "...subrayando", "...reflejando" adjuntas al final de las frases.
9. Reemplaza aforismos con detalles concretos (un precio, un mes, un objeto con nombre). Los detalles suenan humanos; las generalidades suenan generadas.

Verificación mecánica (adapta las rutas):

grep -o "—" <archivos de contenido> | wc -l   # objetivo: un solo dígito en todo el sitio
grep -inE "ahondar|tapiz|testimonio|fundamental|esencial|vibrante|sin fisuras|sin esfuerzo|presume|apalancar|elevar|robusto|meticuloso|paisaje|subrayar|mostrar|fomentar|transformador|revolucionar|empoderar|agilizar|sirve como|se presenta como|no es solo|no es simplemente|no solo" <archivos de contenido>

Los nombres de clase CSS (por ejemplo, transition-transform) darán falsos positivos; ignóralos. Lo que mantengas debe sobrevivir a la pregunta "¿escribiría un humano ocupado esta frase?"

Mantén intacto mientras desplastificas: slugs, encabezados/palabras clave, enlaces internos, esquema (regenera el esquema desde la fuente reescrita para que el texto visible y el JSON-LD sigan siendo idénticos).

Fase 6 — Verificar

• npm run build debe pasar, luego ejecuta una verificación con script sobre dist/**/index.html: exactamente un H1 por página, canónico presente, cada <script type="application/ld+json"> se analiza, cada href/src interno se resuelve a un archivo en dist (mapea URLs con barra inclinada final a <path>/index.html), cada <loc> del sitemap se mapea a un archivo real, y las preguntas visibles del FAQ de la página de inicio son iguales a los names del JSON-LD FAQPage.
• Verifica que cada registro de guía tenga una imagen de característica horizontal distinta, que cada archivo exista en la salida construida, que las dimensiones intrínsecas sean más anchas que altas, que los atributos HTML width/height coincidan con la fuente, y que las URLs Open Graph, Twitter y Article.image de cada guía resuelvan correctamente.