Elementor Pro lädt nicht oder zeigt eine weiße Seite – Was ist Schritt für Schritt zu prüfen?

Lesezeit: ~9 Min. · Niveau: mittel

Sie klicken auf „Edit with Elementor“ – und statt des Editors erhalten Sie eine weiße Seite oder ein endlos drehendes Ladesymbol. Manchmal erscheint die Meldung „There has been a critical error on this website“. Das sieht dramatisch aus. In der Praxis liegt die Ursache in 80 % der Fälle bei einer von wenigen wiederkehrenden Gründen: einem Konflikt von Plugins oder Theme, einem zu niedrigen PHP-Speicherlimit, inkompatiblen Versionen von Elementor und Elementor Pro, aggressivem Caching oder Server-Headern, die das iFrame blockieren. Dieser Artikel führt Sie durch eine diagnostische Reihenfolge – von den einfachsten Tests (Cache, Inkognito-Modus) bis zu schwereren Kalibern (Safe Mode, WP_DEBUG, Versions-Rollback). Die meisten Fälle lösen Sie selbst, ohne Hosting-Support und ohne Verlust von Seiteninhalten.

1. Beginnen Sie mit den einfachsten Tests – leeren Sie den Cache (Browser, Plugin, Cloudflare) und öffnen Sie den Editor im Inkognito-Modus.
2. Prüfen Sie die Anforderungen: WordPress 6.5+, PHP 7.4+ (besser 8.0+), mindestens 256M Speicher für eine typische Website.
3. Aktivieren Sie den Safe Mode unter „Elementor > Tools“ – er deaktiviert Plugins und Theme und lässt nur Elementor übrig.
4. Aktualisieren Sie nach einem Update von Elementor Pro auch den kostenlosen Elementor – eine Versionsinkompatibilität verursacht einen Fatal Error.
5. Wenn nichts hilft: Aktivieren Sie WP_DEBUG, lesen Sie debug.log, und machen Sie bei Bedarf ein Rollback über „Tools > Version Control“.

Was sind typische Symptome eines Elementor-Pro-Ausfalls und wie erkennt man sie?

Ein Ausfall von Elementor nimmt mehrere verschiedene visuelle Formen an, und jede davon lenkt die Diagnose in eine andere Richtung. Ein richtig benanntes Symptom verkürzt die Arbeit um die Hälfte. Statt wahllos alle möglichen Ursachen durchzuprobieren, beginnen Sie mit den häufigsten für das jeweilige Szenario.

Wodurch unterscheidet sich eine weiße Seite von einem hängenden Editor-Loader?

Die weiße Seite (White Screen of Death, WSOD) ist ein völlig leerer Browserbildschirm – kein einziges Interface-Element. Meistens bedeutet das einen PHP-Fatal-Error: Etwas im Code eines Plugins oder Themes hat die Skriptausführung gestoppt, und der Server hat statt der Seite eine leere Antwort zurückgegeben.

Ein hängender Loader ist eine andere Geschichte. Das linke Panel von Elementor lädt normal – Sie sehen Menü, Widgets, Einstellungen –, aber der mittlere Vorschaubereich der Seite bleibt leer mit einem sich drehenden Ladesymbol. Was bedeutet das? PHP hat funktioniert (das Panel wurde aufgebaut), aber das Vorschau-iFrame hat die JS/CSS-Ressourcen nicht geladen, oder ein Server-Header hat es blockiert.

Falle: Viele Nutzer verwechseln diese beiden Zustände und greifen zu Lösungen aus der falschen Kategorie. Ein hängender Loader hat selten mit dem PHP-Speicherlimit zu tun – häufiger ist der Übeltäter der X-Frame-Options-Header, Cloudflare Rocket Loader oder eine Browser-Erweiterung, die Skripte blockiert.

Wann betrifft das Problem das Frontend und wann nur den Editor?

Ein Frontend-WSOD ist ein Zeichen, dass die Seite für Besucher nicht funktioniert. Höchste Priorität. Prüfen Sie zunächst, ob Sie überhaupt in wp-admin gelangen. Wenn ja – betrifft das Problem nur den öffentlichen Teil der Website, und die Ursache liegt meist beim Theme oder einem fehlerhaft gebauten Widget.

