Elementor Oder Eigenes Theme: Die Echten Kosten

Der Streit über Elementor oder ein eigenes Theme wird meist als Geschmacksfrage geführt und gelegentlich als Stammeszugehörigkeit. Er ist weder das eine noch das andere. Er ist eine Kostenfrage mit vorhersehbarer Form: Ein Page Builder verschiebt Kosten aus dem Bau in den laufenden Betrieb der Website. Ob das ein guter Tausch ist, hängt an zwei Zahlen, die fast niemand auf den Tisch legt, nämlich wie viele Seiten die Website hat und wie oft sich diese Seiten ändern.

Die Debatte bleibt ungelöst, weil beide Seiten aus Anekdoten argumentieren. Jemand sagt, Builder seien langsam, jemand anders postet einen grünen Lighthouse-Wert, und geklärt ist nichts. Performance ist ein echter Kostenpunkt, aber nur eine Zeile auf einer längeren Rechnung, auf der auch Lizenzverlängerungen stehen, ein Plugin-Stack, der redaktionelle Durchsatz, die Behebung von Barrierefreiheitsmängeln und am Ende der Preis dafür, die eigenen Inhalte wieder herauszubekommen.

Elementor ist kein schlechtes Werkzeug. Für eine große Klasse von Websites ist es die richtige Antwort, und ein ehrlicher Vergleich sagt das zuerst. Die nützliche Frage ist nicht, ob der Builder gut ist, sondern wo er aufhört, sich zu rechnen, und diese Grenze ist schärfer, als das Geschrei vermuten lässt.

Was kostet weniger, Elementor oder ein maßgeschneidertes Theme? Elementor ist günstiger im Bau und teurer im Betrieb. Beim maßgeschneiderten Theme ist es umgekehrt. Der Umschlagpunkt liegt ungefähr dort, wo eine Website mehr als etwa 25 Seiten aus wenigen wiederkehrenden Layouts hat, ohnehin für Entwicklerzeit zahlt und einen Performance- oder Barrierefreiheitsstandard einhalten muss, statt ihn nur anzustreben. Unterhalb dieser Linie gewinnt der Builder meist bei den Gesamtkosten. Oberhalb ist die Ersparnis beim Bau in zwei bis drei Jahren aufgebraucht.

Was ein Page Builder wirklich mit dem Markup macht

Zu behaupten, Builder seien langsam, nützt nichts, weil sie es manchmal nicht sind. Stabil ist der Mechanismus, und er hat drei Teile. Jeder davon ist eine Tendenz und keine Gewissheit, und genau deshalb entscheiden Screenshot-Duelle nie etwas.

Tiefe im Dokument

Ein visueller Builder muss Layout als Container darstellen, und Container sind Elemente. Eine Section enthält eine Spalte, die Spalte enthält ein Widget, das Widget enthält seinen eigenen Wrapper und dann seinen Inhalt. Handgeschriebenes Markup würde dasselbe Design in zwei oder drei Elementen ausdrücken, wo der Builder sechs oder sieben ausgibt.

Diese Tiefe ist nicht umsonst. Style-Recalculation, Layout und Paint skalieren alle damit, wie viele Knoten der Browser durchlaufen muss und wie komplex die dazu passenden Selektoren sind. Googles Leitfaden zu DOM-Größe und Interaktivität setzt die praktischen Marken: Lighthouse warnt ab 800 Knoten und bewertet eine Seite oberhalb von 1.400 als exzessiv. Builder-Seiten überschreiten 1.400 regelmäßig, und eine lange Seite mit mehreren Slidern und einem Mega-Menü erreicht drei- oder viertausend.

Die Kosten fallen zweimal an. Einmal beim ersten Rendern und noch einmal bei jeder Interaktion, die den Baum verändert, weil das Öffnen eines Accordions oder das Filtern einer Liste den Browser dieselbe Arbeit erneut leisten lässt.

Stylesheets, die pro Seite erzeugt werden

