Ein Rückblick: WordPress Theme Vergleich
Zwanzig Jahre WordPress-Theme-Entscheidungen — meine persönliche Timeline
Von YAML über Xtreme One und UnderStrap zu Neve + Gutenberg. Vier Generationen Theme-Architektur aus der Praxis eines Schweizer WordPress-Entwicklers, mit den Lehren, die sich für KMU daraus ableiten lassen.
Wer einen ehrlichen WordPress Theme Vergleich aus über zwanzig Jahren Praxis sucht, findet ihn hier: von YAML über Xtreme One und UnderStrap zu Neve und dem Gutenberg Block Editor.
Ich werde regelmässig gefragt, warum ich für neue Projekte auf Neve + nativen Gutenberg-Editor setze. Die kurze Antwort: weil es für Schweizer KMU die beste Balance aus Performance, Ease-of-Use und langfristiger Wartbarkeit ist, die ich bis jetzt gesehen habe.
Die längere Antwort ist interessanter. Sie zeigt, wie technische Entscheidungen in der Web-Entwicklung selten auf einen Schlag gefällt werden, sondern sich über Jahre entwickeln. Und sie zeigt, warum man bei einem Werkzeug, das man seiner Kundschaft empfiehlt, nicht einfach auf den nächsten Hype springen sollte, sondern warten, bis sich etwas in der Praxis bewährt hat.
Meine Timeline beginnt nicht erst 2018. Sie beginnt 2006. Hier die vier Generationen, die ich selbst miterlebt habe.
Ein Wort vorab: die zwei Spuren meiner WordPress-Erfahrung
Meine Arbeit mit WordPress verläuft seit Jahren in zwei parallelen Spuren, die sich gegenseitig befruchten.
Die XINDAYA-Spur ist das, was Sie auf dieser Website sehen: Websites für Schweizer KMU, Selbständige, Freelancer, NGOs/Kantone: typischerweise 5 bis 50 Seiten, überschaubare Komplexität, direkter persönlicher Kontakt zum Kunden / zur Kundin.
Die Grossplattform-Spur ist parallel dazu meine Tätigkeit als Webdesigner, Webentwickler und Content Manager für eine Schweizer Publishing-Plattform: sechs- bis siebenstellige monatliche Besuche, über 17’000 Seiten, rund 5’000 redaktionelle Artikel, ein kontinuierlich publizierendes Redaktionsteam. Eine Plattform, bei der ein fehlerhaftes Update mittags tausende Besucherinnen gleichzeitig in die Irre schicken kann.
Diese duale Erfahrung ist für meine Theme-Entscheidungen zentral. Was im Grossen unter Last funktioniert, funktioniert im Kleinen erst recht. Und was im Kleinen nicht sauber aufgesetzt ist, kann im Grossen katastrophal enden.
Generation 1: YAML-Framework (2006–2009)
Bevor ich mit WordPress arbeitete, habe ich mit YAML gearbeitet — dem «Yet Another Multicolumn Layout»-Framework von Dirk Jesse. 2006 war das Web noch eine andere Welt: Bootstrap existierte nicht, Tailwind war Jahre entfernt, und die Ausrichtung von Elementen mit CSS war eine echte handwerkliche Herausforderung. YAML war eines der ersten seriösen CSS-Frameworks für responsive Mehrspalten-Layouts — lange bevor «Responsive Design» ein allgemein gebräuchlicher Begriff war. Dafür war der Internet Explorer noch mit Versionen am Start, die einem Webdesigner den Schlaf rauben konnte.
Parallel begann ich um 2007/2008 mit WordPress zu arbeiten — damals noch als reinem Blog-System. Die zwei Welten — YAML für das Layout, WordPress für das CMS — liefen zunächst getrennt.
Mehr zum YAML-Framework und dem Web von 2006
Das YAML-Framework wurde vom deutschen Entwickler Dirk Jesse ab 2005 entwickelt und war eines der ersten modularen CSS-Frameworks für das Web. Es bot vorgefertigte Spalten-Layouts, die in einer Zeit, in der CSS-Floats die einzige Möglichkeit für Multi-Column-Layouts waren, eine enorme Erleichterung darstellten. Flexbox gab es noch nicht, CSS Grid war Zukunftsmusik.
Für mich war YAML das erste Framework, das zeigte: wiederverwendbare, gut dokumentierte Grundlagen sind produktiver als jedes Mal von Null zu beginnen. Ein Prinzip, das sich durch alle späteren Generationen zieht.
WordPress war zu dieser Zeit (Version 2.0–2.8) primär ein Blog-System. Themes waren typischerweise Ein-Mann-Produkte, die Leute in ihrer Freizeit entwickelten. Der Theme-Markt, wie wir ihn heute kennen (Themeforest, Premium-Theme-Shops), war noch in der Entstehung.
Generation 2: Xtreme One (2010–2015)
Um 2010 entdeckte ich Xtreme One — ein WordPress-Theme-Framework von David Decker (Deckerweb), das auf dem YAML-Framework aufbaute und speziell für WordPress konzipiert war. Ich war in der Beta-Testphase dabei und habe das Theme von der frühen Version 1.x bis zu seinen späten Versionen intensiv in Projekten eingesetzt.
Was Xtreme One für mich ideal machte: die Brücke zwischen dem mir vertrauten YAML-Layout-Denken und dem aufkommenden WordPress-Ökosystem. Es war ein sogenanntes «All-in-one»-Framework — vergleichbar mit anderen Grössen dieser Ära wie Genesis oder Thesis — mit eigenem Layout-Manager, SEO-Features und einem klaren Struktur-Ansatz.
Der kommerzielle Betrieb wurde von MarketPress (Inpsyde GmbH) übernommen. Zwischen 2013 und 2014 kamen mit Version 1.6 wichtige Updates wie WooCommerce-Unterstützung und Responsive Design hinzu.
Dann, im Juli 2015, wurde Xtreme One an die Community übergeben. MarketPress hatte entschieden, das Produkt aus dem kommerziellen Sortiment zu nehmen. Der Code ging auf GitHub, in der Hoffnung, dass eine offene Entwickler-Gemeinschaft die Weiterentwicklung übernehmen würde. Das ist dann leider nie passiert. Der letzte Commit datiert vom August 2015. Seither hat niemand ernsthaft weiterentwickelt.
Für mich war Ende 2015 der Zeitpunkt, an dem klar wurde: Xtreme One hat keine Zukunft mehr. Die Entscheidung war nicht, das Theme von einem Tag auf den anderen aus dem Projektkatalog zu streichen — bestehende Kundinnen habe ich weiter betreut und die Websites blieben funktional — aber neue Projekte bekamen ein anderes Fundament.
Warum Xtreme One versagte, obwohl es technisch solide war
Die Xtreme-One-Story ist ein klassisches Beispiel für die Grenzen von «Community-Übergaben» in der Open-Source-Welt. Der Code war solide, das Produkt war ausgereift, die Nutzerbasis war engagiert — und trotzdem versiegte die Entwicklung praktisch sofort nach der Übergabe.
Die Gründe, wie ich sie aus heutiger Sicht interpretiere:
1. Kein «vested interest». Die Entwickler, die Xtreme One in ihren eigenen Projekten einsetzten, hatten genug mit ihrer eigenen Arbeit zu tun. Niemand war organisatorisch dafür verantwortlich, die nächste Version zu koordinieren. «Community-driven» ohne klare Governance ist oft ein Euphemismus für «niemand ist zuständig».
2. Proprietäre Layout-Engine. Xtreme One hatte ein eigenes Layout-System. Sobald die Entwicklung stoppte, wurde das Wissen darum obsolet — anders als bei Themes, die auf globalen Standards wie Bootstrap aufbauen. Dort kann man als Entwickler mit Standard-CSS-Wissen weiterarbeiten, auch wenn das Theme selbst nicht mehr gepflegt wird.
3. WordPress selbst entwickelte sich weiter. Responsive Design wurde zum Standard. Neue WordPress-Features (Customizer, später Gutenberg) forderten Theme-Anpassungen. Ein Framework ohne aktive Entwicklung kann diesen Tempo-Wechsel nicht mitgehen.
Die Lehre für mich persönlich: Wenn ein Produkt-Ökosystem seinen wirtschaftlichen Motor verliert, stirbt es meistens — auch wenn der Code noch lange verfügbar bleibt. Bei der Wahl von Technologie für Kundenprojekte ist nicht nur die Qualität des aktuellen Produkts entscheidend, sondern auch die Wahrscheinlichkeit, dass es in fünf oder zehn Jahren noch aktiv gepflegt wird.
Generation 3: UnderStrap (ab 2015 — bis heute)
Der Wechsel von Xtreme One zu UnderStrap fiel 2015 genau mit dem Jahr zusammen, in dem Xtreme One versiegte. UnderStrap war als Open-Source-Projekt von Holger Koenemann gestartet worden.
Was UnderStrap fundamental anders machte: es war kein «All-in-one-Framework», sondern ein Starter-Theme für Entwickler. Die Philosophie war, zwei bewährte Standards zu kombinieren:
- Underscores (_s) — das minimale PHP-Starter-Theme von Automattic (der Firma hinter WordPress.com) als Logik-Fundament
- Bootstrap — zu der Zeit das klar dominierende CSS-Framework für Grid-Systeme und UI-Komponenten — als Design-Fundament
Für einen Entwickler, der wusste, was er tat, war UnderStrap ideal. Ich konnte ein Child-Theme aufsetzen, die Bootstrap-Klassen direkt nutzen und in wenigen Stunden die Grundstruktur einer neuen Website stehen haben. Voll kontrollierbar, wartbar, ohne Ballast.
Ein wichtiger Hinweis vorab, damit die folgenden Jahre verständlich werden: UnderStrap ist bis heute auf der Grossplattform, für die ich verantwortlich bin, im Einsatz. Nicht Neve, sondern UnderStrap. Die Entscheidung für UnderStrap 2017/2020 war so gut, dass sie ein Jahrzehnt später immer noch trägt. Das ist bemerkenswert, denn es zeigt: die richtige Wahl für das richtige Projekt altert besser, als viele, die jedem Trend hinterher rennen, glauben.
UnderStrap im Detail — und was es von Xtreme One unterschied
UnderStrap hat aus drei strukturellen Gründen überlebt, wo Xtreme One scheiterte:
1. Standardisierung statt Proprietät. UnderStrap baut auf Bootstrap auf. Bootstrap ist der globale Industriestandard für CSS-Frameworks — jeder Frontend-Entwickler der Welt kennt es. Selbst wenn UnderStrap morgen aufhören würde zu existieren, bleibt das Wissen um Bootstrap-Klassen direkt anwendbar. Das war bei Xtreme Ones proprietärer Layout-Engine anders.
2. Modernes Tooling von Anfang an. UnderStrap umarmte die SASS/Node.js-Revolution früh — mit Gulp-basierten Build-Prozessen, BrowserSync für Live-Reload, einer klaren Trennung zwischen Source und Build. Das Theme war nicht einfach ein Design-Produkt, es war ein Entwicklungs-Workflow.
3. Erfolgreicher Governance-Wechsel. 2020 übergab Holger Koenemann die Projektleitung an Howard Development & Consulting (Howard DC) — eine US-Agentur, die UnderStrap in ihren eigenen Kundenprojekten einsetzte und damit ein echtes wirtschaftliches Interesse an der Fortführung hatte. Im Gegensatz zur Xtreme-One-Übergabe an eine anonyme «Community» war Howard DC eine klar identifizierte Organisation mit Namen, Gesicht und Geschäftsmodell. Zusätzlich wurde mit «UnderStrap Pro» ein kommerzielles Produkt aufgelegt, das die Finanzierung des Open-Source-Cores sichert.
Diese drei Faktoren — Standard-Basis, modernes Tooling, solide Governance — sind heute, 2026, immer noch aktuelle Kriterien, wenn ich neue Technologien evaluiere. Das Abandonment-Risiko ist für mich mindestens so wichtig wie die Qualität des aktuellen Produkts.
Unter der Howard-DC-Ära wurde UnderStrap komplett überarbeitet: Bootstrap 3 → 4 → 5, Entfernung der jQuery-Abhängigkeit, Umstellung des Build-Systems von Gulp auf NPM-Scripts und Vite-kompatible Standards. UnderStrap ist damit heute noch ein lebendiges, aktiv gepflegtes Projekt — über zehn Jahre nach Gründung.
Wenn Sie heute eine Agentur treffen, die UnderStrap einsetzt, ist das kein Warnsignal. Im Gegenteil: es zeigt meistens einen Entwicklungsansatz, der auf Standards und Kontrolle setzt — und nicht auf Page-Builder-Abkürzungen.
Die Lehre für mich persönlich: Wenn ein Produkt-Ökosystem seinen wirtschaftlichen Motor verliert, stirbt es meistens — auch wenn der Code noch lange verfügbar bleibt. Bei der Wahl von Technologie für Kundenprojekte ist nicht nur die Qualität des aktuellen Produkts entscheidend, sondern auch die Wahrscheinlichkeit, dass es in fünf oder zehn Jahren noch aktiv gepflegt wird.
2017–2022: Die Grossplattform auf UnderStrap
Um das Gutenberg-Kapitel verständlich zu machen, muss ich einen parallelen Handlungsstrang einführen: die Grossplattform.
2017 begann die Konzeptphase für die Plattform, die bis heute unter meiner Mitverantwortung läuft. 2020 lief die konkrete Entwicklungsarbeit, 2022 war die grosse Migration abgeschlossen: eine neue, leistungsfähige WordPress-Installation auf UnderStrap-Basis, in der über die Zeit ein fünfstelliger Seitenbestand aufgewachsen war — und der weiter ausgebaut wurde, bis heute rund 17’000 Seiten und 5’000 Artikel darin stehen. Rund 500 unabhängige Informationswebsites und eine Newsplattform wurden unter ein Dach gebracht.
Das Setup zu diesem Zeitpunkt: UnderStrap als Theme, Classic Editor als Editor. Gutenberg war seit Ende 2018 der offizielle WordPress-Standard-Editor, aber für eine Plattform dieser Grösse war das Classic-Editor-Plugin die pragmatische Wahl.
Auch im XINDAYA-Alltag setzte ich zu dieser Zeit für neue Projekte weiter auf UnderStrap + Classic Editor — nicht aus Konservatismus, sondern weil es für meine Kundschaft die stabilste Lösung war. In der Tech-Welt wird der «Early Adopter» gern romantisiert. In der Praxis — besonders wenn man Verantwortung für laufenden Betrieb trägt — ist der «Late Majority Adopter» oft die verantwortungsvollere Position.
2023–2025: Classic Editor wird zum Problem — Migration auf Gutenberg erzwungen
Hier wird die Geschichte interessant, und anders als viele sie erzählen.
Ich bin nicht auf Gutenberg umgestiegen, weil Gutenberg plötzlich so grossartig war, sondern weil Classic Editor bei 17’000 hierarchischen Seiten zum operativen Problem wurde. Die Lag-Zeiten im Backend wurden spürbar — erst bei einzelnen Pfaden, dann breitflächig. Eine Seite zu öffnen dauerte Sekunden, nicht Millisekunden. Ein Redaktionsteam, das in dieser Frequenz arbeitet, kann sich solche Reibungsverluste nicht dauerhaft leisten.
Das Gute war: Gutenberg hatte bis dahin — 2023 herum — eine Reife erreicht, die eine Migration praktisch machbar machte. Mit WordPress 5.9 (Anfang 2022) und der Einführung von Full Site Editing war Gutenberg kein reiner Content-Editor mehr, sondern ein vollständiger Site-Builder. Die API war stabil. Die Community hatte sich auf Patterns und Best Practices geeinigt. Und vor allem: Gutenberg-Seiten performten im Admin-Backend deutlich besser als Classic-Editor-Seiten mit derselben Seitenzahl.
Wir sind schrittweise migriert — von 2023 bis 2025. Erst neue Artikel im News-Bereich auf Block Editor umgestellt, um den Editor im aktiven Einsatz zu haben. Dann wurden ältere News-Artikel nachgezogen. Schliesslich die hierarchischen Pages, die den eigentlichen Performance-Engpass dargestellt hatten. Zwei Jahre schrittweise, kontrollierte Migration mit sorgfältigem Testing.
Wichtig dabei: UnderStrap blieb das Theme. Die Grossplattform läuft bis heute auf UnderStrap — jetzt eben mit Gutenberg als Editor statt Classic Editor. UnderStrap + Gutenberg ist eine perfekt valide Kombination, und die Plattform ist der lebende Beweis dafür.
Warum die Editor-Migration anders war als eine Theme-Migration
Ein wichtiger technischer Punkt, der oft missverstanden wird: Theme-Wechsel und Editor-Wechsel sind zwei verschiedene Dinge.
Das Theme (UnderStrap, Neve, Custom) bestimmt das Erscheinungsbild und das Styling. Der Editor (Classic vs. Gutenberg) bestimmt, wie Inhalte erfasst und strukturiert werden. Man kann — und wir haben es getan — den Editor wechseln, ohne das Theme anzufassen. Und man kann das Theme wechseln, ohne den Editor zu ändern.
Das ist eine Subtilität, die aus der öffentlichen Diskussion oft verschwindet, weil viele Premium-Themes und Page-Builder die beiden Schichten eng verzahnen (Elementor zum Beispiel ist de facto ein eigener Editor plus eine Theme-Erweiterung). UnderStrap hat diese Schichten sauber getrennt — das Theme kümmert sich um Bootstrap-basiertes Layout, der Editor (ob Classic oder Gutenberg) liefert die Inhalte. Darum konnte die Migration so sauber ablaufen: wir haben eine Schicht getauscht, nicht die ganze Architektur umgebaut.
Die Lehre daraus für KMU: Saubere Architektur mit klar getrennten Verantwortlichkeiten macht langfristig flexibel. Fest verzahnte All-in-one-Lösungen (Page-Builder-basierte Themes, proprietäre Editor-Theme-Kombinationen) machen dich bei jedem Technologie-Wechsel zum Gefangenen.
Generation 4: Neve + Gutenberg für XINDAYA (ab Anfang 2024)
Die Grossplattform-Erfahrung hat für meine XINDAYA-Arbeit einen konkreten Effekt gehabt: ich hatte Gutenberg unter realer Last gesehen. Nicht theoretisch, nicht aus Blog-Artikeln, sondern im täglichen Redaktionsbetrieb einer Website mit 5’000 Artikeln und einem laufend publizierenden Team. Ich wusste jetzt, was Gutenberg kann und was nicht.
Anfang 2024 habe ich deshalb die Entscheidung getroffen, für neue XINDAYA-Projekte auf Neve + Gutenberg als Standard umzustellen. Die Gründe:
Erstens: KMU-Projekte haben andere Anforderungen als Developer-Projekte. UnderStrap war und ist ideal für entwicklerzentrierte Arbeit — volle Kontrolle, sauberer Code, Bootstrap als Standard. Aber für eine KMU-Inhaberin, die ihre Website selbst pflegen möchte, ist der native Gutenberg-Editor in einem Gutenberg-optimierten Theme intuitiver. Neve liefert genau das.
Zweitens: Performance von Haus aus. Neve kommt unter 100 KB CSS + JavaScript aus — und wurde von Anfang an Gutenberg-first konzipiert. In einer Welt, in der Core Web Vitals ein Ranking-Faktor sind, ist das ein messbarer Vorteil gegenüber älteren, schwereren Themes.
Drittens: Block Patterns statt Page-Templates. Als Gutenberg sein Pattern-System einführte, war Neve einer der ersten Themes, der konsequent darauf umstieg. Statt grosse Import-Dateien mit fest verdrahteten Designs zu liefern, arbeiten Neve-Nutzer mit modularen Block-Patterns, die sich frei kombinieren lassen. Das bedeutet: meine Kundinnen können einzelne Abschnitte einer Seite austauschen, neu anordnen, anpassen — ohne jedes Mal Code anzufassen.
Viertens: Theme-Hersteller mit klarer Governance. ThemeIsle ist ein etabliertes Unternehmen mit funktionierendem Geschäftsmodell und aktiver Produktentwicklung. Das gleiche Prinzip, das mich zur UnderStrap-Wahl gebracht hat: Abandonment-Risiko ist mindestens so wichtig wie die Qualität des aktuellen Produkts.
Warum Neve zusammen mit dem Gutenberg-Editor
Neve ist ein Lehrbuch-Beispiel für das perfekte Timing einer Technologie-Wette.
Das Theme wurde Ende 2018 / Anfang 2019 von ThemeIsle released — wenige Monate nach dem Gutenberg-Launch in WordPress 5.0. Während etablierte Themes (die grossen Themeforest-Produkte, aber auch ältere Frameworks wie Xtreme One) versuchten, Gutenberg-Unterstützung nachträglich in ihre bestehenden Architekturen zu «retrofitten», war Neve von Tag 1 an «Gutenberg-first» konzipiert.
Drei Faktoren machten den Unterschied:
1. Leichtgewicht als Grundprinzip. Neve’s Philosophie fiel zeitlich mit Googles Ankündigung der Core Web Vitals als Ranking-Faktor zusammen (Mai 2020, Rollout 2021). Legacy-Themes luden oft 2 MB+ an CSS und JavaScript. Neve kommt unter 100 KB aus. In einer Welt, in der Ladezeit plötzlich direkt SEO-relevant wurde, war das ein entscheidender Vorteil.
2. Block Patterns statt Page-Templates. Als Gutenberg 2020/2021 sein Pattern-System einführte, war Neve einer der ersten Themes, der konsequent darauf umstieg. Statt grosse Import-Dateien mit fest verdrahteten Designs zu liefern, arbeiten Neve-Nutzer mit modularen Block-Patterns, die sich frei kombinieren lassen. Sobald Gutenberg ein neues Feature bekam, profitierten Neve-Nutzer sofort — ohne auf ein Theme-Update warten zu müssen.
3. Auf den WordPress-Core gesetzt, nicht gegen ihn. Viele erfolgreiche Themes der Page-Builder-Ära (Astra mit Elementor, OceanWP mit Elementor und Beaver Builder) hatten ihre Position durch die enge Verzahnung mit Drittanbieter-Page-Buildern aufgebaut. Neve hat diesen Pfad bewusst nicht eingeschlagen. Die Wette war: WordPress-Core mit Gutenberg wird sich durchsetzen — und wir wollen die Plattform sein, die am besten mit Core zusammenspielt. Diese Wette hat sich ausgezahlt.
Für mich als Entwickler bedeutet das: Neve zwingt mich nicht in ein fremdes Ökosystem, sondern verstärkt, was WordPress ohnehin kann. Das ist die Anti-Lock-in-Architektur, die ich für KMU-Websites suche.
Was die Grossplattform-Erfahrung für meine KMU-Arbeit bedeutet
Die Lehren aus einem Betrieb mit bis zu einer Million monatlichen Besuchen und 17’000 Seiten übertragen sich direkt auf die KMU-Arbeit — nicht in der Grössenordnung, aber in den Prinzipien:
Robustheit schlägt Eleganz
Was im Grossen unter Last zusammenbricht, bricht im Kleinen vielleicht erst nach Jahren zusammen — aber es bricht. Wer im Grossen gelernt hat, welche Konstellationen tatsächlich robust sind, baut auch kleine Websites zuverlässiger.
Editorialtauglichkeit ist ein Qualitätsmerkmal, nicht nur eine Grosskunden-Anforderung
Ein Block Editor, der für ein Redaktionsteam mit wöchentlich einem Dutzend neuer Beiträge funktioniert, funktioniert erst recht für eine KMU-Inhaberin, die einmal im Monat einen Blogbeitrag schreibt. Die Ergonomie, die im Grossen entscheidend ist, ist im Kleinen ein angenehmer Komfort.
Updates sind kein Klick-Workflow, sondern ein Prozess
Auf einer Plattform mit sechsstelligen monatlichen Besuchen kann man nicht einfach per «auf Update klicken» aktualisieren. Man testet erst auf einem Staging-Server, prüft systematisch, rollt kontrolliert aus. Dieselbe Disziplin wende ich bei der Wartung generell an.
Tool-Auswahl? Zuverlässigkeit vor Neuigkeit
Die Frage ist nie «welches Tool ist am neuesten», sondern «welches Tool ist unter realistischen Bedingungen am zuverlässigsten». Das ist der rote Faden durch alle vier Generationen meiner Theme-Timeline.
Ein konkretes KMU-Beispiel: Modernisierung von psyche-und-arbeit.ch
Im letzten Jahr habe ich eine Kampagnen-Website modernisiert — psyche-und-arbeit.ch, eine Sensibilisierungs-Plattform rund um psychische Gesundheit am Arbeitsplatz, getragen vom Ostschweizer Forum für Psychische Gesundheit und vom Forum BGM Ostschweiz.
Die Ausgangslage war ein älteres Theme aus einer früheren Entwicklungsphase, das seinen Dienst jahrelang zuverlässig getan hatte, aber schrittweise aus der Zeit gefallen war: mobile Darstellung in Teilen problematisch, Ladezeiten nicht mehr optimal, Pflege durch den Kunden wurde mühsamer.
Die Entscheidung: Wechsel auf Neve + Gutenberg. Nicht als spektakulärer Relaunch, sondern als strukturierte Modernisierung — mit genau der Disziplin, die ich aus dem Grossplattform-Betrieb gewohnt bin.
Was der Wechsel konkret gebracht hat:
- Die Kampagnen-Botschaft kommt technisch sauber bei den Nutzerinnen und Nutzern an
- Der Kunde kann Inhalte selbst einpflegen, ohne jedes Mal Support anfragen zu müssen
- Die Website ist auf allen Endgeräten einheitlich gut dargestellt
- Die technische Basis ist für die nächsten fünf Jahre tragfähig
Was heisst das für Schweizer KMU?
Wenn Sie aktuell eine WordPress-Website haben, stellt sich die Frage: Ist Ihr Theme noch das richtige? Die ehrliche Antwort ist: es kommt drauf an.
Ihr Theme ist vermutlich noch okay, wenn:
- Es regelmässig aktualisiert wird
- Sie die Website selbst pflegen können, ohne jedes Mal Frust zu haben
- Die Performance auf Mobile im grünen Bereich ist (PageSpeed 80+)
- Keine akuten Sicherheits- oder Kompatibilitätsprobleme bestehen
Ein Umstieg auf Neve + Gutenberg wird relevant, wenn:
- Sie mit einem Page-Builder arbeiten (Elementor, WPBakery, Divi) und die Website zunehmend unhandlich wird
- Ihr Theme aus einer Theme-Sammlung stammt, die keine aktive Pflege mehr erfährt
- Mobile Darstellung oder Ladezeiten zum Problem werden
- Sie bei jeder kleinen Änderung externe Hilfe brauchen, obwohl es anders sein sollte
Wichtig: Ein Theme-Wechsel ist kein Selbstzweck. Wenn Ihre Website läuft, Ihre Kundinnen zufrieden sind und die technischen Kennzahlen stimmen, gibt es keinen zwingenden Grund, aus ideologischen Motiven umzubauen. Pragmatismus schlägt Dogma.
Was die vier Generationen gemeinsam haben — ein WordPress Theme Vergleich über zwanzig Jahre
Vier Theme-Generationen über zwanzig Jahre — und zu keinem Zeitpunkt war «jetzt sofort wechseln» die beste Antwort. Die richtige technische Entscheidung war immer die, die zum aktuellen Reifegrad der Technologie, zur Kundensituation und zum langfristigen Ökosystem passte.
2018 wäre ein Komplettwechsel auf Gutenberg verfrüht gewesen. 2020 wäre ein Festhalten an Elementor grob fahrlässig gewesen. 2022 wäre ein Beharren auf UnderStrap + Classic Editor bei der Grossplattform noch vertretbar gewesen — zwei Jahre später nicht mehr. 2024 war für XINDAYA der richtige Moment für Neve + Gutenberg. 2026 wäre ein Sprung auf das nächste Hype-Theme ohne Ökosystem-Check unverantwortlich.
Das ist kein Widerspruch, sondern genau die Arbeit. Ein guter Web-Entwickler trifft technische Entscheidungen nicht einmal und für immer, sondern laufend neu. Der Hype-Zyklus in der Web-Entwicklung ist schnell. Die Langfristigkeit einer KMU-Website ist es nicht. Die Langfristigkeit einer Grossplattform mit 17’000 Seiten erst recht nicht.
Wer den Unterschied versteht, baut Websites, die fünf, sieben, zehn Jahre funktionieren — statt alle zwei Jahre zum nächsten Trend zu springen.
Kurz zusammengefasst
- 2006–2009: YAML-Framework als CSS-Grundlage, paralleler Einstieg in WordPress.
- 2010–2015: Xtreme One als All-in-one-Framework, Beta-Tester seit der frühen Phase. Scheiterte 2015 an der missglückten Community-Übergabe.
- Ab 2015: UnderStrap als Bootstrap-basierter Developer-Starter — ideal für voll kontrollierbare Custom-Projekte. Bis heute aktiv, bis heute für die Grossplattform in Betrieb.
- 2017–2021: Konzept und Aufbau der Grossplattform auf UnderStrap + Classic Editor.
- 2023–2025: Schrittweise Migration der Grossplattform vom Classic Editor auf Gutenberg — erzwungen durch Performance-Probleme bei 17’000 hierarchischen Seiten. UnderStrap bleibt Theme.
- Ab Anfang 2024: Neve + Gutenberg wird für neue XINDAYA-Projekte die Standard-Wahl — auf Basis der Erfahrung, Gutenberg unter echter Last gesehen zu haben.
- Übergreifend: Standardisierung, Netzwerkeffekte und klare Governance sind die dauerhaften Kriterien. Modernisierungen im richtigen Moment sind wertvoller als Early-Adopter-Experimente.
Weiterführende Informationen
- WordPress Webentwicklung für KMU
- WordPress Wartung & Support
- Zur Person
- Glossar: Netzwerkeffekte | Understrap Theme | Neve Theme | Classic Editor | Gutenberg Block-Editor | Full Site Editing
- Bildquelle: Caspar David Friedrich, Public domain, via Wikimedia Commons
Ihr Theme ist zeitgemäss — oder reif für die Modernisierung?
Ein kurzer Audit Ihrer aktuellen WordPress-Installation zeigt schnell, ob Handlungsbedarf besteht. Kostenloses 30-Minuten-Gespräch zur ersten Einschätzung.
