Evolution vor Revolution! Vermeide einen Relaunch solange, wie es geht und versuche, alle Punkte, die bisher für einen Relaunch vorgetragen wurden, einzeln bzw. inkrementell umzusetzen. Verbessere eine Sache, bringe sie live, werte aus, was passiert, passe erneut an oder widme dich dem nächsten Punkt.
Agentur-Relaunch: Warum wir von Headless CMS Strapi zurück zu WordPress wechselten
Warum wir nach einem SEO-Crash bewusst einen Schritt zurück gegangen sind: Im Sommer 2023 haben wir unsere Agenturwebsite von WordPress auf ein Headless-Setup mit Strapi und Nuxt umgestellt. Ziel war eine moderne Architektur, saubere Content-Modelle und ein klarer technischer Schnitt. Das Ergebnis war ernüchternd: Unsere organische Sichtbarkeit und die Klicks brachen um über 90 Prozent ein. Am 8. Dezember 2025 sind wir erneut live gegangen: diesmal mit einem gestalterisch nahezu identischen Auftritt, aber wieder auf WordPress-Basis. Seitdem baut sich unsere Sichtbarkeit messbar und stabil wieder auf. Innerhalb von drei Wochen stieg der Seobility-Sichtbarkeitswert der von uns beobachteten Keywords von 30 auf 69.
Diese Case Study zeigt, warum das passiert ist und welche Schlüsse wir daraus ziehen.
Ausgangslage: WordPress war in Ordnung, aber der Trend zeigte auf Headless CMS
Vor dem ersten Relaunch lief unsere Website klassisch auf WordPress. Technisch war das System solide, inhaltlich gewachsen und SEO-seitig stabil. Rankings, interne Verlinkungen und historische Inhalte hatten sich über Jahre aufgebaut.
So sah unsere alte Website vor dem Relaunch 2023 aus, die erstmal 2016 in diesem User Interface online ging:
WordPress war kein Innovationsprojekt, sondern ein funktionierendes Fundament. Ich mochte die alte Website. Über Jahre lief sie zuverlässig. Auch die Gestaltung war noch modern und wäre noch heute vermutlich besser als die meisten Websites unserer Agenturmitbewerber. Ein Relaunch ist selten nötig. Wir entschieden uns dafür. Und damit verstieß ich direkt gegen die erste Empfehlung, die ich in meiner Relaunch-Checkliste nannte, ein Relaunch zu vermeiden, solange es geht. Lieber inkrementell verbessern als den großen Wurf zu wagen. Mein Backend-Entwickler warnte noch, wir sollten es nicht tun. Mein Head of Development war heiß auf das Projekt und auch ich wollte, dass wir mit unserer Agentur zur Speerspitze der modernsten Weblösungen im Einsatz gehören, weswegen wir auch frühzeitig auf das Bildformat Avif in unseren Webprojekten setzten und auch gern HTTP3 einsetzen … allerdings auch hier mit unerwarteten Wechselwirkungen.
Relaunch 1: WordPress → Strapi + Nuxt (Sommer 2023)
Der Wechsel zu Headless war eine bewusste (Fehl-) Entscheidung. Ein Relaunch ohne echte Not. Wir wollten:
- eine moderne Architektur
- eine klare Trennung von Content und Frontend
- bessere Wartbarkeit auf Code-Ebene
- eine langfristig skalierbare Lösung
Strapi ist ein Headless CMS (API-first), wo Backend (Content) und Frontend (Website/App) komplett getrennt sind. Inhalte werden über REST oder GraphQL geliefert. Das ganze setzten wir um mit Nuxt.
WordPress hingegen ist ein monolithisches CMS (Backend + Frontend in einem System), indem Inhalte und Darstellung direkt miteinander gekoppelt sind. (Optional ist es auch Headless nutzbar by the way.) Während WordPress ein riesiges Ökosystem aus Themes & Plugins hat und auch die größte Entwicklergemeinde verzeichnet, ist der Einstieg in eine Headless-CMS anspruchsvoller. Das zeichnete sich auch bei uns im Team ab. Während alle meine fünf Entwickler WordPress von A bis Z beherrschen, war auf Nuxt nur mein Head of Development spezialisiert. Und die Einarbeitungszeit ist wesentlich höher.
Wir haben über Monate ein neues User Interface konzipiert, Bilder vorbereitet, Inhalte erstellt und vor allem programmiert. Parallel dazu haben wir auch Inhalte aufgeräumt, veraltete Blogartikel entfernt und Themen zusammengeführt. Was wir unterschätzt haben: die SEO-Auswirkungen dieses Gesamtpakets.
Was beim Headless-Relaunch schiefgelaufen ist: Sichtbarkeit –90 Prozent
Wir gingen online im Sommer 2023 voller Zuversicht, ein neues Kapitel der Webentwicklung bei uns einzuläuten. Wie im folgenden Chart zu sehen ist, war unsere Sichtbarkeit ohnehin schon rückläufig. Der Relaunch wird es schon richten. Klar …
Was ist mit Stichtag zum Relaunch passiert? Der Sichtbarkeitsverlauf zeigt eine klare Abrisskante. Innerhalb kürzester Zeit waren fast alle Rankings weg. In den folgenden Monaten tat sich nahezu nichts … weder nach oben noch nach unten. Es sah fast so aus, als wären wir mit noindex online gegangen, aber das war es nicht.
Rückblickend wurde uns erst mit zeitlichem Abstand klar, dass der drastische Sichtbarkeitsverlust nicht durch eine einzelne Maßnahme ausgelöst wurde, sondern durch das Zusammenspiel mehrerer Faktoren. Der Wechsel auf ein Headless-Setup mit Strapi und Nuxt bedeutete nebem dem technologischen Wechsel auch einen fundamentalen Bruch in der Art, wie unsere Inhalte an Suchmaschinen ausgeliefert werden.
Parallel zum technischen Relaunch hatten wir unsere Inhalte bewusst reduziert. Veraltete Blogartikel wurden gelöscht, Themen zusammengeführt und das Gesamtangebot verschlankt. Diese Entscheidung war inhaltlich sinnvoll, hatte jedoch in Kombination mit dem Headless-Setup gravierende Nebenwirkungen.
Ein Teil der gelöschten Inhalte hatte über Jahre Rankings, interne Verlinkungen und externe Signale aufgebaut. Diese historischen Relevanzsignale vollständig verloren. Während klassische CMS-Setups solche Einschnitte häufig besser abfedern, traf dieser Vertrauensverlust im Headless-Kontext auf eine ohnehin erschwerte Crawlbarkeit. Für Google entstand der Eindruck einer stark veränderten, instabilen und schwer einzuordnenden Domain.
Das Ergebnis war keine kurzfristige Korrektur, sondern eine monatelange Phase, in der Google die Website zwar weiterhin kannte, sie jedoch kaum noch aktiv bewertete. Diese „SEO-Zwischenzone“ dauerte fast ein halbes Jahr und ist rückblickend ein Zeichen für eine grundlegende Neubewertung unserer Domain. Wir haben es Google am Anfang auch schwer gemacht aus selbst verursachten Problemen innerhalb der Website.
Zwar kann Google JavaScript grundsätzlich rendern, in der Praxis ist dieser Prozess jedoch zweistufig und fehleranfällig. Ein erheblicher Teil der Inhalte, Meta-Informationen und internen Verlinkungen war für den Crawler im initialen HTML nicht vollständig sichtbar, sondern wurde erst nach der clientseitigen Hydration bereitgestellt. Dadurch fehlten Google in der ersten Crawling-Phase zentrale Signale zur Einordnung der Seiten. Die Folge war keine punktuelle Abwertung einzelner URLs, sondern ein fast vollständiger Verlust der organischen Sichtbarkeit auf Domain-Ebene.
Hinzu kam, dass strukturierte Daten, Canonicals und Meta-Informationen nicht in jedem Fall serverseitig und konsistent ausgeliefert wurden. Für Menschen war die Website vollständig nutzbar, für Suchmaschinen jedoch nicht eindeutig interpretierbar. Vielmehr hatten die Crawler echte Probleme in der Abrufbarkeit der Inhalte, wie ein Einblick in die Search Console zu jener Zeit verriet. Genau diese Diskrepanz ist typisch für viele Headless-Setups, wenn SEO nicht von Anfang an als gleichwertige Disziplin in der Architektur mitgedacht wird. Und das können wir uns vorwerfen.
In der Search Console wurde auch ein weiterer Effekt sichtbar: Für mehrere Wochen erhielten wir keinerlei Crawling-Anfragen. Mein Entwickler kümmerte sich drum, sodass erst ab Anfang September die Crawlinganfragen wieder nach oben gingen. In dieser Phase wurden unsere Seiten faktisch nicht mehr aktiv gecrawlt und bewertet, was funktional einem temporären Auslisten gleichkam.
Rückblickend war insbesondere eine gestalterische Spielerei problematisch: eine vorgeschaltete Animation, die kurzzeitig eine leere Seite auslieferte, bevor der eigentliche Inhalt geladen wurde. Für Nutzer wirkte das modern, für Google jedoch wie zwei getrennte Seiten. In der Praxis wurde häufig nur die leere Seite gecrawlt. Diese eine Entscheidung hatte massive Auswirkungen auf Crawling, Rendering und letztlich auf die gesamte Sichtbarkeit der Domain.
Es gab dann 2024 noch einen richtigen PageSpeed-Sprint, sodass wir unsere Werte für mobile und desktop auf 90+ gebracht haben.
Die unterschätzte Abhängigkeit vom Spezial-Know-how
Ein weiterer Aspekt, der sich im laufenden Betrieb immer deutlicher zeigte, war die starke Abhängigkeit von spezialisiertem Entwicklerwissen. Das Strapi-Setup war individuell angepasst, update-sensibel und in weiten Teilen nur von einer einzelnen Person vollständig bei uns im Team durchdrungen. Kleinere Änderungen, Bugfixes oder Updates erforderten immer wieder tiefes Einarbeiten und führten zu Verzögerungen.
Im Vergleich dazu ist WordPress in unserem Team breit verankert. Alle fünf Entwickler sind extrem fit in WordPress, Updates und funktionelle Wünsche sind Standardprozesse und Probleme lassen sich schnell und unabhängig voneinander lösen. Diese Teamfähigkeit einer Technologie wird bei Systementscheidungen oft unterschätzt, so auch bei uns. Es hat aber direkte Auswirkungen auf Stabilität, Geschwindigkeit und langfristige Wartbarkeit einer Website.
Unser Fokus lag 2024 und 2025 vor allem auf unser Eigenprojekt TutKit.com, wodurch die Agenturwebsite immer nur zweitranging in der Projektpipeline war. Die Agenturaufträge kamen hauptsächlich aus unserem Netzwerk, weswegen der Abfall der Rankings auch gar nicht groß unser Tagesgeschäft tangierte. Wir bemerkten es kaum, weil wir es auch gar nicht wirklich prüften. Es lief ja grundsätzlich gut im Unternehmen und den Proejkten. So haben wir nie die Zeit gefunden, alle Probleme bis zum Ende zu fixen und es fand sich irgendwie nie die Gelegenheit, unser gesamtes Entwicklerteam auf Headless-Entwicklung upzugraden. Unsere Kundenprojekte wurden weiterhin mit WordPress umgesetzt.
Rückblickend kamen mehrere Faktoren zusammen, die sich gegenseitig verstärkten und zu unseren (hausgemachten) Problemen führten:
- ein Headless-Setup mit fehleranfälliger Initial-Auslieferung
- eine gleichzeitige Content-Reduktion ohne vollständige Relevanzvererbung
- JavaScript-abhängige Navigation und interne Verlinkung
- technische Spielereien, die Crawler blockierten
- fehlende Ressourcen, um alle Probleme zeitnah zu beheben
Der zweite Relaunch: gleiche Website, anderes Fundament
Als wir uns im Spätsommer für den Rückwechsel zu WordPress entschieden, war ein Punkt elementar: Es handelte sich nicht um einen klassischen Relaunch. Interface, Inhalte und URL-Struktur blieben vollständig unverändert. Lediglich das technische Fundament wurde ausgetauscht. Am 8. Dezember 2025 gingen wir online mit dem nachgebauten User Interface auf der uns wohlbekannten WordPress-Codebasis. Hierzu nutzten wir auch gleich die Gelegenheit, unser selbst entwickeltes WordPress-Theme zu optimieren. Wir als Agentur sind kein Fan von Klicki-Bunti-Pagebuildern wie Elementor oder anderen Websitebaukästen. Wir benötigen schlanken Code und volle Kontrolle über alles. Und somit bauten wir unser eigenes Theme mit einer Auswahl an vorinstallierten Plugins und einer Struktur, die vor allem auf Advanced Custom Fields basiert. Anders als beim Relaunch 2023 sicherten wir bereits in der Entwicklungsumgebung alle wichtigen Prüfparameter ab und konnten direkt mit Topwerten in OnPage-Qualität, Sicherheit und PageSpeed online gehen.
WordPress-Seiten haben nicht perse eine schlechte Performance. Wir haben die Performance auf 96 mobile optimiert, obwohl wir auch solche schwerlastigen Plugins wie WPML für die Mehrsprachigkeit im Einsatz haben:
Direkt eine hohe OnPage-Qualität mit 96 % Score: mithilfe von Seobility sichern wir in Projekten die technische, strukturelle und inhaltliche Qualität zum Relaunch ab:
Innerhalb weniger Wochen zeigte sich, dass Google die Seiten deutlich schneller und konsistenter erfassen konnte. Inhalte waren sofort im HTML vorhanden, Meta-Daten und strukturierte Informationen lagen direkt vor und interne Verlinkungen waren ohne JavaScript vollständig sichtbar. Die Suchmaschine erhielt wieder klare, stabile Signale.
Die Folge war ein rascher Wiederaufbau der Sichtbarkeit bei den von uns getrackten Keywords. Der Seobility-Sichtbarkeitswert stieg innerhalb von drei Wochen von 30 auf 69, die Anzahl der rankenden Keywords nahm kontinuierlich zu und der Trend zeigte klar nach oben. Dieser schnelle Effekt wäre ohne eine grundlegende technische Verbesserung nicht erklärbar. Und ich nehme an, dass ist erst der Anfang. Im kommenden Jahr werde ich ein Update dieses Charts hier veröffentlichen.
Warum WordPress in diesem Fall die bessere Wahl war
Diese Case Study ist kein grundsätzliches Urteil gegen Headless-CMS. Systeme wie Strapi haben ihre Stärken in komplexen Plattformen, App-Anbindungen und Multichannel-Szenarien. Für eine SEO-getriebene Agenturwebsite mit starkem Content-Fokus zeigte sich jedoch, dass WordPress die robustere und wirtschaftlichere Lösung ist.
WordPress liefert Inhalte, Metadaten und semantische Strukturen unmittelbar und konsistent aus. Fehler werden von Suchmaschinen eher verziehen, Änderungen schneller neu bewertet und Relaunches sind insgesamt risikoärmer. In Kombination mit der breiten Verfügbarkeit von Know-how im Team ergibt sich eine Stabilität, die gerade im Marketing- und SEO-Umfeld entscheidend ist.
Für uns war dieser Fail eine teure Investition, die dazu geführt hat, konsequent datenbasierte Prüftools zur Absicherung noch vor dem Going-Live von Kundenprojekten einzusetzen. Wir sind weg von der Haltung, dass bestimmte Probleme später, also on the fly gefixt werden. Später ist ein Zeitpunkt, der selten oder zu spät kommt, weil immer wieder andere Themen und Tasks auf der Agenda sind.
Der Wechsel zurück zu WordPress war keine nostalgische Entscheidung, sondern eine pragmatische. Moderne Architektur ist kein Selbstzweck. Entscheidend ist, wie zuverlässig ein System Inhalte transportiert, wie gut es im Team beherrscht wird und wie stabil es unter realen SEO-Bedingungen funktioniert. Wenn selbst wir als Tech-Agentur unsere Herausforderungen hatten, sollte jedes Unternehmen genau überlegen, ob es solche technischen Experimente wagen möchte. Diese Erfahrung hat unsere Entscheidungsprozesse nachhaltig verändert. Und freuen uns, dass es jetzt sichtlich bergauf geht in der Sichtbarkeit.
