Wie Sie einen KI-Baukasten zu einer Website bringen, die Sie wirklich launchen: 10 Fragen
Die 10 Fragen, die Ihren Prompt für Sie schreiben
Mit KI-Website-Baukästen macht jeder dieselbe Erfahrung. Sie tippen einen Satz, erhalten etwas, das aussieht wie jede andere generierte Website, und verbringen die nächste Stunde damit, das Ergebnis zurück in Richtung Ihrer eigentlichen Idee zu prompten. Das Werkzeug ist nicht das Problem. Ein Ein-Satz-Briefing ist es.
Ein guter Prompt ist nicht länger um der Länge willen – er ist ein Briefing. Zwischen einem generischen Ergebnis und einer Website, die Sie einem Kunden zeigen würden, liegen etwa zehn Entscheidungen, die Sie treffen, bevor Sie überhaupt tippen. Beantworten Sie diese zehn Fragen, fügen Sie Ihre Antworten zusammen – und Sie haben den Prompt.
Am Ende dieses Artikels finden Sie ein vollständiges Beispiel zum Kopieren und Anpassen.
1. Um welche Art von Website geht es, und für wen ist sie?
Fragen Sie sich: Was muss diese Website leisten, und wer muss von ihr überzeugt werden?
Jede generierte Website driftet in Richtung Standardvorlage, solange Sie die Kategorie nicht benennen. „Eine Website“ bringt Ihnen eine Vorlage. „Eine Marketing-Website für ein B2B-SaaS-Unternehmen“ bringt Ihnen die richtige Informationsarchitektur: Lösungsseiten, Preisstufen, Demo-Anfrage, Social Proof.
2. An welcher bestehenden Website soll sie sich strukturell orientieren?
Fragen Sie sich: Wessen Struktur löst dieses Problem bereits gut?
Das ist der wirkungsvollste Satz im gesamten Prompt. Eine Referenz-Website zu nennen, importiert jahrzehntelange Layout-Entscheidungen in fünf Worten. Sagen Sie ausdrücklich, dass Sie die Struktur meinen und nicht die Optik – sonst übernimmt das Modell auch die Farben.
3. Wie soll sie aussehen – und wie ausdrücklich nicht?
Fragen Sie sich: Was ist die visuelle Identität, formuliert als Gegensatz?
Eine Ästhetik positiv zu beschreiben, bleibt vage; sie gegen etwas abzugrenzen, ist präzise. „Dunkel und präzise“ ist auslegbar. „Dunkel und präzise statt hellem Orange auf Weiß“ nicht.
4. Wie lautet der exakte Tech-Stack – und was ist verboten?
Fragen Sie sich: Womit muss sie gebaut werden, und was darf auf keinen Fall verwendet werden?
Die wichtigste Vorgabe ist die negative. Die meisten KI-Baukästen greifen standardmäßig zu Next.js mit Server Components – der mit Abstand häufigste Grund, warum sich eine generierte Website später nicht in ein CMS-Theme überführen lässt. Sagen Sie ausdrücklich Nein.
5. Wie lauten die exakten Design-Tokens?
Fragen Sie sich: Welche Hex-Werte, Schriften und Größen gelten konkret?
Hier fallen die meisten Prompts in „modern und clean“ zurück. Geben Sie eine echte Palette mit Hex-Codes an, eine Typo-Skala mit Pixelwerten, eine Spacing-Einheit und eine Radius-Skala. Eine benannte Token-Tabelle ist der Unterschied zwischen einem Designsystem und einer Stimmung.
6. Wo darf die Akzentfarbe auftauchen?
Fragen Sie sich: Welche Regeln bestimmen das Design – nicht nur seine Werte?
Tokens sagen dem Modell, was existiert. Regeln sagen ihm, wie Zurückhaltung aussieht. Ohne Regel landet ein greller Akzent als vollflächiger Hintergrund, und der Enterprise-Charakter ist dahin.
7. Welche Komponenten braucht die Website?
Fragen Sie sich: Wie sieht das tatsächliche Komponenten-Inventar aus?
Komponenten aufzulisten macht aus einer vagen Anfrage eine Checkliste, die das Modell abarbeiten kann. Und es verhindert, dass Sie erst nach drei Seiten merken, dass es weder eine Testimonial-Karte noch eine Preistabelle gibt.
8. Welche Seiten und Routen gibt es?
Fragen Sie sich: Wie sieht die Sitemap aus, Route für Route?
Benennen Sie jede Route – auch die Detail-Templates, die gern vergessen werden: Eine Blog-Übersicht ohne Blog-Detailseite ist eine Sackgasse, und genau diese Auslassung tritt in generierten Websites am häufigsten auf.
9. Sollen die Seiten fertig sein oder nur ein Gerüst?
Fragen Sie sich: Wie vollständig müssen die Inhalte sein?
Wenn Sie nichts anderes sagen, bekommen Sie Blindtext und leere Zustände. Fordern Sie plausible Texte auf jeder Seite und in jedem Template – dann haben Sie etwas, das Sie tatsächlich vorlegen können.
10. Was muss in puncto Qualität gelten?
Fragen Sie sich: Welche Punkte sind nicht verhandelbar, weil Sie sie sonst von Hand nachziehen müssten?
Barrierefreiheit, Responsivität und Dateistruktur kosten wenig, wenn man sie vorab verlangt, und viel, wenn man sie nachrüstet. Fordern Sie sie im selben Atemzug wie das Design.
Alles zusammensetzen
Zehn Antworten, der Reihe nach, ergeben den Prompt. Nichts davon ist raffiniert – es ist nur konkret. Das Modell muss nicht raten, was Sie mit „modern“ meinten, weil Sie ihm #22262A genannt haben.
Hier das vollständige Beispiel, zusammengesetzt aus den Antworten oben. Der Prompt selbst bleibt bewusst auf Englisch: KI-Baukästen liefern damit verlässlichere Ergebnisse, und die Token- und Routen-Namen sind ohnehin englisch.
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.
Die zwei Dinge, die fast alle vergessen
Zwei der zehn Fragen oben existieren, weil ihr Fehlen der häufigste Mangel generierter Websites ist – und beide sind mit einem Satz behoben.
- Die Blog-Detailseite. Prompts fordern regelmäßig eine Blog-Übersicht und hören dort auf. Sie erhalten ein Raster aus Karten, die ins Leere führen. Verlangen Sie das Template /resources/:slug ausdrücklich und beschreiben Sie, was eine Artikelseite enthält.
- Fertige Inhalte. Wenn Sie nicht danach fragen, bekommen Sie Platzhaltertext und leere Zustände. „Fülle jede Seite mit echten Inhalten, kein Blindtext“ kostet neun Wörter und macht aus einem Gerüst etwas Vorzeigbares.
Eine Vorgabe, die über alles Weitere entscheidet
Frage 4 lohnt einen zweiten Blick, denn sie ist die einzige Antwort mit Folgen über das Design hinaus. React + Vite, kein SSR, keine Server Components.
Die meisten KI-Baukästen greifen standardmäßig zu Next.js mit App Router. Solange das Projekt im Baukasten lebt, ist das in Ordnung – und es ist der mit Abstand häufigste Grund, warum sich eine generierte Website danach nicht in ein WordPress- oder HubSpot-Theme überführen lässt. WordPress rendert PHP, HubSpot rendert HubL auf eigenen Servern. Keines von beiden hat eine Node-Laufzeit, die auf Ihre Server-Schicht wartet.
Die Vorgabe im Prompt zu nennen, kostet nichts. Sie erst nach der Design-Freigabe zu entdecken, kostet ein Refactoring.
Vom Prompt zu einer Website, die andere pflegen können
Ein guter Prompt bringt Ihnen ein gutes Frontend. Ein CMS bringt er Ihnen nicht – das Marketing-Team kann noch immer keine Überschrift ändern, ohne Entwicklung und Deployment.
Genau diesen Schritt übernimmt transjt: Sie pushen den generierten Code zu GitHub, verbinden das Repository, und aus dem React-Frontend wird ein natives WordPress-Theme mit echten PHP-Templates oder werden native HubSpot-Module mit editierbaren Feldern. Erst gut prompten, dann konvertieren – und die Website gehört Ihnen und ist bedienbar.