Baue auf meinem Hosting-Server
[server name] von Grund auf eine neue Website für mein Restaurant. Angaben:
1. Name:
[business name], Art:
[restaurant / café / breakfast place], Küche:
[cuisine]
2. Speisekarte mit Rubriken, Beschreibungen und Preisen:
[menu and prices]
3. Hinweise zu vegetarischen, veganen und glutenfreien Gerichten sowie zu Allergenen:
[dietary information]
4. Öffnungszeiten (getrennt für Frühstück und Abendessen, falls sie abweichen):
[hours]
5. So nehmen wir Reservierungen an:
[phone / WhatsApp / both], Telefon:
[phone], WhatsApp:
[WhatsApp]
6. Adresse und Anfahrtshinweise:
[address],
[parking and transport]
7. Woher unsere Produkte kommen, und unsere Geschichte:
[producers and story]
8. Domain:
[domain], echte Fotos:
[where the photos are, or "use stock"]
Bestätige zuerst den Server mit list_servers und führe scaffold_site mit style="restaurant" aus, zunächst mit confirm=false und nach meiner Freigabe mit confirm=true. Lies site_design_guide und site_seo_guide. Schreibe eine natürliche, organische Designentscheidung nach _kaynak/ART.md und zeige sie mir: eine warme Serifen-Schrift für Überschriften von Fontshare (zum Beispiel Gambarino) mit einer weichen Textschrift (zum Beispiel Supreme), ein sandfarbener Hintergrund, erdtonige Texte, zwei warme Töne in Olivgrün und Terrakotta und derselbe abgerundete Radius an jeder Karte. Das Signaturelement ist ein Kasten "Heute auf der Tafel" auf der Speisekarten-Seite. Wenn die gewählte Schrift kein ₺-Zeichen hat, schreibe die Preise mit "TL".
Seiten und Schema:
1. Startseite: Der erste Bildschirm sagt, was wir servieren und wo, mit den Buttons "Tisch reservieren" und "Speisekarte ansehen" und einem großen Foto. Danach drei Gerichte aus der Speisekarte, die Herkunft der Produkte, eine Zusammenfassung von Öffnungszeiten und Standort sowie 4 FAQs. Schema: WebPage, FAQPage; ergänze im #business-Knoten servesCuisine, acceptsReservations (die URL der Reservierungsseite) und hasMenu.
2. Speisekarte: HTML, kein PDF. Jede Rubrik hat eine Überschrift und einen Ankerlink, jedes Gericht hat Namen, Beschreibung, Preis und Ernährungslabels, und oben auf der Seite stehen das Datum der letzten Aktualisierung und ein Allergenhinweis. Übernimm Preise nur aus der Liste, die ich dir gegeben habe; erfinde niemals einen fehlenden Preis. Schema: Menu mit MenuSection unter hasMenuSection, MenuItem unter hasMenuItem, Offer unter offers (price, priceCurrency TRY) und suitableForDiet, wo es zutrifft.
3. Reservierung: wie Reservierungen funktionieren, Telefon und WhatsApp, ein WhatsApp-Formular mit vorausgefüllter Nachricht (Datum, Uhrzeit, Personenzahl, Garten oder Innenraum) und 3 FAQs (verspätetes Eintreffen, große Gruppen, Stornierung). Schema: WebPage, FAQPage.
4. Unsere Geschichte und Produzenten: wer das Haus führt, von wem die Produkte kommen, und eine saisonale Tabelle, die zeigt, welche Zutat in welchen Monaten auf der Karte steht. Schema: AboutPage.
5. Standort und Öffnungszeiten: Adresse, Tabelle mit Öffnungszeiten, ein Link "Route anzeigen", Anfahrt mit dem Auto, vom Stadtzentrum und mit öffentlichen Verkehrsmitteln sowie ein Hinweis zur Barrierefreiheit. Schema: ContactPage.
6. Eine 404-Seite.
Um trotz der Fotos schnell zu bleiben: ein großes Bild im ersten Bildschirm und alle anderen Bilder lazy; WebP mit Qualität 60 bis 65 und höchstens acht Bilder pro Seite; lade keine Slider-Bibliothek für die Galerie.
Nichts erfinden: Schreibe keine Bewertungen, Sterne, Auszeichnungen, Zertifikate, Kundenzahlen oder Behauptungen wie "der Beste", die nicht echt sind. Füge keine Öffnungszeiten, Koordinaten, Preise oder E-Mail-Adressen, die ich nicht angegeben habe, in das Schema oder den Text ein; lass das Feld weg und führe es im Bericht als fehlend auf. Verwende keine Gedankenstriche und keine Standardfloskeln, und lass den ersten Absatz jeder Seite die Frage dieser Seite direkt beantworten.
Gemeinsame SEO-Arbeit: Jede Seite bekommt einen eigenen Title mit 48 bis 60 Zeichen, eine Description mit 145 bis 158 Zeichen, genau ein H1 und ein Canonical, das mit einem Schrägstrich endet. Füge für jede Seite einen eigenen WebPage-Knoten und eine BreadcrumbList hinzu, per @id mit dem Basisgraphen verknüpft. Schreibe in robots.txt Allow: / für Googlebot, Bingbot, OAI-SearchBot, ChatGPT-User, GPTBot, Claude-SearchBot, Claude-User, ClaudeBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended und CCBot, erkläre die Entscheidung in einem Kommentar und vermerke, was zu ändern ist, falls ich Trainings-Crawler blockieren möchte. Die sitemap.xml enthält echte lastmod-Daten. llms.txt beschreibt das Unternehmen in zwei Sätzen korrekt und listet NAP und die wichtigen Seiten mit Links auf.
Technische Einrichtung (der Standardweg des Toolkits wird auf dieser Website aus den folgenden Gründen nicht verwendet):
1. Tailwind kompilieren und das CDN entfernen. Das Kit lädt Tailwind über das Play-CDN, das im Browser kompiliert, eine Konsolenwarnung ausgibt und die mobile Performance senkt. Schreibe _kaynak/package.json mit site_write_file, installiere mit site_run_command("cd _kaynak && npm i -D tailwindcss@3 html-validate", background=true) und warte mit site_command_status darauf. Setze in _kaynak/tailwind.config.js content auf "./*.html", "./**/*.html", "!./_kaynak/**" und "./_kaynak/chrome.mjs". Verschiebe die @font-face-Regeln, die @tailwind-Zeilen sowie Fokusring, Skip-Link und Overflow-Schutz aus der app.css des Kits nach _kaynak/site.css. Gib die Ausgabe nach assets/app.css aus, weil design-check.mjs in dieser Datei nach Schriften sucht, und füge auf jeder Seite ?v=<content hash> an den Link an, damit der Edge-Cache nie die alte Datei ausliefert.
2. Schriften selbst hosten. Lies die CSS-URL der gewählten Fontshare-Familien (api.fontshare.com/v2/css?f[]=...) mit site_read_url, lade deren woff2-Dateien mit site_fetch nach assets/fonts/ herunter und deklariere sie mit @font-face und font-display: swap. Lade jeden oberhalb der Falz verwendeten Schnitt per <link rel="preload" as="font" type="font/woff2" crossorigin> vor, höchstens drei Dateien. Wenn du das auslässt, verschiebt der Schriftwechsel das Layout; in der Demo lag der Desktop-CLS deshalb bei 0,078 und fiel mit Preloading auf 0.
3. Menü und Footer als statisches HTML bauen. Die Komponenten <site-nav> und <site-footer> des Kits laufen über JavaScript, und die meisten KI-Crawler sehen weder die Navigation noch Adresse oder Telefonnummer. Entferne die Skripte chrome.js und motion.js von jeder Seite. Schreibe in _kaynak/chrome.mjs zwei Funktionen, die das Header- und Footer-HTML aus assets/site.config.js erzeugen; baue das mobile Menü ohne JavaScript mit <details> und <summary> und markiere die aktuelle Seite mit aria-current="page". Schreibe im Stammverzeichnis der Website eine build.mjs, die der Reihe nach node seo-stamp.mjs ausführt, auf jeder Seite alles zwischen <!-- chrome:header:start --> und <!-- chrome:header:end --> (und beim Footer entsprechend) neu einfügt, Tailwind kompiliert und den Hash am CSS-Link aktualisiert. Führe nach jeder Änderung nur site_run_command("node build.mjs") aus.
4. Bewegung nur über CSS und dezent. Setze data-reveal auf die Bildkarten und baue den Reveal mit einer CSS-Scroll-Animation (animation-timeline: view()) nur mit transform; animiere nicht opacity, denn Text, der mit Deckkraft null startet, verschwindet in Browsern ohne JavaScript und fällt bei Barrierefreiheits-Audits im Kontrastcheck durch. Fasse die Regel in @media (prefers-reduced-motion: no-preference) und @supports (animation-timeline: view()). Lade weder GSAP noch Lenis noch Swiper.
5. Bilder verkleinern. Lade jedes Foto mit site_fetch in separate Dateien herunter, mit resize="480x", "800x", "1200x", "1600x", image_format="webp" und einer Qualität zwischen 60 und 68. Gib jedem <img> srcset, sizes sowie width und height passend zum echten Seitenverhältnis; wenn du zuschneidest, füge eine Ratio-Klasse wie aspect-
[4/3] mit object-cover hinzu, sonst verschiebt sich das Layout beim Laden des Bildes. Das Bild im ersten Bildschirm bekommt fetchpriority="high" und ist nicht lazy; alle anderen bekommen loading="lazy". Lade das Social-Sharing-Bild mit site_fetch als 1200x630-JPG herunter.
6. Kleine Details, die Punkte kosten: Füge ein SVG-Favicon mit <link rel="icon"> hinzu (sonst fragt der Browser /favicon.ico an, der 404 erscheint als Konsolenfehler und Best Practices sinkt). Schreibe DOCTYPE in Großbuchstaben, verwende keine style-Attribute und lass keine Leerzeichen am Zeilenende stehen. Verwende im sichtbaren Text von Telefonlinks statt Leerzeichen (die html-validate-Regel tel-non-breaking). Links in Menü, Footer, Breadcrumb und Überschriften müssen mindestens 44 Pixel hoch und breit sein. Binde keinen Google-Maps-iframe ein; die Website soll keine externen Anfragen auslösen, zeige also die Adresse und einen Link "Route anzeigen".
7. Keine Anfrage darf die Website verlassen: Schriften, Skripte, Stile und Bilder liegen alle auf dem eigenen Server. Es gibt keinen Formular-Handler, daher ist das Kontaktformular ein method="get"-Formular, das auf https://wa.me/
[WhatsApp number] zeigt, mit einer vorausgefüllten Textarea namens "text"; JavaScript wird nicht benötigt.
Gates (in dieser Reihenfolge; nenne es erst fertig, wenn alle bestanden sind):
1. Führe node build.mjs mit site_run_command aus, dann node seo-check.mjs: 0 Fehler, 0 Warnungen. Eine Warnung zu doppeltem Inhalt bedeutet, dass zwei Seiten sich nicht genug unterscheiden; schreibe sie neu.
2. node design-check.mjs: 0 Fehler. Wenn du einen bewegungslosen Stil gewählt hast, melde die Warnung "keine Bewegung" als bewusste Entscheidung mit Begründung.
3. _kaynak/node_modules/.bin/html-validate für jede HTML-Datei: 0 Fehler. Lege im Stammverzeichnis der Website eine Datei .htmlvalidateignore mit einer Zeile _kaynak/ an, damit Abhängigkeiten nicht gescannt werden.
4. Sieh dir jede Seite mit site_preview bei view="mobile", view="desktop" und zusätzlich bei 360 und 768 Breite an. Behebe horizontales Scrollen, überlaufende Überschriften, gedrängte Buttons oder unlesbaren Text und sieh noch einmal nach.
5. Miss jede Seite mit core_web_vitals bei strategy="mobile" und strategy="desktop" und hole mit seo_audit die Werte für Barrierefreiheit, Best Practices und SEO. Das Ziel auf Mobilgeräten ist 100 für Barrierefreiheit, Best Practices und SEO und mindestens 95 für Performance; auf dem Desktop mindestens 95 in allen vier Bereichen. Führe auf einer Seite, die das Ziel verfehlt, core_web_vitals mit resources=true aus, finde das LCP-Element und jedes überdimensionierte Bild, behebe es und wiederhole seo_audit mit runs=2, denn ein einzelner Labormesslauf kann schwanken.
6. Die Netzwerkanfragen dürfen keine Adresse außerhalb der eigenen Domain der Website enthalten.
Nach der Veröffentlichung: Reiche sitemap.xml mit gsc_submit_sitemap ein und prüfe die Startseite sowie die drei wichtigsten Seiten mit gsc_inspect_urls. Kein Tool kann "Indexierung beantragen" drücken; liste auf, was ich in der Search Console von Hand beantragen muss.
Schließe mit diesem Bericht ab: die Seitenliste mit den Mobil- und Desktop-Werten pro Seite in einer Tabelle (Performance, Barrierefreiheit, Best Practices, SEO, LCP, CLS), das Ergebnis jedes Gates, die vorgenommenen Korrekturen und die Informationen, die du noch von mir brauchst. Wenn ein Ziel verfehlt wurde, sage das klar, statt es als fertig zu bezeichnen.
