Baue auf meinem Opus Growth Hosting-Server
[Servername] eine Landingpage für die Mobile App
[App-Name]. App:
[was sie macht, für wen sie gedacht ist], Plattformen und Mindestversionen:
[iOS- und Android-Versionen]. Die vier Hauptfeatures und was der jeweilige Screen zeigt:
[Feature, Beschreibung in einem Satz, Elemente auf dem Screen]. Tarife und Preise: [Tarifname, Preis, Zeitraum, enthaltene Leistungen, Dauer der Testphase; inklusive oder exklusive MwSt.]. Store-Links:
[App-Store-Link],
[Google-Play-Link]. Support-Fragen: [echte Antworten zu Kontolöschung, Kündigung, Datenexport usw.]. Unternehmen und Kontakt:
[Firmenname],
[Adresse],
[Support-E-Mail],
[Telefon]. Domain:
[Domain]. Echte Screenshots:
[Links oder "keine, in HTML zeichnen"].
Seiten: Startseite (/: Hero, vom Handy geführte Feature-Story #ozellikler, Zielgruppen, Preise #fiyatlar, FAQ, Download-Call-to-Action #indir), Support (/destek/: häufige Fragen und Support-Kontakt), Datenschutz und KVKK (/gizlilik/: gilt für App und Website; die Stores verlangen eine URL zur Datenschutzerklärung) und 404.html. Der Preisbereich enthält Tarifkarten und darunter einen echten `<table>`-Vergleich; gib der Tabelle kein min-width, denn in der Demo hat eine feste Mindestbreite auf Smartphones Spalten aus dem Bildschirm geschoben.
Stil: eine warme, vertrauenswürdige App-Landingpage. Cremefarbener Hintergrund, eine dunkle Markenfarbe und ein einziger leuchtender Akzent, der nur als Hintergrund verwendet wird. Eine runde, freundliche Fontshare-Display-Schrift (zum Beispiel Chillax) und eine gut lesbare Fließtextschrift (zum Beispiel Manrope). Zeichne den Handy-Rahmen in CSS (aspect-ratio 9/19, abgerundete Ecken, Notch) und baue die Screens in HTML und CSS statt mit Bilddateien; die Screen-Karten sind aria-hidden-Dekoration, und der Text daneben beschreibt das Feature. Lade für eine echte App die offiziellen Badges von Apple und Google auf deinen eigenen Server herunter, nutze sie für die Store-Buttons und halte dich an deren Richtlinien; ergänze den Markenhinweis im Footer.
Bewegungsregeln (der schwierigste Teil, halte sie buchstabengetreu ein):
1. Bibliotheken: nur der GSAP-3.13-Core und ScrollTrigger, nur auf der Startseite. Lenis, SplitText, Swiper, Lottie und Video werden NICHT geladen; auf den Support- und Datenschutzseiten gibt es überhaupt keine Skripte.
2. Jede Feature-Sektion enthält im HTML ihr eigenes kleines Handy mit eigenem Screen. Auf Smartphones, ohne JS und bei reduzierter Bewegung zeigt jedes Feature seinen eigenen Screen untereinander (auf breiteren Bildschirmen nebeneinander); dieser Zustand muss für sich allein vollständig sein.
3. Ab 1024 px Breite und wenn Bewegung erlaubt ist, kopiert JS die Screens aus den Sektionen in das einzelne Handy in der rechten Spalte, fügt der Sektion die Klasse `has-phone` hinzu und blendet die kleinen Handys aus. Schreibe die Screens nicht doppelt ins HTML. Da die Feature-Sektion unterhalb des ersten Bildschirms liegt, zählt dieser Klassenwechsel nicht als Layout Shift; die Demo hat CLS 0 gemessen.
4. Halte das Handy per CSS `position: sticky` (top: calc(50vh - halbe Handyhöhe)) an Ort und Stelle, statt ein ScrollTrigger-Pin zu verwenden. Es wird kein pin-spacer eingefügt, es funktioniert ohne JS, und die Seite springt nicht.
5. Screen-Wechsel: Verwende für jede Feature-Sektion ScrollTrigger.create mit start "top 55%", end "bottom 55%" und onToggle; zeige den aktiven Screen mit gsap autoAlpha und blende den vorherigen mit autoAlpha 0 aus. Nutze nicht nur opacity; ausgeblendete Screens müssen visibility:hidden sein, damit das Accessibility-Audit sie nicht liest. Die Überschrift der aktiven Sektion wechselt die Farbe (kein Ausblenden per opacity), und Punkte neben dem Handy zeigen, welches Feature aktiv ist.
6. Karten und Preisboxen erscheinen mit data-reveal und gleiten beim Scrollen 20 px nach oben; leere die kopierten Screens in der Revert-Funktion von matchMedia, damit das Layout nicht kaputtgeht, wenn das Fenster verkleinert wird.
Einrichtung und bekannte Fallstricke (jeder davon hat in der Demo-Messung Punkte gekostet oder etwas kaputt gemacht, überspringe keinen):
1. Wenn auf dem Server bereits eine Live-Seite liegt, sage mir das zuerst, denn die Einrichtung überschreibt index.html und den Ordner assets. 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 zeige sie mir.
2. Kompiliere Tailwind, lade es nicht vom CDN. 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` zu einer einzigen Datei. Entferne das Skript cdn.tailwindcss.com und die Inline-tailwind.config aus den Seiten und verlinke nur `/assets/site.css`. Kompiliere nach jeder HTML-Änderung neu.
3. Hoste die Schriften selbst. Prüfe zuerst, ob die gewählte Fontshare-Familie die türkischen Buchstaben (ş, ğ, ı, İ, ç, ö, ü) enthält: In der Demo hatte Tanker kein punktloses ı und Outfit kein ş, ğ oder İ, sodass diese Buchstaben in Überschriften auf eine andere Schrift zurückfielen. Lade jede woff2-Datei pro Schriftschnitt einzeln mit site_fetch nach `assets/fonts/` herunter, 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 oberhalb des Folds genutzten Überschrifts- und Fließtextschriften auf jeder Seite mit `<link rel="preload" as="font" type="font/woff2" crossorigin>` vor, noch vor dem Stylesheet; preloade nicht mehr als zwei Dateien, denn ein dritter vorgeladener Schriftschnitt hat in der Demo den mobilen LCP um 0,2 Sekunden verlängert. Den meisten Fontshare-Schriften fehlt das ₺-Zeichen, schreibe daher bei Preisen "TL".
4. Mache Menü und Footer zu statischem HTML. Lade auf den Seiten weder chrome.js noch site.config.js. 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 den Markern `<!-- nav:start --><!-- nav:end -->` und `<!-- footer:start --><!-- footer:end -->` einstempelt 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>`. Lasse Organisationsname, Adresse und Telefon als reinen Text im Footer stehen, und mache jedes Touch-Ziel mindestens 44x44 px groß, auch Footer- und Breadcrumb-Links.
5. Konvertiere Bilder beim Herunterladen mit site_fetch: Schreibe dasselbe Foto mit resize="480x", "800x" und "1200x", image_format="webp", quality=65 in separate Dateien. site_fetch schneidet nie zu; wenn ein Unsplash-Foto ein anderes Seitenverhältnis braucht, lade die zugeschnittene Version herunter, indem du der URL Parameter wie `?w=1600&h=1200&fit=crop` hinzufügst. Gib jedem `<img>` srcset, sizes sowie width und height passend zum echten Seitenverhältnis. Das Hauptbild oberhalb des Folds bekommt fetchpriority="high" und ist nicht lazy; alle anderen bekommen loading="lazy" decoding="async". Wenn das Hauptbild auf Smartphones den Bildschirm füllt, liefere per `<picture>` einen kleineren Zuschnitt aus.
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>` in ein `<figure>` nach dem figcaption.
8. Lade die Bewegungsbibliotheken (GSAP, ScrollTrigger) von jsdelivr mit site_fetch nach `assets/vendor/` herunter, fixiere die Version und lade sie nur auf der Startseite. Verwende kein `<script defer>`; setze am Seitenende einen kleinen Loader ein, 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`, außer prefers-reduced-motion ist "reduce"; ohne `anim` lädt der Loader nichts herunter. Definiere versteckte Startzustände nur unter `.anim` und füge eine CSS-Animation als Sicherheitsnetz hinzu, die alle versteckten Elemente nach 2,5 Sekunden einblendet, falls die Bibliothek nie ankommt. In früheren Demos haben per defer geladene Bibliotheken den mobilen LCP auf 3,2 Sekunden gedrückt; mit diesem Loader haben die Seiten 99 bis 100 erreicht. Nenne das Attribut für beim Scrollen eingeblendete Elemente data-reveal; design-check erkennt Bewegung nur anhand dieses Namens.
SEO, AEO und GEO:
1. Verwende URLs im Verzeichnisstil mit abschließendem Schrägstrich (/destek/, /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, MobileApplication (operatingSystem, applicationCategory, beide Store-URLs als downloadUrl, die von mir genannten Tarife als offers mit TRY-Preisen; füge KEIN aggregateRating hinzu, denn eine Store-Bewertung ist keine auf deiner Seite gesammelte Rezension) und FAQPage; Support: WebPage und FAQPage; Datenschutz: WebPage; BreadcrumbList auf Unterseiten. Für ein Softwareunternehmen ohne Ladengeschäft: localBusiness:false in site.config.js) in separate `<script type="application/ld+json">`-Blöcke und verknüpfe sie per @id mit dem Basis-Graphen. Verschachtele 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, ein h1 pro Seite und keine übersprungenen Überschriftenebenen (ein h3 direkt nach dem h1 hat Accessibility auf 98 gedrückt). Jede Seite braucht mindestens 150 Wörter Hauptinhalt; Kontakt- und Datenschutzseiten bleiben oft darunter.
3. Der erste Absatz jeder Seite beantwortet direkt die Frage der Seite. Schreibe seitenspezifische FAQs mit `<details>` und zeichne sie als FAQPage aus. Zeige die veröffentlichende Organisation und ein "Zuletzt aktualisiert"-Datum in `<time>`.
4. Schreibe in der robots.txt deine Entscheidung für GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot und CCBot auf und begründe sie, und verweise auf die Sitemap. Gib der sitemap.xml echte lastmod-Daten. llms.txt enthält eine korrekte Zusammenfassung der Website 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. Lasse jedes Feld, das du nicht kennst, ganz aus dem Schema weg.
Gates (der Reihe nach; sage nicht "fertig", bevor 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 Zustand ohne Bewegung kaputt. Weiter unten liegende Lazy-Bilder können in der 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. Abnahmekriterium: Auf Mobile Performance mindestens 95 und Accessibility, Best Practices und SEO 100; auf Desktop alle vier mindestens 95. Finde bei einer Seite, die das verfehlt, mit resources=true die langsame Datei, behebe das Problem und miss erneut. Führe danach seo_audit für die Startseite mit strategy="mobile" und runs=2 aus. In der Netzwerk-Request-Liste darf keine Adresse außerhalb deiner eigenen Domain übrig bleiben.
4. Kein horizontales Scrollen bei 360, 390, 768 und 1440 px, Touch-Ziele von mindestens 44 px und keine Konsolenfehler. Die Seite muss außerdem in einem 390x790- und einem 1440x898-Rahmen makellos aussehen, wie auf den Prompt-Seiten.
Bewegungsprüfung: site_preview kann keine Bewegung zeigen, sage mir also, worauf ich in meinem eigenen Browser achten soll. Auf dem Desktop soll das Handy beim Erreichen des Feature-Bereichs rechts in der Bildschirmmitte fest stehen bleiben, sein Screen soll zum jeweiligen Feature wechseln, sobald dessen Überschrift die Mitte erreicht, die Überschrift soll die Farbe annehmen und der Punkt daneben soll weiterrücken. Auf einem Smartphone und bei aktivierter reduzierter Bewegung zeigt jedes Feature seinen eigenen kleinen Screen, und nichts bleibt fest stehen. Die Store-Buttons müssen den richtigen Store öffnen.
Nach der Veröffentlichung: Zeige mit site_headers eine Vorschau der Regel `/assets/* Cache-Control: public, max-age=31536000, immutable` und wende sie nach meiner Freigabe an; versioniere danach 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 getesteten Interaktionen und die Liste der angewendeten Korrekturen.
