Vor dem Senden ausfüllen
[Produkt- oder Startup-Name][Servername][was es tut, für wen][drei Schritte][4 bis 6 Funktionen][Tarifnamen und Preise oder "keine Preisseite"][App Store, Google Play oder Anmelde-URL][E-Mail][Telefon][WhatsApp-Nummer][Adresse][Domain]
Baue eine neo-brutalistische, mehrseitige, JavaScript-freie Produktwebsite für [Produkt- oder Startup-Name] auf der Site [Servername] auf meinem Opus Growth Hosting-Server. Produkt: [was es tut, für wen]. So funktioniert es: [drei Schritte]. Wichtigste Funktionen: [4 bis 6 Funktionen]. Preise: [Tarifnamen und Preise oder "keine Preisseite"]. Download- oder Anmelde-Links: [App Store, Google Play oder Anmelde-URL]. Kontakt: [E-Mail], [Telefon], [WhatsApp-Nummer], [Adresse]. Domain: [Domain]. Markenfarben: [Farben oder "du wählst"]. Echte Fotos oder Screenshots: [Links oder "keine"].
Seiten: Startseite (/), So funktioniert's (/nasil-calisir/ bzw. /how-it-works/), Preise (/fiyat/), Über uns (/hakkimizda/), Kontakt (/iletisim/), Datenschutz (/gizlilik/) und 404.html. Abschnitte der Startseite in dieser Reihenfolge: Hero (h1, Intro in zwei Sätzen, zwei Buttons, Sticker-Badges und das Signature-Element), Kategorieleiste, drei Schritte, für wen es gedacht ist (mit Foto), Funktionen, FAQ und ein abschließender Call to Action. Kein Formular auf der Kontaktseite; stattdessen E-Mail, Telefon, ein WhatsApp-Link mit vorausgefüllter Nachricht und die Download-Links, weil der Server nur statische Dateien ausliefert.
Stil: neo-brutalistisch, aber wie ein Produkt, nicht wie ein Spielzeug. Dicke schwarze Rahmen (3 Pixel), harte Schatten ohne Unschärfe (nur Schwarz, Versatz 4, 6 und 10 Pixel), flache leuchtende Farbblöcke (höchstens fünf flache Farben wie Tomatenrot, Zitronengelb, Mint, Himmelblau und Flieder auf cremefarbenem Hintergrund), leicht schräg sitzende Badges, die wie Sticker aussehen. Typografie: eine kräftige Display-Schrift mit Charakter von Fontshare (zum Beispiel Chubbo) mit einer ruhigen Grotesk für den Fließtext (zum Beispiel Supreme 400 und 700). Keine Verläufe, kein Glaseffekt, keine weichen Schatten und keine Lila-zu-Blau-Übergänge. Die Seite enthält überhaupt kein JavaScript; GSAP, Lenis und Swiper werden nicht geladen. Signature-Element: rechts im Hero eine Karte mit dickem Rahmen, die den wichtigsten Bildschirm des Produkts in echtem HTML statt als Bild zeichnet (zum Beispiel die Ausgaben eines Haushalts in diesem Monat und die Abrechnung zum Monatsende), mit Stickern, die drumherum kleben.
Regeln zu Farbe, Kontrast und Bewegung (hier verliert dieser Stil am leichtesten Punkte):
1. Schreibe Text auf jedem farbigen Hintergrund in Schwarz und verwende nie weißen Text. Berechne das Kontrastverhältnis jeder Farbe gegenüber Schwarz und lege es als Tabelle in ART.md ab; dunkle jede Farbe unter 4,5 ab. In der Demo lag der niedrigste Wert bei 6,7 auf Tomatenorange, und die Barrierefreiheit lag auf jeder Seite bei 100.
2. Mache den Fokusring 3 Pixel schwarz mit 3 Pixel Abstand, in einem schwarzen Footer wechselt er auf Zitronengelb. Nutze outline-offset, damit der Fokusring nicht mit dem dicken Rahmen verschmilzt.
3. Den verspielten Versatz von Buttons und Karten setzt du nur mit transform und box-shadow um: beim Hover translate(-2px, -2px) und ein größerer Schatten, beim Drücken translate(4px, 4px) und kein Schatten. Buttons sind mindestens 48 Pixel hoch, kleine Buttons mindestens 44.
4. Lege die Sticker-Neigung in die separate Eigenschaft `rotate`, nicht in transform, und setze den Winkel mit einer Tailwind-Arbitrary-Property-Klasse wie `[--r:-4deg]`. So bleiben die Sticker auch dann schief, wenn die Reduced-Motion-Regel transform zurücksetzt, und es ist kein style=""-Attribut nötig.
5. Lass den "Aufklatsch"-Auftritt der Sticker nur mit `scale` und `translate` laufen, innerhalb von `@media (prefers-reduced-motion: no-preference)` und mit einem data-reveal="slap"-Attribut (design-check erkennt Bewegung an diesem Attribut). Kein Ausblenden per opacity, und die h1 bewegt sich nie. Bei prefers-reduced-motion: reduce sind alle Animationen und Übergänge aus.
6. Markiere dekorative Sticker mit aria-hidden="true"; Badges mit Informationsgehalt (zum Beispiel "kostenlos bis 6 Personen") bleiben normale Listeneinträge. Blende auf Mobilgeräten unter 640 Pixeln einen dekorativen Sticker aus, wenn er am Kartenrand ein anderes Badge überdeckt; in der Demo verdeckte der Sticker "Beleg hinzugefügt" bei 390 Pixeln das Badge "3 Personen".
Einrichtung und bekannte Fallen (jede einzelne hat in der Demo-Messung Punkte gekostet oder ein Gate scheitern lassen, überspringe keine):
1. Läuft auf dem Server bereits eine Website, sag mir das zuerst, denn die Einrichtung überschreibt index.html und den Ordner assets. Sieh dir scaffold_site zuerst mit confirm=false als Vorschau an und rufe es erst mit confirm=true auf, sobald ich zustimme. Lies danach site_design_guide und site_seo_guide. Schreibe vor dem Code die Designrichtung (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 über das 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 samt Unterordnern abdecken, außerdem die `_src/*.tpl`-Templates und jede JS-Datei, 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` in eine einzige Datei. Entferne das Script 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. Diese Website hat keine JavaScript-Dateien, also braucht die content-Liste keine JS-Einträge.
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/` 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 genutzt wird (Überschrift, Fließ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 also mit "TL".
4. Mache Menü und Footer zu statischem HTML. Schreibe ein kleines `chrome-stamp.mjs`, das die Nav-Liste aus site.config.js liest und `_src/header.tpl` und `_src/footer.tpl` auf jeder Seite zwischen die Marker `<!-- nav:start --><!-- nav:end -->` und `<!-- footer:start --><!-- footer:end -->` 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. Lass Firmenname, Adresse und Telefon im Footer als reinen Text stehen, und mache Footer- und Breadcrumb-Links mindestens 44 Pixel hoch.
5. Konvertiere Bilder schon beim Herunterladen mit site_fetch: Schreibe dasselbe Foto in getrennte Dateien mit resize="480x", "800x" und "1120x" (oder den Breiten, die die Seite braucht), image_format="webp" und quality=65. 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 am echten 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; gibt es ein PNG-Logo, erstelle 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 Elemente ohne Rolle wie `<ul>` oder `<div>` und nimm `<section aria-label="...">` statt role="region".
8. Hat der Footer einen schwarzen Hintergrund, mache seine Links cremefarben mit Zitronengelb beim Hover, jeweils mindestens 44 Pixel hoch.
SEO, AEO und GEO:
1. Nutze Verzeichnis-URLs mit abschließendem Slash (/nasil-calisir/, /fiyat/, /hakkimizda/, /iletisim/, /gizlilik/ oder die Entsprechungen in deiner Sprache). Fülle den seo-Block in site.config.js aus und führe `node seo-stamp.mjs` aus. Für ein Startup ohne Ladengeschäft setze localBusiness:false in site.config.js. Seiten-Schemas: Startseite WebPage und FAQPage; So funktioniert's WebPage und FAQPage; Preise SoftwareApplication (applicationCategory, operatingSystem und ein Offer pro Tarif) und FAQPage; Über uns AboutPage; Kontakt ContactPage; BreadcrumbList auf den Unterseiten. Weil du SoftwareApplication keine Nutzerbewertungen oder Ratings hinzufügst, zeigt Google womöglich kein App-Rich-Result; das ist in Ordnung, erfinde keine Bewertung. Schreibe jedes seitenspezifische Schema in einen eigenen `<script type="application/ld+json">`-Block und verknüpfe es per @id mit dem Basis-Graph. Verschachtle 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 über 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 Über-uns-, Kontakt- und Datenschutzseite im ersten Anlauf nur auf 113 bis 148 Wörter; ergänze echte Informationen, etwa "was in eine Support-Anfrage gehört" oder "an wen Daten weitergegeben werden".
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 hat ein echtes lastmod. llms.txt enthält eine zutreffende Zusammenfassung der Website 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, komplett 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 aus: `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).
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 kaputt. Lazy-Bilder weiter unten können in einer Ganzseitenaufnahme leer sein; werte das nicht als Fehler, prüfe aber ihre Pfade.
3. Führe core_web_vitals für jede Seite mit strategy="mobile" und strategy="desktop" aus. Abnahme: Auf Mobil Performance mindestens 95 und Accessibility, Best Practices und SEO jeweils 100; auf Desktop alle vier mindestens 95, Ziel 100. Findest du bei einer Seite, die das verfehlt, mit resources=true die langsame Datei, behebe sie und miss erneut. Führe danach seo_audit für die 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 keine Bewegung zeigen kann, sag mir, worauf ich in meinem eigenen Browser achten soll: Ein Button hebt sich beim Hover nach oben links und sinkt beim Drücken in seinen Schatten; die Sticker klatschen beim Laden der Seite sanft auf; beim Tabben zeigt jeder Link einen dicken schwarzen Fokusring; bei aktivierter Bewegungsreduzierung im Betriebssystem bewegt sich nichts, aber die Sticker bleiben schief; bei ausgeschaltetem JavaScript öffnet sich das mobile Menü trotzdem.
Nach der Veröffentlichung: Sieh dir die Regel `/assets/* Cache-Control: public, max-age=31536000, immutable` mit site_headers als Vorschau an und wende sie einmal an, sobald ich zustimme; ab dann versionierst du den Dateinamen, sobald 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 Mobil-Werte, vier Desktop-Werte, LCP, CLS), die Gate-Ergebnisse und die Liste der angewendeten Korrekturen.