Vor dem Senden ausfüllen
[Servername][Hotel / Wohnprojekt][Name des Betriebs oder Projekts][Standort][Boutiquehotel / Wohnprojekt][Zimmerdetails][Details zu den Einheiten][Telefon][WhatsApp][E-Mail][Adresse][Domain]
Erstelle auf meinem Hosting-Server [Servername] eine türkische und englische Website für mein [Hotel / Wohnprojekt]. Angaben:
1. Name: [Name des Betriebs oder Projekts], Lage: [Standort], Typ: [Boutiquehotel / Wohnprojekt]
2. Bei einem Hotel die Zimmertypen (Größe, Bett, Gäste, Aussicht, Ausstattung), Check-in- und Check-out-Zeiten, Saison und Hausregeln: [Zimmerdetails]
3. Bei einem Projekt die Einheitentypen (Zimmer, Quadratmeter, Etage, Übergabetermin) und die Angaben zum Verkaufsbüro: [Details zu den Einheiten]
4. Telefon: [Telefon], WhatsApp: [WhatsApp], E-Mail: [E-Mail], Adresse: [Adresse]
5. Domain: [Domain], echte Fotos: [wo die Fotos liegen, oder "Stockfotos verwenden"]
6. Wer die englischen Texte prüft: [Person, oder "niemand"]
Bestätige zuerst den Server mit list_servers und führe scaffold_site mit style="universal" aus, zunächst mit confirm=false und nach meiner Freigabe mit confirm=true. Lies site_design_guide und site_seo_guide. Schreibe eine luxuriöse, warme Designentscheidung in _kaynak/ART.md und zeige sie mir: eine feine Serifen-Schrift für Überschriften von Fontshare (zum Beispiel Boska 300) mit einer schlichten Textschrift (zum Beispiel Synonym), dunkle Kaffee- und Leinentöne, ein Kupfer-Akzent, kleine, weit gesperrte Labels und vollflächige Fotografie. Das Signaturelement ist das vollflächige erste Bild auf der Startseite und sein sanfter Parallax. Lege keinen transparenten Header über das Foto; auf hellen Seiten verschwindet der helle Menütext (in der Demo sank dadurch die Barrierefreiheit auf der Zimmer- und der Kontaktseite auf 95). Gib der Leiste einen dunklen Hintergrund.
Sprachstruktur:
1. Türkische Seiten liegen im Stammverzeichnis, ihre englischen Pendants unter /en/. Jede türkische Seite hat ein englisches Pendant, und beide verweisen aufeinander. Führe die Seitenpaare in einer Liste in assets/site.config.js und erzeuge Menü, Footer und Sprachumschalter daraus; der Umschalter führt immer zum Pendant der jeweiligen Seite, nie zur Startseite.
2. Das <head> jeder Seite enthält hreflang="tr", hreflang="en" und hreflang="x-default", die auf die türkische Seite zeigen, jeweils als absolute URLs; schreibe dieselben Paare als xhtml:link-Einträge in die sitemap.xml.
3. Englische Seiten verwenden <html lang="en">, einen englischen Title, eine englische Description und einen englischen Breadcrumb sowie WebPage inLanguage "en". seo-stamp.mjs stempelt auf jeder Seite og:locale tr_TR; ändere das in build.mjs nach dem Stempeln auf englischen Seiten in en_GB und füge og:locale:alternate in beiden Sprachen hinzu.
4. Schreibe das Englisch wie ein Muttersprachler, nicht wie eine Übersetzung, und behalte Ortsnamen in ihrer türkischen Schreibweise.
Seiten und Schema (jeweils in beiden Sprachen):
1. Startseite: vollflächiges erstes Bild, in einem Absatz, was der Ort ist, kurze Fakten (Zimmerzahl, Check-in, Check-out, Saison), Zimmerkarten und ein Link zum lokalen Guide. Schema: WebPage, und am Business-Knoten der Typ Hotel mit checkinTime, checkoutTime, numberOfRooms, amenityFeature und den Zimmern unter containsPlace. Bei einem Wohnprojekt stattdessen Residence oder ApartmentComplex verwenden.
2. Eine Zimmerübersicht und je eine Seite pro Zimmertyp: Größe, Bett, Gästezahl, Ausstattung, für wen es sich eignet, und ein Link zum anderen Zimmertyp. Schema: HotelRoom (bed, occupancy, floorSize, amenityFeature, containedInPlace #business). Bei einem Wohnprojekt je Einheitentyp ein RealEstateListing mit einem Apartment darin (numberOfRooms, floorSize). Wenn ich keine Preise angegeben habe, schreibe keine offers und sage im Text: "Senden Sie uns Ihre Reisedaten, und wir nennen Ihnen den Preis dafür."
3. Lokaler Guide: Ortskenntnis mit Datum der letzten Aktualisierung. Schema: WebPage.
4. Kontakt und Buchung: Telefon, WhatsApp-Formular, E-Mail, Adresse, "Route anzeigen", Anreisehinweise und Buchungsbedingungen. Schema: ContactPage.
5. Eine 404-Seite (kurz, in beiden Sprachen).
Behaupte keine Sternekategorie, keine Auszeichnungen, keine Gästebewertungen und kein "das Beste"; füge weder starRating noch aggregateRating hinzu.
So öffnen große Fotos schnell: Liefere das erste Bild mit <picture> aus; auf Bildschirmen bis 767 Pixel verwende einen Hochformat-Zuschnitt in 600 und 900 Pixel Breite (an der Quelladresse zugeschnitten und mit site_fetch geladen), auf breiteren Bildschirmen die Querformat-Version in 1200, 1600 und 2000 Pixel. Ohne den Hochformat-Zuschnitt wird das Querformat auf dem Handy auf die Bildschirmfläche hochskaliert, sodass es entweder unscharf aussieht oder unnötig viele Daten lädt.
Nichts erfinden: Schreibe keine Bewertungen, Ratings, Auszeichnungen, Zertifikate, Kundenzahlen oder Behauptungen wie "das Beste", die nicht der Wahrheit entsprechen. Füge keine Öffnungszeiten, Koordinaten, Preise oder E-Mail-Adressen, die ich nicht genannt habe, in Schema oder Text ein; lasse das Feld weg und führe es im Bericht als fehlend auf. Verwende keine langen Gedankenstriche und keine Standardfloskeln, und lasse den ersten Absatz jeder Seite direkt die Frage dieser Seite beantworten.
Gemeinsame SEO-Arbeit: Jede Seite bekommt einen einzigartigen Title mit 48 bis 60 Zeichen, eine Description mit 145 bis 158 Zeichen, genau eine H1 und einen Canonical, der auf einen 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 notiere, was zu ändern ist, falls ich Trainings-Crawler blockieren möchte. Die sitemap.xml enthält echte lastmod-Daten. llms.txt beschreibt den Betrieb in zwei Sätzen korrekt und listet NAP-Daten und die wichtigen Seiten mit Links auf.
Technische Einrichtung (der Standardweg des Toolkits wird auf dieser Website aus folgenden Gründen nicht verwendet):
1. Tailwind kompilieren und das CDN weglassen. 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, da design-check.mjs in dieser Datei nach Schriften sucht, und hänge an den Link auf jeder Seite ?v=<Inhaltshash>, 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/ und deklariere sie mit @font-face und font-display: swap. Lade jede oberhalb des Falzes verwendete Schriftstärke mit <link rel="preload" as="font" type="font/woff2" crossorigin> vor, höchstens drei Dateien. Ohne das verschiebt der Schriftwechsel das Layout; in der Demo lag der CLS auf dem Desktop deshalb bei 0,078 und sank durch das Vorladen 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 das Menü, die Adresse und die Telefonnummer nie. 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 entsprechend für den Footer) neu stempelt, Tailwind kompiliert und den Hash am CSS-Link aktualisiert. Führe nach jeder Änderung nur site_run_command("node build.mjs") aus.
4. Parallax ohne JavaScript. Versieh das erste Bild mit data-parallax und bewege es langsam per CSS-Scroll-Animation (animation-timeline: scroll(root)) ausschließlich über transform; gib Abschnitten einen data-reveal-Einblendeffekt, der ebenfalls nur transform nutzt, niemals opacity. Fasse die Regeln in @media (prefers-reduced-motion: no-preference) und @supports (animation-timeline: scroll()) ein; bei reduzierter Bewegung oder in einem Browser ohne Unterstützung bleibt das Bild ruhig. 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 springt das Layout, wenn das Bild lädt. Das Bild im ersten Bildschirmbereich erhält fetchpriority="high" und wird nicht lazy geladen; alle anderen erhalten loading="lazy". Lade das Vorschaubild für das Teilen als 1200x630-JPG mit site_fetch herunter.
6. Kleine Details, die Punkte kosten: Füge ein SVG-Favicon mit <link rel="icon"> hinzu (sonst fragt der Browser /favicon.ico an, die 404 erscheint als Konsolenfehler und Best Practices sinkt). Schreibe DOCTYPE in Großbuchstaben, verwende keine style-Attribute und lasse keine nachgestellten Leerzeichen stehen. Verwende statt Leerzeichen im sichtbaren Text von Telefonlinks (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 stellen, zeige stattdessen 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-Nummer] zeigt, mit einem vorausgefüllten Textarea namens "text"; JavaScript wird nicht benötigt.
Prüfschritte (in dieser Reihenfolge; melde erst Vollzug, 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 wegen doppelter Inhalte bedeutet, dass sich zwei Seiten nicht genug unterscheiden; schreibe sie um.
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 auf jeder HTML-Datei: 0 Fehler. Lege im Stammverzeichnis der Website eine Datei .htmlvalidateignore mit einer Zeile _kaynak/ an, damit Abhängigkeiten nicht geprüft werden.
4. Sprachprüfung: Zeige in einer Tabelle, dass das hreflang-Pendant jeder Seite existiert, 200 zurückgibt und zurückverweist; seo-check darf keine hreflang-Warnung ausgeben.
5. 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, beengte Buttons oder unleserlichen Text und prüfe erneut.
6. 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 bei Barrierefreiheit, Best Practices und SEO sowie mindestens 95 bei Performance; auf dem Desktop mindestens 95 in allen vier. Führe bei einer Seite, die das Ziel verfehlt, core_web_vitals mit resources=true aus, finde das LCP-Element und jedes überdimensionierte B