Warum wir unsere Webseite mit KI komplett neu gebaut haben (Teil A)

Worum es in dieser Doppelfolge geht

Bei Kernkompetenz Pferd wurde in den letzten Wochen die komplette Webseite neu gebaut – von Grund auf, mit KI-Unterstützung, ohne klassisches Entwicklerteam. Wer kernkompetenz-pferd.de in den letzten Jahren besucht hat, sah eine über die Jahre gewachsene WordPress-Seite mit Elementor. Was heute dort läuft, basiert auf einem komplett neuen technischen Fundament: einer eigenen Plattform auf Basis von Next.js.

In Teil A geht es um das Warum und um das Wie im Groben. Teil B folgt in zwei Wochen und steigt ins Eingemachte ein – mit den Knackpunkten, den Stolperstellen und einem ehrlichen Fazit.

Wo wir herkommen: WordPress + Elementor

Kernkompetenz Pferd ist seit fast zehn Jahren online. Der Stack war klassisch gewachsen: WordPress als System, Elementor als visueller Page-Builder, dazu ein ordentlicher Park an Plugins. Für den Start vor zehn Jahren war das die richtige Lösung – visuell bauen, sofort sehen was passiert, kein Entwickler für jede Kleinigkeit.

Aber irgendwann dreht sich das. Hier sind die sechs Schmerzpunkte, die am Ende den Ausschlag gegeben haben.

1. Kraut und Rüben

Über die Jahre hat jede Seite ein bisschen anders ausgesehen. Hier ein anderer Button, da ein anderer Abstand, drüben eine andere Schriftgröße, mal blau, mal grün. Schleichender Verlust der Designsprache – nicht im Großen, sondern im Detail.

2. Globale Änderungen waren faktisch unmöglich

51 Danke-Seiten, auf denen ein Hauptbutton geändert werden soll? Ein Tagesprojekt: Editor öffnen, ändern, speichern, nächste Seite. 51 Mal das Gleiche. Das ist keine Arbeit, das ist eine Bestrafung.

3. Die Pop-Up-Hölle

Jedes einzelne Pop-Up hat einen halben Tag gekostet. Plugin auswählen, mit den Conditions kämpfen, mit dem Cookie-Banner streiten, auf Mobile bricht es, mal schließt es zu schnell, mal gar nicht. Am Ende hat es trotzdem nicht so funktioniert, wie es sollte.

4. Ladegeschwindigkeit, vor allem auf Mobile

WordPress macht für jeden Seitenaufruf eine Datenbankabfrage, dazu Plugin-Aufrufe und CSS aus etlichen Quellen. Auf dem Handy, im Stall, mit schwachem Netz: spürbar zäh. Wer schnelles Internet gewohnt ist, springt ab.

5. Update-Roulette

Bei jedem Plugin-Update Bauchschmerzen: Geht etwas kaputt? Funktioniert das danach noch? Updates wurden oft rausgeschoben, einfach um keine Überraschungen zu erleben.

6. Abhängigkeit von externen Experten

Auch technisch verstandene Sachen ließen sich oft nicht selbst sauber umsetzen. Idee am Sonntag, Brief raus, auf Termin warten, Angebot, Beauftragung, auf Umsetzung warten – der Schwung war weg, bevor die Idee live war. Bei kurzfristigen Aktionen war der Zug abgefahren.

Der Auslöser: KI-Tools, die Code schreiben

Was den Ausschlag gegeben hat, waren KI-Tools, mit denen sich Code schreiben lässt. Bei Hendrik konkret war das Claude Code.

Stichwort Vibe Coding: Man beschreibt in normaler Sprache, was man will, die KI schreibt den Code, man testet, gibt Feedback, sie verbessert – und so arbeitet man sich Stück für Stück voran. Man muss kein klassischer Entwickler sein. Aber: Ein bisschen technisches Verständnis hilft enorm.

Wichtige Ehrlichkeit an dieser Stelle: Hendrik war nie professioneller Webentwickler. Aber durch fast zehn Jahre Kernkompetenz Pferd hat er sich auf ein fortgeschrittenes Entwicklerniveau hochgearbeitet. Eine Webseite in dieser Größe hätte er vor zwei Jahren trotzdem nie selbst gebaut. Was sich verändert hat, ist nicht primär seine Fähigkeit, sondern das Werkzeug.

Und: KI ist kein Zauberstab. Sie macht Fehler. Wer nicht versteht, was sie tut, baut sich blind Sicherheitslücken oder eine Architektur ein, die später um die Ohren fliegt. Vibe Coding ja – aber wie immer: mit Kopf einschalten.

Die drei Treiber für den Neubau

Treiber 1: Flexibilität und Eigenständigkeit