Elementors eigener technischer Beitrag zur CSS-Rendering-Performance beschreibt die beiden Ausgabemodi klar: Das CSS wird entweder in ein <style>-Tag im Dokument geschrieben oder in eine Datei, die mit der Seite geladen wird. Die Dateiausgabe ist statisch und wird nur neu erzeugt, wenn sich die Seite ändert.

Beide Modi haben Kosten, die leicht zu übersehen sind. Styling wird pro Seite erzeugt statt seitenweit geteilt, sodass ein Besucher auf dem Weg von der Startseite zu einer Leistungsseite ein frisches Stylesheet lädt, statt ein zwischengespeichertes wiederzuverwenden. Beim internen Einbetten reist das CSS bei jedem Aufruf im HTML mit, was das Dokument aufbläht und Caching vollständig zunichtemacht.

Ein handgebautes Theme dreht das um. Ein Stylesheet, einmal zwischengespeichert, überall wiederverwendet, und die zweite Seite, die ein Besucher öffnet, kostet beim CSS fast nichts.

Skripte, die laufen, bevor das Layout steht

Widgets bringen eigenes JavaScript mit. Slider, Tabs, Accordions, Zähler, Popups und Formulare registrieren jeweils Handler, und mehrere davon legen ihre endgültigen Maße erst zur Laufzeit fest. Wenn die Position von Inhalt erst feststeht, nachdem ein Skript gelaufen ist, zeichnet der Browser ein Layout und danach ein anderes.

Das ist das klassische Muster für Layout-Verschiebungen, und es verstärkt sich mit Medien ohne Maßangaben und spät geladenen Webfonts. Nichts davon ist unbehebbar, aber die Korrekturen erfolgen pro Widget, sie müssen nach jeder Bearbeitung der Seite erneut angewendet werden, und wer die Seite bearbeitet, ist meist nicht die Person, die sie angewendet hat.

Core Web Vitals, und welcher Metrik ein Builder wirklich schadet

Zuerst der richtige Satz an Metriken, denn ein großer Teil des Builder-Kommentars streitet noch über eine Metrik, die es nicht mehr gibt. Es gibt drei Core Web Vitals, und Googles Definitionen geben die Schwellen für eine gute Erfahrung genau an: Largest Contentful Paint sollte innerhalb von 2,5 Sekunden nach dem Ladebeginn der Seite eintreten, Interaction to Next Paint sollte bei 200 Millisekunden oder darunter liegen, und Cumulative Layout Shift bei 0,1 oder darunter. Alle drei werden am 75. Perzentil der Seitenaufrufe bewertet, getrennt für Mobil und Desktop gemessen.

First Input Delay ist Geschichte. Interaction to Next Paint hat es am 12. März 2024 als stabiles Core Web Vital abgelöst, und die Änderung ist hier wichtig, weil FID nur die Verzögerung vor der Verarbeitung der ersten Interaktion maß, was schwere Seiten schmeichelhaft aussehen ließ. INP misst den vollständigen Weg von der Eingabe bis zum nächsten gezeichneten Frame, über die Interaktionen der Seite hinweg, und greift nahezu den schlechtesten Wert heraus.

Warum INP die Metrik ist, die sich wehrt

Largest Contentful Paint ist weitgehend ein Auslieferungsproblem. Besseres Hosting, ein CDN, korrekt dimensionierte und komprimierte Bilder, ein vorgeladenes Hero-Bild, weniger renderblockierende Ressourcen, und die meisten Builder-Seiten kommen unter 2,5 Sekunden, ohne den Builder selbst anzufassen.

Cumulative Layout Shift ist ein Disziplinproblem. Maße an Medien setzen, Platz für alles reservieren, was nachträglich eingefügt wird, Schriften so laden, dass die Seite nicht neu umbricht, und 0,1 ist erreichbar.

Interaction to Next Paint ist ein strukturelles Problem. Es misst, wie viel Arbeit der Haupt-Thread erledigen muss, bevor er antworten kann, und tiefes Markup plus ein Stapel Widget-Skripte ist genau diese Arbeit. Da lässt sich nichts wegcachen, und ein schnellerer Server hilft nicht. Hier gehen eine Elementor-Seite und ein schlankes maßgeschneidertes Theme am weitesten auseinander, und hier bleiben sie auch auseinander, wenn die einfache Optimierung erledigt ist. Unser Leitfaden zum WordPress-Performance-Audit zeigt, wie man diese drei Probleme auf einer Live-Website voneinander trennt.

