Zuletzt aktualisiert: 20. Oktober 2026
Quick Answer: Die Meldung „In diesem Block ist ein Fehler aufgetreten“ ist ein Validierungsfehler des Editors: Das gespeicherte Markup eines Bausteins passt nicht mehr zu seiner Definition. Meist hilft zuerst „Wiederherstellung versuchen“, dann das Abschalten der zuletzt aktualisierten Erweiterung. Bleibt der Fehler, zeigt debug.log den Auslöser.
Ein einzelner Zeilenumbruch im gespeicherten Code kann ausreichen, damit der Editor eine komplette Seite verweigert. Genau das steckt hinter der Meldung: Der Editor hat einen Baustein gefunden, dessen Markup nicht mehr zu seiner Definition passt. Wer die Ursache kennt, repariert den Abschnitt in wenigen Minuten, statt die Seite neu aufzubauen.
Was die Fehlermeldung bedeutet
Technisch steckt dahinter ein Validierungsfehler. Der Gutenberg-Editor vergleicht beim Laden einer Seite das gespeicherte Markup jedes Bausteins mit dem, was die registrierte Bausteindefinition erwartet. Weichen beide voneinander ab, bricht die Vorschau ab und statt des Inhalts erscheint die Meldung „In diesem Block ist ein Fehler aufgetreten“. Im englischen Original heißt sie „This block has encountered an error and cannot be previewed“.
Diese Prüfung ist kein Bug, sondern eine Schutzfunktion: Sie verhindert, dass beschädigter Code unkontrolliert ausgegeben wird. Für Betreiber ist die Wirkung trotzdem ärgerlich, denn der betroffene Abschnitt lässt sich nicht mehr bearbeiten, in manchen Fällen verhindert der Fehler sogar das Speichern der ganzen Seite.
Vier Auslöser decken den Großteil der Fälle ab:
- Aktualisierungen von Erweiterungen oder Vorlagen, die die Bausteinstruktur verändert haben
- Manuelle Eingriffe im Code-Editor mit unsichtbaren Whitespace-Abweichungen
- Ein veralteter Browser-Cache, der alte JavaScript-Dateien lädt
- Zwei Erweiterungen, die denselben Bausteintyp unterschiedlich registrieren
Wer die Ursache richtig einordnet, sucht nicht am falschen Ende.
Soforthilfe: Den Editor wieder benutzbar machen
Bevor Sie tief in die Technik einsteigen, arbeiten Sie diese Reihenfolge ab. Sie kostet fünf Minuten und löst die meisten Fälle:
- Browser-Cache leeren und die Seite in einem Inkognito-Fenster neu laden
- Im Editor auf „Wiederherstellung versuchen“ klicken
- Über das Drei-Punkte-Menü auf „Als HTML bearbeiten“ wechseln und den Abschnitt prüfen
- Testen, ob der Fehler nur im Backend auftritt oder auch im Frontend sichtbar ist
Bleibt die Meldung bestehen, folgt der klassische Ausschlusstest: Alle Plugins bis auf die nötigsten deaktiviert lassen und eine Standardvorlage wie Twenty Twenty-Four aktivieren. Verschwindet der Fehler damit, war eine Erweiterung oder die Vorlage die Ursache. Die Methode dauert länger, ist aber zuverlässig. Dieselben Diagnoseschritte helfen auch bei verwandten Ausfällen wie dem 500 Internal Server Error, weil die Konfliktmuster identisch sind.
Ein wichtiger Hinweis zum Testing: Nehmen Sie dafür eine Kopie der Seite, nicht das Original. Ein Screenshot der Fehlermeldung und der geöffneten Browser-Konsole hilft später bei der Eingrenzung, weil dort der Name der fehlerhaften Datei steht. Der Login ins Backend bleibt davon unberührt, die Störung betrifft nur den Editor.
Ursache 1: Erweiterungen und Baustein-Bibliotheken
In der Praxis ist der Plugin-Konflikt die häufigste reale Ursache. Baustein-Bibliotheken wie Kadence Blocks oder das Editing Toolkit laufen nach einem Core-Update nicht mehr synchron mit den nativen Bausteinen. Das Muster ist typisch: Nach einer Aktualisierung erscheint die Meldung plötzlich auf Seiten, die vorher monatelang funktioniert haben.
Der Grund liegt selten im Text selbst. Eine Erweiterung registriert eine veraltete Bausteindefinition, während der gespeicherte Inhalt bereits die neue Struktur erwartet. Beim Laden prallen beide Versionen aufeinander, und die Validierung schlägt fehl.
So finden Sie den Verursacher:
- Erweiterungen einzeln abschalten und die Seite nach jedem Schritt neu laden
- Die Browser-Konsole auf JavaScript-Fehler prüfen, der Stacktrace nennt oft den Ordner
- Das Changelog der zuletzt aktualisierten Erweiterung lesen, Hinweise auf Gutenberg stehen meist oben
- In den Support-Foren der Community nach dem Namen der Erweiterung plus Fehlermeldung suchen
Wer regelmäßig mit Drittanbieter-Bausteinen arbeitet, sollte zusätzlich unseren Beitrag zu Fehlern durch Plugin-Konflikte lesen, weil die Diagnosetechnik fast identisch ist. Bei KI-generierten Seiten treten solche Konflikte häufig zusammen mit CSS- und JavaScript-Fehlern auf.
Ursache 2: Beschädigtes Markup im Baustein
Nicht immer steckt eine Erweiterung dahinter. Oft liegt das Problem direkt im gespeicherten HTML. Ein unsichtbarer Zeilenumbruch, ein fehlendes schließendes Tag oder ein eingefügtes geschütztes Leerzeichen reichen aus, damit die Prüfung fehlschlägt.
Besonders anfällig sind drei Konstellationen:
- Eigene HTML-Bausteine mit manuell eingefügtem Code
- Inhalte, die über den Code-Editor nachträglich verändert wurden
- Text, der aus einem Textverarbeitungsprogramm oder aus einer anderen Seite kopiert wurde
Die Prüflogik ist streng. Zwei Markup-Varianten können optisch identisch aussehen und trotzdem an einer Abweichung im Whitespace scheitern. Das erklärt, warum manche Fehler scheinbar aus dem Nichts entstehen, obwohl niemand bewusst etwas geändert hat.
Ein fehlendes schließendes Tag genügt, damit ein vorher funktionsfähiger Baustein als defekt markiert wird.
Wenn Sie mit KI-generierten Inhalten arbeiten, kennen Sie dieses Muster aus unserem Artikel über typische Fehler von AI-Buildern. Dort sind die Markup-Abweichungen aufgelistet, die am häufigsten zu Validierungsfehlern führen. Bauen Sie die Seiten mit Elementor statt mit dem nativen Editor, greift dessen eigene Prüfung, die Fehlerursachen bleiben aber dieselben.
Ursache 3: Theme und PHP nach der Aktualisierung
Vorlagen greifen in die Darstellung von Bausteinen ein, über eigene CSS-Klassen oder Funktionen in der functions.php. Nach einem Theme-Update oder einem Wechsel der PHP-Version kann diese Verbindung brechen. Kritisch sind vor allem Umstellungen von PHP 7 auf PHP 8, weil sich interne Funktionsweisen ändern, die ältere Vorlagen nicht abbilden.
Das äußert sich nicht immer in der Editor-Meldung, häufig aber in Kombination mit Darstellungsfehlern. Details dazu stehen in unserem Beitrag zum Umstieg von PHP 7 auf PHP 8. Auch reine Core-Updates auf eine neue Minor-Version lösen den Fehler gelegentlich aus, wie unser Fall zu Fehler 500 nach Core-Update zeigt. Verwandt ist die Meldung „Es gab einen kritischen Fehler auf dieser Website“, die meist auf eine ganz ähnliche Inkompatibilität zurückgeht.
Prüfen Sie nach jeder größeren Änderung:
- Das Changelog der Vorlage auf Hinweise zu Gutenberg
- Die PHP-Versionsanforderungen der Vorlage
- Die Kompatibilitätsmeldungen im Dashboard, dort steht die empfohlene PHP-Version
- Ob der Fehler auch mit einer Standardvorlage auftritt
WordPress-Debug-Modus aktivieren und debug.log auswerten
Wer die Ursache nicht durch Ausprobieren findet, sollte das Logging einschalten. Tragen Sie in die Datei wp-config.php den Debug-Modus ein, dazu die Protokollierung in eine Datei und die abgeschaltete Anzeige im Frontend. Die drei Konstanten dafür stehen in der offiziellen Dokumentation.
Danach schreibt das System PHP-Warnungen und Fehler in die Datei debug.log im Ordner für Ihre Inhalte. Diese Datei zeigt oft genau, welche Funktion den Konflikt auslöst. Wichtig ist, dass die Anzeige im Frontend aus bleibt: Sonst sehen Besucher technische Details, und die Meldung erscheint zusätzlich auf der öffentlichen Seite.
Parallel lohnt der Blick in die Browser-Konsole, denn viele Fälle entstehen auf JavaScript-Ebene und tauchen im PHP-Log gar nicht auf. Eine strukturierte Vorgehensweise beschreibt unsere Diagnose-Checkliste, die sich unverändert auf Editor-Fehler übertragen lässt. Wer keinen FTP-Zugang einrichten möchte, kann die Datei auch über den Dateimanager des Webhosting-Pakets bearbeiten. Liegt die Seite im Stammverzeichnis eines eigenen Linux-Servers, gelten dieselben Schritte, nur als Administrator mit Root-Rechten.
Den betroffenen Baustein reparieren
Sobald die Ursache klar ist, geht es an die Reparatur. Der Editor bringt dafür mehrere Werkzeuge mit, die in dieser Reihenfolge sinnvoll sind:
| Methode | Wann sinnvoll | Risiko |
|---|---|---|
| Wiederherstellung versuchen | immer als erster Versuch | sehr gering |
| Als HTML bearbeiten | Markup manuell korrigieren | mittel, setzt Code-Kenntnisse voraus |
| In Classic-Baustein umwandeln | wenn die Prüfung dauerhaft scheitert | gering, moderne Einstellungen entfallen |
| Baustein löschen und neu aufbauen | letzte Option | Inhalt muss neu erstellt werden |
„Wiederherstellung versuchen“ nutzt den gespeicherten Rohinhalt und passt ihn automatisch an die aktuelle Definition an. Das löst einfache Fälle. Scheitert es, hilft der Code-Editor: Dort entfernen Sie unsichtbare Zeichen und schließen fehlende Tags. Als letzte Rettung wandeln Sie den Abschnitt in einen Classic-Baustein um, der klassisches HTML statt der Bausteinsyntax nutzt. Das umgeht die Prüfung vollständig, kostet aber moderne Einstellungen.
Wenn der Editor gar nicht mehr öffnet: Datenbank und Backup
Manchmal greift keines der Werkzeuge, weil die Seite schon beim Aufruf abbricht. Dann hilft nur der Eingriff in die Datenbank oder die Wiederherstellung aus einer Sicherung. Gehen Sie so vor:
- Vollständige Sicherung der Datenbank erstellen, bevor irgendein Wert geändert wird
- Den betroffenen Beitrag über phpMyAdmin suchen und das Feld für den Inhalt öffnen
- Den Abschnitt auf den Zustand vor der Fehlerstelle zurücksetzen oder aus der Sicherung wiederherstellen
- Die Domain neu aufrufen und im Editor prüfen, ob der Abschnitt wieder reagiert
Dieser Schritt verlangt Erfahrung, weil ein fehlerhafter Befehl weiteren Schaden anrichtet. Hinweise zum gezielten Reparieren einzelner Tabellen stehen in unserem Artikel zu Datenbanktabellen ohne Datenverlust retten. Legen Sie vorher ein Notfall-Backup an, damit ein Rückweg bleibt. Wer unsicher ist, sollte diesen Teil abgeben statt zu experimentieren.
Vorbeugen: Backup, Testumgebung, kontrollierte Updates
Die beste Reaktion auf den Fehler ist, ihn nicht entstehen zu lassen. Drei Maßnahmen senken das Risiko deutlich:
- Automatisierte tägliche Sicherungen, damit jeder Zustand wiederherstellbar ist
- Eine Testumgebung, in der Aktualisierungen vor dem Livegang laufen
- Ein fester Update-Rhythmus statt spontaner Einzelklicks
Gerade Shop-Betreiber sollten nie direkt auf der Live-Seite testen. Ein Vergleich gängiger Lösungen steht in unserem Beitrag zu Backup-Erweiterungen im Vergleich. Zusätzlich hilft ein Wartungsplan mit regelmäßigen Sicherheitsprüfungen; was ein guter Wartungsvertrag enthalten sollte, haben wir dort zusammengestellt.
Ein letzter Punkt, der oft übersehen wird: Notieren Sie bei jedem Vorfall, welche Änderung unmittelbar davor stattfand. Diese Notiz ist bei der nächsten Störung mehr wert als jede allgemeine Checkliste.
Wann professionelle Hilfe sinnvoll ist
Nicht jeder Fall lässt sich in zehn Minuten selbst lösen. Spätestens wenn mehrere Seiten gleichzeitig betroffen sind, der Fehler nach dem Abschalten aller Erweiterungen bleibt oder ein Eingriff in die Datenbank nötig wird, steigt das Risiko für Laien deutlich.
In solchen Fällen prüfen wir zuerst kostenlos; wer uns kontaktiert, erhält eine ehrliche Einschätzung, wie groß der Schaden ist, und nennen danach einen Festpreis für die Reparatur. Die Umsetzung startet erst, wenn das Angebot passt. Bei Shops, in denen ein defekter Abschnitt direkt Umsatz kostet, zählt vor allem Tempo. Wie wir bei typischen Shop-Störungen vorgehen, zeigt unser Beitrag zu den häufigsten WooCommerce-Fehlern.
Häufige Fragen
Was bedeutet „In diesem Block ist ein Fehler aufgetreten“ genau? Es ist ein Validierungsfehler des Editors. Der gespeicherte Inhalt eines Bausteins passt nicht mehr zu seiner Definition, deshalb bricht die Vorschau ab.
Verschwindet die Meldung nach einer Aktualisierung von selbst? Manchmal, wenn der Hersteller der Erweiterung nachliefert. Verlassen sollte man sich nicht darauf, weil die Bearbeitung bis dahin nicht möglich ist.
Kann ich das ohne technisches Wissen beheben? Einfache Fälle löst „Wiederherstellung versuchen“. Bei beschädigtem Markup oder Datenbank-Eingriffen ist Unterstützung sinnvoll.
Ist die Website für Besucher kaputt? Meist nicht. Der Fehler betrifft zuerst das Backend. Nur wenn der Abschnitt gar nicht mehr ausgegeben wird, sehen Besucher eine Lücke.
Hilft ein Rollback auf eine ältere Version? Er kann helfen, ist aber die letzte Option, weil ältere Versionen offene Sicherheitslücken enthalten können.
Wie vermeide ich den Fehler künftig? Durch Testumgebung, tägliche Sicherungen und Aktualisierungen in festen Abständen statt einzeln zwischendurch.
References
1] Gutenberg-Handbuch: Baustein-Validierung und Wiederherstellung – developer.wordpress.org 2] Support-Forum: This block has encountered an error – wordpress.org Deutsch 3] Debugging in WordPress – Handbuch zur Fehlersuche