Ein Problem, das sich auf den Editor beschränkt, sieht ganz anders aus. Die Seite funktioniert für Nutzer, das Admin-Panel funktioniert, aber nach einem Klick auf „Edit with Elementor“ – Leere. Dieses Szenario ist deutlich häufiger und deutlich weniger dramatisch. Sie arbeiten in aller Ruhe an der Lösung, ohne den Stress, dass das Unternehmen jede Minute Kunden verliert.

Was bedeutet die Meldung „There has been a critical error on this website“?

Diese Meldung hat die klassische weiße Seite in neueren WordPress-Versionen ersetzt. Der Text ist immer derselbe, aber im Hintergrund sendet WordPress dem Administrator eine E-Mail mit einem Link zum Wiederherstellungsmodus (Recovery Mode). Dort finden Sie die konkrete Fehlermeldung und den Namen des Plugins, das sie verursacht hat.

Prüfen Sie das Postfach der Administrator-Adresse, die unter „Einstellungen > Allgemein“ eingestellt ist. In der Nachricht befindet sich ein Link ?action=enter_recovery_mode mit einem Token. Ein Klick meldet Sie im Panel im Notfallmodus an, in dem das problematische Plugin deaktiviert ist.

Erfüllen Ihr Server und WordPress die Anforderungen von Elementor Pro?

Nicht erfüllte Serveranforderungen sind die zweithäufigste Ursache für eine weiße Seite, gleich nach Konflikten. Elementor hat die Anforderungen 2024 aktualisiert. Ältere Anleitungen, die sich auf PHP 5.6 oder WordPress 5.x beziehen, sind heute technisch veraltet.

Welche Mindest- und empfohlenen Versionen von WordPress und PHP gibt es?

Die offizielle Anforderungsseite von Elementor gibt WordPress 6.5+ und PHP 7.4+ als technisches Minimum an. In der Praxis sollten Sie bei PHP 8.0 oder 8.1 bleiben – schneller, sicherer, besser vom Hersteller getestet. Das Plugin-Repository nennt zusätzlich ein Mindestspeicherlimit von 64 MB, aber das ist ein rein formaler Wert, der sich für reale Arbeit nicht eignet.

Wie prüft man das aktuelle PHP-Speicherlimit im WordPress-Panel?

WordPress zeigt diese Daten an zwei Stellen an. Beide sind über das Administrationspanel anklickbar.

In „Website-Zustand > Informationen“ öffnen Sie den Abschnitt Server. Dort finden Sie die Felder PHP memory limit und WordPress memory limit. Das sind zwei unterschiedliche Werte – beide müssen ausreichend hoch sein. Das PHP memory limit legt das Hosting fest (php.ini), das WordPress memory limit legt die Konstante WP_MEMORY_LIMIT in wp-config.php fest.

Wie erhöht man WP_MEMORY_LIMIT in wp-config.php oder im Hosting-Panel?

Der schnellste Weg führt über die Datei wp-config.php im Hauptverzeichnis der WordPress-Installation. Öffnen Sie die Datei über den File Manager des Hostings oder per FTP und fügen Sie eine Zeile über dem Kommentar /* That's all, stop editing! */ hinzu:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Die erste Zeile legt das Limit für das Frontend fest, die zweite für administrative Aufgaben: Importe, Updates, den Editor. Öffnen Sie nach dem Speichern der Datei „Website-Zustand > Informationen“ und prüfen Sie, ob der neue Wert erscheint.

Hat die Bearbeitung von wp-config.php nicht geholfen? Das Hosting hat global ein niedrigeres Limit erzwungen. Melden Sie sich im Hosting-Panel an, suchen Sie ein Tool wie „Multi-PHP INI Editor“ oder „Select PHP Version“ und erhöhen Sie memory_limit auf 256M oder 512M. Bei Shared-Hosting kann dieser Parameter blockiert sein. Dann bleibt Ihnen nur eine Option: Kontakt zum Support oder ein Wechsel des Pakets.