Was sich wirklich verbessert hat

Fair zu sein ist hier keine Höflichkeit, sondern Genauigkeit, denn viel von der Kritik an Elementor zielt auf die Version von 2019.

Elementor liegt im WordPress-Plugin-Verzeichnis inzwischen als Version 4.2.4 vor, verlangt WordPress 6.8 oder höher und PHP 7.4 oder höher und weist über 10 Millionen aktive Installationen aus. Editor V4 hat die Element-Architektur um das herum neu gebaut, was Elementor atomare Elemente nennt, mit einem CSS-First-Ansatz und, in den Worten des Unternehmens, ohne „den Overhead alter DOM-Aufblähung". Elementor gibt an, dass der Atomic Editor ab 4.0 die Standarderfahrung für alle neuen Websites ist.

Zwei Einschränkungen wiegen schwerer als die Schlagzeile. Erstens bekommen bestehende Websites das nicht durch ein Update. Elementor sagt ausdrücklich, dass ein Update auf 4.0 aktuelle Live-Websites nicht verändert und dass die neuen Funktionen manuell aktiviert werden, sodass eine 2022 gebaute Website ihre Ausgabe von 2022 behält, bis jemand sie neu baut. Zweitens existieren V3- und V4-Elemente während der Migration auf derselben Seite nebeneinander, was bedeutet, dass eine teilweise migrierte Seite beide Architekturen und beide Overhead-Sätze trägt.

Behandeln Sie die Verbesserung als real und als nach vorn gerichtet. Sie verändert, was eine neue Elementor-Website sein kann. Sie verändert nicht, was Ihre bestehende gerade ist.

Der Lock-in-Mechanismus, richtig formuliert

Das ist das stärkste Argument gegen einen Builder, und es wird fast immer schlecht vorgetragen. Die übliche Fassung, man bleibe mit einem Bildschirm voller kaputter Shortcodes zurück, trifft nicht ganz zu und ist leicht abzutun. Die zutreffende Fassung ist schlimmer.

Elementors Dokumentation zur Datenstruktur sagt genau, wo Ihre Seiten liegen: Der Editor speichert Seitendaten und Layout im JSON-Format als WordPress-Post-Metadaten in der Tabelle wp_postmeta, und die Dokumentation vermerkt, dass sie als privates Custom Field abgelegt werden, das im WordPress-Dashboard nicht sichtbar ist. Ihr Layout, Ihr Styling und ein Großteil Ihrer Texte sitzen in einer serialisierten Struktur, die nur Elementor lesen kann.

Vergleichen Sie das mit dem WordPress-Core. Der Block-Editor serialisiert Blöcke in post_content als HTML mit HTML-Kommentar-Trennzeichen, wobei Attribute als JSON-Literale in den Kommentaren mitgeführt werden. Das erklärte Ziel des Core ist eine einzige Quelle der Wahrheit, die lesbar bleibt und mit allem anderen kompatibel ist, das WordPress-Inhalte anfasst. Nehmen Sie den Block-Editor weg, und im Content-Feld steht immer noch gültiges HTML.

Das ist der ganze Unterschied. Ein System bewahrt Ihre Inhalte dort auf, wo WordPress Inhalte immer aufbewahrt hat. Das andere legt sie in ein privates Feld daneben.

Was das für den Relaunch in drei Jahren bedeutet

Deaktivieren Sie Elementor, und die Seiten verschlechtern sich nicht sanft. WordPress rendert post_content, was bei einer Builder-Seite typischerweise leer oder ein Fragment ist, also wird die Seite nicht schlicht, sondern leer. Gelöscht wurde nichts, aber es rendert auch nichts.

