Baue für
[Markenname], meine Ein-Produkt-Marke, auf der Site
[Servername] auf meinem Opus Growth Hosting-Server eine Direct-to-Consumer-Produktseite und einige unterstützende Seiten. Produkt:
[Produktname, was es leistet, für wen]. Preis:
[Preis]. Farben oder Varianten: [je Variante Name, Farbcode und ein Foto-Link, aufgenommen aus DEMSELBEN Winkel auf DERSELBEN Leinwand]. Spezifikationen: [Maße, Material, Gewicht und Leistungswerte mit ihren Testbedingungen]. Zu vergleichende Modelle:
[deine eigenen anderen Modelle und ihre Werte]. Kauf-Link:
[Shop-URL und Variantenparameter]. Versand, Rückgabe und Garantie:
[Fristen und Bedingungen]. Kontakt:
[E-Mail],
[Telefon],
[WhatsApp-Nummer],
[Adresse]. Domain:
[Domain].
Seiten: Produkt-Startseite (/), Garantie und Rückgabe (/garanti-ve-iade/), Kontakt (/iletisim/), Datenschutz (/gizlilik/) und 404.html. Abschnitte der Startseite in dieser Reihenfolge: Hero (3D-Showcase links; rechts Label, h1, zwei Sätze Einleitung, Preis, Farbauswahl, Kaufbutton und eine Zusammenfassung zu Versand, Rückgabe und Garantie), drei kurze Abschnitte dazu, wie das Produkt funktioniert, eine Spezifikationstabelle (#ozellikler), eine Größen- oder Modellvergleichstabelle (#karsilastir), FAQ (#sss). Das Menü verlinkt auf diese Abschnitte innerhalb der Seite sowie auf die Seiten Garantie und Kontakt. Diese Site hat keinen Warenkorb und keinen Checkout; der Kaufbutton führt mit der gewählten Variante zur Shop-Seite, und die Seite sagt das klar.
Stil: eine klare, moderne D2C-Produktseite. Ein warmer Off-White-Hintergrund, eine Markenfarbe passend zum Produkt, ein schwarzer, abgerundeter Kaufbutton und saubere Tabellen. Typografie: eine enge Grotesk-Display-Schrift von Fontshare (zum Beispiel Familjen Grotesk 500 und 700) mit einer gut lesbaren Textschrift (zum Beispiel Ranade 400 und 500). Das Produktfoto ist der Star; hebe dir das Mutige für das 3D-Showcase auf. GSAP, Lenis und Swiper werden nicht geladen; das einzige JavaScript ist ein Inline-Skript unter 1 KB, das das Showcase neigt.
Regeln für 3D-Showcase, Farbauswahl und Kaufleiste (genau befolgen):
1. Baue das 3D-Showcase mit CSS: `perspective: 1100px` auf dem Container, `transform: rotateX(var(--rx, 3deg)) rotateY(var(--ry, -7deg))` und `transform-style: preserve-3d` auf der inneren Karte sowie eine Transform-Transition von 0,3 Sekunden. Ohne JavaScript und auf Touchscreens ruht die Karte in dieser leicht geneigten Pose. Zwei kleine Badges (zum Beispiel Kapazität und ein Leistungswert) schweben mit `translateZ(60px)` vor der Karte und sind aria-hidden; dieselbe Information steht auch im Text. Lege ein weiches Highlight über das Bild, das dem Mauszeiger folgt (ein radial-gradient, gesteuert über --gx und --gy).
2. Das Neigungsskript steht inline am Seitenende und läuft nur, wenn `matchMedia("(pointer: fine) and (prefers-reduced-motion: no-preference)")` zutrifft. Bei pointermove bildet es die Zeigerposition innerhalb der Karte auf -0,5 bis 0,5 ab, setzt --ry auf höchstens 8 und --rx auf höchstens 6 Grad und drosselt die Schreibzugriffe mit requestAnimationFrame; bei pointerleave entfernt es die Variablen und kehrt zur Standardpose zurück. Nur transform ändert sich, das Layout verschiebt sich nie. Füge dem Showcase-Container ein Attribut data-reveal="tilt" hinzu, damit design-check die Bewegung erkennt.
3. Baue die Farbauswahl ohne JavaScript: in einem `<fieldset>` mit `<legend>` je Variante ein echtes `<input type="radio" name="colour">`, eingebettet in ein `<label>` von 44x44 Pixeln; das Radio ist visuell versteckt (sr-only), der Farbpunkt erhält über `input:checked + .dot` einen doppelten Ring und über `input:focus-visible + .dot` einen Fokusring; die Pfeiltasten wechseln die Farbe. Alle Variantenbilder liegen mit `position: absolute; inset: 0` übereinander in derselben `aspect-ratio`-Box, und nur `opacity` ändert sich, sodass sich das Layout beim Farbwechsel nie verschiebt (CLS 0 in der Demo). Bilde die Auswahl mit `.product:has(#r-colour:checked)` auf Bild, Farbname in der Legend und Kauf-Link ab. Unterstützt der Browser :has nicht, bleiben Bild, Name und Link der Standardvariante sichtbar.
4. Das Bild der Standardvariante ist das LCP-Element: fetchpriority="high", nicht lazy. Die übrigen Variantenbilder erhalten loading="lazy" decoding="async". Variantenfotos müssen aus demselben Winkel, auf derselben Leinwand und mit demselben Zuschnitt aufgenommen sein; sonst springt das Produkt beim Farbwechsel. Frag mich danach, statt zu versuchen, unterschiedlich fotografierte Bilder durch Zuschneiden anzugleichen.
5. Lass den `display`-Wert einer Button-Klasse wie `.btn-buy` nicht die Sichtbarkeit der Varianten-Kauflinks überschreiben. In der Demo wurde die Regel `.vb { display: none }` weiter unten von `.btn-buy { display: inline-flex }` überschrieben, und alle vier Kaufbuttons erschienen gleichzeitig; schreibe die Regel mit einem spezifischeren Selektor wie `.product :is(.vb)` und prüfe im Browser, dass nur ein Button angezeigt wird.
6. Sticky-Kaufleiste auf Mobilgeräten: unter 768 Pixeln eine Leiste mit `position: fixed; bottom: 0`, mit Produktname und Preis, dem Namen der gewählten Farbe und einem einzigen „Kaufen“-Button (mindestens 48 Pixel). Halte den Buttontext kurz und einzeilig (`whitespace-nowrap`); setze den Farbnamen für Screenreader als sr-only-Text in den Button. Gib dem Body ein Padding unten in Höhe der Leiste, damit die Leiste weder Inhalte noch den Footer verdeckt, und prüfe, dass der letzte Link am Seitenende oberhalb der Leiste bleibt. Auf dem Desktop ist die Leiste ausgeblendet.
7. Tabellen: Die Spezifikationstabelle hat `<th scope="row">`-Zeilenköpfe, eine visuell versteckte `<caption>` und einen Satz, der die Testbedingungen nennt (zum Beispiel Raumtemperatur, Deckel geschlossen). Vergleiche in der Vergleichstabelle nur deine eigenen Modelle, ohne Namen oder Behauptungen von Wettbewerbern; hebe das angebotene Modell mit einer Hintergrundfarbe hervor, verlasse dich dabei aber nicht allein auf Farbe. Umschließe die Tabelle mit `<section aria-label="..." tabindex="0" class="overflow-x-auto">`, damit sie auf schmalen Bildschirmen nie überläuft; schreibe kein role="region", das html-validate als prefer-native-element markiert.
Einrichtung und bekannte Fallstricke (jeder hat in der Demo-Messung Punkte gekostet oder ein Gate scheitern lassen, nicht überspringen):
1. Wenn auf dem Server bereits eine Site live ist, sag mir das zuerst, denn das Setup überschreibt index.html und den assets-Ordner. Sieh dir scaffold_site zuerst mit confirm=false als Vorschau an und rufe es nach meiner Freigabe mit confirm=true auf. Lies danach 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 über das CDN. Installiere `npm i -D tailwindcss@3` mit site_run_command und background=true und lass site_command_status folgen. 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` 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. Wenn du die Farbpunkte mit Arbitrary-Value-Klassen wie `bg-
[#28385C]` setzt, werden sie kompiliert, weil sie im HTML stehen.
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 Custom Font. Preloade JEDEN oberhalb des Folds verwendeten Schnitt (Ü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, also schreibe Preise 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` auf jeder Seite zwischen den Markern `<!-- nav:start --><!-- nav:end -->` und `<!-- footer:start --><!-- footer:end -->` einstempelt und dem aktiven Link aria-current="page" hinzufügt. 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 Telefon als reinen Text im Footer stehen und mach Footer- und Breadcrumb-Links mindestens 44 Pixel hoch.
5. Konvertiere Bilder 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 Hauptbild oberhalb des Folds erhält fetchpriority="high" und ist nicht lazy; gib fetchpriority nur dem echten LCP-Element und den übrigen loading="lazy" decoding="async". Lade die Variantenbilder im Format 4:5 mit resize="480x", "720x" und "960x" herunter.
6. Schreibe ein kleines `favicon.svg` in das Site-Root 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, verwende ` ` für die Leerzeichen im sichtbaren Text von tel:-Links, nutze nie ein style=""-Attribut (brauchst du eine CSS-Variable, verwende 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. Ein Touch-Target-Audit kann das visuell versteckte Radio als 1 Pixel markieren; das echte Touch-Target ist das Label darum. Miss, dass das Label mindestens 44x44 Pixel groß ist, und halte den Grund im Bericht fest.
SEO, AEO und GEO:
1. Verwende verzeichnisartige URLs mit abschließendem Schrägstrich (/garanti-ve-iade/, /iletisim/, /gizlilik/ oder ihre Entsprechungen in deiner Sprache). Fülle den seo-Block von site.config.js aus und führe `node seo-stamp.mjs` aus. Setze bei einer Marke ohne physisches Geschäft localBusiness:false in site.config.js. Startseite: ItemPage (mainEntity das Produkt), das Produkt-Schema und FAQPage. Produkt-Schema: bei einer einzelnen Variante Product und Offer; bei Farbvarianten eine ProductGroup (productGroupID, variesBy https://schema.org/color, brand, description, material) und innerhalb von hasVariant je Farbe ein Product (sku, color, image) mit einem Offer (price, priceCurrency TRY, availability, itemCondition, die Shop-URL der Variante als url, seller @id, shippingDetails mit OfferShippingDetails und hasMerchantReturnPolicy mit MerchantReturnPolicy). Veröffentliche dieselbe MerchantReturnPolicy mit ihrer @id in einem eigenen Block auf der Seite zu Garantie und Rückgabe. Füge GTIN, Bewertungen oder Rezensionen nur hinzu, wenn ich echte Werte habe. Schreibe jedes seitenspezifische Schema in einen eigenen Block `<script type="application/ld+json">` und verknüpfe ihn per @id mit dem Basisgraphen. Verschachtle 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 über 65 als Fehler), Descriptions mit 145 bis 158 Zeichen, ein h1 pro Seite. Der Hauptinhalt jeder Seite umfasst mindestens 150 Wörter. In der Demo kamen die Seiten Garantie und Rückgabe, Datenschutz und Kontakt beim ersten Versuch auf 141, 124 und 106 Wörter und wurden mit echten Informationen wie „Schritte der Rückgabe“, „an wen die Daten weitergegeben werden“ und „was ein Garantieanspruch braucht“ ergänzt.
3. Der erste Absatz jeder Seite beantwortet die Frage der Seite direkt, und die h1 ist als diese Frage formuliert. Schreibe die eigene FAQ der Seite mit `<details>` und zeichne sie als FAQPage aus. Zeige die veröffentlichende Organisation und ein „Zuletzt aktualisiert“-Datum 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 genaue Zusammenfassung der Site in zwei Sätzen und eine Liste der wichtigen Seiten.
5. Nichts erfinden: Schreibe keine Rezensionen, Bewertungen, Auszeichnungen, Kundenzahlen, Zertifikate, Öffnungszeiten, Koordinaten, Preise oder Produktwerte, 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 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 No-Motion-Zustand 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: auf Mobilgeräten Performance mindestens 95 sowie Accessibility, Best Practices und SEO 100; auf dem Desktop alle vier mindestens 95, Ziel 100. Finde 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 (Shop- und WhatsApp-Links sind Links, keine Anfragen).
4. Kein horizontales Scrollen bei 360, 390, 768 und 1440 Pixeln Breite, Touch-Targets mindestens 44 Pixel, keine Konsolenfehler.
Interaktionsprüfung: Da site_preview weder Bewegung noch Klicks zeigen kann, sag mir, worauf ich im eigenen Browser achten soll: Auf dem Desktop neigt sich die Karte beim Bewegen der Maus über das Produkt zum Zeiger, während die Badges davor schweben, und kehrt in die geneigte Pose zurück, wenn die Maus die Karte verlässt; ein Klick auf einen Farbpunkt oder ein Druck auf eine Pfeiltaste wechselt Bild, Farbnamen und Kauf-Link, ohne dass sich etwas auf der Seite verschiebt; bei ausgeschaltetem JavaScript funktioniert die Farbauswahl weiterhin; auf einem Smartphone ist die untere Leiste immer sichtbar und verdeckt nicht die Links am Seitenende; bei aktivierter Option „Bewegung reduzieren“ neigt sich die Karte nicht.
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 nach meiner Freigabe einmal an; versioniere ab dann 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 je Seite (Seite, vier Mobile-Werte, vier Desktop-Werte, LCP, CLS), die Gate-Ergebnisse und die Liste der vorgenommenen Korrekturen.