Profi-Tipp: Erzwingen Sie nach dem Erhöhen des Speicherlimits einen Neustart des PHP-Prozesses. In cPanel erledigen Sie das über „Select PHP Version > (Version hin- und zurückwechseln)“. In DirectAdmin über „PHP Selector“. Ohne Neustart wirkt sich der neue Wert nicht auf laufende Prozesse aus.

Wie leert man den Cache und schließt ein Problem auf Browserseite aus?

Der Cache ist der erste Verdächtige bei jedem seltsamen Verhalten von Elementor. Das Problem? In WordPress existiert der Cache an sechs Stellen gleichzeitig. Nur einen davon zu leeren, reicht nicht aus.

Welche Cache-Ebenen müssen geleert werden (Browser, Plugin, Cloudflare)?

Leeren Sie den Cache der Reihe nach, beginnend mit der äußersten Ebene. Sie starten mit Cloudflare – im Panel „Caching > Configuration > Purge Everything“. Danach das Cache-Plugin in WordPress: WP Rocket, LiteSpeed Cache oder W3 Total Cache – Option „Clear Cache“ oder „Purge All“. Anschließend Elementor selbst: „Tools > Regenerate Files & Data“. Zum Schluss der Browser-Cache über Strg+Umschalt+R (Hard Refresh) oder öffnen Sie die Seite im Inkognito-Modus.

Prüfen Sie einen bestimmten HTTP-Header, um zu bestätigen, ob die Antwort aus dem Cache oder vom Origin-Server kommt:

curl -I https://twojadomena.pl/?nocache=1

Suchen Sie in der Antwort nach den Headern CF-Cache-Status (Cloudflare) und X-Cache (Server). Der Wert HIT bedeutet, dass die Antwort aus dem Cache kam. MISS oder BYPASS – die Anfrage ging zum Origin. Die zweite Variante ist ein gutes Zeichen: Der Cache ist geleert.

Wie prüft man, ob eine Browser-Erweiterung den Editor blockiert?

Adblock, uBlock Origin, NoScript, Privacy Badger und ähnliche Add-ons können JavaScript-Ressourcen blockieren, die von Elementor geladen werden. Das klassische Symptom? Der Editor funktioniert in einem Browser, in einem anderen zeigt er ein leeres Panel, und im Inkognito-Modus läuft alles reibungslos.

1. Schritt 1 (10 Sek.): Öffnen Sie dieselbe Seite im Inkognito-Modus (Strg+Umschalt+N in Chrome).
2. Schritt 2 (30 Sek.): Wenn es im Inkognito-Modus funktioniert – wechseln Sie zurück in den normalen Modus und deaktivieren Sie die Erweiterungen nacheinander.
3. Schritt 3 (1 Min.): Setzen Sie nach dem Finden des Übeltäters die Domain der Website auf die Whitelist, statt das Add-on dauerhaft zu deaktivieren.

Warum kann Cloudflare Rocket Loader das Laden des Editors stören?

Rocket Loader ist eine Cloudflare-Funktion, die das Laden von JavaScript-Skripten verzögert, um die Seite schneller zu rendern. Klingt sinnvoll. Nur dass Elementor auf einer bestimmten Reihenfolge der Skript-Initialisierung basiert – Rocket Loader bringt diese Reihenfolge durcheinander, und der Editor funktioniert nicht mehr.