Praktisch macht das aus einem Relaunch zwei Projekte. Sie wechseln nicht das Theme, Sie führen eine Content-Migration durch: das gerenderte HTML Seite für Seite extrahieren oder das JSON parsen und dann jedes Layout im neuen System neu aufbauen. Budgetieren Sie es als Migration, und es ist beherrschbar. Entdecken Sie es mitten im Relaunch, und es ist das, was den Zeitplan sprengt. Es gilt dieselbe Disziplin wie bei jeder CMS-Migration, bei der die Arbeit, die über das Ergebnis entscheidet, stattfindet, bevor irgendetwas abgeschaltet wird.

Das ehrliche Argument für Elementor

Es gibt eine reale Klasse von Websites, bei denen der Builder kein Kompromiss ist, sondern die richtige technische Entscheidung, und diese Klasse ist groß.

Eine Broschüren-Website mit zehn bis zwanzig Seiten. Kein interner Entwickler und keine Absicht, einen einzustellen. Eine Person im Marketing, die heute Nachmittag eine Überschrift ändern, ein Foto tauschen oder eine Landingpage veröffentlichen muss, ohne Ticket, Branch und Deployment. Ein Budget, das für einen maßgeschneiderten Bau wirklich nicht reicht, wo die Alternative keine bessere Website ist, sondern eine schlechtere oder gar keine.

Für dieses Profil verwandelt ein Builder eine Entwicklerabhängigkeit in ein Abonnement, und das ist meist ein guter Tausch. Eine Website, die niemand in der Organisation aktualisieren kann, ist ein schlechteres Gut als eine etwas schwerere Website, die das Marketingteam vollständig besitzt. Der Fehlerfall der maßgeschneiderten Route ist nicht Langsamkeit, sondern eine Website, die veraltet, weil jede Änderung jemanden von außen braucht.

Es gibt ein zweites ehrliches Argument, nämlich das Tempo bis zum ersten Umsatz. Eine glaubwürdige Website in drei Wochen statt in drei Monaten live zu haben, hat einen Wert, den keine Core-Web-Vitals-Zahl erfasst, und für ein junges Unternehmen ist dieser Wert oft größer als alles bisher Besprochene.

Die Entscheidungsregel für Elementor oder eigenes Theme

Hier ist eine Regel, die Sie auf Ihre eigene Website anwenden können statt auf eine allgemeine. Bewerten Sie diese sechs Punkte und behandeln Sie drei oder mehr davon als den Punkt, an dem ein Builder mehr kostet, als er spart.

Seitenzahl gegen Anzahl der Templates. Mehr als etwa 25 Seiten aus weniger als acht verschiedenen Layouts heißt, dass Sie für Wiederholung zahlen. Ein Theme drückt diese Wiederholung einmal aus, ein Builder lässt Sie sie an 25 Stellen pflegen.

Redaktioneller Durchsatz. Mehr als eine Handvoll Inhaltsänderungen pro Woche, von mehr als einer Person, heißt, dass Werkzeuge und Review-Prozess wichtiger sind als das Bearbeitungserlebnis.

Ein Design-System, das bereits existiert. Wenn es ein echtes Token-Set in Figma gibt, kann ein Theme es einmal kodieren und durchsetzen. Ein Builder kann nichts durchsetzen, weil jede Seite alles überschreiben kann.

Mehrsprachige Inhalte. Jede Sprache vervielfacht die Builder-Strukturen, die Sie pflegen, und Übersetzungs-Plugins vertragen sich schlecht mit Layout, das außerhalb von post_content liegt.

Ein vertraglich zugesagtes Performance-Budget. Wenn Core Web Vitals in einer Ausschreibung, einem SLA oder einem Kundenvertrag auftauchen, brauchen Sie eine Untergrenze, die Sie kontrollieren, statt einer Zahl, auf die Sie hoffen.

Eine Verpflichtung zur Barrierefreiheit. Weiter unten behandelt, und für sich allein oft ausschlaggebend.

Trifft nichts davon zu, nutzen Sie den Builder und stecken Sie die Ersparnis in Inhalte. Treffen vier oder mehr zu, ist ein maßgeschneidertes Theme kein Luxus, sondern über die Lebensdauer der Website die günstigere Option.

Der Mittelweg, den die meisten Vergleiche auslassen

