Vom Ein-Datei-KI-Entwurf zur Produktionsseite, live in neun Tagen

Wie ESGready den KI-generierten Website-Entwurf des Gründers in eine schnelle, KI-auffindbare Produktionsseite verwandelte.

Der Kunde

Die ESGready GmbH berät deutsche Mittelstandsunternehmen bei Nachhaltigkeit und ESG-Transformation, gegründet etwa 18 Monate vor diesem Projekt. Sie verkauft "Transformation as a Service": feste Leistungspakete statt offener Beratung, geführt von Gründer und Geschäftsführer Frank Siebke.

ESGready gewinnt Aufträge über Direktansprache und Konferenzvorträge, und wurde im August 2026 auch in Fachartikeln unter seiner neuen Positionierung genannt. Damit wurde die öffentliche Website zu einem akuten Problem, nicht zu einer Nebensache.

Die Ausgangslage

Die bisherige Seite war ein unfertiger WordPress-Aufbau, nie live gegangen. Sie war kaum beworben und weder bei Google noch bei KI-Systemen auffindbar, der Traffic praktisch bei null. In der Praxis startete ESGready bei null. Frank nannte die Seite "eine Katastrophe."

Ein Live-Audit fand konkrete Probleme: rund 91 % von 45 Bildern hatten keinen Alt-Text, es gab keine strukturierten Daten für Organisation oder Leistungen, kein Social-Preview-Bild (geteilte Links zeigten ein Favicon oder einen zufälligen Ausschnitt), das kanonische Tag der Startseite zeigte auf /home/ statt auf /, und über die Jahre hatten sich rund 20 nahezu identische Buchungs-URLs angesammelt. 17 von 29 Überschriften auf der Startseite waren eigentlich Slider-Bildunterschriften, die als Überschriften ausgezeichnet waren, was die Struktur verzerrt, auf die sich Screenreader und Suchcrawler verlassen.

Frank hatte bereits selbst einen Redesign-Entwurf erstellt, generiert in einem einzigen KI-Prompt, dazu einen KI-geschriebenen Migrationsplan. Er räumte offen ein, dass beide Fehler enthielten. Der Entwurf war eine einzelne, Hash-geroutete JavaScript-Datei: Ihr Inhalt erschien erst, nachdem Skripte gelaufen waren, sodass Google und KI-Antwortsysteme eine leere Seite sahen. Diese Datei in eine funktionierende Website zu verwandeln, sagte er später, hätte sonst "einen Psychiater gebraucht."

Warum jetzt gehandelt wurde

Zwei Auslöser trafen zusammen: die öffentlichen Nennungen unter der neuen Positionierung, und ein Entwurf, der die gewünschte Richtung zeigte, aber nicht produktionsreif war. Der begrenzende Faktor war die Zeit. ESGready hatte ein Webinar vor sich, und jeder Tag auf der alten Seite kostete Glaubwürdigkeit.

Nach einem früheren Website-Projekt, das nie fertig wurde, war Verlässlichkeit ein Entscheidungskriterium, keine Selbstverständlichkeit: Frank legte Wert darauf, dass Calls pünktlich begannen und täglich Updates kamen. Er wollte Hosting, DNS oder WordPress nicht selbst anfassen und wollte eine direkt programmierte statische Seite, keinen weiteren WordPress-Aufbau. Frank sah die Website als Vertrauensbeweis, der die anderen Kanäle glaubwürdig macht, und wollte, dass sie von ChatGPT und Perplexity zitiert wird, nicht nur bei Google gerankt.

Ziele & Erfolgskriterien

1. 1Ein Vertrauensbeweis, der die Direktansprache und Vorträge glaubwürdig macht.
2. 2Gefunden und zitiert von KI-Suchsystemen, nicht nur bei Google gerankt — crawlbares HTML plus strukturierte Daten.
3. 3Schnell live: innerhalb der Webinar-Woche.

Der Umfang war die öffentliche Website. Ein Kundenportal war für diese Phase außen vor, aber der Technik-Stack wurde so gewählt, dass das Portal darauf aufbauen kann. Der Preis war für den gesamten Umfang fest, voll live.

Was gemacht wurde