Deaktivieren Sie Rocket Loader im Cloudflare-Panel: „Speed > Optimization > Rocket Loader > Off“. Deaktivieren Sie dabei auch „Auto Minify JavaScript“ für die Dauer der Diagnose. Nach der Bearbeitung können Sie beide Optionen wieder aktivieren, aber fügen Sie für die Editor-Domain eine Page Rule hinzu, die den Pfad /wp-admin/* von Rocket Loader ausschließt.

Wie nutzt man den Safe Mode, um einen Konflikt von Plugins oder Theme zu erkennen?

Der Safe Mode ist das stärkste Diagnosewerkzeug, das Elementor eingebaut hat. Sie aktivieren ihn mit einem Klick und wissen sofort, ob das Problem in Elementor selbst oder in seiner Umgebung liegt.

Wo im Panel aktiviert man den Safe Mode und was genau macht dieser Modus?

Safe Mode isolates Elementor and WordPress from the themes and plugins that may be causing the error.

Offizielle Elementor-Dokumentation — What is Safe Mode

In der Praxis deaktiviert der Safe Mode vorübergehend alle anderen Plugins und lädt ein leeres Theme anstelle Ihres eigenen. Aber nur für den Editor – das Frontend der Website bleibt für Besucher unberührt.

Kehren Sie nach der Aktivierung zu einer beliebigen Seite zurück und klicken Sie auf „Edit with Elementor“. Lädt der Editor normal? Dann ist ein Plugin oder das Theme schuld. Funktioniert es immer noch nicht? Dann liegt das Problem bei Elementor selbst, in der Serverkonfiguration oder im Browser.

Wie findet man das problematische Plugin nach der Deaktivierung systematisch?

Deaktivieren Sie den Safe Mode und gehen Sie zu „Plugins > Installierte Plugins“. Die schnellste Methode? Selektive Deaktivierung statt einzelnes Ausschalten:

1. Deaktivieren Sie alle Plugins außer „Elementor“ und „Elementor Pro“.
2. Prüfen Sie, ob der Editor funktioniert. Er sollte – Sie haben gerade 99 % der potenziellen Übeltäter eliminiert.
3. Aktivieren Sie die Plugins in Fünferpaketen und testen Sie den Editor nach jedem Paket.
4. Wenn ein Paket den Editor zum Absturz bringt – deaktivieren Sie es und aktivieren Sie die Plugins aus diesem Paket einzeln.
5. Nach dem Auffinden des Konflikts prüfen Sie Updates für das Plugin, melden Sie das Problem dem Autor oder suchen Sie nach einer Alternative.

Die Paketmethode verkürzt die Diagnosezeit bei 30 Plugins von 30 Versuchen auf 5–8 Versuche. Es ist der Ansatz der „binären Suche“, den Programmierer bei der Fehlersuche verwenden.

Wann ist das Theme schuld und wie bestätigt man das?

Hat die Deaktivierung aller Plugins nicht geholfen? Verdächtiger Nummer eins ist das Theme. Gehen Sie zu „Design > Themes“ und aktivieren Sie ein Standard-Theme – Twenty Twenty-Four oder Hello Elementor, das speziell für Elementor entwickelt wurde und federleicht ist.

Prüfen Sie den Editor. Funktioniert er? Dann war das Theme schuld. Theme-Updates von ThemeForest warten oft lange auf Kompatibilität mit neueren Elementor-Versionen. Ein dokumentierter Fall im ThemeIsle-Blog zeigte ein Theme, das erst 2 Monate nach der Veröffentlichung von Elementor 3.21 aktualisiert wurde – es erzeugte einen WSOD bis zur Veröffentlichung des Updates „fixed bug from plugins update feedback“.

Was tun, wenn nach einem Update von Elementor Pro eine weiße Seite erscheint?

Ein Update von Elementor Pro ohne gleichzeitiges Update des kostenlosen Elementors? Eine klassische Falle. Pro enthält Code, der auf neue Klassen und Funktionen der kostenlosen Version zugreift – fehlen diese, wirft PHP einen Fatal Error.

Warum verursachen inkompatible Versionen von Elementor und Elementor Pro einen Fatal Error?

Elementor Pro ist ein Aufbau, der den kostenlosen Elementor erweitert – er nutzt dessen Klassen, Funktionen und Hooks. Wenn der Pro-Autor eine neue Funktionalität hinzufügt, die die Klasse X aus der kostenlosen Version 3.22 benötigt, Sie aber die kostenlose Version 3.20 haben – stürzt PHP beim Laden mit einem Fehler wie „Class X not found“ ab.

In debug.log sehen Sie einen Eintrag ähnlich diesem:

PHP Fatal error: Uncaught Error: Class "Elementor\Core\Base\Module" not found in /wp-content/plugins/elementor-pro/modules/forms/module.php on line 27

Ein eindeutiges Signal für eine Versionsinkompatibilität. Die Lösung: Aktualisieren Sie den kostenlosen Elementor auf dieselbe Generation wie Pro.

Wie stellt man den Zugriff auf wp-admin durch Umbenennen des Plugin-Ordners wieder her?

Blockiert ein Fatal Error den Zugang zum Adminbereich? Sie müssen Elementor Pro vorübergehend über die Datei deaktivieren. Melden Sie sich per FTP oder über den File-Manager im Hosting-Panel an und wechseln Sie zu /wp-content/plugins/.

1. Suchen Sie den Ordner elementor-pro und benennen Sie ihn in elementor-pro-OFF um.
2. WordPress deaktiviert das Plugin automatisch – der Ordner mit dem ursprünglichen Namen existiert nicht mehr, also „verschwindet“ das Plugin aus dem System.
3. Melden Sie sich bei wp-admin an – es sollte funktionieren.
4. Aktualisieren Sie den kostenlosen Elementor über „Plugins > Installierte Plugins > Aktualisieren“.
5. Kehren Sie zu FTP zurück und benennen Sie den Ordner wieder in elementor-pro um.
6. Aktivieren Sie Elementor Pro im Plugin-Bereich und aktualisieren Sie es sofort auf die neueste Version.

Häufiger Fehler: Löschen Sie das Plugin nach der Umbenennung des Ordners nicht aus der Datenbank. Ihre Lizenzen, Einstellungen und der Theme Builder bleiben in den Datenbanktabellen erhalten. Die Umbenennung des Ordners ist eine vorübergehende Deaktivierung, keine Deinstallation.

Wie setzt man Elementor über Tools → Version Control auf eine stabile Version zurück?

Hat ein Update des kostenlosen Elementors einen Fehler verursacht, den der Hersteller noch nicht behoben hat? Nutzen Sie den integrierten Rollback. Gehen Sie zu „Elementor > Tools > Version Control“.

Sie sehen zwei Felder: „Rollback Version“ (für den kostenlosen Elementor) und „Rollback Pro Version“ (für Pro). Wählen Sie im Dropdown eine frühere stabile Version aus und klicken Sie auf „Reinstall this version“. Elementor lädt die ausgewählte Version vom Server des Herstellers herunter und überschreibt die aktuelle.

Wählen Sie beim Zurücksetzen beider Plugins Versionen aus derselben Generation (z. B. 3.21.x für beide). Deaktivieren Sie nach dem Rollback die automatischen Updates unter „Plugins > Installierte Plugins“ – bis der Hersteller einen Hotfix veröffentlicht.

Welche Einstellungen in Elementor → Tools lösen Probleme beim Laden?

Das Panel „Elementor > Tools“ enthält drei Tools, die die meisten Probleme beheben, ohne dass Dateien bearbeitet werden müssen: Switch Editor Loader Method, Regenerate Files & Data und Sync Library.

Wann sollte man Switch Editor Loader Method aktivieren und was ändert diese Option?

Switching the editor loading method can solve server issues. This can also be useful in solving the white screen of death.

Offizielle Elementor-Dokumentation — Server configuration conflicts

Die Option ändert die Art, wie Elementor den Editor lädt – von der Standardmethode zu einer alternativen, die mit restriktiven Serverkonfigurationen kompatibel ist. Hat Ihr Hosting aggressive mod_security-Regeln oder eine WAF, die den Standard-Ladevorgang des iframes blockiert? Dieser Schalter löst das Problem oft.

Sie finden es unter „Elementor > Settings > Advanced > Switch Editor Loader Method > Enable“. Speichern Sie die Änderungen und testen Sie den Editor. Hat es nicht geholfen? Schalten Sie es wieder aus – in manchen Konfigurationen ist die alternative Methode langsamer.

Wie funktioniert Regenerate Files & Data und wann sollte man es ausführen?

Elementor generiert CSS-Dateien für jede Seite und speichert sie in wp-content/uploads/elementor/css/. Nach einem Update des Plugins, des Themes oder einer Änderung der globalen Stile können diese Dateien nicht mehr mit der aktuellen Struktur übereinstimmen. Die Folge? Fehlende Stile, ein seltsames Layout, weiße Bereiche.

„Tools > Regenerate Files & Data“ löscht den alten CSS-Cache und baut ihn von Grund auf neu auf. Der Vorgang ist sicher – er löscht weder Inhalte noch Widget-Einstellungen, sondern nur die generierten Hilfsdateien.

Pro tip: Nach dem Klick auf „Regenerate Files & Data“ generiert Elementor das CSS nicht sofort – das geschieht erst beim nächsten Seitenbesuch. Nutzen Sie den Preload-Cache von WP Rocket? Dann cachen Sie eine Version ohne Stile. Zuerst regenerieren, dann die Seite manuell besuchen, erst danach den Cache starten.

Was macht Sync Library und lohnt es sich, sie zu erzwingen?

Sync Library aktualisiert die Liste der fertigen Vorlagen und Widgets, die in der Elementor-Bibliothek verfügbar sind. Für sich allein behebt es selten Probleme beim Laden des Editors, ist aber Teil des Prozesses „Regenerate Files & Data“ – führen Sie es gemeinsam mit einem Reset und Neustart des gesamten Ökosystems aus.

Erzwingen Sie eine Synchronisierung nach größeren Pro-Updates oder nach einer Änderung des Lizenzplans. Manchmal erscheinen neue Vorlagen erst in der Bibliothek, wenn Sie sie manuell aktualisieren.

Wie aktiviert man WP_DEBUG und liest PHP- und JavaScript-Fehlerprotokolle aus?

Hat keiner der vorherigen Schritte funktioniert? Zeit, unter die Haube zu schauen. WP_DEBUG verwandelt die weiße Seite in eine konkrete Fehlermeldung, und die JavaScript-Konsole zeigt, warum der Editor-Loader hängen geblieben ist.

Welche Einträge fügt man in wp-config.php hinzu, um sicheres Debugging zu aktivieren?

Fügen Sie in wp-config.php den Debugging-Block über der Zeile /* That's all, stop editing! */ hinzu. Diese für eine Produktivseite sichere Konfiguration schreibt Fehler in eine Datei, anstatt sie den Besuchern anzuzeigen:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Die Werte der Reihe nach: WP_DEBUG aktiviert den Debug-Modus, WP_DEBUG_LOG erzwingt das Schreiben von Fehlern in eine Datei, WP_DEBUG_DISPLAY auf false gesetzt verbirgt Fehler vor den Besuchern, und display_errors blockiert zusätzlich die Anzeige von PHP-Warnungen.

