Baue auf meinem Hosting-Server
[Servername] eine komplett neue Website für mein Unternehmen. Angaben:
1. Firmenname:
[Firmenname], Gewerk:
[Installateur / Schlüsseldienst / Klimaservice / anderes]
2. Name des Unternehmensprofils oder Domain:
[Name des Unternehmensprofils]
3. Leistungen (jede bekommt eine eigene Seite):
[Leistungen]
4. Stadtteile bzw. Bezirke, die ich bediene, und Standort meiner Werkstatt:
[Bezirke],
[Standort der Werkstatt]
5. Telefon:
[Telefon], WhatsApp:
[WhatsApp], Adresse:
[Adresse, oder "Ich blende meine Adresse aus"], Öffnungszeiten:
[Öffnungszeiten]
6. Domain:
[Domain], Farbwunsch:
[Farbwunsch], echte Fotos:
[Ablageort der Fotos, oder "keine"]
7. Arbeiten, die ich nicht anbiete:
[nicht angebotene Leistungen]
Lies zuerst den Eintrag
[Name des Unternehmensprofils] mit gbp_location_details aus. Vergleiche Name, Telefon, Adresse, Website, Öffnungszeiten, Hauptkategorie, Leistungen und Kartenlink mit meinen Angaben in einer einzigen Tabelle. Wo es Abweichungen gibt, frag mich, was stimmt; ändere nichts am Unternehmensprofil. Verwende auf der Website Name, Adresse und Telefonnummer exakt so, wie sie im Unternehmensprofil stehen. Wenn der Eintrag die Adresse ausblendet, zeige auf der Website keine Straßenadresse und nenne nur die Einsatzgebiete. Nimm Koordinaten nur aus dem Kartenmarker des Eintrags, rate sie nie. Wähle den LocalBusiness-Untertyp im Schema anhand der Hauptkategorie (Plumber, Locksmith, HVACBusiness, Electrician usw.).
Bestätige dann den Server mit list_servers, rufe zuerst scaffold_site mit style="service" und confirm=false auf, um zu zeigen, was überschrieben wird, und führe es nach meiner Freigabe mit confirm=true aus. Lies site_design_guide und site_seo_guide. Schreibe vor dem Coden die Designentscheidung nach _kaynak/ART.md und zeige sie mir: ein minimalistisches Schweizer Layout, eine kräftige Grotesk als Display-Schrift von Fontshare (zum Beispiel Cabinet Grotesk 800) mit einer schlichten Textschrift (zum Beispiel General Sans 400 und 600), ein gebrochen weißer Hintergrund, dunkelblaue Schrift, eine Signalfarbe mit mindestens 4,5:1 Kontrast zu weißem Text und ein separates WhatsApp-Grün. Das Erkennungsmerkmal sind zwei große Buttons, die am Handy unten am Bildschirm fixiert sind: "Jetzt anrufen" und "Per WhatsApp schreiben".
Seiten und Schema:
1. Startseite: Der erste Bildschirm sagt in einem Satz, was du tust und welche Bezirke du abdeckst, mit Anruf- und WhatsApp-Button und Öffnungszeiten. Danach Leistungskarten, Bezirkskarten, die Schritte eines Einsatzes und eine FAQ mit 4 Fragen. Schema: WebPage, FAQPage.
2. Eine Leistungsübersicht und je Leistung eine eigene Seite: Der erste Absatz beantwortet direkt "Was machst du und wie"; danach Symptome, die Schritte vor Ort, wann es ein Notfall ist, wie der Preis zustande kommt (ohne Zahlen zu erfinden), 3 seitenspezifische FAQs, Autor und Datum. Schema: Service (provider #business, areaServed die Bezirke), FAQPage.
3. Pro Bezirk eine Gebietsseite. Diese dürfen KEINE Kopien mit ausgetauschtem Städtenamen sein. Jede enthält die Stadtteilnamen dieses Bezirks, die dort häufigsten Störungen vor dem Hintergrund des örtlichen Gebäudebestands (eine Tabelle, deren Zeilen sich von Bezirk zu Bezirk unterscheiden), einen Hinweis zu Anfahrt und Parken, die Entfernung von der Werkstatt, zwei FAQs speziell zu diesem Bezirk und Links zu den anderen Gebieten. Schreibe mindestens 300 Wörter Originaltext; wenn der Duplikat-Scan von seo-check mehr als 50 Prozent Überschneidung zwischen zwei Gebietsseiten findet, schreibe sie neu. Lege keine Seite für einen Bezirk an, den ich nicht wirklich bediene. Schema: AdministrativeArea (containedInPlace die Provinz bzw. der Landkreis, containsPlace die Stadtteile), Service, FAQPage.
4. Über uns: Wer du bist, wie du arbeitest, mit welcher Ausrüstung und welche Aufträge du nicht annimmst. Schema: AboutPage, und Person, wenn ich dir einen echten Namen gegeben habe.
5. Kontakt: NAP, Öffnungszeiten, ein Link "Route anzeigen" und das WhatsApp-Formular. Schema: ContactPage mit mainEntity #business.
6. Eine Seite für die Datenschutzerklärung und eine 404-Seite.
Nichts erfinden: Schreibe keine Bewertungen, Sterne, Auszeichnungen, Zertifikate, Kundenzahlen oder Behauptungen wie "der Beste", die nicht echt sind. Nimm keine Öffnungszeiten, Koordinaten, Preise oder E-Mail-Adressen in Schema oder Text auf, die ich dir nicht gegeben habe; lass das Feld weg und führe es im Bericht als fehlend auf. Verwende keine langen Gedankenstriche und keine Standard-Slogans, und lass den ersten Absatz jeder Seite die Frage dieser Seite direkt beantworten.
Gemeinsame SEO-Arbeit: Jede Seite bekommt einen eindeutigen Title mit 48 bis 60 Zeichen, eine Description mit 145 bis 158 Zeichen, genau eine H1 und einen Canonical, der 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, wenn ich Trainings-Crawler blockieren möchte. sitemap.xml enthält echte lastmod-Daten. llms.txt beschreibt das Unternehmen in zwei Sätzen korrekt und listet NAP sowie die wichtigen Seiten mit Links auf.
Technische Umsetzung (der Standardweg des Toolkits wird auf dieser Website aus folgenden Gründen nicht genutzt):
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, weil design-check.mjs in dieser Datei nach Schriften sucht, und hänge auf jeder Seite ?v=<Inhalts-Hash> an den Link, 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 jede Schriftstärke, die im sichtbaren Bereich ohne Scrollen verwendet wird, per <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 am Desktop deshalb bei 0,078 und fiel mit Preloading auf 0.
3. Menü und Footer als statisches HTML. Die Komponenten <site-nav> und <site-footer> des Kits laufen mit JavaScript, und die meisten KI-Crawler sehen weder Menü noch Adresse noch Telefonnummer. Entferne die Skripte chrome.js und motion.js von jeder Seite. Schreibe in _kaynak/chrome.mjs zwei Funktionen, die Header- und Footer-HTML aus assets/site.config.js erzeugen; baue das mobile Menü ohne JavaScript mit <details> und <summary> und kennzeichne 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. Keine Bewegung. Lade auf dieser Website weder GSAP noch Lenis, Swiper oder irgendein Animationsskript; Besucher kommen mit dem Handy, um schnell anzurufen oder zu schreiben.
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. Versieh jedes <img> mit 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 beim Laden des Bildes. Das Bild im sichtbaren Bereich ohne Scrollen bekommt fetchpriority="high" und wird nicht lazy geladen; alle anderen bekommen loading="lazy". Lade das Vorschaubild für Social Media als 1200x630-JPG mit site_fetch herunter.
6. Kleinigkeiten, die Punkte kosten: Füge ein SVG-Favicon mit <link rel="icon"> hinzu (sonst fragt der Browser /favicon.ico an, das 404 erscheint als Konsolenfehler und Best Practices fällt ab). Schreibe DOCTYPE in Großbuchstaben, verwende keine style-Attribute und lass keine Leerzeichen am Zeilenende. Verwende im sichtbaren Text von Telefonlinks statt normaler 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 stellen, zeige stattdessen die Adresse und einen Link "Route anzeigen".
7. Keine Anfrage darf die Website verlassen: Schriften, Skripte, Styles 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 gebraucht.
Prüfschritte (in dieser Reihenfolge; nicht als fertig melden, bevor 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 Duplicate Content bedeutet, dass sich zwei Seiten 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 auf jeder HTML-Datei: 0 Fehler. Lege im Stammverzeichnis der Website eine .htmlvalidateignore mit einer Zeile _kaynak/ an, damit Abhängigkeiten nicht gescannt werden.
4. NAP-Prüfung: Zeige in einer Tabelle, dass Name, Adresse und Telefonnummer auf der Website Buchstabe für Buchstabe mit der Ausgabe von gbp_location_details übereinstimmen.
5. Sieh dir jede Seite mit site_preview bei view="mobile", view="desktop" sowie bei 360 und 768 Breite an. Behebe horizontales Scrollen, überlaufende Überschriften, gedrängte Buttons oder unlesbaren Text und schau erneut hin.
6. Miss jede Seite mit core_web_vitals bei strategy="mobile" und strategy="desktop" und hole Barrierefreiheit, Best Practices und SEO mit seo_audit. Das Ziel am Handy ist 100 für Barrierefreiheit, Best Practices und SEO und mindestens 95 für Performance; am Desktop mindestens 95 in allen vier Werten. Führe bei 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, weil ein einzelner Lab-Lauf schwanken kann.
7. 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 von Hand in der Search Console beantragen muss.
Schließe mit diesem Bericht ab: die Seitenliste mit den Handy- und Desktop-Werten pro Seite in einer Tabelle (Performance, Barrierefreiheit, Best Practices, SEO, LCP, CLS), das Ergebnis jedes Prüfschritts, die von dir vorgenommenen Korrekturen und die Informationen, die du noch von mir brauchst. Wenn ein Ziel verfehlt wurde, sag das offen, statt