Ein System, in dem neue Funktionen selbst gebaut werden können, sobald sie gebraucht werden. Nicht warten, bis ein Plugin-Hersteller ein Feature liefert oder ein Entwickler Zeit hat. Heute eine Idee – nach zwei Stunden ist das Ding live.

Konkretes Beispiel: Der Pferdemenschen-Typentest. Vorher: Ein externer Link auf ein Formular-Tool, neun Fragen, Punktesystem, Ergebnis per E-Mail – viele Schritte, viele Conversion-Killer. Heute: Alles direkt in Next.js auf der eigenen Seite, der Nutzer bekommt sofort sein Ergebnis. In Elementor wäre das nahezu unmöglich gewesen.

Treiber 2: Geschwindigkeit

Eine moderne Next.js-Seite läuft technisch in einer ganz anderen Liga als eine gewachsene WordPress-Seite. Statisches Prerendering – Seiten liegen fertig da, wenn der Besucher kommt. Keine Datenbank-Roundtrips für jeden Aufruf, weniger Code, der überhaupt ausgeliefert wird. 5 bis 7 Sekunden Ladezeit vorher gegen Bumm-die-Seite-ist-da heute. Auch SEO-relevant: Google misst und wertet das.

Treiber 3: Konsistenz und globale Kontrolle

Eine Code-Änderung wirkt sich automatisch auf alle 51 Danke-Seiten aus, die diese Komponente nutzen. Die Designsprache wird nicht mehr eingehalten, weil man dran denkt – sondern weil das System es erzwingt.

Wird's billiger? Nein – aber das ist auch nicht der Punkt

Ein wichtiger Realitätscheck: Selbst gebaute KI-Lösungen werden oft als "viel günstiger" verkauft. Stimmt so nicht. Die neue Plattform läuft auf Vercel Pro und Supabase Pro – die reine Infrastruktur ist sogar minimal teurer als das vorherige WordPress-Setup.

Aber: Was heute in einer Stunde umgebaut werden kann, hätte in WordPress eine Woche gekostet – oder einen externen Dienstleister, auf den gewartet wird. Die Investition rechnet sich in Zeit, Flexibilität und Möglichkeiten, nicht in eingesparten Euros.

Der neue Stack im Überblick

Die Begriffe muss man sich nicht merken – wichtig ist das Bild dahinter.

• Next.js statt WordPress – ein modernes Framework für Web-Apps. Alles ist Code, alles ist versionsverwaltet, jede Änderung nachvollziehbar und notfalls zurückrollbar.
• GitHub – der versionierte Aktenschrank für den kompletten Code. Wer hat was wann gemacht, was war der Stand letzte Woche, vor drei Monaten?
• Vercel – das Hosting. Hängt direkt an GitHub: Push auf GitHub → Vercel zieht automatisch nach → 30 Sekunden später ist die Änderung live. Geht etwas schief? Einen Stand zurück, push, alter Stand wieder live.
• Tailwind – das CSS-Framework, das für durchgängig konsistente Designsprache sorgt.
• Supabase – die Datenbank für alles, was später draufsattelt: Mitgliederbereich, Bild-Datenbank, etc.

Souveränität durch Standard-Code

Ein Punkt, der im Tool-Trubel oft untergeht: Diese Webseite wurde mit Claude Code gebaut – aber sie ist nicht auf Claude Code festgelegt. Wer morgen Codex von OpenAI ausprobieren will oder Antigravity von Google, öffnet einfach den gleichen Ordner mit dem nächsten Tool. Nach 13 Sekunden hat das neue Tool den Code verstanden und es geht weiter, wo aufgehört wurde.

Warum? Weil unter all dem ganz normaler Standard-Code liegt. Standard-Frameworks. Jede KI, die heute beim Programmieren hilft, versteht das.

Der Unterschied zu WordPress + Elementor: Dort war man vom Tool selbst und vom Page-Builder abhängig. Wenn der Hersteller Preise verdoppelt oder das Produkt einstellt, hat man ein Problem. Hier: Der Code gehört einem selbst, liegt im eigenen GitHub-Account, die KI ist eine reine Komfortentscheidung. Heute Claude, morgen vielleicht eine andere, übermorgen wieder Claude. Souveränität auf einer ganz anderen Ebene.

Wenn man heute bei null anfangen würde – die ersten drei Schritte

Schritt 1: Inventarisierung

Bevor irgendetwas Neues gebaut wird, muss klar sein, was da ist. Mit einem kleinen Skript (selbst von Claude Code geschrieben) wurden alle Pages, Posts, Bilder und PDFs aus der WordPress-API gezogen. Das Ergebnis: über 150 Blogposts, 51 Danke-Seiten, jede Menge Hauptseiten für Online-Kurse, mehrere Varianten für die KKP-Welt, etliche Bilder. Allein durch die Inventur wurde klar, wie groß das Ding eigentlich ist.