Aus der Ein-Datei-Vorlage wurden 23 eigenständige, crawlbare Seiten, wobei Kostenrechner, Paket-Selbsttest und Pflichten-Radar als funktionierende Features erhalten blieben. Nach einem ersten Durchgang in reinem HTML wechselte die Seite zu Astro 5 auf Cloudflare Workers, Inhalte in Git verwaltet und über Keystatic bearbeitet, Deploys automatisch aus GitHub mit Ein-Klick-Rollback. Strukturierte Daten für Organisation, Artikel und FAQ sowie gebrandete Vorschau-Tags kamen auf jede Seite: die konkrete Grundlage für KI-Suchsichtbarkeit, die der alten Seite fehlte.

Das Stylesheet wurde von 149 KB auf 23 KB gekürzt, Header, Navigation und Footer aus 23 Kopien in eine gemeinsame Quelle zusammengeführt. WCAG-AA-Kontrast wurde mit der tatsächlichen Formel geprüft (dabei wurde ein echter Bug gefunden: fast unsichtbarer Footer-Text), falsch ausgezeichnete Überschriften wurden korrigiert, ein Tastatur-Fokusindikator hinzugefügt, und mehrere Interaktions-Bugs gefunden und behoben. Die Domain wurde umgestellt, 21 alte WordPress-URLs auf ihre neuen Entsprechungen umgeleitet, www auf die Root-Domain gelenkt, die E-Mail-Zustellbarkeit erneut geprüft und die Google Search Console verbunden.

Die Seite ging innerhalb des vereinbarten Zeitfensters live, vor dem Webinar. Der Ausbau endete dort nicht: In der folgenden Woche wurde die CMS-Ebene richtig aufgebaut — Keystatic wurde für jeden Inhaltstyp der Seite verdrahtet, sodass Frank keinen Entwickler-only-Workflow behielt, sondern ein CMS, in das er anschließend eingearbeitet wurde. Ein zweiter Lead-Generierungs-Flow kam neben dem Kontaktformular dazu: ein Flyer-Download hinter einem kurzen Modal, der in dieselbe Lead-Pipeline fließt und vollständig ohne Code editierbar ist. Ein Produktionsvorfall trat auf und wurde im selben Zeitfenster gelöst: eine Routing-Eigenheit der Hosting-Plattform legte eine neue Route für echte Besucher lahm, und der erste Fix-Versuch legte kurz auch das Kontaktformular lahm, bevor die Ursache gefunden und behoben wurde. Code-, Sicherheits- und Architektur-Reviews liefen durchgehend, nicht erst am Ende in einem einmaligen Durchgang.

Ergebnisse

Der Ausgangspunkt war nahezu null: kein nennenswerter Traffic, nichts indexiert, keine Bewerbung. Die Ergebnisse betreffen also das Fundament, das jetzt existiert, nicht einen Zahlensprung. Geliefert, und live innerhalb des vereinbarten Zeitfensters zum Festpreis.

Technische Basis

Lighthouse — mobil, Slow-4G-Drosselung

¹ Gemessen über einen archivierten Snapshot, da die Live-Domain inzwischen auf die neue Seite zeigt; die Ladezeit-Werte enthalten Archivierungs-Overhead und sind vermutlich schlechter als die echte alte Seite. Barrierefreiheit, Best Practices und SEO-Werte basieren auf Markup und sind direkter vergleichbar.

Betrieb & Kosten

• Automatische Deploy-Pipeline: eine Änderung ist in Minuten live, mit Preview-URL und Ein-Klick-Rollback.
• Hosting-Kosten nahe null bei dieser Größe, gegenüber €10/Monat beim alten Hosting-Plan. Kein Server zu patchen, keine Plugins abzusichern, kein Login anzugreifen.
• Eine Infrastruktur, auf der ein künftiges Kundenportal aufbauen kann, und ein Muster für Content-Wiederverwendung (Testimonials, FAQ) bereits vorhanden.
• Ein CMS, das jeden Inhaltstyp der Seite abdeckt, mit Frank eingearbeitet, um es selbst zu bedienen, kein Entwickler für routinemäßige Inhaltsänderungen nötig.
• Ein zweiter, eigenständiger Lead-Generierungs-Flow (Flyer-Download) neben dem Kontaktformular.
• Code-, Sicherheits- und Architektur-Reviews liefen während des gesamten Aufbaus, nicht erst am Ende in einem einmaligen Durchgang.

