Baue auf der
[server name]-Website auf meinem Opus-Growth-Hosting-Server eine statische, schnelle Veranstaltungswebsite für
[event name]. Veranstaltung:
[was es ist, für wen, welche Ausgabe, zwei Sätze]. Datum und Uhrzeit:
[Beginn und Ende, Zeitzone]. Veranstaltungsort: [Name des Ortes, vollständige Adresse, Anreise, Parken, Barrierefreiheit]. Programm:
[pro Tag Uhrzeit, Sessiontitel, Referent und Raum]. Referenten: [Name, Titel, Organisation, Vortragstitel, Biografie, Foto-Link und Erlaubnis zur Veröffentlichung des Fotos]. Tickets: [Ticketarten, Preise, ob die Mehrwertsteuer enthalten ist, Gültigkeitsdaten, der Link auf der Ticketplattform, Erstattungs- und Übertragungsbedingungen]. Veranstalter:
[Name der Organisation],
[email],
[phone]. Aufzeichnungs- und Fotorichtlinie:
[ob Vorträge aufgezeichnet und Fotos gemacht werden]. Domain:
[domain].
Seiten: Startseite (eine Zeile mit Datum und Ort, Countdown, kurze Einführung, was passieren wird, vier der Referenten, eine Kurzübersicht zum Veranstaltungsort, FAQ), Programm (/program/: Tagesreiter und eine .ics-Kalenderdatei), Referenten (/konusmacilar/), Tickets (/bilet/: Ticketarten, was enthalten ist, Erstattungen, Rechnungs-FAQ), Veranstaltungsort (/mekan/: Adresse, Anreise, Barrierefreiheit, Unterkunft), Datenschutz (/gizlilik/, einschließlich der Wahlmöglichkeit zu Foto und Aufzeichnung) und 404.html.
Stil: ein Konferenzplakat. Wenn keine
[colour preference] angegeben ist: ein signalgelbes Hero-Band, ein cremefarbener Hintergrund, schwarzer Text und schwarze Rahmen mit 2 Pixeln. Eine breite, fette Fontshare-Schrift in Großbuchstaben für Überschriften (zum Beispiel Panchang 700) und eine abgerundete Sans für den Fließtext (zum Beispiel Chillax 400 und 500); alle drei Dateien des ersten Bildschirms per Preload laden. Die Großschreibung braucht `<html lang="tr">`, sonst wird aus "i" ein "I". Hat ein Referent kein Foto oder keine Veröffentlichungserlaubnis, verwende ein Monogramm mit den Initialen; verwende nie das Foto einer anderen Person.
Interaktionsregeln (keine Bibliothek, eine einzige `ix.js` mit defer, nur auf Start-, Programm- und Referentenseite):
1. Der Countdown stimmt auch ohne JS: Das HTML enthält in einer Box fester Höhe den Text "Beginn: <time datetime="2027-05-13T09:00:00+03:00">Donnerstag, 13. Mai 2027, 09.00 Uhr</time> (türkische Zeit)". JS liest die ISO-Daten mit Zeitzonen-Offset aus data-start und data-end mit Date.parse und schreibt Tages-, Stunden- und Minutenboxen in dieselbe Box. Die Box muss in beiden Zuständen gleich hoch sein (CSS min-height und eine feste Einheitenhöhe), sonst verschiebt sich der erste Bildschirm. Zeige keine Sekunden; aktualisiere jede Minute und pausiere, solange der Tab verborgen ist. Die Zahlenboxen sind aria-hidden mit einem einzigen visuell verborgenen Satz für Screenreader daneben und ohne Live-Region (aria-live), weil sie sonst jede Minute vorgelesen würde. Sobald die Veranstaltung begonnen hat, schreibe "läuft gerade", nach dem Ende "ist beendet"; zeige bei einem vergangenen Datum nie negative Zahlen.
2. Tagesreiter: Im HTML ist jeder Tag ein eigener Abschnitt mit eigener Überschrift (id="gun-1", "gun-2"), darüber Links zu diesen Abschnitten; ohne JS werden alle Tage untereinander angezeigt. Der Container um die Links trägt role="group" und ein aria-label. JS macht daraus ARIA-Tabs (tablist, tab, tabpanel, aria-selected, tabindex, Pfeiltasten, Pos1 und Ende), wählt den zweiten Tag, wenn die Seite mit #gun-2 geöffnet wird, und aktualisiert beim Tabwechsel die URL mit history.replaceState, damit ein Tag als Link geteilt werden kann. Jede Session ist eine Listenzeile mit `<time datetime>`: Uhrzeit, Titel, ein Link zum Anker des Referenten auf der Referentenseite und der Raum; Pausen erhalten einen eigenen Hintergrund.
3. Referenten-Biografie: Im HTML steht sie auf jeder Karte in einem `<details>`, ist also ohne JS und für Suchmaschinen lesbar. JS fängt den Klick auf die summary ab, baut ein einziges `<dialog>`, kopiert Name, Titel, Vortragstitel und Biografie per textContent hinein, öffnet es mit showModal und setzt den Fokus auf die Schaltfläche "Schließen"; Esc und ein Klick auf den Hintergrund schließen es, und der Fokus kehrt zur summary zurück. Füge der summary aria-haspopup="dialog" hinzu. Die id jeder Karte ist der Slug des Referenten, auf den die Links im Programm zeigen.
4. Fixierter Ticket-Call-to-Action: ein Button "Tickets sichern" im Header auf dem Desktop und auf dem Smartphone eine am unteren Bildschirmrand fixierte Leiste (Datum, niedrigster Preis und "Tickets sichern"). Die Leiste ist statisches HTML im Footer-Template und von der ersten Darstellung an position: fixed; ein späteres Hinzufügen per JS verursacht einen Layoutsprung. Gib dem body auf dem Smartphone unten ein Padding in Höhe der Leiste, damit die letzten Links nicht darunter verschwinden, ergänze `env(safe-area-inset-bottom)` und blende die Leiste auf der Ticketseite über eine Klasse am body aus.
5. Kalenderdatei: `/assets/
[event].ics`, auf der Programmseite herunterladbar (VCALENDAR mit einem VEVENT, DTSTART und DTEND in UTC, SUMMARY, LOCATION, URL, Zeilenenden CRLF). Versieh den Link mit dem Attribut download.
Schema: dasselbe Event (@id /#event) auf Start-, Programm- und Ticketseite: name, description, startDate und endDate mit Zeitzonen-Offset, eventStatus EventScheduled, eventAttendanceMode OfflineEventAttendanceMode, location als Place mit vollständiger PostalAddress, drei Bilder in den Verhältnissen 1x1, 4x3 und 16x9, organizer, die Referenten als performer und ein offers-Array (für jede Ticketart name, price, priceCurrency "TRY", availability, validFrom, validThrough für Early Bird und die Verkaufsseite als url). Das Event-Rich-Result von Google verlangt location und startDate und führt @id nicht seitenübergreifend zusammen, also schreibe das Event auf jeder Seite, die es verwendet, vollständig aus; auf der Programmseite ergänze zusätzlich jede Session als subEvent. Wird die Veranstaltung verschoben oder abgesagt, setze eventStatus auf EventPostponed oder EventCancelled, statt die Seite zu löschen. Place auf der Seite zum Veranstaltungsort und BreadcrumbList auf jeder Unterseite. Sponsoren, Teilnehmerzahlen oder "ausverkauft" werden nur geschrieben, wenn sie stimmen.
Einrichtung und bekannte Stolperfallen (jede einzelne hat in den Demo-Messungen Punkte gekostet, keine überspringen):
1. Ist auf dem Server bereits eine Website live, 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 erst nach meiner Freigabe mit confirm=true auf. Lies danach site_design_guide und site_seo_guide. Bevor du Code schreibst, halte die Designrichtung (Typografie, Farben, Raster, Signature-Element, Bewegungssprache und die Bibliotheken, die NICHT geladen werden) in einer kurzen Datei ART.md außerhalb von assets fest und zeig sie mir.
2. Kompiliere Tailwind, lade es nicht vom CDN. Installiere es mit site_run_command und background=true (`npm i -D tailwindcss@3`) und verfolge den Vorgang mit site_command_status. Die content-Pfade in `tailwind.config.js` müssen jede HTML-Datei, die `_src`-Templates und jede JS-Datei abdecken, die Klassen schreibt. `_src/tw.css` enthält die Zeile `@import "../assets/app.css";` plus 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 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-Familie, lade das woff2 jeder Schriftstärke einzeln mit site_fetch nach `assets/fonts/` und schreibe die @font-face-Regeln mit `font-display: swap` in `assets/app.css`, denn dort sucht design-check nach einer eigenen Schrift. Prüfe den font-family-Namen im heruntergeladenen CSS und vergewissere dich, dass die Familie die türkischen Buchstaben ı, İ, ş und ğ enthält (Tanker hat kein ı). Lade JEDE im ersten Bildschirm verwendete Schriftstärke per `<link rel="preload" as="font" type="font/woff2" crossorigin>` vor, platziert vor der Stylesheet-Zeile; sind es mehr als drei Dateien, nimm weniger Schriftstärken. In der Demo hat eine einzige nicht vorgeladene Schriftstärke im Fließtext den mobilen LCP auf 2,6 Sekunden und Performance auf 97 gedrückt. Den meisten Fontshare-Schriften fehlt das ₺-Zeichen, schreibe Preise also mit "TL".
4. Mach Menü und Footer zu statischem HTML. Lade chrome.js, motion.js oder site.config.js nicht auf den Seiten. 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 die Marker `<!-- nav:start --><!-- nav:end -->` und `<!-- footer:start --><!-- footer:end -->` stempelt und dem aktiven Link aria-current="page" hinzufügt. Verwende Platzhalter wie `
[[NAV]]` statt `{{...}}` und gib den Templates keine .html-Endung, sonst behandeln design-check und seo-check sie als halbfertige Seiten. Baue das mobile Menü mit einem JS-freien `<details>`. Behalte Firmenname, Adresse und Telefon als reinen Text im Footer und mach Footer- und Breadcrumb-Links mindestens 44 Pixel hoch.
5. Konvertiere Bilder direkt beim Abruf mit site_fetch: Schreibe dasselbe Bild mit resize="480x", "800x" und "1200x", image_format="webp", quality=60 als getrennte Dateien (site_fetch beschneidet nicht, fordere die Quelle also im benötigten Seitenverhältnis an). Gib jedem `<img>` srcset, sizes sowie width und height passend zum echten Seitenverhältnis. Das Bild, das das LCP-Element der Seite ist, erhält fetchpriority="high" und wird nicht lazy geladen; jedes andere Bild erhält loading="lazy" decoding="async". Füllt ein Bild den ersten mobilen Bildschirm, liefere mit `<picture>` einen kleineren Ausschnitt für Mobilgeräte.
6. Füge jeder Seite `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` hinzu und erzeuge aus dem Logo mit site_fetch und resize="180x180" ein apple-touch-icon mit 180 Pixeln. Ohne Favicon-Link fragt der Browser /favicon.ico an, protokolliert einen 404 und Best Practices fällt auf 96.
7. Regeln des HTML-Validators: Beginne jedes Dokument mit einem großgeschriebenen `<!DOCTYPE html>`; jedes Leerzeichen im sichtbaren Text eines tel:-Links muss ` ` sein, auch das nach einem Präfix wie "Anrufen: 0212..."; verwende kein style=""; gib jedem Button ein type; setze aria-label nur an Landmarks, Formularen oder interaktiven Elementen (an einer ul oder einem div ohne Rolle war es ein Fehler); beschrifte nie zwei Landmarks mit demselben Namen; lass keine nachgestellten Leerzeichen stehen.
8. Überspringe keine Überschriftenebenen: Auf einer Listenseite haben Kartentitel als h3 direkt nach dem h1 die Barrierefreiheit auf 98 gedrückt. Wenn du eine Karte wiederverwendest, setze ihre Überschriftenebene pro Seite (h2 auf einer Listenseite, h3 innerhalb eines h2-Abschnitts).
9. Nenne das Bewegungsattribut data-reveal (design-check erkennt Bewegung nur unter diesem Namen). JS gibt den verborgenen Startzustand nur Blöcken, die beim Öffnen der Seite unterhalb des Bildschirms liegen, und blendet nie Inhalte des ersten Bildschirms aus; verwende transform, denn ein Einblenden über opacity senkt das Kontrast-Audit. Setze das Attribut auf den Block, der eine Überschrift samt Beschreibung umschließt, nicht auf die Überschrift allein; in der Demo ist eine wartende Überschrift über den darunterliegenden Absatz geglitten. Bei prefers-reduced-motion: reduce wird nichts ausgeblendet und Animationen sind aus.
SEO, AEO und GEO:
1. Verwende URLs im Verzeichnisstil mit abschließendem Schrägstrich. Fülle den seo-Block von site.config.js und führe `node seo-stamp.mjs` aus. Schreibe seitenspezifisches Schema in getrennte `<script type="application/ld+json">`-Blöcke, die über @id mit dem Basisgraphen verknüpft sind. Verschachtle BreadcrumbList nicht in @graph; halte sie in einem eigenen Block, nur so erkennt seo-check sie.
2. Titel höchstens 60 Zeichen (seo-check meldet alles unter 25 oder über 65 als Fehler), Beschreibungen 130 bis 158 Zeichen, ein h1 pro Seite und mindestens 150 Wörter Hauptinhalt auf jeder Seite. Kontakt-, Datenschutz- und Listenseiten bleiben oft darunter; ergänze seitenspezifische Informationen, keinen Füllstoff.
3. Der erste Absatz jeder Seite beantwortet die Frage der Seite direkt. Schreibe seitenspezifische FAQs mit `<details>` und zeichne sie als FAQPage aus. Zeige den Herausgeber und ein Datum "Zuletzt aktualisiert" in einem `<time>`-Element.
4. Schreibe in robots.txt deine Entscheidung mit 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 eine Liste der wichtigen Seiten.
5. Nichts erfinden: Schreibe ohne Rückfrage keine Bewertungen, Ratings, Auszeichnungen, Kundenzahlen, Zertifikate, Öffnungszeiten, Koordinaten oder Preise. Lass jedes Feld, das du nicht kennst, ganz aus dem Schema weg.
Prüfschritte (der Reihe nach; sag 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 an, view="mobile" und view="desktop". site_preview erfasst die Seite ohne Bewegung (reduced-motion); fehlt in dieser Aufnahme Inhalt, ist der statische Zustand kaputt. In Ganzseitenaufnahmen können fixierte Elemente wie eine Sticky-Leiste mitten auf der Seite erscheinen und weiter unten liegende Lazy-Bilder 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. Abnahmekriterien: Auf Mobilgeräten Performance mindestens 95 (Ziel 99 bis 100) sowie Barrierefreiheit, Best Practices und SEO 100; auf dem Desktop alle vier 100. Verwende bei einer Seite, die das verfehlt, resources=true, um die Datei zu finden, die sie verzögert, behebe das Problem und miss erneut. Führe danach seo_audit auf der Startseite mit strategy="mobile" und runs=2 aus. In der Liste der Netzwerkanfragen darf keine Adresse außerhalb deiner eigenen Domain übrig bleiben.
4. Kein horizontales Scrollen bei 360, 390, 768 und 1440 Pixeln Breite, Touch-Ziele mindestens 44 Pixel, keine Konsolenfehler.
Interaktionsprüfung: site_preview kann Zeit, Tabs oder Dialoge nicht zeigen. Sag mir, wie ich prüfe, dass der Countdown bei deaktiviertem JavaScript das richtige Datum zeigt und mit JS in gleich hohe Boxen übergeht, dass /program/#gun-2 den zweiten Tag öffnet und die Tabs sich mit den Pfeiltasten wechseln lassen, dass sich eine Referenten-Biografie im Modal öffnet und der Fokus nach Esc zurückkehrt, dass die Ticketleiste auf dem Smartphone die letzten Links der Seite nicht verdeckt, dass die Kalenderdatei zur richtigen Uhrzeit im Kalender des Telefons landet und dass der Rich-Results-Test von Google das Event ohne Fehler anzeigt.
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 einmal 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 Punktetabelle pro Seite (Seite, vier Mobil-Werte, vier Desktop-Werte, LCP, CLS), das Ergebnis jedes Prüfschritts und die Liste der angewandten Korrekturen.
