Kiwop hatte jahrelang eine Website auf WordPress. Sie funktionierte, aber sie repräsentierte uns nicht mehr. Wir hatten uns in Richtung maßgeschneiderter Softwareprojekte, Headless-Architekturen und angewandter künstlicher Intelligenz weiterentwickelt — und unsere eigene Website war immer noch ein PHP-Monolith mit über Jahre angesammelten Plugins. Es war wie ein Schreiner mit einer kaputten Haustür.
Im Januar 2026 haben wir beschlossen, innezuhalten und von Null anzufangen. Kein Redesign auf WordPress, sondern eine komplett neue Architektur. Dieser Artikel beschreibt das Warum, das Wie und die Ergebnisse, die wir erzielt haben.
Die alte Website: was nicht funktionierte
Es war nicht so, dass die Website kaputt war. Sie lud, sah gut aus, hatte Inhalte. Aber sie häufte Probleme an, die sich zunehmend verschärften:
Mittelmäßige Performance. WordPress mit seinen Cache-Plugins, Bildoptimierung und Page-Buildern erzeugte schweren HTML-Code. Die Core Web Vitals auf Mobilgeräten wurden nicht konsistent bestanden, und Google bestraft die Nutzererfahrung zunehmend stärker.
Offene Sicherheitslücken. WordPress ist das meistangegriffene CMS der Welt. Das Administrationspanel befindet sich unter /wp-admin, die API-Endpunkte sind bekannt, und jedes Plugin ist eine potenzielle Angriffsfläche. Es aktuell zu halten war eine ständige Aufgabe.
Starrheit. Das Design einer Sektion zu ändern bedeutete, PHP-Templates, Hooks und Inline-CSS des Page-Builders anzufassen — und zu hoffen, dass nichts anderes kaputtging. Der Inhalt war an die Darstellung gekoppelt.
Technische Schulden bei Inhalten. Jahre an Veröffentlichungen hatten mehr als 240 Artikel niedriger Qualität hinterlassen, fast 200 unübersetzte WPML-Duplikate und Dutzende Thin-Content-Seiten. Google sah alles, und die Autorität der Domain verwässerte sich.
Die Entscheidung: Headless-Architektur
Wenn wir "Headless" sagen, sprechen wir nicht von einem Technologie-Trend. Wir sprechen davon, zwei Dinge zu trennen, die nicht zwangsläufig zusammengehören: wo der Inhalt verwaltet wird und wie er dem Nutzer angezeigt wird.
Was bringt das dem Unternehmen?
Echte Geschwindigkeit, nicht nur gefühlte. Das Frontend generiert reines HTML auf dem Server. Kein PHP, das bei jeder Anfrage interpretiert wird, keine Plugins, die unnötige Skripte laden. Der Browser erhält genau das, was er braucht — nicht mehr.
Sicherheit durch Design. Das CMS, in dem Inhalte bearbeitet werden, ist nicht dem Internet ausgesetzt. Es gibt kein /wp-admin, das angegriffen werden kann. Die Angriffsfläche wird drastisch reduziert.
Vollständige Flexibilität. Das Designteam kann jede visuelle Komponente ändern, ohne die Inhaltsdatenbank anzufassen. Und das Redaktionsteam kann veröffentlichen, ohne sich um das Rendering kümmern zu müssen.
Skalierbarkeit. Eine Website in 7 Sprachen von einem einzigen Frontend mit mehrstufigem Cache zu betreiben ist machbar. Mit WordPress und WPML vervielfachte jede Sprache die Komplexität.
Astro + Payload CMS: warum diese Kombination
Wir haben mehrere Optionen evaluiert. Next.js, Nuxt, Remix für das Frontend. Strapi, Directus, Sanity für das CMS. Wir haben uns aus ganz konkreten Gründen für Astro und Payload entschieden.
Astro generiert statisches oder serverseitig gerendertes HTML, ohne standardmäßig JavaScript an den Browser zu senden. Wenn eine Seite keine Interaktivität benötigt, erhält der Nutzer reines HTML und CSS. Das Ergebnis: 0 Millisekunden Total Blocking Time. Null. Der Haupt-Thread des Browsers bleibt frei.
Payload CMS ist ein Headless-CMS auf Basis von PostgreSQL mit einer sauberen REST-API und vollständiger Typisierung in TypeScript. Anders als Strapi oder Sanity wird Payload selbst gehostet: Unsere Daten liegen in unserer eigenen Datenbank, nicht bei einem externen SaaS-Anbieter. Für eine Agentur, die mit Kundendaten arbeitet, ist das nicht verhandelbar.
Die Kombination löst ein reales Problem: professionell verwaltete Inhalte, präsentiert mit einem Lighthouse-Score von 97 und 0 ms Blockierung im Browser — ohne externe Abhängigkeiten und ohne Vendor-Lock-in.
Der Prozess: 35 Tage, 230 Commits
Es war kein Sechsmonatsprojekt. Vom ersten Commit am 10. Januar 2026 bis zur Produktionsversion vergingen 35 Tage. 230 Commits. Ein kleines Team mit klaren Zielen.
Phase 1: Struktur und Komponenten (Woche 1–2)
Wir definierten die modulare Architektur: 14 wiederverwendbare Sektionskomponenten (Hero, Service-Grid, Schritt-für-Schritt-Prozess, FAQs, CTAs), die wie Bausteine kombiniert werden, um jede Serviceseite aufzubauen. Jeder Service wird über eine Konfigurationsdatei pro Sprache definiert, ohne Code anzufassen.
Die wichtigste Entscheidung war, kein JavaScript-Framework auf der Client-Seite zu verwenden. Kein React, kein Vue, kein Svelte. Reines Astro mit Islands-Architektur für die wenigen Komponenten, die Interaktivität benötigen (wie den Chatbot). Das Ergebnis: ein JavaScript-Bundle nahe Null für 95 % der Seiten.
Phase 2: Mehrsprachigkeit (Woche 3)
Wir gingen von 3 Sprachen (Spanisch, Englisch, Katalanisch) auf 7 (plus Deutsch, Französisch, Niederländisch und Portugiesisch). Das umfasste:
- Ein zentralisiertes Übersetzungssystem für die gesamte Benutzeroberfläche, verwaltet aus einer einzigen Datei.
- Korrekte Hreflang-Tags mit deaktiviertem Fallback, um zu verhindern, dass Google unübersetzte Inhalte indexiert.
- Saubere URLs pro Sprache ohne Trailing Slash (1.001 indexierte URLs in Google Search Console, alle konsistent).
Ein Detail, das uns Stunden gekostet hat: die Regex zur Spracherkennung in URLs. Ein falsches Muster erkannte /ca innerhalb von /casos-de-exito und zerstörte die Routen auf Katalanisch. Das klingt trivial, aber auf einer Website mit mehr als 2.000 Seiten ist ein solcher Bug katastrophal für SEO.
Phase 3: Content-Migration und Bereinigung (Woche 4)
Wir migrierten den gesamten Blog von WordPress zu Payload CMS. Aber es war kein direkter Datentransfer: Wir nutzten die Gelegenheit für ein gründliches Content-Audit.
- 243 toxische Artikel gelöscht (Inhalte niedriger Qualität, irrelevant oder veraltet)
- 199 WPML-Duplikate depubliziert (englische und katalanische Versionen, die unübersetzte Kopien des Spanischen waren)
- 31 Thin-Content-Seiten entfernt mit 410-Statuscodes in nginx
- 3 Paare doppelter Beiträge konsolidiert mit 301-Weiterleitungen
- 885 Titel gekürzt auf unter 60 Zeichen
- 333 Meta-Beschreibungen angepasst auf unter 160 Zeichen
Diese Bereinigung war bewusst. Googles Helpful Content Update bestraft auf Website-Ebene. 200 minderwertige Seiten ziehen die 700 guten nach unten.
Phase 4: SEO und Performance (Woche 5)
Audit der Heading-Hierarchie auf allen 2.114 Seiten der Website: 0 Fehler, 0 Warnungen. Jede Seite hat eine korrekte semantische Struktur von H1 bis H4.
Wir implementierten ein vierstufiges Cache-System (Payload CMS, Redis SWR, nginx SSR und Cloudflare CDN) mit geordneter Invalidierung. Die Reihenfolge ist entscheidend: Wenn man Cloudflare leert, aber Payload noch alten Cache hat, speichert nginx sofort veraltete Daten erneut. Es klingt offensichtlich, wenn man es liest — aber wir haben es beim Debuggen gelernt, warum Änderungen nicht in der Produktion erschienen.
Die Rolle der KI
Es wäre unehrlich, es nicht zu erwähnen: Wir haben KI während des gesamten Prozesses als Entwicklungswerkzeug eingesetzt. Nicht um blind Code zu generieren, sondern als Pair-Programming-Partner, der uns half, über 2.000 Seiten zu auditieren, SEO-Inkonsistenzen im großen Maßstab zu erkennen und repetitive Aufgaben wie die Normalisierung von Titeln in 7 Sprachen zu automatisieren.
Die KI hat weder die Architektur entworfen noch Geschäftsentscheidungen getroffen. Aber sie hat die Umsetzung erheblich beschleunigt, insbesondere in den Phasen des Content-Audits und der Bereinigung.
Ergebnisse: die Zahlen
Performance (Lighthouse)
Die Lighthouse-Werte der produktiven Website:
- Performance: 97/100 (Mobil und Desktop)
- Barrierefreiheit: 100/100
- Best Practices: 100/100
- SEO: 100/100
Core Web Vitals
- LCP (Largest Contentful Paint): 2,2 Sekunden — bestanden (Google-Schwellenwert: < 2,5 s)
- TBT (Total Blocking Time): 0 Millisekunden — bestanden (Schwellenwert: < 200 ms)
- CLS (Cumulative Layout Shift): 0 — bestanden (Schwellenwert: < 0,1)
TBT von 0 Millisekunden bedeutet, dass der Browser zu keinem Zeitpunkt blockiert wird. CLS von 0 bedeutet, dass sich nichts verschiebt, während die Seite lädt. Diese Zahlen sind nicht theoretisch: Es sind echte Messungen der produktiven Website.
Auswirkungen auf Suchmaschinen
Die Bereinigung der Inhalte brachte ein erwartetes Ergebnis: weniger Gesamtimpressionen (wir haben Hunderte von Seiten entfernt), aber eine höhere Qualität dessen, was übrig bleibt.
- CTR: +27,8 % (von 0,17 % auf 0,22 %)
- Durchschnittliche Position: +9,3 Positionen (von 50,6 auf 41,3)
- Durchschnittliche Position auf Mobilgeräten: +13,6 Positionen (von 36,9 auf 23,3)
Weniger Volumen, mehr Qualität. Die verbliebenen Seiten ranken besser und konvertieren mehr. Das ist die richtige Strategie, wenn die Priorität darin liegt, Kunden zu gewinnen — nicht leere Besuche anzuhäufen.
Skalierung
- 2.114 Seiten geprüft und funktionsfähig
- 7 Sprachen aus einer einzigen Codebasis
- ~1.600 Blogartikel veröffentlicht (712 ES, 406 EN, 407 CA, 33 DE/FR/NL, 10 PT)
- Deployments ohne Ausfallzeit mit automatischem Rollback
Was das für unsere Kunden bedeutet
Diese Website ist nicht nur unser Schaufenster. Sie ist der praktische Beweis für das, was wir tun.
Dieselbe Headless-Architektur, die kiwop.com antreibt — Trennung von Frontend und CMS, mehrstufiger Cache, native Mehrsprachigkeit, PageSpeed-Performance von 97+ — ist genau das, was wir in Kundenprojekten umsetzen.
Wenn Ihre aktuelle Website:
- Länger als 3 Sekunden zum Laden auf Mobilgeräten braucht
- Von WordPress mit 20 Plugins abhängt, um zu funktionieren
- Wiederkehrende Sicherheitsprobleme hat
- Nicht gut auf mehrere Sprachen oder Märkte skaliert
- Technische Schulden ansammelt, die jede Änderung ausbremsen
Es gibt eine bewährte Alternative. Nicht theoretisch: Sie sehen sie gerade.
Sprechen wir? Fordern Sie ein kostenloses Audit Ihrer Website an