Aktualisieren Sie nach dem Speichern der Datei die Seite mit dem Fehler. WordPress schreibt alle Fehler in wp-content/debug.log. Setzen Sie nach Abschluss der Diagnose WP_DEBUG wieder auf false – im Produktivmodus darf Debugging nicht aktiv sein.

Wo findet man die Datei debug.log und wie erkennt man einen Fehler im Zusammenhang mit Elementor Pro?

Die Datei liegt in wp-content/debug.log. Öffnen Sie sie über den File-Manager oder FTP. Suchen Sie nach Zeilen, die mit PHP Fatal error beginnen und ein Datum nahe dem Zeitpunkt haben, an dem Sie versucht haben, den Editor zu öffnen.

Wie liest man Fehler in der JavaScript-Konsole bei einem hängenden Editor?

Bei einem hängenden Loader (Seitenleiste funktioniert, Vorschau leer) zeigt WP_DEBUG nichts an – der Fehler passiert im Browser, nicht auf dem Server. Öffnen Sie die Entwicklertools mit der Taste F12 und wechseln Sie zum Tab „Console“.

Suchen Sie nach roten Fehlerzeilen. Die häufigsten Muster:

• Refused to display ... in a frame because it set 'X-Frame-Options' to 'DENY' – Problem mit dem iframe-Header (Abschnitt weiter unten).
• Failed to load resource: net::ERR_BLOCKED_BY_CLIENT – eine Browsererweiterung blockiert das Skript.
• Uncaught TypeError: Cannot read properties of undefined mit Verweis auf eine Datei in /wp-content/plugins/X/ – JS-Konflikt mit Plugin X.
• 404 Not Found für die Datei elementor.min.js oder elementor-pro.min.js – führen Sie „Tools > Regenerate Files & Data“ aus.