Es gibt eine dritte Option, und sie ist weder ein maßgeschneidertes Theme noch ein Builder eines Drittanbieters. Der WordPress-Core liefert Full Site Editing seit 5.9 im Januar 2022 aus, und der Site Editor ist inzwischen ein ausgereifter Teil des Produkts.

Die wichtige Einschränkung steht klar in der Dokumentation zum Site Editor: Der Site Editor ist nur verfügbar, wenn Sie ein Block-Theme installieren und aktivieren. Mit einem aktiven Block-Theme bekommen Redakteure Identity, Styles, Pages, Navigation, Patterns und Templates, und seit WordPress 6.3 können sie Seiten von dort aus verwalten und bearbeiten. Globale Styles, Typografie, Farbpaletten und Layout werden einmal in der theme.json des Themes gesetzt und website-weit angewendet.

Damit ist der größte Teil des echten Nutzens eines Builders gelöst. Das Marketing kann eine Seite ändern, einen Header bearbeiten, die Website umgestalten und veröffentlichen, ohne ein Deployment. Dazu kommt das, was der Builder nicht gibt: Inhalte in post_content, ein vom Entwickler definiertes Design-System, keine Lizenz eines Drittanbieters und ein Export im Site Editor, der ein ZIP des Themes samt Ihrer Templates und Styles erzeugt.

Nicht gelöst ist damit die Disziplin. Ein Block-Theme mit lockerer theme.json und einem Haufen Block-Plugins von Drittanbietern reproduziert die Probleme des Builders innerhalb des Core, einschließlich des Lock-in, denn diese Blöcke verlassen Ihre Seiten, wenn das Plugin geht. Es braucht außerdem weiterhin einen Entwickler für die saubere Einrichtung, und eine bestehende Elementor-Website darauf umzuziehen, bleibt eine Content-Migration.

Barrierefreiheit, wo Builder still versagen

Das ist der Fehlerfall, den niemand vorführt, und der, aus dem ein rechtliches Problem wird statt einer langsamen Seite.

Die Überschriftenreihenfolge folgt dem Layout, nicht der Bedeutung. Jemand wählt H3, weil H2 zu groß aussah, und die Dokumentgliederung beschreibt den Inhalt nicht mehr. Das ist WCAG 2.2 Erfolgskriterium 1.3.1 Info and Relationships auf Level A, dazu 2.4.6 Headings and Labels auf Level AA. Nichts im Builder verhindert es, weil die Überschriftensteuerung ein Styling-Werkzeug ist.

Kontrast-Voreinstellungen. 1.4.3 Contrast (Minimum) auf Level AA verlangt ein Verhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text, und 1.4.11 Non-text Contrast verlangt mindestens 3:1 für Interface-Komponenten und grafische Objekte gegenüber angrenzenden Farben. Hellgrauer Fließtext auf Weiß und blasse Icons auf getöntem Grund sind die beiden häufigsten Fehler, die wir auf Builder-Websites finden, und beide stammen direkt aus einem Template, das in der Demo gut aussah.

Die Fokusreihenfolge in verschachtelten Containern. 2.4.3 Focus Order auf Level A verlangt, dass fokussierbare Komponenten in einer Reihenfolge fokussiert werden, die Bedeutung und Bedienbarkeit erhält, und 2.4.7 Focus Visible auf Level AA verlangt einen sichtbaren Fokusindikator. Tief verschachtelte Container, absolut positionierte Overlays und Popups brechen beides regelmäßig, und Builder-Themes entfernen die voreingestellte Fokuskontur häufig, weil sie unordentlich aussah.

Im Vereinigten Königreich ist das für viele Organisationen nicht optional. GOV.UK sagt ausdrücklich, dass öffentliche Stellen WCAG 2.2 auf Level AA nach den Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 erfüllen und eine Erklärung zur Barrierefreiheit veröffentlichen müssen. Diese Anforderung wandert zunehmend über Lieferantenfragebögen in die private Beschaffung. Generiertes Markup nachzubessern ist deutlich schwerer, als Markup zu korrigieren, das Sie selbst geschrieben haben.

Was die einzelnen Wege wirklich kosten

