Baue auf meinem Opus-Growth-Hosting-Server
[Servername] eine statische, schnelle Portfolio-Website für
[Studioname], die sich wie die interaktiven Agentur-Websites aus Webflow anfühlt, ohne Webflow zu verwenden. Studio:
[was es macht, für wen], Stadt und Stadtteil:
[Stadt, Stadtteil]. Leistungen:
[3 Leistungen]. Projekte: [für jedes: Name, Art der Arbeit, Jahr, ein Satz zum Problem, einer zur Lösung, Bildlink]. Kontakt:
[E-Mail],
[Telefon],
[WhatsApp-Nummer],
[Adresse]. Domain:
[Domain].
Seiten: Startseite (Hero, Index ausgewählter Arbeiten, Leistungen, Ablauf, FAQ, abschließender Call-to-Action), Arbeiten (/isler/: Galerie plus Problem, geleistete Arbeit und Hinweis zur Übergabe je Projekt), Studio (/hakkimizda/), Kontakt (/iletisim/, ohne Formular; E-Mail, WhatsApp mit vorausgefüllter Nachricht und Telefon), Datenschutz (/gizlilik/) und 404.html. Ohne vom Kunden freigegebene Daten schreibst du keine Prozentwerte oder Wachstumszahlen zu Projektergebnissen; beschreibe das Ergebnis in Worten.
Stil: brutalistisch-modern. Scharfe Ecken, sichtbare 1-px-Rasterlinien, eine fette, großgeschriebene Grotesk als Display-Schrift (zum Beispiel Clash Grotesk) und eine ruhige Fließtextschrift (zum Beispiel Supreme), ein fluoreszierender Akzent, der nur als Hintergrund mit schwarzem Text darauf eingesetzt wird. Hover-Zustände ändern Farbe und Hintergrund; der Fokusring ist dick und auf jedem Hintergrund sichtbar.
Interaktionsregeln (das Webflow-IX2-Gefühl, ohne Bibliothek):
1. Lade KEIN GSAP und KEIN Lenis. Schreibe die Interaktionen in eine kleine Vanilla-JS-Datei (IntersectionObserver und requestAnimationFrame) und lade sie mit defer nur auf der Start- und der Arbeiten-Seite. Auf den anderen Seiten kein Skript.
2. Signature-Element, der Index „Ausgewählte Arbeiten“: Jede Zeile ist ein echter Link zum Projekt und trägt den Pfad des Vorschaubilds in einem data-img-Attribut. Standardmäßig (ohne JS oder auf Touch-Geräten) zeigt jede Zeile ein kleines Bild im Textfluss. Nur auf Geräten, die `(hover: hover) and (pointer: fine)` erfüllen und keine reduzierte Bewegung wünschen, fügt das JS dem `<html>` die Klasse cursor-fx hinzu, blendet die Inline-Bilder aus und zeigt eine einzelne Vorschaubox, die dem Zeiger folgt. Bewege die Box über CSS-Variablen und transform: translate3d statt über left und top, und stoppe die requestAnimationFrame-Schleife, wenn der Zeiger ruht. Bei Tastaturfokus öffnet sich dieselbe Vorschau fest neben der Zeile und schließt sich, wenn der Fokus die Zeile verlässt.
3. Füge den eigenen Cursor-Ring nur unter derselben Bedingung hinzu; blende den nativen Cursor nie aus, markiere den Ring mit aria-hidden und lass ihn über Links wachsen.
4. Abschnittsübergänge: Abschnittsüberschriften öffnen sich beim Scrollen per clip-path von links nach rechts. Das JS setzt den verborgenen Startzustand nur bei Überschriften, die beim Öffnen der Seite unterhalb des Bildschirms liegen; Inhalte im ersten Bildschirm werden nie ausgeblendet. Nenne das Attribut data-reveal; design-check erkennt Bewegung an diesem Namen und warnt sonst mit „keine Bewegung“.
5. Swiper-Galerie nur auf der Arbeiten-Seite. Ohne JS ist das Galerie-HTML ein horizontaler CSS-Scroll-Snap-Streifen, und die Buttons für Zurück und Weiter bleiben verborgen, bis Swiper startet. Lade das Swiper-14-Bundle (js und css) mit site_fetch nach `assets/vendor/` herunter. Lade es, wenn der Zeiger die Galerie betritt, bei Touch, bei Fokus oder beim ersten Scrollen der Seite. In der Demo schob das Laden, sobald die Galerie in die Nähe des Viewports kam, wegen des 150-KB-Bundles den mobilen LCP auf 3 s (Performance 94); das Laden bei der ersten Interaktion ergab 99. Aktiviere die Module Navigation, Keyboard und A11y mit türkischen Meldungen und setze die Übergangsgeschwindigkeit bei reduzierter Bewegung auf 0.
6. Baue die Slides mit div statt mit ul und li. Swiper vergibt an Slides role="group"; bei li führte diese Rolle zu aria-allowed-role- und Listenfehlern und senkte Accessibility auf 96.
Einrichtung und bekannte Fallstricke (jeder davon hat in den Demo-Messungen einen Wert gesenkt, nicht überspringen):
1. Falls auf dem Server bereits eine Website live ist, sag es mir zuerst, denn die Einrichtung überschreibt index.html und den Ordner assets. Zeige scaffold_site mit confirm=false als Vorschau und rufe es nach meiner Freigabe mit confirm=true auf. Lies danach site_design_guide und site_seo_guide. Lege vor dem Schreiben von Code die Design-Richtung (Typografie, Farbe, Raster, Signature-Element, Bewegungssprache und die Bibliotheken, die NICHT geladen werden) in einer kurzen ART.md außerhalb von assets ab und zeige sie mir.
2. Kompiliere Tailwind, statt es vom CDN zu laden. Installiere es mit site_run_command und background=true: `npm i -D tailwindcss@3`, und folge dann mit site_command_status. Die content-Pfade in `tailwind.config.js` müssen alle HTML-Dateien, die Templates und jede JS-Datei abdecken, die Klassennamen 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 Skript cdn.tailwindcss.com und die Inline-tailwind.config von jeder Seite und verlinke nur `/assets/site.css`. Kompiliere nach jeder HTML-Änderung neu.
3. Hoste die Schriften selbst. Lies das CSS der gewählten Fontshare-Familien, lade die woff2-Datei jedes Schnitts 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 einer eigenen Schrift. Prüfe den font-family-Namen im heruntergeladenen CSS, denn Fontshare kann eine andere Familie liefern, wenn ein Schnitt nicht existiert. Lade die Schrift der Überschrift im ersten Bildschirm und die Fließtextschrift auf jeder Seite mit `<link rel="preload" as="font" type="font/woff2" crossorigin>` vor; in der Demo beseitigte das die durch den Schriftwechsel verursachte Layoutverschiebung (CLS 0,024 auf 0). Die meisten Fontshare-Schriften haben kein ₺-Zeichen, schreibe daher für Preise „TL“.
4. Mache Menü und Footer zu statischem HTML. Lade auf den Seiten weder chrome.js noch site.config.js. Schreibe eine kleine `chrome-stamp.mjs`, die die Navigationsliste in site.config.js liest und `_src/header.tpl` sowie `_src/footer.tpl` zwischen die Marker `<!-- nav:start --><!-- nav:end -->` und `<!-- footer:start --><!-- footer:end -->` jeder Seite stempelt und dem aktuellen Link aria-current="page" hinzufügt. Gib den Templates keine .html-Endung und verwende Platzhalter wie `
[[NAV]]` statt `{{...}}`, sonst lesen design-check und seo-check sie als unfertige Seiten. Baue das mobile Menü ohne JS mit `<details>`. Lass Firmenname, Adresse und Telefon im Footer als reinen Text stehen.
5. Konvertiere Bilder beim Herunterladen mit site_fetch: Schreibe dasselbe Foto in getrennte Dateien mit resize="480x", "800x" und "1200x", image_format="webp", quality=65. Gib jedem `<img>` srcset, sizes, width und height. Das Hauptbild im ersten Bildschirm erhält fetchpriority="high" und wird nie lazy geladen; die übrigen erhalten loading="lazy" decoding="async". Wenn das Hauptbild den Handy-Bildschirm füllt, liefere mobil mit `<picture>` einen breiteren, kleineren Ausschnitt (in der Demo sank das mobile Hero-Bild von 89 KB auf 43 KB).
6. Erstelle aus dem Logo mit site_fetch ein 48-px-PNG-Favicon und füge auf jeder Seite `<link rel="icon">` hinzu. Ohne Favicon protokolliert der Browser einen 404, und Best Practices fällt auf 96.
7. Regeln des HTML-Validators: Beginne jedes Dokument mit einem großgeschriebenen `<!DOCTYPE html>` (die Starterdateien des Kits verwenden Kleinbuchstaben), nutze ` ` für die Leerzeichen im sichtbaren Text von tel:-Links, verwende nie ein style=""-Attribut und gib jedem Button type="button".
SEO, AEO und GEO:
1. Verwende Verzeichnis-URLs mit abschließendem Schrägstrich (/isler/, /hakkimizda/, /iletisim/, /gizlilik/). Fülle den seo-Block von site.config.js und führe `node seo-stamp.mjs` aus. Schreibe das seitenspezifische Schema (Startseite WebPage und FAQPage; Arbeiten CollectionPage mit je einem CreativeWork pro Projekt unter hasPart; Studio AboutPage; Kontakt ContactPage; BreadcrumbList auf Unterseiten. Für ein Studio mit physischem Büro verwende businessType ProfessionalService) in getrennte `<script type="application/ld+json">`-Blöcke und verknüpfe es per @id mit dem Basis-Graphen. Vergrabe BreadcrumbList nicht in einem @graph; gib ihr einen eigenen Block, denn nur so sieht seo-check sie.
2. Titel mit 48 bis 60 Zeichen (seo-check meldet alles über 65 als Fehler), Beschreibungen mit 145 bis 158 Zeichen, ein h1 pro Seite. Jede Seite braucht mindestens 150 Wörter Hauptinhalt; Kontakt- und Datenschutzseite bleiben oft darunter.
3. Der erste Absatz jeder Seite beantwortet direkt die Frage der Seite. Schreibe eine seitenspezifische FAQ mit `<details>` und zeichne sie als FAQPage aus. Zeige die veröffentlichende Organisation und ein „Zuletzt aktualisiert“-Datum mit `<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 und verweise auf die Sitemap. sitemap.xml enthält echte lastmod-Daten. llms.txt enthält eine zutreffende Zusammenfassung der Website in zwei Sätzen und die Liste der wichtigsten Seiten.
5. Erfinde nichts: keine Bewertungen, Ratings, Auszeichnungen, Kundenzahlen, Zertifikate, Öffnungszeiten, Koordinaten oder Preise, sofern ich sie nicht angebe. Lass unbekannte Felder im Schema weg.
Prüfschritte (in dieser Reihenfolge; melde erst Vollzug, 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 an, mit view="mobile" und view="desktop". site_preview erfasst die Seite bei ausgeschalteter Bewegung (reduced-motion); fehlt in diesem Bild Inhalt, ist der bewegungslose Zustand defekt. In Full-Page-Aufnahmen können weiter unten liegende Lazy-Bilder leer erscheinen; das ist kein Fehler, prüfe aber ihre Pfade.
3. Führe core_web_vitals für jede Seite mit strategy="mobile" und strategy="desktop" aus. Bestanden heißt: mobil Performance mindestens 95 und Accessibility, Best Practices und SEO 100; Desktop alle vier mindestens 95. Finde bei einer durchgefallenen Seite mit resources=true die bremsende Datei, behebe das Problem und miss erneut. Führe danach seo_audit für die Startseite mit strategy="mobile" und runs=2 aus. Die Liste der Netzwerkanfragen darf keinen anderen Host als deine eigene Domain enthalten.
4. Kein horizontales Scrollen bei 360, 390, 768 und 1440 px Breite, Touch-Ziele mindestens 44 px, keine Konsolenfehler.
Interaktionsprüfung: site_preview kann keine Hover- oder Cursor-Effekte zeigen. Sag mir, wie ich in einem Desktop-Browser prüfe, dass die Vorschau dem Zeiger über den Index-Zeilen folgt, dass sie sich beim Tabben neben der Zeile öffnet, dass ein Handy die Inline-Bilder zeigt und dass sich die Galerie per Fingerwisch bedienen lässt.
Nach der Veröffentlichung: Zeige die Regel `/assets/* Cache-Control: public, max-age=31536000, immutable` mit site_headers als Vorschau und wende sie nach meiner Freigabe an; benenne ab dann CSS- oder JS-Dateien bei Änderungen um (site-v2.css und so weiter). Reiche sitemap.xml mit gsc_submit_sitemap ein und prüfe die Startseite mit gsc_url_inspect. Schließe mit einer Punktetabelle pro Seite ab (Seite, vier mobile Werte, vier Desktop-Werte, LCP, CLS), den Ergebnissen der Prüfschritte und der Liste der angewendeten Korrekturen.