Kopieren Sie die gesamte Fehlermeldung und fügen Sie sie zusammen mit dem Wort „elementor“ bei Google ein. Höchstwahrscheinlich stoßen Sie auf ein Issue auf GitHub oder ein Forum, in dem jemand dasselbe Problem gelöst hat.

Wie löst man Probleme mit dem X-Frame-Options-Header und der Serverkonfiguration?

Der Elementor-Editor zeigt die Seitenvorschau in einem iframe an. Der iframe hat eigene Sicherheitsregeln, die über den Header X-Frame-Options gesteuert werden. Ist der Header zu restriktiv eingestellt, verweigert der Browser das Laden des Inhalts – Sie sehen ein leeres Panel.

Warum blockiert die Einstellung DENY das Laden des Editors im iframe?

Der Wert DENY bedeutet: „Erlaube niemandem, diese Seite in einem iframe einzubetten – nicht einmal sich selbst“. Wenn das Hosting oder ein Sicherheits-Plugin einen solchen Header setzt, funktioniert der Elementor-Editor nicht mehr. Er kann die Seitenvorschau nicht in seinem iframe laden.

Sie erkennen das Problem an der Meldung in der Konsole: „Refused to display ‚https://IhreDomain.de/…‘ in a frame because it set ‚X-Frame-Options‘ to ‚DENY'“.

