Baue für mein Unternehmen auf meinem Opus Growth Hosting-Server
[server name] eine mehrseitige, vollständig statische Unternehmenswebsite. Unternehmen:
[business name],
[sector, e.g. engineering and architecture practice],
[city/service area]. Leistungen:
[services with a short description each]. Telefon:
[phone], E-Mail:
[email], Adresse:
[address], Domain:
[domain]. Farbwunsch:
[colour/brand preference, or "your choice"]. Fotos: [where the real photos are, or "use suitable stock photos"].
Diese Website stellt Geschwindigkeit und Barrierefreiheit an die erste Stelle. Keine einzige Zeile JavaScript auf irgendeiner Seite; GSAP, Lenis und Swiper werden nie geladen. Alles, auch das Menü, das mobile Menü und die FAQ, funktioniert mit HTML und CSS.
Die Designrichtung lautet "technisches Zeichenblatt":
1. Typografie: eine enge Grotesk für Überschriften von Fontshare (z. B. Cabinet Grotesk 800) und eine ruhige Fließtextschrift (z. B. General Sans 400 und 600). Höchstens drei Schriftdateien.
2. Farbe: ein heller Papierton als Hintergrund, dunkle Tintenfarbe für den Text, ein sekundäres Grau und eine Signalfarbe als Akzent. Der Akzent erscheint nur bei Labels, dünnen Linien und dem Haupt-Button. Jede Textfarbe erreicht mindestens 4,5:1 Kontrast.
3. Raster: 12 Spalten, Abschnitte durch 1-Pixel-Linien getrennt; keine Schatten, abgerundeten Ecken oder Verläufe.
4. Signaturelement: unter dem Bild im ersten Bildschirmbereich ein vierzelliger Streifen im Stil des Schriftfelds einer Architekturzeichnung (z. B. Projektart, angewandte Norm, Maßstab, Blattnummer) sowie ein sehr feines Millimeterraster, das nur mit CSS hinter dem ersten Bildschirmbereich gezeichnet wird.
5. Bewegung: keine. Auch keine Transition-Dauern; nur Unterstreichung und Farbe wechseln beim Hover sofort.
Seiten und ihr Schema:
1. index.html: ein erster Bildschirmbereich, dessen Einleitungsabsatz direkt beantwortet "Was macht ihr, für wen, wo", drei Leistungskarten (jede verlinkt auf ihren Abschnitt), ein vierstufiger Ablauf (nummeriert mit "Schritt 1" über einen CSS-Counter, nicht 01/02), zwei Projektbeispiele, ein Telefonband. WebPage.
2. hizmetler.html: ein Abschnitt pro Leistung; der erste Absatz beantwortet "Wann wird sie gebraucht, was bewirkt sie", danach eine Liste des Leistungsumfangs, die typische Dauer und die Ergebnisse. WebPage plus ein Service pro Leistung (provider #business, areaServed).
3. projeler.html: Beispiele mit Gebäudetyp, Vorgehen und Ergebnis; Kundennamen nur mit Erlaubnis. CollectionPage.
4. hakkimizda.html: wer wir sind, unsere Arbeitsgrundsätze, wo wir arbeiten. AboutPage.
5. sss.html: mindestens sechs echte Fragen in <details>. WebPage und FAQPage.
6. iletisim.html: Telefon, E-Mail und Adresse in <address>, ein Kartenlink; Öffnungszeiten weglassen, wenn sie nicht bekannt sind. ContactPage mit mainEntity #business.
7. kvkk.html (Datenschutzhinweis) und 404.html.
Technische Regeln. Halte sie genau ein, denn die unten genannten Prüfungen messen genau diese:
1. Einrichtung. Führe zuerst scaffold_site 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. Bevor du Code schreibst, halte die Richtung in _kaynak/ART.md fest (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 von jeder Seite das Skript cdn.tailwindcss.com, die Zeile tailwind.config, die Tags für GSAP, ScrollTrigger, SplitText, Lenis und Swiper sowie die Script-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 per 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 unter _kaynak/parca-bas.mjs: Es stempelt beide Fragmente zwischen die Marker in jeder HTML-Datei, setzt aria-current="page" auf den 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>Menu</summary>; Desktop- und mobiles Menü sind zwei getrennte <nav>-Elemente mit unterschiedlichen aria-label.
4. Schriften selbst hosten. Diese Website verwendet höchstens drei Schriftdateien. 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 gewünschten Familie; der Dienst hängt manchmal eine Familie an, die du nicht angefragt hast. Lade jede woff2 mit site_fetch nach assets/fonts/. Lege die @font-face-Regeln (font-display: swap) in assets/app.css ab, 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;, danach @font-face, der Fokusring, der Skip-Link, eine prefers-reduced-motion-Regel und deine eigenen Komponentenklassen in @layer components. Gib einer Komponentenklasse nie den Namen eines Tailwind-Utilitys (list-item, table, grid, container, hidden und so weiter), denn der Konflikt zerstört nach dem Kompilieren still das Layout. Schreibe tailwind.config.js ins 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: genau ein <link rel="stylesheet" href="/assets/site.css">, dann eine Preload-Zeile für jede Schriftdatei, die im ersten Bildschirmbereich verwendet wird (Überschrift, Akzent und Fließtext; as="font" type="font/woff2" crossorigin). Preload-Zeilen vor dem Stylesheet verzögern das CSS und verlängern LCP; eine Schrift im ersten Bildschirmbereich ohne Preload wird spät getauscht, verschiebt die Seite und erhöht 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, erhält ein 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 Bildschirmbereich, 480, 800 und 1200 für alle anderen; Qualität zwischen 60 und 75, niedriger bei detailreichen Fotos). Jedes <img> hat srcset, sizes passend zum tatsächlichen Layout, width und height (null CLS) und einen aussagekräftigen, ehrlichen Alt-Text. fetchpriority="high" kommt nur auf das Bild, das Lighthouse als LCP-Element meldet, und dieses Bild ist nicht lazy; alle anderen Bilder verwenden loading="lazy". Ist das LCP-Element Text, bekommt kein Bild fetchpriority. Bereite außerdem assets/img/logo.png, ein assets/img/og.jpg im Format 1200x630 und assets/img/favicon.svg vor.
7. HTML-Regeln (html-validate-Standards). <!DOCTYPE html> in Großbuchstaben; kein Inline-style-Attribut (auch nicht das style="background:var(--brand)" des Kits, verwende stattdessen eine Klasse); statt normaler Leerzeichen im Text von tel:-Links; ein type bei 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 Touch-Flä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, Unternehmenstyp, Adressfelder) und führe "node seo-stamp.mjs" mit site_run_command aus; es stempelt Organization, WebSite und, wo passend, 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 ein Service pro Leistung auf der Leistungsseite und FAQPage auf der FAQ-Seite. 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 gesamte Website 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 llms.txt im Stammverzeichnis 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 direkt die Hauptfrage der Seite. 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 Website nicht echt ist, sage klar, dass es fiktiv ist.
Prüfungen. Führe sie nach jeder Änderung in dieser Reihenfolge mit site_run_command aus und gehe erst weiter, wenn jede sauber durchläuft:
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 zulässige Warnung ist "Hiç hareket yok" (keine Bewegung); das ist die bewusste Entscheidung dieser Website, nenne also 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 oder Touch-Flächen unter 44 Pixeln und sieh noch einmal hin.
6. Miss jede Seite mit core_web_vitals bei strategy="mobile" und strategy="desktop" und prüfe dann die Startseite und die längste Seite mit seo_audit. Ziel: mobil Accessibility, Best Practices und SEO 100 und Performance mindestens 95; auf dem Desktop alle vier mindestens 95. Keine einzige Anfrage darf die Website verlassen. Ist LCP hoch, finde mit resources=true die bremsende Datei: meist Preload-Zeilen vor dem Stylesheet oder ein fetchpriority auf einem Bild, das nicht das LCP-Element ist. Liegt CLS über 0,1, suche nach einer Schrift im ersten Bildschirmbereich ohne Preload.
Melde die Arbeit erst als erledigt, wenn alles davon bestanden ist.
Sende nach der Veröffentlichung https://
[domain]/site
