El prompt web perfecto: 10 preguntas

Las 10 preguntas que escriben tu prompt por ti

Todo el mundo ha tenido la misma experiencia con un generador de webs con IA. Escribes una frase, obtienes algo que se parece a cualquier otra web generada y pasas la hora siguiente reconduciéndolo a base de prompts hacia lo que querías decir. La herramienta no es el problema. Un briefing de una sola frase sí.

Un buen prompt no es más largo porque sí: es un briefing. Entre un resultado genérico y una web que enseñarías a un cliente hay unas diez decisiones, tomadas antes de escribir nada. Responde a estas diez preguntas, junta tus respuestas y ya tienes el prompt.

Al final de este artículo encontrarás un ejemplo completo para copiar y adaptar.

1. ¿Qué tipo de sitio es y a quién se dirige?

Pregúntate: ¿qué tiene que conseguir este sitio y a quién tiene que convencer?

Toda web generada tiende a la plantilla genérica mientras no nombres la categoría. «Una web» te da una plantilla. «Una web de marketing para una empresa B2B de SaaS» te da la arquitectura de información correcta: páginas de soluciones, planes de precios, solicitud de demo, prueba social.

2. ¿En qué sitio existente debería inspirarse estructuralmente?

Pregúntate: ¿qué estructura resuelve ya bien este problema?

Es la frase con más impacto de todo el prompt. Nombrar un sitio de referencia importa décadas de decisiones de layout en cinco palabras. Deja claro que hablas de estructura y no de estética, o el modelo copiará también los colores.

3. ¿Cómo debe verse y cómo no debe verse?

Pregúntate: ¿cuál es la identidad visual, formulada como contraste?

Describir una estética en positivo resulta vago; describirla frente a algo es preciso. «Oscuro y preciso» admite interpretaciones. «Oscuro y preciso en lugar de naranja intenso sobre blanco» no.

4. ¿Cuál es el stack técnico exacto y qué está prohibido?

Pregúntate: ¿con qué debe construirse y qué no debe usar nunca?

La restricción que más importa es la negativa. La mayoría de generadores con IA recurren por defecto a Next.js con server components, el motivo más habitual de que una web generada no pueda convertirse después en un tema de CMS. Di que no de forma explícita.

5. ¿Cuáles son los design tokens exactos?

Pregúntate: ¿cuáles son los valores hex, las tipografías y los tamaños concretos?

Aquí es donde la mayoría de prompts se desinfla en «moderno y limpio». Da una paleta real con códigos hex, una escala tipográfica con valores en píxeles, una unidad de espaciado y una escala de radios. Una tabla de tokens con nombres es la diferencia entre un sistema de diseño y un estado de ánimo.

6. ¿Dónde puede aparecer el color de acento?

Pregúntate: ¿qué reglas gobiernan el diseño, no solo sus valores?

Los tokens le dicen al modelo qué existe. Las reglas le dicen qué aspecto tiene la contención. Sin una regla, un acento intenso acaba como fondo a sangre completa y la sensación empresarial se evapora.

7. ¿Qué componentes necesita el sitio?

Pregúntate: ¿cuál es el inventario real de componentes?

Enumerar componentes convierte una petición vaga en una lista que el modelo puede recorrer. Además evita que descubras, tres páginas más tarde, que no hay tarjeta de testimonio ni tabla de precios.

8. ¿Qué páginas y rutas existen?

Pregúntate: ¿cómo es el sitemap, ruta por ruta?

Nombra cada ruta, incluidas las plantillas de detalle que se olvidan: un listado de blog sin página de detalle es un callejón sin salida, y es la omisión más frecuente en las webs generadas.

9. ¿Las páginas deben estar terminadas o solo esbozadas?

Pregúntate: ¿cuán completo tiene que ser el contenido?

Si no dices lo contrario, obtendrás lorem ipsum y estados vacíos. Pide textos verosímiles en cada página y cada plantilla y tendrás algo que de verdad puedes enseñar a alguien.

10. ¿Qué debe cumplirse en cuanto a calidad?

