Baue auf meinem Opus Growth Hosting-Server
[server name] eine mehrseitige Website für
[business name], die überhaupt kein JavaScript lädt und Bewegung sowie Seitenübergänge ausschließlich mit den CSS-Funktionen des Browsers umsetzt. Unternehmen:
[what it does, for whom], Stadt:
[city, district]. Leistungen oder Produkte:
[list]. Arbeiten: [for each: name, material or scope, duration, problem solved, image link]. Kontakt:
[email],
[phone],
[WhatsApp number],
[address]. Domain:
[domain].
Seiten: Startseite (Hero, aktuelle Arbeiten, Ablauf, FAQ), Arbeiten (/isler/), Über uns (/hakkimizda/), Kontakt (/iletisim/, ohne Formular), Datenschutz (/gizlilik/) und 404.html.
Stil: redaktionell und natürlich. Eine Serifen-Display-Schrift (zum Beispiel Zodiak) mit einer ruhigen Fließtextschrift (zum Beispiel Switzer), ein leinenfarbener Hintergrund, ein dunkler Akzent, großzügiger Raum. Die Kühnheit hebst du dir für die Karten der Arbeiten auf.
Regeln für modernes CSS (Progressive Enhancement; in einem Browser ohne Unterstützung muss die Seite statisch, aber vollständig sein):
1. Lade überhaupt keine JavaScript-Datei; kein GSAP, Lenis oder Swiper. Das mobile Menü funktioniert mit `<details>`.
2. Seitenübergänge (View Transitions zwischen Seiten derselben Origin): Schreibe `@media (prefers-reduced-motion: no-preference) { @view-transition { navigation: auto; } }` und halte die Dauer bei etwa 0,35 s. Gib der oberen Leiste view-transition-name: site-header. Gib einem Bild einer Arbeitskarte auf der Startseite und demselben Bild auf der Arbeiten-Seite denselben eindeutigen view-transition-name, damit das Bild auf der neuen Seite an seinen Platz wächst. Verwende jeden Namen pro Seite nur einmal.
3. Scroll-driven Animations: eine Fortschrittslinie am oberen Rand, die per scaleX mit `animation-timeline: scroll(root)` wächst (standardmäßig display:none, nur mit Unterstützung sichtbar); bei Karten und Abschnittsüberschriften `animation-timeline: view()` mit `animation-range: entry 0% entry 70%` und ausschließlich translateY; beim Hero-Bild eine sanfte Skalierung und Verschiebung, solange es im Blick ist. Verwende keine Opazität: Elemente, die ausgeblendet unterhalb des Bildschirms liegen, fallen beim Kontrastcheck von Lighthouse durch. Packe alle diese Regeln in `@supports (animation-timeline: scroll())` und `prefers-reduced-motion: no-preference`.
4. Container Queries: Mache die Arbeitskarte mit `container-type: inline-size` zu einer Komponente. Mit `@container (min-width: 34rem)` sitzt das Bild in einem schmalen Container oben und in einem breiten neben dem Text. Dieselbe Karte ist auf der Startseite im dreispaltigen Raster schmal und auf der Arbeiten-Seite in einer einzelnen Spalte breit. Tailwind 3 Core hat keine Container-Query-Klassen; schreibe diese Regeln als reines CSS in app.css.
5. Die Überschriftenebene der Karte muss zur Seite passen, auf der sie steht: Setze auf der Arbeiten-Seite ein h2 zwischen das h1 und die h3-Überschriften der Karten. Als das in der Demo fehlte, fiel Accessibility wegen heading-order auf 98.
6. Auf der Arbeiten-Seite ist das erste Kartenbild, das im ersten Bildschirm erscheint, nicht lazy und bekommt fetchpriority="high".
Einrichtung und bekannte Fallstricke (jeder davon hat in den Demo-Messungen einen Wert gesenkt, nichts überspringen):
1. Wenn auf dem Server bereits eine Website live ist, sag mir das 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. Bevor du Code schreibst, lege die Designrichtung (Typografie, Farbe, Raster, Signature-Element, Bewegungssprache und die Bibliotheken, die NICHT geladen werden) in einer kurzen ART.md außerhalb von assets ab und zeig sie mir.
2. Kompiliere Tailwind, statt es über das CDN zu laden. Installiere es mit site_run_command und background=true: `npm i -D tailwindcss@3`, danach folgt site_command_status. Die content-Pfade in `tailwind.config.js` müssen jede HTML-Datei, 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 aus 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 jeder Schriftstärke 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 eine Schriftstärke 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 hat das die durch den Schriftwechsel verursachte Layoutverschiebung beseitigt (CLS 0,024 auf 0). Die meisten Fontshare-Schriften haben kein ₺-Zeichen, schreibe für Preise also "TL".
4. Mache Menü und Footer zu statischem HTML. Lade weder chrome.js noch site.config.js auf den Seiten. Schreibe eine kleine `chrome-stamp.mjs`, die die Navigationsliste in site.config.js liest und `_src/header.tpl` sowie `_src/footer.tpl` zwischen den Markern `<!-- nav:start --><!-- nav:end -->` und `<!-- footer:start --><!-- footer:end -->` jeder Seite einstempelt und dem aktuellen Link aria-current="page" hinzufügt. Gib den Templates keine .html-Endung und nutze 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 Telefonnummer im Footer als einfachen Text stehen.
5. Konvertiere Bilder schon 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 bekommt fetchpriority="high" und ist nie lazy; alle übrigen bekommen loading="lazy" decoding="async". Wenn das Hauptbild den Smartphone-Bildschirm füllt, liefere mit `<picture>` auf Mobilgeräten einen breiteren, kleineren Ausschnitt (in der Demo sank das mobile Hero-Bild so von 89 KB auf 43 KB).
6. Erstelle mit site_fetch aus dem Logo ein 48-px-PNG-Favicon und füge `<link rel="icon">` zu jeder Seite 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 nutzen Kleinschreibung), verwende ` ` für die Leerzeichen im sichtbaren Text von tel:-Links, nutze 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 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 Arbeit unter hasPart (mit material, falls bekannt); Über uns AboutPage; Kontakt ContactPage; BreadcrumbList auf den Unterseiten. Der spezifischste LocalBusiness-Untertyp in site.config.js) in getrennte `<script type="application/ld+json">`-Blöcke und verknüpfe es per @id mit dem Basis-Graphen. Verstecke BreadcrumbList nicht in einem @graph; gib ihr einen eigenen Block, denn nur so erkennt seo-check sie.
2. Titel 48 bis 60 Zeichen (seo-check markiert alles über 65 als Fehler), Beschreibungen 145 bis 158 Zeichen, ein h1 pro Seite. Jede Seite braucht mindestens 150 Wörter Hauptinhalt; Kontakt- und Datenschutzseite bleiben dabei oft zu kurz.
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 herausgebende Organisation und ein Datum "Zuletzt aktualisiert" 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. Die 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 nenne. Lass unbekannte Felder im Schema weg.
Prüfschritte (der Reihe nach; 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, view="mobile" und view="desktop". site_preview erfasst die Seite bei ausgeschalteter Bewegung (reduced-motion); fehlen auf diesem Bild also Inhalte, ist der Zustand ohne Bewegung kaputt. In Vollseiten-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 sowie Accessibility, Best Practices und SEO 100; auf dem Desktop alle vier mindestens 95. Finde bei einer durchgefallenen Seite mit resources=true die Datei, die sie ausbremst, behebe das Problem und miss erneut. Führe danach seo_audit auf der 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.
Unterstützungsprüfung: site_preview erfasst bei ausgeschalteter Bewegung und kann die Übergänge daher nicht zeigen. Sag mir, wie ich in Chrome prüfe, dass das Bild an seinen Platz wächst, wenn ich auf der Startseite eine Arbeit anklicke, dass sich die obere Linie beim Scrollen füllt, dass die Karte ihr Layout ändert, wenn ich das Fenster verenge und erweitere, und dass die Seite in einem Browser ohne diese Funktionen vollständig öffnet.
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 um, wenn sie sich ändern (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.