Die Lizenzzeile, die Sie selbst prüfen können

Zuerst die Lizenzpreise, denn das ist die einzige Zahl in diesem Abschnitt, die nicht von uns stammt. Elementor veröffentlicht Preise direkt in GBP, es ist also keine Umrechnung im Spiel. Auf Elementors Preisseite, gelesen am 2. September 2026, reichen die Jahrespläne von 48 GBP pro Jahr für Essential über 72 GBP für Advanced Solo und 84 GBP für Advanced bis zu 168 GBP pro Jahr für Expert. Die neueren gebündelten Stufen liegen bei 144 GBP pro Jahr für Elementor One und 348 GBP pro Jahr für One Agency.

Die übrigen Zahlen unten sind die Bänder, die wir aufrufen, keine veröffentlichten Werte, und sie gehen von der Website eines britischen kleinen bis mittelgroßen Unternehmens aus, nicht von einem E-Commerce-Projekt.

Bau, laufende Kosten und der Relaunch am Ende

Lesen Sie das als Prosa, denn die Tabelle fasst es nur zusammen. Eine Builder-Website ist im Bau um den Faktor drei oder mehr die günstigste und im Betrieb die teuerste, weil die Jahreszahl die Elementor-Lizenz trägt, dazu die Premium-Addons, die fast immer dazukommen, dazu den Plugin-Stack, der darum herum wächst, dazu die regelmäßige Performance-Arbeit, die nie ganz fertig wird.

Die Relaunch-Spalte ist die, in der sich der Vergleich auflöst. Eine Builder-Website neu zu bauen kostet mehr als eine themebasierte, aus dem oben genannten Grund: Der Inhalt muss extrahiert werden, bevor er neu gebaut werden kann. Über fünf Jahre landen eine Builder-Website für 4.000 GBP und eine maßgeschneiderte für 20.000 GBP näher beieinander, als beide Seiten erwarten, und welche gewinnt, hängt an Seitenzahl und Änderungsfrequenz, nicht am Geschmack. Unsere Kostenaufschlüsselung für Websites zeigt, wie sich diese Bänder bei größeren Projekten verhalten, und unsere Seite zur Website-Entwicklung beschreibt, was ein maßgeschneiderter Bau umfasst.

Wenn Sie schon auf einem Builder sind und heraus wollen

Die Migration ist beherrschbar, wenn Sie sie richtig sequenzieren, und schmerzhaft, wenn nicht.

Beginnen Sie mit einer Inventur statt mit einem Plan. Fragen Sie die Post-Meta ab, um herauszufinden, welche Seiten tatsächlich Builder-Daten tragen, denn auf den meisten Websites sind es weit weniger als erwartet, und die Blogbeiträge sind ohnehin meist schlichter Inhalt. Dann triagieren Sie: neu bauen, konvertieren oder löschen. Die meisten Websites tragen einen langen Schwanz an Seiten, die seit einem Jahr niemand besucht hat und für deren Migration niemand zahlen sollte.

Extrahieren Sie, bevor Sie neu bauen. Rendern Sie jede verbleibende Seite und bewahren Sie das HTML auf, oder parsen Sie das JSON aus der Post-Meta, damit Sie den Inhalt in einer vom Plugin unabhängigen Form haben. Tun Sie das auch für Seiten, die Sie von Hand neu bauen wollen, denn es ist Ihre einzige Kopie, sobald das Plugin geht.

Behalten Sie die URLs. Ein Neubau ist kein Grund, Adressen zu ändern, und jede geänderte Adresse braucht eine Weiterleitung auf ihr konkretes Gegenstück.

Arbeiten Sie dann Seite für Seite, lassen Sie Elementor installiert, bis die letzte Seite davon los ist, und messen Sie Interaction to Next Paint vorher und nachher an echten Felddaten statt an einem Laborwert, denn ein Laborwert auf einem schnellen Laptop wird Ihnen sagen, das Problem habe nie bestanden.

Wo das hinführt