Pregúntate: ¿qué es innegociable, porque de lo contrario tendrás que arreglarlo a mano?

La accesibilidad, la adaptabilidad y la estructura de archivos salen baratas si se piden por adelantado y caras si hay que añadirlas después. Pídelas en la misma frase que el diseño.

Cómo se monta todo

Diez respuestas, en orden, son el prompt. Nada de esto es ingenioso: solo es concreto. El modelo no adivina qué querías decir con «moderno», porque le has dicho #22262A.

Este es el ejemplo completo, montado a partir de las respuestas anteriores. El prompt se mantiene en inglés a propósito: los generadores con IA dan resultados más fiables así, y los nombres de tokens y de rutas ya están en inglés.

Build a marketing/corporate website frontend for a B2B SaaS company, structurally
inspired by hubspot.com (its layout patterns, information architecture, and content
density) but with a completely different visual identity: a dark, precise, "enterprise
software" aesthetic instead of HubSpot's bright/friendly orange-on-white look.

TECH CONSTRAINTS
- React + Vite only. No Next.js, no SSR, no server components.
- Client-side routing with React Router.
- Tailwind CSS, configured with the custom design tokens below (extend the theme;
  do not use Tailwind's default palette for brand colors).
- Component-driven: reusable components in /src/components, page views in /src/pages.
- Fully responsive: mobile, tablet, desktop. Mobile nav becomes a slide-in drawer.
- Semantic, accessible markup: heading hierarchy, alt text, focus states, and
  contrast that passes WCAG AA for accent-on-anthracite and accent-on-white.
- Scroll-triggered fade/slide-in animations (CSS + IntersectionObserver, or Framer
  Motion — nothing heavier).
- Placeholder imagery: abstract gradients, geometric shapes, illustrative SVG
  patterns. No stock photography.

BRAND
Placeholder brand name "NORTHBEAM" (all caps in the logo lockup), stored in a single
config file so it can be swapped later.

COLOR TOKENS
--color-white              #FFFFFF   primary/light backgrounds
--color-off-white          #F5F6F7   secondary background, cards on light
--color-anthracite         #22262A   primary dark background
--color-anthracite-2       #2C3136   elevated surface on dark
--color-dark-gray          #3F454B   borders/dividers on dark
--color-text-primary       #1A1D20   body text on light
--color-text-secondary     #6B7280   muted text on light
--color-text-inverse       #F5F6F7   body text on dark
--color-text-inverse-muted #9CA3AF   muted text on dark
--color-accent             #D6FF3F   electric lime: CTAs, highlights, active states
--color-accent-hover       #C2EB2C   accent hover/pressed
--color-accent-contrast    #1A1D20   text ON the accent (never white)
--color-border             #E5E7EB   borders on light
--color-success            #3FCE7E   positive status
--color-danger             #FF5C5C   errors

DESIGN RULE: the accent is used sparingly — primary CTAs, small badges, underline
bars, active nav indicator, key stat numbers, chart accents. Never a large background
fill. It stays a spark, not a wash.

TYPOGRAPHY (load via Google Fonts)
- Headings: Space Grotesk 500/600/700
- Body/UI: Inter 400/500/600
- Monospace: JetBrains Mono 400/500 for code, data labels, tags
Type scale (desktop / mobile, fluid clamp() where sensible):
H1 56/40 Space Grotesk 600, -0.02em, line-height 1.05
H2 40/30 Space Grotesk 600, line-height 1.1
H3 28/22 Space Grotesk 500
H4 20/18 Space Grotesk 500
Body Large 18 Inter 400/1.6 - Body 16 Inter 400/1.6 - Small 14 Inter 500
Eyebrow 13 Inter 600 uppercase, 0.08em, often in the accent

SPACING & LAYOUT
8px base unit. Section padding 96px desktop / 56px mobile. Max width 1280px centered,
24px gutter mobile / 64px desktop. 12-column grid collapsing to 1-2 columns.
Radius: 8px buttons/inputs, 16px cards, 24px large panels. Shadows subtle
(0 1px 2px rgba(0,0,0,0.04), 0 4px 12px rgba(0,0,0,0.06)); cards on anthracite use a
1px --color-dark-gray border instead of a shadow.

COMPONENTS
Navbar (sticky, transparent over hero, solid white on scroll, mega-menu dropdowns for
Product / Solutions / Resources / Pricing, "Log in" text link + "Request a demo"
accent button) - Buttons (primary accent, secondary ghost on light and dark, text link
with arrow) - Hero (dark, H1 + subhead, two CTAs, abstract visual, trusted-by strip) -
Logo strip - Feature grid and alternating image/text blocks - Stats band (large accent
numbers on dark) - Product tabs/showcase - Testimonial cards - Pricing (3 tiers, middle
highlighted "Most popular") - Resource/blog cards (image, mono accent category tag,
title, date) - CTA band - Footer (multi-column links, newsletter input, social, legal
bar) - Badge/tag in mono.

PAGES / ROUTES (all sharing one layout with Navbar + Footer)
/                 Home: hero, logo strip, feature grid, product tabs, stats,
                  testimonials, CTA band
/product          Product overview, feature deep-dives
/solutions        Solutions by industry/team, card grid
/pricing          Three tiers + FAQ accordion
/resources        Blog/resource listing grid with filter tags
/resources/:slug  Blog DETAIL template: title, category tag, date, author, hero image,
                  long-form article body (headings, paragraphs, lists, pull quote,
                  inline image, code block), and a "related articles" row
/about            Mission, leadership grid, timeline/stats
/demo-request     Form page with validation states using success/danger tokens

CONTENT COMPLETENESS
Fill every page with real content — no lorem ipsum, no empty states, no "coming soon".
Write plausible, concise enterprise SaaS copy: short headlines, benefit-driven
subheads. Populate the resource listing with at least 6 article cards, and write at
least 3 complete blog detail pages so /resources/:slug is genuinely browsable.

DELIVERABLES
Clean componentized code. tailwind.config.js centralizing every token above.
src/config/brand.js holding brand name, tagline and nav links. Prioritize Home,
Product and Pricing for full visual polish; other pages reuse the same components.

Las dos cosas que casi todo el mundo olvida

Dos de las diez preguntas anteriores existen porque su ausencia es el fallo más habitual de las webs generadas, y ambas se resuelven con una frase.

• La página de detalle del blog. Los prompts piden habitualmente un listado de blog y se detienen ahí. Obtienes una rejilla de tarjetas que no llevan a ninguna parte. Pide la plantilla /resources/:slug de forma explícita y describe qué contiene una página de artículo.
• Contenido terminado. Si no lo pides, obtendrás texto de relleno y estados vacíos. «Rellena cada página con contenido real, sin lorem ipsum» cuesta nueve palabras y convierte un esqueleto en algo presentable.

Una restricción que decide todo lo que viene después

La pregunta 4 merece una segunda mirada, porque es la única respuesta con consecuencias más allá del diseño. React + Vite, sin SSR, sin server components.

La mayoría de generadores con IA recurren por defecto a Next.js con App Router. Está bien mientras el proyecto vive dentro del generador, y es el motivo más habitual de que una web generada no pueda convertirse después en un tema de WordPress o de HubSpot. WordPress renderiza PHP; HubSpot renderiza HubL en sus propios servidores. Ninguno tiene un runtime de Node esperando para ejecutar tu capa de servidor.

Indicar la restricción en el prompt no cuesta nada. Descubrirla cuando el diseño ya está aprobado cuesta una refactorización.

Del prompt a una web que otra persona pueda editar

Un gran prompt te da un gran frontend. No te da un CMS: el equipo de marketing sigue sin poder cambiar un titular sin desarrollo y sin un despliegue.

Ese es el paso del que se encarga transjt: subes el código generado a GitHub, conectas el repositorio y el frontend en React se convierte en un tema nativo de WordPress con plantillas PHP reales, o en módulos nativos de HubSpot con campos editables. Primero un buen prompt, luego la conversión, y la web es tuya y además manejable.