Baue eine mehrseitige Produktwebsite mit Aurora-Hintergrund, mattierten Glaskarten sowie hellem und dunklem Theme für
[AI product name] auf der Site
[server name] auf meinem Opus Growth Hosting-Server. Produkt:
[what it does, for whom]. So funktioniert es:
[three steps]. Was es erzeugt oder leistet:
[4 to 6 features]. Daten und Sicherheit: [where data is stored, for how long, whether it is used for model training]. Test- oder Anmeldeweg:
[trial length, sign-up URL]. Kontakt:
[email],
[phone],
[WhatsApp number],
[address]. Domain:
[domain]. Markenfarben:
[colours, or "you choose"]. Produkt-Screenshots oder Fotos:
[links, or "none"].
Seiten: Startseite (/), Funktionen (/ozellikler/), Sicherheit (/guvenlik/), Kontakt (/iletisim/), Datenschutz (/gizlilik/) und 404.html. Abschnitte der Startseite in dieser Reihenfolge: Hero (h1, Einleitung in zwei Sätzen, zwei Buttons und die Produktkarte als Signature-Element), drei Schritte, für wen es gedacht ist (mit Foto), FAQ und ein abschließender Call to Action. Bei KI-Produkten ist die Sicherheitsseite die halbe Kaufentscheidung; nenne Aufbewahrung, Zugriff und Modelltraining klar und deutlich. Kein Formular auf der Kontaktseite, weil der Server nur statische Dateien ausliefert.
Stil: Aurora und Glas. Ein weiches, mehrfarbiges Licht, das langsam im Hintergrund driftet (die Aurora), mit den Inhalten auf mattierten Glaskarten. Keine Palette von Lila zu Blau; wähle drei weiche Töne, die zur Marke passen, etwa Mint, Aprikose und Eisblau. Typografie: eine weiche Serifen-Display-Schrift von Fontshare (zum Beispiel Gambetta 500) mit einer ruhigen Textschrift (zum Beispiel Synonym 400 und 600). Setze den Glaseffekt nur auf Kartenflächen ein; lass die Seite nicht in Glas versinken. Kein Canvas, kein WebGL, kein Video, kein GSAP, Lenis oder Swiper. Das einzige JavaScript ist ein kleiner Inline-Theme-Umschalter. Signature-Element: eine Glaskarte im Hero mit einem echten HTML-Beispiel dafür, was das Produkt tut (zum Beispiel eine aus einem Meeting-Transkript extrahierte Entscheidung und Aufgabe).
Regeln für Aurora, Glas und Theme (hier brechen Performance und Kontrast bei diesem Stil am leichtesten):
1. Baue die Aurora in reinem CSS: eine aria-hidden-Ebene mit `position: fixed`, zwei Pseudo-Elemente (::before und ::after) und drei große radial-gradients darin. Animiere nur mit transform (translate3d, rotate, scale) in einer `alternate`-Schleife von 25 bis 35 Sekunden und ergänze `will-change: transform`. Animiere weder den Verlauf selbst noch background-position oder filter: blur; diese lösen in jedem Frame ein Repaint aus. Lege die Animation in `@media (prefers-reduced-motion: no-preference)`; bei reduzierter Bewegung steht die Aurora still, bleibt aber sichtbar.
2. Definiere die Farben als CSS-Variablen (--bg, --fg, --mute, --line, --card, --solid, --acc, --accfg und die Aurora-Töne) und verweise die Tailwind-Farben darauf (zum Beispiel colors: {bg: "var(--bg)"}). Schreibe die dunklen Werte sowohl unter `:root
[data-theme="dark"]` als auch unter `@media (prefers-color-scheme: dark) { :root:not(
[data-theme="light"]) }`, damit das System-Theme auch ohne JavaScript greift.
3. Theme-Umschalter: Ein einzeiliges Skript im `<head>`, nach dem Stylesheet, liest die gespeicherte Wahl aus localStorage, schreibt data-theme auf `<html>` und setzt die Klasse `js`; weil es vor dem ersten Paint läuft, blitzt die Seite nie im falschen Theme auf. Kapsle den localStorage-Zugriff in try. Ein kleines Skript am Seitenende wechselt beim Klick das Theme, speichert die Wahl und aktualisiert den Button, wenn sich das System-Theme ändert. Der Button ist ein echtes `<button type="button">` mit `aria-pressed` auf true, solange Dark aktiv ist, und behält seinen zugänglichen Namen ("Dark theme"), auch wenn mobil nur das Icon sichtbar ist. Blende den Button ohne JavaScript aus (`html:not(.js) .theme-toggle { display: none }`). Füge außerdem `<meta name="color-scheme" content="light dark">` hinzu.
4. Halte die Glaskarte in einer einzigen Klasse `.glass`: zuerst ein solider Hintergrund (--solid), dann innerhalb von `@supports (backdrop-filter: blur(1px))` ein transluzenter Hintergrund mit `backdrop-filter: blur(18px) saturate(140%)` (mit dem -webkit-Präfix für Safari). Unter `@media (prefers-reduced-transparency: reduce), (prefers-contrast: more)` wird die Karte solide und die Aurora ausgeblendet. Verwende das Utility backdrop-blur nicht im HTML; design-check warnt vor "Glassmorphism überall", wenn es mehr als fünf davon auf einer Seite findet.
5. Miss den Kontrast in BEIDEN Themes. Lighthouse prüft nur das helle Theme; wenn du Dark nicht separat prüfst, rutscht blasser Text im Dark Mode durch. Mach den transluzenten Kartenhintergrund so deckend, dass der Text auch über der hellsten Aurora-Farbe über 4,5:1 bleibt (in der Demo Weiß mit 66 Prozent im hellen und dunkles Grün mit 58 Prozent im dunklen Theme). Stelle die Textfarbe des Akzent-Buttons je Theme um (Weiß auf dunklem Pinienton im hellen, dunkelgrün auf blassem Mint im dunklen Theme).
6. Gib der Hero-Karte ihren Auftritt nur per transform und mit einem data-reveal-Attribut (design-check erkennt Bewegung an diesem Attribut); verstecke oder blende die h1 niemals aus, denn sie ist das LCP-Element.
Setup und bekannte Fallstricke (jeder davon hat in der Demo-Messung Punkte gekostet oder ein Gate scheitern lassen, überspringe keinen):
1. Wenn auf dem Server bereits eine Site live ist, sag es mir zuerst, denn das Setup überschreibt index.html und den Ordner assets. Sieh dir scaffold_site zuerst mit confirm=false als Vorschau an und rufe es mit confirm=true erst auf, wenn ich zugestimmt habe. Lies danach site_design_guide und site_seo_guide. Schreibe vor dem Code die Design-Richtung (Typografie, Farbe, Raster, Signature-Element, Bewegungssprache und die Bibliotheken, die NICHT geladen werden) in eine kurze ART.md außerhalb von assets und zeig sie mir.
2. Kompiliere Tailwind, lade es nicht vom CDN. Installiere `npm i -D tailwindcss@3` mit site_run_command und background=true und folge mit site_command_status. Die content-Pfade in `tailwind.config.js` müssen jede HTML-Datei inklusive Unterordner, die `_src/*.tpl`-Templates und jede JS-Datei abdecken, die Klassen schreibt. `_src/tw.css` enthält die Zeile `@import "../assets/app.css";` und die drei `@tailwind`-Zeilen; kompiliere sie mit `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify` zu einer einzigen Datei. Entferne das Skript cdn.tailwindcss.com, die Inline-tailwind.config, chrome.js und motion.js aus den Seiten und verlinke nur `/assets/site.css`. Kompiliere nach jeder HTML-Änderung neu. Weil die Theme-Farben Variablen sind, funktionieren Tailwinds Opacity-Kürzel (wie bg-fg/50) nicht; definiere eine separate Variable, wenn du eine transparente Farbe brauchst.
3. Hoste die Schriften selbst. Lies das Fontshare-CSS mit einer Anfrage pro Familie und Schnitt (`https://api.fontshare.com/v2/css?f[]=family@weight`), lade jede woff2-Datei mit site_fetch nach `assets/fonts/` herunter und schreibe die @font-face-Regeln mit `font-display: swap` in `assets/app.css`; design-check sucht dort nach der eigenen Schrift. Preloade JEDEN Schnitt, der above the fold verwendet wird (Überschrift, Text und Buttons), auf jeder Seite mit `<link rel="preload" as="font" type="font/woff2" crossorigin>` und setze diese Zeilen vor den Stylesheet-Link. Die meisten Fontshare-Schriften haben kein ₺-Zeichen, schreibe Preise daher mit "TL".
4. Mach Menü und Footer zu statischem HTML. Schreibe ein kleines `chrome-stamp.mjs`, das die Navigationsliste aus site.config.js liest und `_src/header.tpl` sowie `_src/footer.tpl` zwischen den Markern `<!-- nav:start --><!-- nav:end -->` und `<!-- footer:start --><!-- footer:end -->` auf jede Seite stempelt und dem aktiven Link aria-current="page" gibt. Gib den Templates keine .html-Endung und nutze Platzhalter wie `
[[NAV]]` statt `{{...}}`. Baue das mobile Menü mit `<details>` und ohne JS. Halte Firmenname, Adresse und Telefonnummer im Footer als reinen Text und mach Footer- und Breadcrumb-Links mindestens 44 Pixel hoch.
5. Konvertiere Bilder schon beim Herunterladen mit site_fetch: Schreibe dasselbe Foto mit resize="480x", "800x" und "1120x" (oder den Breiten, die die Seite braucht), image_format="webp" und quality=65 in getrennte Dateien. Gib jedem `<img>` srcset, sizes sowie width und height passend zum echten Seitenverhältnis. Das wichtigste Bild above the fold bekommt fetchpriority="high" und ist nicht lazy; vergib fetchpriority nur an das echte LCP-Element und loading="lazy" decoding="async" an alle übrigen.
6. Schreibe ein kleines `favicon.svg` ins Stammverzeichnis und füge jeder Seite `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` hinzu; falls es ein PNG-Logo gibt, erzeuge mit site_fetch, resize="180x180" und image_format="png" ein apple-touch-icon. Ohne Favicon protokolliert der Browser einen 404 für /favicon.ico und Best Practices fällt auf 96.
7. Regeln des HTML-Validators: Beginne jedes Dokument mit einem großgeschriebenen `<!DOCTYPE html>`, setze Attribute in doppelte Anführungszeichen, nutze ` ` für die Leerzeichen im sichtbaren Text von tel:-Links, verwende nie ein style=""-Attribut (brauchst du eine CSS-Variable, nimm eine Tailwind-Arbitrary-Property-Klasse wie `
[--r:-4deg]`), gib jedem Button type="button", setze kein aria-label auf rollenlose Elemente wie `<ul>` oder `<div>` und nimm `<section aria-label="...">` statt role="region".
SEO, AEO und GEO:
1. Nutze verzeichnisartige URLs mit abschließendem Slash (/ozellikler/, /guvenlik/, /iletisim/, /gizlilik/ oder deren Entsprechungen in deiner Sprache). Fülle den seo-Block in site.config.js und führe `node seo-stamp.mjs` aus. Für ein Softwareunternehmen ohne physisches Ladengeschäft setze in site.config.js localBusiness:false. Schemas pro Seite: Startseite WebPage und FAQPage; Funktionen SoftwareApplication (applicationCategory, operatingSystem, featureList) und FAQPage; Sicherheit WebPage und FAQPage; Kontakt ContactPage; BreadcrumbList auf den Unterseiten. Nenne kein Sicherheitszertifikat und kein Compliance-Dokument, das du nicht besitzt; wenn du eines besitzt, gib Nummer und Gültigkeitsdatum an. Schreibe jedes seitenspezifische Schema in einen eigenen `<script type="application/ld+json">`-Block und verknüpfe es per @id mit dem Basis-Graphen. Verschachtele BreadcrumbList nicht in @graph, sondern halte sie in einem eigenen Block, denn nur so sieht seo-check sie.
2. Title mit 48 bis 60 Zeichen (seo-check wertet mehr als 65 als Fehler), Description mit 145 bis 158 Zeichen, eine h1 pro Seite. Der Hauptinhalt jeder Seite umfasst mindestens 150 Wörter. In der Demo kamen Kontakt- und Datenschutzseite im ersten Versuch auf 84 und 116 Wörter und wurden mit echten Informationen wie "was während der Testphase passiert" und "mit wem die Daten geteilt werden" ergänzt.
3. Der erste Absatz jeder Seite beantwortet die Frage der Seite direkt, und die h1 ist als diese Frage formuliert. Schreibe die FAQ der Seite mit `<details>` und zeichne sie als FAQPage aus. Zeige die veröffentlichende Organisation und ein Datum "Zuletzt aktualisiert" mit `<time datetime>`.
4. Schreibe in robots.txt deine Entscheidung samt Begründung für GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot und CCBot und verweise auf die Sitemap. sitemap.xml enthält ein echtes lastmod. llms.txt enthält eine zutreffende Zusammenfassung der Site in zwei Sätzen und eine Liste der wichtigen Seiten.
5. Nichts erfinden: Schreibe keine Bewertungen, Ratings, Auszeichnungen, Kundenzahlen, Zertifikate, Öffnungszeiten, Koordinaten, Preise oder Produktkennzahlen, ohne mich zu fragen. Lass jedes Feld, das du nicht kennst, ganz aus dem Schema weg.
Gates (der Reihe nach; sag nicht "fertig", bevor alle bestanden sind):
1. Führe mit site_run_command der Reihe nach `node chrome-stamp.mjs`, den Tailwind-Build, `node seo-stamp.mjs`, `node seo-check.mjs` (0 Fehler, 0 Warnungen), `node design-check.mjs` (0 Fehler; begründe jede verbleibende Warnung) und `npx html-validate "**/*.html"` (0 Fehler) aus.
2. Sieh dir jede Seite mit site_preview an, view="mobile" und view="desktop". site_preview erfasst die Seite mit ausgeschalteter Bewegung; ist der Inhalt in dieser Aufnahme nicht vollständig, ist der Zustand ohne Bewegung defekt. Lazy-Bilder weiter unten können in einer Full-Page-Aufnahme leer sein; werte das nicht als Fehler, prüfe aber ihre Pfade. Prüfe auch das dunkle Theme: Da site_preview das System-Theme nicht ändern kann, führe ein Kontrast-Audit im Dark Mode durch (zum Beispiel die color-contrast-Regel von axe-core mit prefers-color-scheme: dark) oder stelle Dark vorübergehend als Standard ein und sieh es dir einmal an.
3. Führe core_web_vitals für jede Seite mit strategy="mobile" und strategy="desktop" aus. Abnahmekriterium: mobil Performance mindestens 95 sowie Accessibility, Best Practices und SEO bei 100; Desktop alle vier mindestens 95, Ziel 100. Finde bei einer Seite, die das verfehlt, mit resources=true die langsame Datei, behebe das und miss erneut. Führe danach seo_audit auf der Startseite mit strategy="mobile" und runs=2 aus. Die Liste der Netzwerkanfragen darf keine Adresse außerhalb deiner eigenen Domain enthalten (Store- und WhatsApp-Links sind Links, keine Anfragen).
4. Kein horizontales Scrollen bei 360, 390, 768 und 1440 Pixeln Breite, Touch-Ziele mindestens 44 Pixel, keine Konsolenfehler.
Interaktionsprüfung: Da site_preview weder Bewegung abspielen noch Themes wechseln kann, sag mir, worauf ich in meinem eigenen Browser achten soll: Das Licht im Hintergrund driftet sehr langsam; ein Klick auf den Umschalter wechselt das Theme, die Wahl bleibt über einen Seitenwechsel erhalten und die Seite blitzt beim Laden nie im anderen Theme auf; ist das Betriebssystem im Dark Mode, öffnet sich die Site dunkel; bei aktivierter Bewegungsreduzierung steht die Aurora still; bei aktivierter Transparenzreduzierung werden die Karten solide; bei ausgeschaltetem JavaScript ist der Umschalter ausgeblendet, das System-Theme greift aber trotzdem.
Nach der Veröffentlichung: Sieh dir die Regel `/assets/* Cache-Control: public, max-age=31536000, immutable` mit site_headers in der Vorschau an und wende sie einmal an, sobald ich zugestimmt habe; versioniere ab dann den Dateinamen, wann immer sich CSS oder JS ändert (site-v2.css und so weiter). Reiche sitemap.xml mit gsc_submit_sitemap ein und prüfe die Startseite mit gsc_url_inspect. Gib mir am Ende: eine Punktetabelle pro Seite (Seite, vier mobile Werte, vier Desktop-Werte, LCP, CLS), die Gate-Ergebnisse und die Liste der angewendeten Fixes.
