Baue auf meinem Opus Growth Hosting-Server
[server name] eine einzelne Kampagnenseite für Traffic aus Google Ads und Meta Ads sowie eine Datenschutzseite. Es gibt kein Formular; Besucher erreichen uns per Telefon, WhatsApp oder Buchungslink. Angaben: Unternehmen
[business name], Leistung
[service], Einzugsgebiet
[districts], Telefon
[phone], WhatsApp
[number], Buchungslink
[link or "none"], Adresse
[address], Öffnungszeiten
[opening hours], Anzeigen-Überschriften und Hauptangebot
[headlines and offer], Tag-Manager-Container
[GTM-XXXXXXX], Google-Ads-Konto
[account name], Meta-Werbekonto
[account name].
Message Match: Die h1 wiederholt das Versprechen der Anzeigen-Überschrift mit denselben Worten (Leistung, Gebiet, Hauptangebot). Setze auf der Seite kein Versprechen, das nicht in der Anzeige steht, und in der Anzeige keines, das nicht auf der Seite steht. Wenn sich die Überschriften bei Google und Meta unterscheiden, nimm die Überschrift der Anzeige mit dem höchsten Budget und schlage vor, wie die andere Anzeige an die Seite angeglichen werden kann. Bei Gesundheit, Recht oder Finanzen keine Sicherheitsversprechen ("garantiert", "100 %").
Seitenaufbau: Die obere Leiste enthält nur den Markennamen und einen Anruf-Button, kein Menü, damit Besucher nicht abgelenkt werden. Hero: h1, ein Satz Beschreibung, drei Buttons (Jetzt anrufen, Per WhatsApp schreiben, Termin wählen), darunter vier kurze Vertrauenspunkte und ein Bild. Danach der Ablauf in drei Schritten, was den Preis bestimmt (Answer-first, falls du keine Preise veröffentlichst), FAQ, ein abschließender Call-to-Action und ein Footer mit Name, Adresse, Telefon und Link zum Datenschutz. Auf Mobilgeräten heftest du eine zweiteilige Leiste (Anrufen, WhatsApp) am unteren Bildschirmrand an und gibst dem Body unten ein Padding in gleicher Höhe, damit nichts verdeckt wird und nichts springt. Der WhatsApp-Link nutzt wa.me mit vorausgefüllter Nachricht. Halte das Design schlicht und vertrauenswürdig: eine Schriftfamilie (zum Beispiel General Sans, zwei Schnitte), eine Akzentfarbe, ein dunkelgrüner WhatsApp-Button mit mindestens 4,5:1 Kontrast zu weißem Text.
Regeln für Animation und Messung:
1. Leichte Animation ohne Bibliotheken: Lade weder GSAP noch Lenis noch Swiper. Hover- und Press-Übergänge an Buttons; an den Schritt-Karten ein kleiner scrollgesteuerter Aufstieg, der ausschließlich transform nutzt, innerhalb von `@supports (animation-timeline: view())` und nur für Besucher, die keine reduzierte Bewegung eingestellt haben. Verwende kein opacity: In der Demo fielen Karten, die ausgeblendet unterhalb des Bildschirms lagen, beim Kontrast durch und drückten Accessibility auf 96. Nichts im ersten Bildschirm startet mit einer Eintrittsanimation.
2. Lade die Messschicht als `assets/tag.js` mit defer:
a. `window.dataLayer` und die Consent-Mode-v2-Defaults: ad_storage, ad_user_data, ad_personalization und analytics_storage auf "denied", wait_for_update 500.
b. Gib jedem Aktionslink data-conv="phone", "whatsapp" oder "booking" und ein data-conv-place mit dem Namen seines Abschnitts. Ein einziger Click-Listener schickt sie als `{event: "phone_click" | "whatsapp_click" | "booking_click", conv_place, page_path}` an dataLayer.
c. Setze das klassische GTM-Snippet nicht in den `<head>`; injiziere es nach dem load-Event mit requestIdleCallback, damit Tags den ersten Paint nie aufhalten.
d. Füge eine kleine fixierte Consent-Leiste hinzu: Ablehnen und Akzeptieren als gleichwertige Buttons, die Auswahl im Browser gespeichert und als Consent-Update gesendet. Auf Mobilgeräten sitzt sie über der Aktionsleiste und ist niedrig genug, um den Haupt-Button im Hero nicht zu verdecken.
3. Tag Manager: Zeige zuerst den aktuellen Stand mit list_gtm_containers, list_gtm_triggers und gtm_workspace_status. Schlage mit create_gtm_trigger drei Custom-Event-Trigger vor (phone_click, whatsapp_click, booking_click). Finde die Kontakt-Conversion und ihren send_to-Wert in Google Ads mit list_conversion_actions und get_conversion_tags. Damit jemand, der sowohl anruft als auch schreibt, nicht doppelt gezählt wird, schlage vor, Telefon und WhatsApp an eine einzige "Contact click"-Conversion zu binden, die einmal zählt; falls keine existiert, sage, was du anlegen würdest, und warte auf meine Freigabe. Schlage mit create_gtm_tag (tag_type "sp") ein Google-Ads-Conversion-Tag vor. Suche für Meta den Pixel mit list_meta_pixels; falls der Basis-Pixelcode nicht im Container ist, schlage ihn als Custom-HTML-Tag auf allen Seiten vor, und getrennt davon die Tags, die bei Klicks `fbq('track','Contact')` und bei Buchung `fbq('track','Schedule')` senden. Führe jedes Tool zuerst mit confirm=false aus, zeige mir die Änderungsliste und lege sie nach meiner Freigabe an. Zeige publish_gtm_container zuerst mit confirm=false, veröffentliche nach meiner Freigabe und nenne die Version, die sich wiederherstellen lässt.
4. Testplan: Schreibe Schritt für Schritt auf, wie ich im GTM-Vorschaumodus sehen kann, welches Tag bei jedem der drei Buttons feuert und dass bei abgelehntem Consent kein Werbe-Cookie gesetzt wird.
5. Führe nach dem Hinzufügen von GTM und den Tags core_web_vitals erneut aus, denn Tags können den Score senken, und zeige den Unterschied in einer Tabelle. Damit das Google-Tag nicht von Adblockern blockiert wird, zeige mit site_tag_gateway eine Vorschau des First-Party-Messpfads und richte ihn nach meiner Freigabe ein.
Einrichtung und bekannte Stolperfallen (jede hat in den Demo-Messungen einen Score gesenkt, überspringe keine):
1. Wenn auf dem Server bereits eine Website live ist, sage mir das zuerst, denn die Einrichtung überschreibt index.html und den assets-Ordner. 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. Schreibe vor dem Code die Gestaltungsrichtung (Typografie, Farbe, Raster, Signature-Element, Bewegungssprache und die Bibliotheken, die NICHT geladen werden) in eine kurze ART.md außerhalb von assets 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`, danach 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 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 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 Custom Font. 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 den durch den Font-Swap verursachten Layout Shift (CLS 0,024 auf 0). Die meisten Fontshare-Schriften haben kein ₺-Glyph, schreibe bei Preisen also "TL".
4. Mach Menü und Footer zu statischem HTML. Lade weder chrome.js noch site.config.js auf den Seiten. Schreibe ein kleines `chrome-stamp.mjs`, das die Nav-Liste 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 beim aktuellen Link aria-current="page" ergänzt. 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 Mobilmenü ohne JS mit `<details>`. Lass Firmenname, Adresse und Telefon im Footer als reinen Text stehen.
5. Konvertiere Bilder schon beim Herunterladen mit site_fetch: Schreibe dasselbe Foto in separate 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 wird nie lazy geladen; alle anderen bekommen loading="lazy" decoding="async". Füllt das Hauptbild den Handy-Bildschirm, liefere mit `<picture>` auf Mobilgeräten einen breiteren, kleineren Ausschnitt (in der Demo sank das mobile Hero von 89 KB auf 43 KB).
6. Erzeuge 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 für den HTML-Validator: 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. Nutze Verzeichnis-URLs mit abschließendem Schrägstrich (/gizlilik/). Fülle den seo-Block in site.config.js und führe `node seo-stamp.mjs` aus. Schreibe das seitenspezifische Schema (auf der Kampagnenseite WebPage, einen Service mit Verknüpfung zu #business als provider mit areaServed sowie FAQPage; auf der Datenschutzseite WebPage und BreadcrumbList. In site.config.js den spezifischsten LocalBusiness-Untertyp, zum Beispiel HousePainter, Plumber, Dentist. Die Datenschutzseite erklärt die Cookies, die Mess-Tags und wie sich die Consent-Auswahl ändern lässt) in separate `<script type="application/ld+json">`-Blöcke und verknüpfe es per @id mit dem Basis-Graph. Verstecke 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, eine h1 pro Seite. Jede Seite braucht mindestens 150 Wörter Hauptinhalt; Kontakt- und Datenschutzseiten bleiben dabei oft zu kurz.
3. Der erste Absatz jeder Seite beantwortet die Frage der Seite direkt. Schreibe eine seitenspezifische FAQ mit `<details>` und zeichne sie als FAQPage aus. Zeige die veröffentlichende Organisation und ein "Zuletzt aktualisiert"-Datum mit `<time>` an.
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 korrekte 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.
Gates (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, view="mobile" und view="desktop". site_preview erfasst die Seite mit ausgeschalteter Bewegung (reduced-motion); fehlt in diesem Bild Inhalt, ist der bewegungslose Zustand kaputt. Bei 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: mobil Performance mindestens 95 sowie Accessibility, Best Prac
