Por qué tu app de Bolt.new parece genérica, y por qué la demo puede ver una página vacía

Bolt.new está hecho para ir rápido del prompt a la app funcionando, y la velocidad favorece los valores por defecto.

• Un stack de partida común. Salvo que pidas otra cosa, Bolt.new tiende a recurrir a React, Vite y Tailwind con un set de iconos conocido, las mismas piezas que usan la mayoría de las apps generadas.
• Prompts de app entera. «Hazme un planificador de comidas con una landing» pide un producto y su marketing de una sola vez, y la landing es lo que menos atención recibe.
• Ningún paso para el texto. El modelo escribe cada palabra en la primera pasada y nada en el flujo le pide a nadie que la cambie, así que el primer borrador es lo que leen los visitantes.

La app que hay detrás de la página suele ser impresionante. La landing que tiene delante es la parte que se nota generada.

IntentGrid reescribe las palabras para cada visitante: titulares, cuerpo de texto, descripciones de funciones y etiquetas de los botones, según cómo llegó ese visitante. Trabaja a partir del texto que ya tiene tu página y mantiene los nombres de marca, los precios, las fechas y las cifras en una lista intocable.

No toca tu proyecto de Bolt.new, tu código, tus estilos ni tu despliegue, y no puede arreglar una página renderizada en el cliente que no sirve texto. En una página así no hay nada en el HTML que reescribir.

Hoy la parte que funciona es una demo que muestra una copia reescrita de una URL pública en un espacio aislado en intentgrid.ai; la adaptación en tu propio dominio es acceso anticipado y se configura sitio por sitio, a mano. Cómo funciona explica el mecanismo completo.

Cuando una app de Bolt.new es una aplicación de una sola página con Vite, su servidor devuelve index.html: un título, una meta description, un elemento raíz vacío y un script. Cada titular aparece solo después de que se ejecute ese script. La demo descarga el HTML y elimina los scripts, así que en estas apps no suele encontrar casi nada que reescribir, y la vista previa vuelve casi en blanco. Es un límite de la demo, y preferimos decirlo aquí a que lo descubras tú.

Esa misma cáscara es lo que recibe cualquier rastreador que no ejecute JavaScript, incluidos muchos rastreadores de IA, y el head de ese archivo es lo único que lee una vista previa de enlace. Para ver lo que ven ellos, abre «Ver código fuente de la página» (no «Inspeccionar») en tu URL desplegada. Si tu titular no está ahí, ni la demo ni esos rastreadores pueden leerlo.

Misma maquetación, mismos precios, mismas afirmaciones. Cada versión usa únicamente lo que ya dice la página original: en este caso inventado, planificar con los ingredientes que ya tienes y una lista de la compra generada. En un build renderizado en el cliente, el texto tendría que estar primero en el HTML para que la demo pudiera reescribir algo.

Más o menos en orden de cuánto cambia cada uno en relación con el esfuerzo:

• Escribe un título y una meta description de verdad en index.html. En una app renderizada en el cliente suele ser el único texto que llega a leer un rastreador que no renderiza o una vista previa de enlace.
• Mete la landing en el HTML. Pídele a Bolt.new que prerrenderice las rutas de marketing, o que construya la landing como página estática delante de la app.
• Reescribe tú el hero, con palabras que haya usado un usuario real. Una frase escrita a mano vale más que cualquier cantidad de regeneraciones.
• Pide otra maquetación por su nombre. Di qué quieres en lugar de un hero con degradado y tres tarjetas: una captura del producto, un vídeo corto de demostración, un único ejemplo resuelto que convenza.
• Prohíbe las frases hechas una vez, de forma explícita: «sin esfuerzo», «sin fricciones», «todo en uno», «potenciar». Después pídele que señale cualquier frase que pudiera ir en la página de un competidor.

La mitad de diseño del problema se explica en por qué los sitios vibe coded se parecen.