Die Wahl ist nicht ideologisch. Ein Builder ist eine legitime Antwort für eine kleine, sich langsam ändernde Website ohne Entwickler, und er ist weit häufiger die richtige Antwort, als Entwickler zugeben mögen. Er hört auf, die richtige Antwort zu sein, sobald Seitenzahl, Template-Wiederverwendung, redaktioneller Durchsatz oder eine harte Performance- oder Barrierefreiheitsanforderung ins Spiel kommt, und die Kosten dafür, darüber hinaus dabeizubleiben, werden still bezahlt, in Jahreslizenzen, in Nachbesserung und am Ende in einer Migration.

Mecanik baut beides. Wir betreiben Builder-Websites für Kunden, bei denen das die sinnvolle Ökonomie ist, und wir ersetzen sie, wenn es das nicht mehr ist, meist durch ein Block-Theme auf dem Core statt durch einen vollständig maßgeschneiderten Bau. Wenn Sie eine klare Antwort wollen, auf welcher Seite der Linie Ihre Website steht, beschreiben unsere Seiten zur Website-Entwicklung und zur WordPress-Entwicklung, wie wir das abstecken, und der Leitfaden dazu, was man bei der Beauftragung eines WordPress-Entwicklers fragen sollte, zeigt, wie Sie jeden prüfen, mit dem Sie sprechen, uns eingeschlossen.

Häufig gestellte Fragen

Ist Elementor schlecht für SEO? Nein. Elementor blockiert die Indexierung nicht, und eine gut gebaute Elementor-Seite rankt wie jede andere Seite. Der Druck auf die Suche ist indirekt und landet bei den Core Web Vitals, vor allem bei Interaction to Next Paint, weil tiefes generiertes Markup und Widget-Skripte dem Haupt-Thread mehr Arbeit geben. Vitals sind einer von vielen Faktoren, also schlägt eine langsame Builder-Seite mit besseren Inhalten weiterhin eine schnelle Seite mit schlechteren.

Was passiert mit meinen Seiten, wenn ich Elementor deaktiviere? Das Layout verschwindet. Elementor hält die Seitenstruktur als JSON in einem privaten Custom Field in der Tabelle wp_postmeta statt in post_content, also rendert WordPress nach dem Deaktivieren nur das, was in post_content steht, und das ist bei einer Builder-Seite meist leer oder ein Fragment. Gelöscht wird nichts, aber es rendert auch nichts, und die Seiten zurückzuholen ist eine Datenmigration und kein Theme-Wechsel.

Was kostet ein individuelles WordPress-Theme im Vereinigten Königreich? Die Bänder, die wir aufrufen, liegen bei ungefähr 12.000 bis 40.000 GBP für ein maßgeschneidertes Theme, 6.000 bis 18.000 GBP für ein Block-Theme auf dem WordPress-Core und 2.000 bis 6.000 GBP für eine Builder-Website. Die maßgeschneiderte Zahl sieht am ersten Tag am schlechtesten aus und über fünf Jahre am besten, weil sie keine Lizenz trägt, einen kleineren Plugin-Stack und am Ende einen weit günstigeren Relaunch.

Kann eine Elementor-Website die Core Web Vitals bestehen? Ja, und viele tun es. Largest Contentful Paint unter 2,5 Sekunden und Cumulative Layout Shift unter 0,1 sind mit gutem Hosting, dimensionierten Medien und Zurückhaltung bei Widgets meist erreichbar. Interaction to Next Paint unter 200 Millisekunden ist der Wert, der sich wehrt, weil er die Arbeit des Haupt-Threads abbildet und nicht die Auslieferung, und genau dort kosten Builder-Markup und Widget-Skripte am meisten.

Ist ein Block-Theme die bessere Alternative zu Elementor? Oft ja, und es ist die Option, die die meisten Vergleiche auslassen. Block-Inhalte liegen als HTML mit Kommentar-Trennzeichen in post_content und überstehen daher einen Theme-Wechsel, und der Site Editor lässt das Marketing Templates und Styles ohne Deployment bearbeiten. Kostenlos ist das nicht: Der Site Editor braucht ein Block-Theme, und jemand muss das Design-System sauber definieren, sonst haben Sie dasselbe Problem im Core nachgebaut.