Wie stellt man X-Frame-Options: sameorigin beim Hosting oder in einem Sicherheits-Plugin ein?

Der Wert SAMEORIGIN erlaubt das Einbetten der Seite in einen iframe, sofern die übergeordnete Seite dieselbe Domain hat. Eine sichere Option, die mit Elementor funktioniert.

Fügen Sie in Apache in .htaccess folgende Zeile hinzu:

Header always set X-Frame-Options "SAMEORIGIN"

Nutzen Sie ein Sicherheits-Plugin wie Wordfence, iThemes Security oder WP Cerber? Suchen Sie darin die Option „X-Frame-Options“ oder „Clickjacking protection“ und stellen Sie sie auf SAMEORIGIN statt DENY. Löschen Sie nach der Änderung den Browser-Cache und prüfen Sie den Editor.

Was tun, wenn sich die WordPress-Domain von der Bearbeitungsdomain unterscheidet (www, https)?

Der Editor verlangt, dass die Admin-Domain und die Domain der Website exakt identisch sind. Sie rufen https://www.twojadomena.pl/wp-admin auf, aber unter „Einstellungen > Allgemein“ steht https://twojadomena.pl ohne www? Der Iframe versucht, eine andere Domain zu laden, und SAMEORIGIN blockiert ihn.

Prüfen Sie zwei Felder unter „Einstellungen > Allgemein“: „WordPress-Adresse (URL)“ und „Website-Adresse (URL)“. Beide müssen identisch sein und mit dem übereinstimmen, was Sie in der Adressleiste eingeben. Vereinheitlichen Sie das Protokoll (überall HTTPS), vereinheitlichen Sie www (mit oder ohne, aber konsequent), erzwingen Sie eine Weiterleitung von der „falschen“ Variante über .htaccess.

Wie lautet die Zusammenfassung der wichtigsten Informationen?

In 80 % der Fälle beheben Sie die weiße Seite oder den hängenden Loader von Elementor Pro mit den ersten drei Schritten: Cache leeren, Serveranforderungen prüfen (PHP, Arbeitsspeicher), Safe Mode aktivieren. Die restlichen 20 % erfordern eine tiefere Diagnose – WP_DEBUG, Rollback der Version, Bearbeitung der Server-Header oder Kontakt mit dem Hosting-Support.

Halten Sie sich an die Reihenfolge von den günstigsten zu den aufwendigsten Tests. Jeder vorherige Schritt erspart Ihnen Stunden des Durchsuchens von Dateien, die Sie gar nicht anfassen müssten. Wenden Sie sich an den Hosting-Support, wenn Sie keine Berechtigung haben, memory_limit zu ändern, wenn der Server global X-Frame-Options: DENY erzwingt oder wenn die PHP-Logs außerhalb Ihrer Reichweite liegen.

Welche Fragen werden am häufigsten gestellt (FAQ)?