Bewusst noch nicht behauptet: Traffic, Rankings, Anfragevolumen, KI-Zitierungen. Eine Nachprüfung nach drei Monaten wird Indexierung, erste Search-Console-Daten, Page-Speed-Werte im Vergleich zur alten Seite und ob KI-Antwortsysteme die Seite zitieren, erfassen.

Kundenaussage: Frank sagte, das Ergebnis gefalle ihm, die Geschwindigkeit sei etwas, das man "mit WordPress nie bekommt", und er sei "wirklich zufrieden" mit dem Ergebnis.

Die Stimme des Kunden

"Diesen einen HTML-Schnipsel in eine komplette Website zu verwandeln, mit allem, was sie brauchte, dafür hätte ich sonst einen Psychiater gebraucht."

"Was mich begeistert, ist das Tempo. Das erreichst du mit WordPress nie."

"Das ist halt noch gute alte Schule: Wenn du sagst, der Termin ist um 11, bist du auch um 11 da."

Wie wir zusammengearbeitet haben

Nach einem früheren Website-Projekt, das nie fertig wurde, war Franks größte offene Frage nicht der Technik-Stack, sondern ob er dem Nächsten vertrauen konnte, ihn tatsächlich auf dem Laufenden zu halten. Das Projekt wurde genau darauf ausgerichtet: Frank bekam während des gesamten Aufbaus einen täglichen Bericht in sein Postfach, sodass er immer wusste, was geliefert wurde, was in Arbeit war und was als Nächstes kam, ohne fragen zu müssen. Dazu kam ein wöchentlicher Abstimmungscall für Richtung und Entscheidungen, und Ad-hoc-Calls waren verfügbar, wann immer er eine Frage hatte, statt auf den nächsten festen Termin warten zu müssen. Calls begannen jedes Mal pünktlich, was Frank unaufgefordert als Kontrast zu früheren Erfahrungen hervorhob.

Warum es funktioniert hat

Das geschäftliche Problem war konkret und dringend, der Entscheider war direkt eingebunden, und der Umfang passte zum Termin: öffentliche Seite jetzt, Portal später, auf demselben Fundament. Frank brachte einen klaren Entwurf und eine feste technische Präferenz mit; das Projekt lieferte das Review, das er wollte, und den produktionsreifen Aufbau, den er selbst nicht leisten konnte. Ein Festpreis und ein fester Termin hielten den Umfang ehrlich.

Für einen Kunden, der ein visuelles Admin-Panel und volle Kontrolle über Layout und neue Seitentypen ohne Entwickler braucht, wäre dieser Ansatz nicht passend. Dieser Stack braucht einen Entwickler, oder ein KI-Coding-Tool, sobald es über routinemäßige Inhaltsänderungen hinausgeht.

Für wen das passt

Inhabergeführte B2B-Unternehmen, deren Website ihrem Vertrieb und ihrer Direktansprache schadet, oft nachdem ein früheres Website-Projekt nicht fertig wurde, die eine gestalterische Richtung haben (oft einen KI-Entwurf), aber keinen Weg in den Betrieb, die echte Sichtbarkeit bei Suche und KI-Suche brauchen, und die einen wartbaren, programmierten Stack einem WordPress-Admin vorziehen können. Sie brauchen einen Entscheider, einen Content-Verantwortlichen, und Zugriff auf Domain und Hosting.

Häufige Fragen

Wie lange hat der ESGready-Relaunch gedauert?

Neun Tage vom KI-generierten Entwurf von Frank Siebke bis zur fertigen, produktionsreifen Seite, zum Festpreis geliefert, rechtzeitig vor seinem Webinar-Termin.

Warum konnte ESGready den KI-Entwurf nicht einfach so live schalten?

Der Entwurf war eine einzelne, hash-geroutete JavaScript-Seite: Ihr Inhalt erschien erst, nachdem Skripte ausgeführt worden waren, sodass Google und KI-Systeme nur eine leere Seite sahen. Daraus musste eine echte, crawlbare, KI-auffindbare statische Seite werden.

Passt dieser Ansatz für jedes Unternehmen?

Er passt für inhabergeführte B2B-Unternehmen mit einer gestalterischen Richtung, aber ohne Weg in den Betrieb, die echte Sichtbarkeit bei Suche und KI-Suche wollen und einen wartbaren, programmierten Stack einem WordPress-Admin vorziehen können. Für einen Kunden, der ein visuelles Admin-Panel und volle Kontrolle über Layout und neue Seitentypen ohne Entwickler braucht, wäre er nicht passend.