Erstelle für
[brand name] auf der Site
[server name] auf meinem Opus Growth Hosting-Server eine mehrseitige Fashion- bzw. Lifestyle-Website im Lookbook-Stil mit Bildübergängen zwischen den Seiten. Marke:
[what it makes, where, for whom]. Saison- oder Kollektionsname:
[name]. Produkte: [for each one name, category, colour, material, price and photo link]. Größentabelle:
[measurements, or "none"]. So kaufen Kundinnen und Kunden:
[workshop or shop address, WhatsApp number, store link if any]. Versand und Rückgabe:
[if any]. Kontakt:
[email],
[phone],
[address]. Domain:
[domain]. Lookbook-Fotos:
[links].
Seiten: Lookbook-Startseite (/), Kollektion (/koleksiyon/), je Produkt eine eigene Seite (/urun/
[product-name]/), Werkstatt bzw. Über uns (/atolye/), Kontakt (/iletisim/) und 404.html. Abschnitte der Startseite: Hero (h1, kurze Markenvorstellung, zwei Buttons und ein hohes Hauptfoto), darunter ein Lookbook mit drei Fotos, die jeweils auf ein Produkt verlinken, die Material- bzw. Herstellungsgeschichte und FAQ. Kollektionsseite: Kategoriefilter und Produktraster. Produktseite: großes Bild, Name, Preis, ein erster Absatz, der sagt, was das Produkt ist, eine Liste mit Material, Farbe, Größen und Pflege, ein Kasten "Wie kaufe ich?", die Größentabelle und zwei Produkte aus derselben Kollektion. Kein Warenkorb und kein Checkout; gekauft wird über WhatsApp, im Laden oder in der Werkstatt, und jede Produktseite sagt das klar und deutlich.
Stil: redaktioneller Fashion-Look, wie ein gedrucktes Lookbook. Ein stofffarbener Hintergrund, randlose Fotos mit eckigen Ecken, 1-Pixel-Haarlinien, kleine Großbuchstaben-Labels mit weitem Buchstabenabstand und viel Weißraum. Typografie: eine kontrastreiche Fashion-Serif von Fontshare (zum Beispiel Melodrama 400 und 600) mit einer ruhigen Grotesk für den Fließtext (zum Beispiel Archivo 400 und 500). Eine einzige Akzentfarbe (zum Beispiel Ton/Lehm) nur für Fokusringe und Hover. Das Lookbook-Trio liegt auf 5, 4 und 3 Spalten eines 12-Spalten-Rasters mit versetztem vertikalem Offset. Es gibt zwei Signature-Elemente: den Bildübergang zwischen den Seiten und die Flip-Quick-View im Kollektionsraster. Lenis, Swiper, ScrollTrigger und SplitText werden nicht geladen.
Regeln für Seitenübergang und Flip (genau befolgen):
1. Cross-Document View Transitions: Schreibe `@view-transition { navigation: auto; }` in `assets/app.css`. Das Bild auf der Kollektionskarte und das Hauptbild auf der Produktseite tragen DENSELBEN view-transition-name; setze ihn mit einer Tailwind-Arbitrary-Property-Klasse (`
[view-transition-name:u-product-name]`), nicht mit style="". Jeder Name darf pro Seite nur einmal vorkommen, weil der Browser den Übergang abbricht, wenn zwei Elemente denselben Namen teilen; die Karten "aus derselben Kollektion" auf einer Produktseite dürfen die Namen ihrer eigenen Produkte tragen. Gib dem oberen Menü `view-transition-name: site-header`, damit es während des Übergangs stehen bleibt. Gruppendauer 0,5 Sekunden, Root-Crossfade 0,3 Sekunden. Schreibe innerhalb von `@media (prefers-reduced-motion: reduce)` `@view-transition { navigation: none; }`. Browser ohne Unterstützung navigieren ganz normal; schreibe keinen JavaScript-Fallback.
2. Lade GSAP und Flip nur auf der Kollektionsseite; keine andere Seite hat ein Script. Lade den GSAP-3.13-Core und das Flip-Plugin von jsdelivr mit site_fetch nach `assets/vendor/` herunter und fixiere die Version. Ein einzeiliges Script in `<head>` setzt die Klasse `js` auf `<html>` und die Klasse `anim`, außer prefers-reduced-motion ist "reduce". Ein kleiner Loader am Seitenende wartet auf das load-Event, zwei requestAnimationFrame-Aufrufe und requestIdleCallback, lädt nichts herunter, wenn `anim` fehlt, und hängt sonst gsap.min.js, Flip.min.js und eine winzige Datei mit `gsap.registerPlugin(Flip)` der Reihe nach mit async=false an.
3. Trenne die Interaktion von Flip: `assets/koleksiyon.js` (defer) führt Filter und Quick View auch OHNE Flip aus. Bei jeder Änderung gilt: Wenn Flip und `anim` vorhanden sind, zuerst `Flip.getState(cards)` aufnehmen, dann das DOM ändern, dann `Flip.from(state, {duration: 0.6, ease: "power3.inOut", nested: true})` aufrufen; andernfalls die Änderung sofort anwenden. So kann auch jemand, der keine Bewegung möchte, Filter und Quick View benutzen.
4. Filter: Die Buttons "Alle" und die Kategorie-Buttons stehen in einem Container mit `role="group"` und einem aria-label, jeder mit `aria-pressed`. Karten, die nicht passen, erhalten `hidden`; in Flip `absolute: true` verwenden, onEnter für eintretende Karten (Opacity und Scale von 0,92 auf 1) und onLeave für austretende. Ein `aria-live="polite"`-Element gibt das Ergebnis an, zum Beispiel "3 Produkte angezeigt".
5. Quick View (Morph vom Raster zum Detail): Jede Karte hat einen Button "Kurz ansehen" mit `aria-expanded` und `aria-controls` sowie ein `hidden`-Detailpanel (Beschreibung, Styling-Tipp, Link zur Produktseite). Beim Öffnen belegt die Karte mit `grid-column: 1 / -1` die volle Breite und teilt sich auf dem Desktop in zwei Spalten, Bild links und Details rechts; Flip animiert das Bild, das aus der kleinen Kachel in die große Ansicht wächst. Aktualisiere das `sizes` des geöffneten Bildes für die große Ansicht, damit eine größere Datei geladen wird. Es ist immer nur eine Karte geöffnet, der Buttontext wechselt zu "Schließen" und der Fokus springt auf das Panel, das tabindex="-1" hat.
6. Ohne JavaScript sind die Buttons für Filter und Quick View ausgeblendet (`.js-only` ist nur unter `.js` sichtbar), und jede Karte und jeder Produktseiten-Link funktioniert weiterhin. Der Hauptlink der Karte führt immer zur Produktseite; Quick View ist ein separater Button.
Setup und bekannte Fallstricke (jeder davon hat in der Demo-Messung Punkte gekostet oder ein Gate nicht bestehen lassen, nichts überspringen):
1. Wenn auf dem Server bereits eine Website live ist, sag mir das 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 erst nach meiner Freigabe mit confirm=true auf. Lies dann site_design_guide und site_seo_guide. Schreibe vor dem Coden 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 vom CDN. Installiere `npm i -D tailwindcss@3` mit site_run_command und background=true und frage danach mit site_command_status den Status ab. Die content-Pfade in `tailwind.config.js` müssen jede HTML-Datei einschließlich Unterordnern, 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` 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. Nimm `assets/koleksiyon.js` ebenfalls in die content-Liste auf, weil es Klassen wie `is-open` schreibt.
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 Custom Font. Preloade JEDEN Schnitt, der above the fold verwendet 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 daher mit "TL".
4. Mach 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` zwischen den Markern `<!-- nav:start --><!-- nav:end -->` und `<!-- footer:start --><!-- footer:end -->` auf jede Seite stempelt und dabei dem aktiven Link aria-current="page" gibt. Gib den Templates keine .html-Endung und verwende Platzhalter wie `
[[NAV]]` statt `{{...}}`. Baue das mobile Menü mit `<details>` und ohne JS. Lass Firmenname, Adresse und Telefonnummer als reinen Text im Footer stehen und mach Footer- und Breadcrumb-Links mindestens 44 Pixel hoch.
5. Konvertiere Bilder direkt 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 Hauptbild above the fold erhält fetchpriority="high" und ist nicht lazy; vergib fetchpriority nur an das echte LCP-Element und loading="lazy" decoding="async" an den Rest.
6. Schreibe eine kleine `favicon.svg` ins Stammverzeichnis und füge jeder Seite `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` hinzu; wenn es ein PNG-Logo gibt, erstelle mit site_fetch, resize="180x180" und image_format="png" ein apple-touch-icon. Ohne Favicon loggt der Browser einen 404 für /favicon.ico und Best Practices fällt auf 96.
7. Regeln für den HTML-Validator: Beginne jedes Dokument mit einem großgeschriebenen `<!DOCTYPE html>`, setze Attribute in doppelte Anführungszeichen, verwende ` ` für die Leerzeichen im sichtbaren Text von tel:-Links, verwende nie ein style=""-Attribut (wenn du eine CSS-Variable brauchst, 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 verwende `<section aria-label="...">` statt role="region".
8. Lade Produktbilder mit site_fetch im Hochformat 4:5 mit resize="400x", "640x" und "960x" herunter; halte jedes Produktfoto im selben Seitenverhältnis, damit das Raster gleichmäßig bleibt und der Flip-Übergang nicht springt. Das Hauptbild einer Produktseite ist das LCP-Element dieser Seite und erhält fetchpriority="high".
9. Prüfe die Ziffern der Display-Schrift: In der Demo hatte die Null der Melodrama einen Schrägstrich, und "2026" in der h1 las sich aus der Entfernung wie "2Ø26". Halte Zahlen aus Display-Schrift-Überschriften heraus oder setze Ziffern in der Fließtextschrift.
SEO, AEO und GEO:
1. Verwende URLs im Verzeichnisstil mit abschließendem Schrägstrich (/koleksiyon/, /urun/
[product-name]/, /atolye/, /iletisim/ oder ihre Entsprechungen in deiner Sprache). Fülle den seo-Block von site.config.js aus und führe `node seo-stamp.mjs` aus. Gibt es eine physische Werkstatt oder einen Laden, setze in site.config.js den spezifischsten businessType (zum Beispiel ClothingStore) und die Adresse; füge Öffnungszeiten nur hinzu, wenn ich sie angebe. Seiten-Schemas: Startseite WebPage und FAQPage; Kollektion CollectionPage und eine ItemList mit der url jedes Produkts; jede Produktseite ItemPage und Product (name, description, image, sku, color, material, category, brand sowie ein Offer mit price, priceCurrency TRY, availability, itemCondition, url und seller @id); Werkstatt AboutPage; Kontakt ContactPage; BreadcrumbList auf den Unterseiten (Lookbook, Kollektion, Produkt). Auch ohne Checkout trägt das Offer den korrekten Preis und den Lagerstatus; wenn ich Versand- und Rückgabebedingungen angebe, ergänze shippingDetails und hasMerchantReturnPolicy im Offer. Erfinde keine Bewertungen (aggregateRating). Schreibe jedes seitenspezifische Schema in einen eigenen `<script type="application/ld+json">`-Block und verknüpfe es per @id mit dem Basis-Graph. Verschachtele BreadcrumbList nicht in @graph; halte sie in einem eigenen Block, denn nur so sieht seo-check sie.
2. Titel mit 48 bis 60 Zeichen (seo-check wertet mehr als 65 als Fehler), Beschreibungen mit 145 bis 158 Zeichen, eine h1 pro Seite. Der Hauptinhalt jeder Seite umfasst mindestens 150 Wörter. In der Demo kamen die Werkstatt- und die Kontaktseite beim ersten Versuch auf 113 bzw. 95 Wörter und wurden mit echten Informationen wie "Was wir in der Werkstatt machen" und "Was Sie in Ihre Nachricht schreiben sollten" ergänzt. Schreibe auf Produktseiten gemeinsame Sätze (Pflege, Stoff) als kurze Listenpunkte und die Beschreibung für jedes Produkt separat; seo-check warnt vor Duplicate Content, wenn Seiten mehr als 50 Prozent ihrer Sätze teilen.
3. Der erste Absatz jeder Seite beantwortet die Frage der Seite direkt, und die h1 ist als diese Frage formuliert. Schreibe die eigenen 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 Zwei-Satz-Zusammenfassung der Website und eine Liste der wichtigen Seiten.
5. Nichts erfinden: Schreibe ohne Rückfrage keine Bewertungen, Ratings, Auszeichnungen, Kundenzahlen, Zertifikate, Öffnungszeiten, Koordinaten, Preise oder Produktangaben. 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; wenn der Inhalt in dieser Aufnahme nicht vollständig ist, ist der Zustand ohne Bewegung defekt. Lazy Bilder weiter unten können in einer Ganzseitenaufnahme leer sein; zähle 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: mobil Performance mindestens 95 sowie Accessibility, Best Practices und SEO jeweils 100; Desktop alle vier mindestens 95, Ziel 100. Finde bei einer Seite, die das verfehlt, mit resources=true die langsame Datei, behebe das Problem und miss erneut. Führe dann 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 (Shop- und WhatsApp-Links sind Links, keine Anfragen).
4. Kein horizontales Scrollen bei 360, 390, 768 und 1440 Pixel 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: In Chrome oder Edge lässt ein Klick auf ein Produkt in der Kollektion das Bild von seiner Karte an seinen Platz auf der Produktseite wachsen, während das Menü stehen bleibt; in Firefox öffnet sich die Seite einfach; ein Klick auf einen Filter schiebt die Karten in eine neue Reihenfolge; "Kurz ansehen" öffnet die Karte im Raster und das Bild wächst; bei aktivierter reduzierter Bewegung passieren dieselben Aktionen sofort; bei ausgeschaltetem JavaScript ist jedes Produkt sichtbar. Bei einer lokalen Prüfung habe ich außerdem gesehen, dass `document.documentElement.matches(':active-view-transition')` auf der Produktseite während des Übergangs true zurückgibt; du kannst dieselbe Prüfung ausführen.
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 nach meiner Freigabe an; versioniere danach den Dateinamen, sobald sich CSS oder JS ändern (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 Tabelle mit den Scores pro Seite (Seite, vier Mobile-Scores, vier Desktop-Scores, LCP, CLS), die Gate-Ergebnisse und die Liste der angewendeten Korrekturen.
