Baue mir auf meinem Opus Growth Hosting-Server
[Servername] eine Expertenseite im redaktionellen Stil. Zu mir:
[vollständiger Name],
[Fachgebiet, z. B. Exportberater],
[Region, in der ich tätig bin, oder "online"]. Leistungen:
[Leistungen]. Erfahrung: [tatsächliche Erfahrung und Branchen, in denen ich gearbeitet habe; nichts erfinden]. Telefon:
[Telefon], E-Mail:
[E-Mail], Domain:
[Domain]. Themen der ersten beiden Ratgeber:
[Thema 1],
[Thema 2]. Falls mein Büro Besuch empfängt, dessen Adresse:
[Adresse oder "keine"].
Die Seite soll wie eine Publikation wirken, die Expertise durch Texte belegt, nicht wie eine Broschüre. Die Ratgeber stehen im Zentrum der Seite, denn sie werden von Lesern und KI-Antworten zitiert.
Die Gestaltungsrichtung ist redaktionell:
1. Schrift: eine charaktervolle Serifenschrift von Fontshare für Überschriften (z. B. Zodiak 700 und 400 kursiv) und eine ruhige Sans für Oberfläche und kurze Texte (z. B. Author 400 und 600). Artikeltext in der Serifenschrift mit 19 Pixeln, Zeilenhöhe 1,7, höchstens 68 Zeichen pro Zeile.
2. Farbe: cremefarbener Papierhintergrund, dunkle Tintenfarbe für den Text, ein warmes Grau als Zweitfarbe und ein dunkler Akzent (z. B. Ochsenblutrot). Der Akzent erscheint nur bei Kickern, der Initiale und den Linien der Pull Quotes.
3. Raster: 12 Spalten; ein asymmetrisches 7-zu-5-Cover auf der Startseite mit dünnen senkrechten Linien zwischen den Spalten. Keine Schatten oder abgerundeten Ecken.
4. Signaturelement: ein Kopf (Masthead) mit Doppellinie wie bei einem Zeitungstitel (mit dünner Datumszeile darüber) und in Artikeln eine große Initiale in der Akzentfarbe sowie ein Pull Quote am Rand.
5. Bewegung: keine.
Seiten und ihr Schema:
1. index.html (Cover): eine Schlagzeile und ein Vorspann, dessen erster Absatz die Frage "Wer bist du, wem hilfst du bei was" beantwortet, Bild und Titel des Leitartikels, eine Seitenspalte mit den übrigen Artikeln, Leistungen und Autorenboxen, ein Pull Quote und ein Band "So arbeite ich". WebPage und Person.
2. hizmetler.html: ein Abschnitt pro Leistung; der erste Absatz nennt, für wen sie gedacht ist und wann, danach nummerierte Schritte und das schriftliche Ergebnis. Ein Service pro Leistung, mit der Autoren-Person als provider.
3. hakkimda.html: tatsächliche Erfahrung, Arbeitsgrundsätze (keine garantierten Ergebnisse), wie die Artikel entstehen und die Quellenrichtlinie. ProfilePage mit mainEntity Person (jobTitle, knowsAbout, worksFor #org).
4. rehber/index.html: Artikel, neueste zuerst, mit Datum und Autor. CollectionPage und ItemList (numberOfItems).
5. rehber/
[artikel].html: mindestens 700 Wörter, ein erster Absatz, der die Frage direkt beantwortet, eine H2-Hierarchie, wo sinnvoll eine Tabelle mit thead und th scope, mindestens ein Pull Quote, zwei bis vier interne Links und Quellen am Ende. Oben ein Autorenlink sowie Veröffentlichungs- und Aktualisierungsdatum in <time>. Article (headline, image, datePublished, dateModified, author per @id auf die Person, publisher #org). Wenn du Beispielzahlen verwendest, kennzeichne sie als fiktiv.
6. iletisim.html: ContactPage. 7. kvkk.html (Datenschutzhinweis) und 404.html.
Wenn das Büro keinen Besuch empfängt, setze in site.config.js localBusiness: false; Organization plus Person genügt.
Technische Regeln. Befolge sie genau, denn die untenstehenden Gates messen genau diese:
1. Einrichtung. Führe scaffold_site zuerst als Vorschau aus, zeige mir die Dateiliste und installiere nach meiner Freigabe mit confirm=true. Lies danach site_design_guide und site_seo_guide vollständig. Schreibe, bevor du Code schreibst, die Richtung in _kaynak/ART.md (Anmutung, Schriftpaarung, Farben mit Kontrastverhältnissen, Raster, Signaturelement, Entscheidung zur Bewegung, Seitenliste) und zeige sie mir.
2. JavaScript entfernen. Keine Seite dieser Website lädt JavaScript. Entferne aus jeder Seite das Skript cdn.tailwindcss.com, die Zeile tailwind.config, die Tags für GSAP, ScrollTrigger, SplitText, Lenis und Swiper sowie die Skript-Tags motion.js, chrome.js und site.config.js; lösche assets/chrome.js und assets/motion.js. Behalte assets/site.config.js, aber nur als Quelle für Marke, Kontakt und SEO für seo-stamp.mjs; sie wird nie im Browser geladen.
3. Menü und Footer sind statisches HTML. Die Komponenten <site-nav> und <site-footer> werden von JavaScript gezeichnet, sodass Such- und KI-Crawler weder das Menü noch die internen Links oder die Kontaktdaten sehen. Schreibe den Header nach _kaynak/ust.inc und den Footer (Name, Adresse, Telefon, E-Mail, alle Seitenlinks, Datenschutzhinweis, "Web: Opus Growth") nach _kaynak/alt.inc. Verwende die Endung .inc, damit seo-stamp und html-validate die Fragmente nicht als Seiten behandeln. Jede Seite trägt die Marker <!-- ust:bas --><!-- ust:son --> und <!-- alt:bas --><!-- alt:son -->. Schreibe dann mit site_write_file ein abhängigkeitsfreies Node-Skript _kaynak/parca-bas.mjs: Es stempelt beide Fragmente zwischen die Marker in jeder HTML-Datei, setzt aria-current="page" am Menülink der aktuellen Seite und schreibt sitemap.xml neu, wobei das dateModified aus dem JSON-LD jeder Seite als lastmod dient (404 und noindex-Seiten werden übersprungen). Baue das mobile Menü ohne JavaScript mit <details><summary>Menü</summary>; Desktop- und Mobilmenü sind zwei getrennte <nav>-Elemente mit unterschiedlichen aria-label.
4. Schriften selbst hosten. Diese Seite verwendet zwei Familien und höchstens fünf Dateien; Überschrift, kursiver Vorspann und Fließtext erscheinen alle im ersten Bildschirm, also lade alle vier vor (preload). In der Demo trieb das Vorladen von nur zweien den CLS bei einem langen Artikel auf 0,24 und die mobile Performance auf 86; mit allen vier lagen CLS bei 0 und Performance bei 99. Lade das Fontshare-CSS (https://api.fontshare.com/v2/css?f[]=family@400,600&display=swap, Gewichtscode 401 für kursiv) mit site_fetch nach _kaynak/fontshare.css, lies es mit site_read_file und übernimm nur die woff2-URLs der angeforderten Familie; der Dienst hängt manchmal eine nicht angeforderte Familie an. Lade jede woff2 mit site_fetch nach assets/fonts/. Setze die @font-face-Regeln (font-display: swap) in assets/app.css, denn design-check.mjs sucht nur in dieser Datei nach einer eigenen Schrift. Verwende nicht die Standardschriften Inter, Roboto, Poppins oder Montserrat.
5. Tailwind kompilieren. assets/app.css wird zur Tailwind-Quelle: oben @tailwind base; @tailwind components; @tailwind utilities;, dann @font-face, der Fokusring, der Skip-Link, eine prefers-reduced-motion-Regel und deine eigenen Komponentenklassen in @layer components. Gib einer Komponentenklasse niemals den Namen eines Tailwind-Utilities (list-item, table, grid, container, hidden usw.), denn der Konflikt zerstört nach dem Kompilieren unbemerkt das Layout. Schreibe tailwind.config.js im Stammverzeichnis (content: ["./*.html", "./**/*.html", "./_kaynak/*.inc"], Farben und fontFamily). Führe "npx --yes tailwindcss@3 -i assets/app.css -o assets/site.css --minify" mit site_run_command und background=true aus und warte mit site_command_status darauf. Der <head> jeder Seite enthält in dieser Reihenfolge: einen einzigen <link rel="stylesheet" href="/assets/site.css">, dann je eine Preload-Zeile für jede Schriftdatei des ersten Bildschirms (Überschrift, Akzent und Fließtext; as="font" type="font/woff2" crossorigin). Preload-Zeilen vor dem Stylesheet verzögern das CSS und verlängern den LCP; eine Schrift des ersten Bildschirms ohne Preload wird spät getauscht, verschiebt die Seite und erhöht den CLS, und <link rel="icon" href="/assets/img/favicon.svg" type="image/svg+xml">. Die Favicon-Zeile ist Pflicht: Ohne sie fragt der Browser /favicon.ico an, bekommt einen 404, und der Konsolenfehler senkt Best Practices.
6. Bilder. Lade Fotos mit site_fetch mit resize und image_format="webp" in mehreren Breiten herunter (480, 800, 1200 und 1600 für das Bild im ersten Bildschirm, 480, 800 und 1200 für die übrigen; Qualität zwischen 60 und 75, niedriger bei detailreichen Fotos). Jedes <img> hat srcset, sizes passend zum tatsächlichen Layout, width und height (kein CLS) sowie einen aussagekräftigen, ehrlichen Alt-Text. fetchpriority="high" gehört nur auf das Bild, das Lighthouse als LCP-Element meldet, und dieses Bild wird nicht lazy geladen; jedes andere Bild nutzt loading="lazy". Ist das LCP-Element ein Text, bekommt kein Bild fetchpriority. Bereite außerdem assets/img/logo.png, ein assets/img/og.jpg mit 1200x630 und assets/img/favicon.svg vor.
7. HTML-Regeln (Standardwerte von html-validate). <!DOCTYPE html> in Großbuchstaben; kein Inline-Attribut style (auch nicht das style="background:var(--brand)" des Kits, verwende stattdessen eine Klasse); statt einfacher Leerzeichen im Text von tel:-Links; ein type an jedem <button>; keine nachgestellten Leerzeichen; Tabellen mit <thead>, <tbody> und th scope. Links in Absätzen sind unterstrichen; Links in Menü, Footer, Breadcrumb und Buttons haben eine Tippfläche von mindestens 44x44 Pixeln (min-h-
[44px] min-w-
[44px]).
8. Strukturierte Daten. Fülle den seo-Block in site.config.js (siteUrl, description, logo, og-Bild, Geschäftstyp, Adressfelder) und führe "node seo-stamp.mjs" mit site_run_command aus; es stempelt Organization, WebSite und gegebenenfalls einen LocalBusiness-Untertyp sowie canonical- und OG-Tags. Ergänze seitenspezifisches Schema von Hand: auf jeder Seite einen WebPage-Knoten mit @id (oder AboutPage, ContactPage, CollectionPage, ProfilePage), datePublished und dateModified, isPartOf #site, about #business oder #org und breadcrumb mit Verweis auf eine BreadcrumbList; dazu einen Service pro Leistung, Person und ProfilePage für den Autor, ItemList auf dem Ratgeber-Index und Article in jedem Ratgeber. Schreibe jeden Knoten in einen EIGENEN <script type="application/ld+json">-Block und verwende keinen @graph-Wrapper, denn seo-check.mjs liest nur den obersten @type und übersieht eine BreadcrumbList innerhalb von @graph. Verknüpfe die Knoten über @id. Erfinde niemals Öffnungszeiten, Koordinaten, Bewertungen, Rezensionen, Auszeichnungen, Kundenzahlen oder Zertifikate; lass unbekannte Felder weg.
9. KI-Zugriff. Schreibe robots.txt: die ganze Seite offen, nur /_kaynak/ gesperrt; Allow: / für GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended und Bingbot; deine Entscheidung zu CCBot mit der Begründung als Kommentar; die Sitemap-Zeile zuletzt. Lege im Stammverzeichnis eine llms.txt an: eine korrekte Zusammenfassung des Unternehmens in zwei Sätzen, die wichtigen Seiten mit je einer Zeile und die Kontaktdaten. Schreibe 404.html (noindex, mit den Markern für Header und Footer).
10. Texte. Jede Seite hat mindestens 150 Wörter Originaltext in <main>, und der erste Absatz beantwortet die Hauptfrage der Seite direkt. Titel haben 48 bis 60 Zeichen, Beschreibungen 145 bis 158, auf jeder Seite einzigartig. Keine Gedankenstriche oder Halbgeviertstriche, keine Standardfloskeln, keine leeren Versprechen. Wenn etwas auf der Seite nicht echt ist, sage klar, dass es fiktiv ist.
Gates. Führe sie nach jeder Änderung mit site_run_command in dieser Reihenfolge aus und gehe erst weiter, wenn jedes sauber ist:
1. node _kaynak/parca-bas.mjs, node seo-stamp.mjs, der Tailwind-Build (erneut, wenn du Klassen hinzugefügt hast).
2. node seo-check.mjs: 0 Fehler und 0 Warnungen. Warnt es mit "gövde kısa" (Textkörper zu kurz), ergänze echten Text, keine Füllwörter.
3. node design-check.mjs: 0 Fehler. Die einzige Warnung darf "Hiç hareket yok" (keine Bewegung) sein; das ist eine bewusste Entscheidung für das Leseerlebnis, nenne dafür im Bericht den Grund.
4. npx --yes html-validate "**/*.html": 0 Fehler.
5. Sieh dir jede Seite mit site_preview bei view="mobile" und view="desktop" an und prüfe die Startseite zusätzlich bei 360 und 768 Pixeln. Behebe horizontalen Überlauf, gedrängte Überschriften und Tippflächen unter 44 Pixeln und schau erneut hin.
6. Miss jede Seite mit core_web_vitals be
