Vor dem Senden ausfüllen
[server name][studio name][what it designs, for whom][city, district][headcount, names and roles][3 services][email][phone][WhatsApp number][address][domain][colour or "you choose"]
Baue auf meinem Opus Growth Hosting-Server [server name] eine schnelle mehrseitige Website für [studio name] mit dem Look der Kreativstudio-Sites, die auf Awwwards ausgezeichnet werden. Studio: [what it designs, for whom], Stadt und Bezirk: [city, district], Team: [headcount, names and roles]. Leistungen: [3 services]. Arbeiten: [for each, client name, type of work, year, one sentence on the question, one on the solution, the parts delivered, image link]. Kontakt: [email], [phone], [WhatsApp number], [address]. Domain: [domain]. Farbwunsch: [colour or "you choose"].
Seiten: Startseite (/: Hero mit riesiger Überschrift, scrollender Leistungs-Marquee, ausgewählte Arbeiten, Was wir tun, Ablauf, FAQ, abschließender Call-to-Action), Arbeiten (/isler/: pro Projekt die Fragestellung, was wir getan und was wir geliefert haben), Studio (/studyo/: Team und Arbeitsprinzipien), Kontakt (/iletisim/), Datenschutz und KVKK (/gizlilik/) sowie 404.html. Auf der Kontaktseite kein Formular; stattdessen E-Mail, Telefon und ein WhatsApp-Link mit vorausgefüllter Nachricht, dazu eine Liste, was die erste Nachricht enthalten sollte. Ohne vom Kunden freigegebene Zahlen beschreibst du Ergebnisse qualitativ und schreibst keine Prozentwerte oder Wachstumszahlen.
Stil: Kreativstudio im Awwwards-Stil. Gebrochen weißer Hintergrund, schwarzer Text und eine einzige Signalfarbe, die nur als Hintergrund verwendet wird (mit schwarzem Text darauf, Kontrast mindestens 4,5:1). Eine Fontshare-Display-Schrift, die auch bei sehr großen Größen trägt (z. B. Clash Display 600), und eine ruhige Textschrift (z. B. Ranade). Die Hero-Überschrift füllt den Bildschirm mit clamp zwischen 3.2rem und 12.5rem und enger Laufweite, ohne bei 360 px überzulaufen. Die Arbeitsliste besteht aus Zeilen mit großen Bildern und großen Titeln in einem asymmetrischen Raster, das zwischen 7/5- und 5/7-Spalten wechselt.
Bewegungsregeln (der schwierigste Teil, befolge sie buchstabengetreu):
1. Bibliotheken: GSAP 3.13 Core, ScrollTrigger, SplitText und Lenis, nur auf der Start- und der Arbeiten-Seite. Auf den Seiten Studio, Kontakt und Datenschutz überhaupt keine Skripte. Kein Swiper, kein WebGL, kein Video laden.
2. SplitText: Die h1 above the fold ist das LCP-Element, also darf sie nie versteckt oder mit Slide-up starten. Die h1 startet sichtbar in einer blassen Farbe, die dennoch den AA-Kontrast erfüllt, und SplitText bringt ihre Zeilen nacheinander auf volle Farbe (type "lines", mask "lines", aria "auto"). Den maskierten Slide-up-Zeileneintritt behältst du für h2-Überschriften unterhalb des Folds und spielst ihn mit ScrollTrigger once:true ab. Split erst nach document.fonts.ready ausführen, damit die Zeilenumbrüche stimmen.
3. Endloser Marquee: Schreibe die Leistungsnamen nur einmal ins HTML. Ohne JS und bei Reduced Motion erscheint die Liste als statische, umbrechende Gruppe; verkleinere diesen statischen Zustand auf Smartphones, denn in der Demo füllte er den Bildschirm als sechszeilige Textwand. JS dupliziert die Gruppe einmal, markiert die Kopie mit aria-hidden und bewegt x in einer Endlosschleife; bei Scroll-Geschwindigkeit wird er kurz schneller und stoppt, solange der Marquee außerhalb des Bildschirms ist. Bewegung, die länger als fünf Sekunden dauert, braucht nach WCAG 2.2.2 einen sichtbaren "Pause"-Button unter dem Marquee (type="button", aria-pressed), der nur angezeigt wird, solange sich der Marquee tatsächlich bewegt. Auch Fokus im Marquee pausiert ihn.
4. Magnetische Buttons: nur auf Geräten, die `(hover: hover) and (pointer: fine)` erfüllen; verschiebe mit gsap.quickTo die Transform x und y um 30 bis 40 Prozent des Abstands des Zeigers zur Button-Mitte, mit elastischem Rückfedern, wenn der Zeiger den Button verlässt. Die klickbare Fläche des Buttons darf sich nicht ändern.
5. Bildspur am Cursor: nur Desktop, unter derselben Fine-Pointer-Bedingung, im Hero-Bereich. JS fügt dem Hero eine Ebene hinzu, die aria-hidden ist, pointer-events:none hat und per z-index UNTER der Überschrift liegt. Die Bilder der Spur dürfen beim Laden der Seite nicht heruntergeladen werden; die 280-px-WebP-Thumbnails laden bei der ersten Zeigerbewegung. Alle 90 px Zeigerweg erscheint das nächste Bild aus dem Pool am Zeiger, wächst aus klein, gleitet dann nach unten und blendet aus; bewege es per transform, nicht per left/top.
6. Lenis nur auf `(pointer: fine)`-Geräten aktivieren und über gsap.ticker antreiben; Touch-Geräte behalten natives Scrollen. Bei Links innerhalb der Seite nach dem Scrollen den Fokus auf das Ziel setzen.
Setup und bekannte Fallen (jede einzelne hat in der Demo Punkte gekostet oder etwas kaputt gemacht, überspringe keine):
1. Wenn auf dem Server bereits eine Live-Site liegt, sag mir das zuerst, denn das Setup überschreibt index.html und den assets-Ordner. Zeige eine Vorschau von scaffold_site mit confirm=false und rufe nach meiner Freigabe confirm=true auf. Lies danach site_design_guide und site_seo_guide. Bevor du Code schreibst, halte die Designrichtung (Typografie, Farbe, Raster, Signature-Element, Bewegungssprache und die Bibliotheken, die NICHT geladen werden) in einer kurzen ART.md außerhalb von assets fest und zeig sie mir.
2. Tailwind kompilieren, nicht vom CDN laden. Installiere `npm i -D tailwindcss@3` mit site_run_command und background=true und beobachte es mit site_command_status. Die content-Pfade in `tailwind.config.js` müssen jede HTML-Datei, jedes Template und jede JS-Datei abdecken, die Klassen schreibt. `_src/tw.css` enthält eine 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 Skript cdn.tailwindcss.com und die Inline-Tailwind-Konfiguration aus den Seiten und verlinke nur `/assets/site.css`. Nach jeder HTML-Änderung neu kompilieren.
3. Schriften selbst hosten. Prüfe zuerst, ob die gewählte Fontshare-Familie die türkischen Buchstaben hat (ş, ğ, ı, İ, ç, ö, ü): In der Demo hatte Tanker kein punktloses ı und Outfit kein ş, ğ oder İ, sodass diese Buchstaben in Überschriften auf eine andere Schrift zurückfielen. Lade die woff2-Datei jeder Schriftstärke einzeln mit site_fetch nach `assets/fonts/`, schreibe die @font-face-Regeln mit `font-display: swap` in `assets/app.css` (design-check sucht dort nach der Custom Font) und prüfe den font-family-Namen im heruntergeladenen CSS. Lade die Überschriften- und Textschrift, die above the fold verwendet werden, auf jeder Seite mit `<link rel="preload" as="font" type="font/woff2" crossorigin>` vor dem Stylesheet vor; preloade nicht mehr als zwei Dateien, denn ein dritter vorgeladener Schriftschnitt verlängerte in der Demo den mobilen LCP um 0,2 Sekunden. Den meisten Fontshare-Schriften fehlt das ₺-Zeichen, also schreibe für Preise "TL".
4. Menü und Footer als statisches HTML. Lade chrome.js oder site.config.js nicht auf den Seiten. Schreibe ein kleines `chrome-stamp.mjs`, das die Navigationsliste 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" hinzufügt. Templates dürfen nicht auf .html enden und müssen Platzhalter wie `[[NAV]]` statt `{{...}}` verwenden. Baue das mobile Menü ohne JS mit `<details>`. Behalte Organisationsname, Adresse und Telefon als reinen Text im Footer und gib jedem Touch-Ziel mindestens 44x44 px, auch Footer- und Breadcrumb-Links.
5. Konvertiere Bilder schon beim Herunterladen mit site_fetch: Schreibe dasselbe Foto mit resize="480x", "800x" und "1200x", image_format="webp", quality=65 in separate Dateien. site_fetch beschneidet nie; wenn ein Unsplash-Foto ein anderes Seitenverhältnis braucht, lade die zugeschnittene Version, indem du seiner URL Parameter wie `?w=1600&h=1200&fit=crop` anhängst. Gib jedem `<img>` srcset, sizes sowie width und height passend zum echten Seitenverhältnis. Das Hauptbild above the fold bekommt fetchpriority="high" und ist nicht lazy; die anderen bekommen loading="lazy" decoding="async". Wenn das Hauptbild auf dem Smartphone den Bildschirm füllt, liefere über `<picture>` einen kleineren Ausschnitt.
6. Schreibe die SVG-Version des Logos mit site_write_file als favicon.svg und füge jeder Seite `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` hinzu. Ohne Favicon protokolliert der Browser einen 404 und Best Practices fällt auf 96.
7. Regeln des HTML-Validators: Beginne mit einem großgeschriebenen `<!DOCTYPE html>`, verwende ` ` für die Leerzeichen im sichtbaren Text von tel:-Links, nutze nie ein style=""-Attribut, gib jedem Button type="button" und setze kein `<details>` nach einem figcaption in ein `<figure>`.
8. Lade die Bewegungsbibliotheken (GSAP, ScrollTrigger, SplitText, Lenis) von jsdelivr mit site_fetch nach `assets/vendor/`, fixiere die Version und lade sie nur auf der Start- und der Arbeiten-Seite. Verwende kein `<script defer>`; setze am Seitenende einen kleinen Loader, der auf das load-Event, zwei requestAnimationFrame-Aufrufe und dann requestIdleCallback wartet und die Skripte der Reihe nach mit async=false anhängt. Ein einzeiliges Skript im `<head>` fügt `<html>` die Klasse `js` hinzu und die Klasse `anim`, sofern prefers-reduced-motion nicht "reduce" ist; ohne `anim` lädt der Loader nichts herunter. Definiere versteckte Startzustände nur unter `.anim` und füge als Sicherheitsnetz eine CSS-Animation hinzu, die alle versteckten Elemente nach 2,5 Sekunden einblendet, falls die Bibliothek nie ankommt. In früheren Demos trieben defer-geladene Bibliotheken den mobilen LCP auf 3,2 Sekunden; mit diesem Loader erreichten die Seiten 99 bis 100. Nenne das Attribut für per Scroll eingeblendete Elemente data-reveal; design-check erkennt Bewegung nur unter diesem Namen.
SEO, AEO und GEO:
1. Verwende Verzeichnis-URLs mit abschließendem Schrägstrich (/isler/, /studyo/, /iletisim/, /gizlilik/). Fülle den seo-Block in site.config.js aus und führe `node seo-stamp.mjs` aus. Schreibe das seitenspezifische Schema (Startseite WebPage und FAQPage; Arbeiten CollectionPage mit einem CreativeWork pro Projekt in hasPart; Studio AboutPage mit Person-Einträgen für das Team; Kontakt ContactPage; BreadcrumbList auf den Unterseiten. Für ein Studio mit Büro businessType ProfessionalService in site.config.js) in separaten `<script type="application/ld+json">`-Blöcken und verknüpfe sie per @id mit dem Basisgraphen. Verschachtle BreadcrumbList nicht in @graph; halte sie in einem eigenen Block, denn nur so sieht seo-check sie.
2. Halte Titel bei höchstens 60 Zeichen (seo-check meldet alles über 65 als Fehler), Beschreibungen zwischen 120 und 158 Zeichen, eine h1 pro Seite und keine übersprungenen Überschriftsebenen (eine h3 direkt nach der h1 senkte die Barrierefreiheit auf 98). Jede Seite braucht mindestens 150 Wörter Hauptinhalt; Kontakt- und Datenschutzseite bleiben oft darunter.
3. Der erste Absatz jeder Seite beantwortet die Frage der Seite direkt. Schreibe seitenspezifische FAQs mit `<details>` und zeichne sie als FAQPage aus. Zeige die veröffentlichende Organisation und ein Datum "Zuletzt aktualisiert" in `<time>`.
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 auf und verweise auf die Sitemap. Gib sitemap.xml echte lastmod-Daten. llms.txt enthält eine korrekte Zusammenfassung der Site in zwei Sätzen, die wichtigsten Fakten und eine Liste der wichtigen Seiten.
5. Nichts erfinden: Schreibe keine Bewertungen, Ratings, Auszeichnungen, Kundenzahlen, Zertifikate, Öffnungszeiten, Koordinaten oder Preise, ohne mich zu fragen. Lass jedes Feld, das du nicht kennst, ganz aus dem Schema weg.
Gates (der Reihe nach; sag erst "fertig", wenn alle bestanden sind):
1. Führe mit site_run_command `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 mit view="mobile" und view="desktop" an. site_preview erfasst die Seite mit ausgeschalteter Bewegung (reduced-motion); fehlt in dieser Aufnahme Inhalt, ist der bewegungslose Zustand kaputt. Lazy-Bilder weiter unten können in der Ganzseitenaufnahme leer sein; zähle das nicht als Fehler, prüfe aber ihre Pfade.
3. Führe core_web_vitals mit strategy="mobile" und strategy="desktop" für jede Seite aus. Abnahme: mobil Performance mindestens 95 sowie Accessibility, Best Practices und SEO 100; Desktop alle vier mindestens 95. Finde bei einer Seite, die das verfehlt, mit resources=true die langsame Datei, behebe sie und miss erneut. Führe danach seo_audit auf der Startseite mit strategy="mobile" und runs=2 aus. In der Netzwerkanfragenliste darf keine Adresse außerhalb deiner eigenen Domain verbleiben.
4. Kein horizontales Scrollen bei 360, 390, 768 und 1440 px, Touch-Ziele von mindestens 44 px und keine Konsolenfehler. Die Site muss auch in einem Rahmen von 390x790 und 1440x898 makellos aussehen, wie auf den Prompt-Seiten.
Bewegungsprüfung: site_preview kann keine Bewegung zeigen, also sag mir, worauf ich in meinem eigenen Browser achten soll. Auf dem Desktop sollten sich die Zeilen der Hero-Überschrift nacheinander abdunkeln, der Marquee sollte laufen, beim Scrollen schneller werden und mit dem Pause-Button anhalten, Buttons sollten sich leicht zum Zeiger neigen, die Bewegung des Zeigers über den Hero sollte Bilder hinterlassen, die hinter ihm erscheinen und ausblenden, und der Text muss immer über den Bildern bleiben. Auf dem Smartphone darf es keine Spur und keinen Magnet-Effekt geben und das Scrollen bleibt nativ. Bei aktiviertem Reduce Motion im Betriebssystem darf sich nichts bewegen und der Marquee erscheint als statische Liste. Der Fokusring muss beim Tabben überall sichtbar sein.
Nach der Veröffentlichung: Zeige die Regel `/assets/* Cache-Control: public, max-age=31536000, immutable` per site_headers als Vorschau und wende sie nach meiner Freigabe an; versioniere von da an den Dateinamen, sobald sich CSS oder JS ändern (site-v2.css usw.). Reiche sitemap.xml mit gsc_submit_sitemap ein und prüfe die Startseite mit gsc_url_inspect. Gib mir zum Schluss: eine Punktetabelle pro Seite (Seite, vier mobile Werte, vier Desktop-Werte, LCP, CLS), die Ergebnisse der Gates, das Ergebnis der im Browser ausprobierten Interaktionen und die Liste der angewendeten Korrekturen.