Schritt 2: Next.js + Vercel aufsetzen

Klingt groß, ist es nicht – ein Nachmittag reicht. Projekt anlegen, mit Vercel verbinden, ersten Deploy machen, fertig. Vercel und GitHub haben kostenlose Pläne – finanziell keine Hürde für den Einstieg.

Schritt 3: Erste Seite als Prototyp

Bei KKP war das eine Landingpage, die parallel als eigene Subdomain zur bestehenden WordPress-Seite lief. Der Moment, in dem klar wurde: Das funktioniert richtig gut – das hätte ich gerne für die komplette Seite. So kam der Anstoß zum großen Projekt.

Der Aha-Moment: Komponenten

In dieser Phase kam der Aha-Moment, mit klarem Namen: Komponenten. Eine Komponente ist ein Stück Code, das überall wiederverwendet wird – wie ein Legostein. Einmal gebaut, beliebig oft eingesetzt. Wird am Legostein etwas geändert, ändert es sich überall, wo er steckt.

Erinnerung: 51 Danke-Seiten. In WordPress: 51 Mal Editor öffnen, 51 Mal ändern, hoffen dass keine vergessen wird. Im neuen System: Eine Codeänderung, alle 51 Seiten sofort aktualisiert.

Drei Beispiele aus dem Alltag

1. Freebie-Page-Layout. Mehrere Freebie-Seiten (Null-Euro-Produkte) teilen sich eine einzige Layout-Komponente. Pro Seite werden nur Bild, Text und die Klick-Tipp-Form-ID übergeben – den Rest macht das System.

2. 51 Danke-Seiten basieren auf einer Vorlage. Soll morgen auf jeder Danke-Seite ein zusätzlicher Hinweis erscheinen – etwa ein Link zu Erfahrungsberichten? Eine Stelle, einmal geändert, fertig.

3. Call-to-Action-System. Boxen in Blogartikeln, die auf Online-Kurse, Freebies, die KKP-Welt oder andere Artikel verweisen. Liegen jetzt zentral in einer Bibliothek. Im Blogartikel steht nur noch: "Nimm CTA X und Y, baue sie ein." Schöner Nebeneffekt: Beim Umzug ist aufgefallen, dass alte Folgen noch CTAs auf einen Programmstart von vor drei Jahren hatten – ein toter Link. Sowas passiert in einem zentral verwalteten System nicht mehr.

Das ist das Geheimnis guter Softwareentwicklung: nicht Copy-Paste, sondern Wiederverwendung. Und das geht in Code tausendmal eleganter als in einem visuellen Page-Builder.

Realitätscheck: So einfach ist es nicht

Bevor jetzt der Eindruck entsteht, das sei am Wochenende erledigt:

Die erste Phase – Stack aufsetzen, Inventur, Komponenten anlegen, Hauptseite bauen – hat mehrere Wochen gedauert. Viele Abende, viele Morgende, viele Wochenenden. Zwischendurch immer wieder die Frage: War das jetzt wirklich nötig? Im Nachgang: ja, definitiv die beste Entscheidung. Aber zwischendrin war es ein langwieriger Prozess.

Die Lernkurve war steil. Auch mit KI muss man verstehen, was gerade gebaut wird – sonst sitzt man irgendwann auf einem Code-Berg, den man nicht mehr durchschaut. Ohne die zehn Jahre Vorerfahrung als der, der bei Kernkompetenz Pferd den technischen Hut auf hat, wäre die Migration nicht in dieser Geschwindigkeit gegangen.

Klare Ansage: Wer Claude Code, Codex, Antigravity oder ein anderes Vibe-Coding-Tool benutzt und glaubt, am nächsten Tag eine fertige Migration zu haben, irrt sich. Die KI nimmt das Tippen ab, nicht das Denken. Den Architektenhut muss man selbst aufhaben.

Was in Folge B kommt

In zwei Wochen geht es ins Eingemachte:

• Wie die ganzen Blogposts samt Bilder rübergekommen sind
• Welche Integrationen gebraucht wurden – Klick-Tipp, Cookie-Consent, SEO, Tracking
• Welche fiesen Knackpunkte beim Go-Live gewartet haben – Mobile-Bugs, DNS-Switch, schlicht übersehene Seiten
• Und das ehrliche Fazit: Für wen ist dieser Weg das Richtige – und für wen nicht?

Wer das Thema interessant findet: Podcast abonnieren und in zwei Wochen wieder einschalten.