Vor rund zehn Jahren war Elementor für mich die logische Antwort auf die eingeschränkten Möglichkeiten von WordPress. In den vergangenen Monaten habe ich rund 30 Websites von Elementor auf moderne WordPress Block Themes migriert. Dabei entstand ein KI-gestützter Migrations-Workflow, der mich zu einer spannenden Frage geführt hat:
Brauchen wir Elementor 2026 überhaupt noch?
Vom Visual Composer zu Elementor
Als ich meine ersten Websites mit WordPress umgesetzt habe, war der klassische Editor schnell an seinen Grenzen. Eine Zeit lang arbeitete ich deshalb mit WPBakery, damals vielen noch unter dem Namen Visual Composer bekannt.
Technisch war damit vieles möglich. Mir persönlich war der Builder jedoch oft zu komplex und wenig intuitiv. Viele Layouts liessen sich zwar umsetzen, der Weg dorthin fühlte sich aber unnötig umständlich an.
Als Elementor 2016 erschien, war das für mich deshalb ein echter Fortschritt.
Plötzlich konnten Seiten direkt visuell bearbeitet werden. Der Aufbau war verständlicher, die Bedienung intuitiver und neue Layouts entstanden deutlich schneller. Für mich war Elementor damals die bessere Antwort auf die Schwächen der bestehenden Page Builder.
Entsprechend habe ich in den vergangenen Jahren zahlreiche Websites mit Elementor umgesetzt.
Was sich in den letzten Jahren verändert hat
Heute sieht die Situation jedoch anders aus.
WordPress hat sich in den letzten Jahren enorm weiterentwickelt. Mit Gutenberg, Full Site Editing und modernen Block Themes lassen sich heute die meisten klassischen Unternehmenswebsites vollständig mit Bordmitteln umsetzen. Wie viel allein WordPress 7.0 dazu beigetragen hat, habe ich in «WordPress 7.0 Armstrong: Vier Features, die mein Block-Theme entschlackt haben» beschrieben.
Die spannende Frage lautet deshalb nicht mehr:
«Kann WordPress das überhaupt?»
Sondern:
«Brauche ich dafür noch einen zusätzlichen Page Builder?»
Warum ich bestehende Elementor-Websites migriert habe
Ausgangspunkt waren verschiedene Kundenprojekte und eigene Websites, die über Jahre mit Elementor gewachsen sind.
Technisch funktionierten diese Websites weiterhin problemlos. Trotzdem wurden die Nachteile mit der Zeit immer sichtbarer:
- zusätzliche Lizenzkosten (ca. eine Verdoppelung in den letzten 10 Jahren)
- mehrere voneinander abhängige Plugins: neben Elementor und Elementor Pro oft noch Essential Addons (frei und Pro) oder Theme-Erweiterungen
- regelmässige Updates und Datenbank-Aktualisierungen
- grösserer Wartungsaufwand
- umfangreichere Backups
- zusätzliche CSS- und JavaScript-Dateien
- unnötiger Ballast für einfache Inhalte
Je mehr Projekte ich analysierte, desto häufiger stellte ich fest, dass ein grosser Teil der verwendeten Elementor-Komponenten heute bereits nativ mit WordPress umgesetzt werden kann.
Der eigentliche Knackpunkt: die Migration
Eine bestehende Elementor-Website neu aufzubauen ist grundsätzlich kein Problem.
Die eigentliche Herausforderung liegt an einem anderen Ort:
Man muss zunächst verstehen, was auf einer Seite überhaupt alles verwendet wird.
Dazu gehören:
- Layout-Strukturen
- Widgets
- globale Styles
- wiederverwendbare Komponenten
- dynamische Inhalte
- Formulare samt ihren Mails
- individuelle Anpassungen
Wie gross das werden kann, zeigt eine der grösseren Websites: 51 Dokumente mit Elementor-Daten, 34 verschiedene Widget-Typen, 266 Widgets insgesamt. Rund 90 Prozent davon liessen sich direkt durch WordPress-Kernblöcke ersetzen. Spannend war auch die Gegenrichtung: Bei einer anderen Site lag die Hälfte aller Widgets in Vorlagen, die gar nirgends mehr verwendet wurden. Ohne Inventar hätte ich sie mühsam nachgebaut.
Genau an diesem Punkt scheitern viele Migrationsprojekte oder werden unnötig aufwendig.
Mein KI-gestützter Migrations-Workflow
Deshalb habe ich einen eigenen KI-gestützten Workflow entwickelt.
Der Prozess läuft vereinfacht in folgenden Schritten ab:
- Lokale Kopie, die nachweislich exakt der Live-Site entspricht. Live bleibt bis zum Umstieg unberührt.
- Analyse und Inventar aller Seiten, Theme-Builder-Vorlagen, Popups, Widgets, Pro-Funktionen und Formulare.
- Zuordnung zu nativen WordPress-Blöcken und Identifikation der Funktionen, die es im Kern nicht gibt.
- Ein eigenes Block Theme mit
theme.json, Vorlagen, Blockstilen und wenig CSS und JavaScript. Ein kleines MU-Plugin kommt nur für Sonderfälle dazu, etwa für Tracking-Code, den bisher Elementor Pro ausgegeben hat. - Wiederaufbau der Inhalte per Import-Skript direkt aus den Elementor-Daten. Texte, Bilder und Links werden übernommen, nicht abgetippt. Den Prototyp schalte ich per Cookie ein und aus, ohne die Datenbank anzufassen.
- Messen statt schätzen: Jede Seite wird in mehreren Bildschirmbreiten gegen das Original verglichen, Texte zeichengenau, Abstände auf den Pixel. Zusätzlich prüfe ich jeden Block auf Gültigkeit im Editor.
- Generalprobe mit Rückweg: Umstieg und Rückweg werden lokal durchgespielt, bevor die Live-Site umgestellt wird. Elementor wird danach nur deaktiviert, nicht gelöscht. Aufgeräumt wird erst nach 2 bis 4 Wochen.
Die KI übernimmt dabei die Fleissarbeit: Elementor-Daten auslesen, Konverter schreiben, im Browser messen, Abweichungen dokumentieren. Was sie dabei lernt, landet in einer Liste mit Stolperfallen, die mittlerweile über 150 Punkte umfasst. Die Entscheide bleiben bei mir: Was vom Original abweicht, was neu formuliert werden muss und wann eine Site live geht.
Was ursprünglich als Experiment begonnen hat, entwickelte sich relativ schnell zu einem wiederholbaren Prozess.
Mittlerweile wurden damit rund 30 Websites erfolgreich migriert.
Die überraschende Erkenntnis
Das Ergebnis hat mich ehrlich gesagt überrascht.
In den meisten Fällen liess sich praktisch die gesamte Funktionalität ohne Elementor nachbauen: Slider, Akkordeons, Popups, Countdown, Mitgliederbereiche mit Passwort, Suche und dynamische Vorlagen. Elementor-Pro-Formulare laufen heute über Fluent Forms, mit denselben Feldern und denselben Mails.
Wie viel Ballast dabei wegfällt, zeigt die Startseite einer der migrierten Websites:
| Startseite | Elementor | Block Theme |
|---|---|---|
| CSS-Dateien | 34 (869 KB) | 3 (87 KB) |
| JavaScript-Dateien | 25 (948 KB) | 3 (33 KB) |
| HTML-Elemente | 926 | 529 |
Gemessen auf der lokalen Kopie, unkomprimiert und ohne Optimierungs-Plugin. Ehrlicherweise: Das CSS direkt im HTML hat leicht zugenommen (von 29 auf 59 KB), und die Kontaktseite braucht wegen des Formular-Plugins weiterhin 9 JavaScript-Dateien. Am Gesamtbild ändert das wenig.
Gleichzeitig profitierten die Websites von verschiedenen Vorteilen:
- weniger Code
- weniger Plugin-Abhängigkeiten: Bei einer Website fielen 4 von 16 aktiven Plugins weg
- weniger Wartungsaufwand, keine Elementor-Datenbank-Updates mehr
- deutlich weniger CSS und JavaScript pro Seite
- kleinere Datenbanken und Backups, sobald nach der Rückfallzeit aufgeräumt ist
- keine laufenden Elementor-Pro-Lizenzkosten
Vor allem wurde deutlich, wie viel Komplexität über die Jahre entstanden war, obwohl die Anforderungen der Website selbst häufig gar nicht so komplex waren. Bei einer Website bestand die Datenbank zu über 90 Prozent aus verwaisten Elementor-Daten längst gelöschter Beiträge. Nach dem Bereinigen schrumpfte sie von 349 auf 24 MB.
Ist Elementor damit überflüssig?
Nein. Elementor hat auch 2026 weiterhin seine Berechtigung. Besonders bei sehr individuellen Landingpages, Marketing-Funnels oder Projekten mit hohen Anforderungen an visuelles Design bietet Elementor nach wie vor Vorteile.
Für viele klassische Unternehmenswebsites, Vereinsseiten oder Content-Websites sehe ich den Bedarf jedoch deutlich kleiner als noch vor einigen Jahren.
Meine wichtigste Erkenntnis lautet deshalb:
Ich habe Elementor nicht verlassen, weil es schlechter geworden wäre. Ich habe es verlassen, weil WordPress heute vieles von dem kann, weshalb ich damals überhaupt zu Elementor gewechselt bin.
Fazit
Brauchen wir Elementor 2026 überhaupt noch?
Ja. Aber deutlich seltener als noch vor fünf oder zehn Jahren.
Für viele Websites überwiegen heute die Vorteile einer nativen WordPress-Lösung: weniger Code, weniger Wartungsaufwand, deutlich weniger CSS und JavaScript, schlankere Datenbanken und keine zusätzlichen Lizenzkosten.
Den KI-Skill, den ich für die Analyse und Migration entwickelt habe, stelle ich auf Anfrage gerne als Markdown-Datei zur Verfügung. Vielleicht hilft er dem einen oder anderen dabei, bestehende Elementor-Projekte auf eine modernere und schlankere Basis zu stellen.
Lohnt sich der Umstieg bei dir?
Und falls du eine bestehende Elementor-Website betreibst und herausfinden möchtest, ob sich eine Migration auf ein Block Theme lohnt, darfst du dich natürlich gerne bei mir melden. Oft lässt sich bereits nach einer kurzen Analyse abschätzen, ob ein Umstieg sinnvoll ist oder ob Elementor für das konkrete Projekt weiterhin die bessere Wahl bleibt.
