Die 10 häu­figs­ten WordPress-Fehler und die passenden Lösungen

WordPress-Probleme entstehen häufig durch feh­ler­haf­te Plugins oder Themes, Code- und Da­ten­bank­feh­ler, falsche Ser­ver­ein­stel­lun­gen, be­schä­dig­te Dateien oder Caching. Häufige Lö­sungs­an­sät­ze sind das De­ak­ti­vie­ren ver­däch­ti­ger Er­wei­te­run­gen, das Prüfen von Logs, Da­tei­rech­ten und Ser­ver­li­mits sowie das Wie­der­her­stel­len per Backup oder Recovery-Modus.

1. White Screen of Death: WordPress zeigt nur noch eine weiße Seite

Früher wurde bei schwer­wie­gen­den Fehlern oft tat­säch­lich nur eine komplett weiße Seite angezeigt – daher stammt der etwas dra­ma­ti­sche Begriff „White Screen of Death“. In­zwi­schen verhält sich WordPress deutlich nut­zer­freund­li­cher und zeigt in vielen Fällen konkrete Feh­ler­mel­dun­gen oder bietet einen Recovery-Modus an.

Es gibt mehrere mögliche Ursachen für den White Screen of Death: nicht funk­tio­nie­ren­de Plugins, Probleme mit PHP und un­ter­schied­lichs­te Co­die­rungs- oder Da­ten­bank­feh­ler. Daher empfiehlt es sich, die genaue Ursache für den Fehler zu ermitteln.

Recovery-Modus: Erster An­lauf­punkt bei kri­ti­schen Fehlern

Seit Version 5.2 verfügt WordPress über einen fest in­te­grier­ten Recovery-Modus, der bei kri­ti­schen Fehlern au­to­ma­tisch greift. Tritt ein schwer­wie­gen­der PHP-Fehler auf, zeigt WordPress statt einer leeren Seite einen all­ge­mei­nen Feh­ler­hin­weis an und sendet gleich­zei­tig eine E-Mail an die Ad­mi­nis­tra­tor-Adresse. Diese E-Mail enthält einen spe­zi­el­len Einmal-Link, über den Sie sich trotz des Fehlers im Backend anmelden können. Dort zeigt WordPress an, welches Plugin oder Theme den Fehler ver­ur­sacht, und er­mög­licht es Ihnen, die be­trof­fe­ne Er­wei­te­rung direkt zu de­ak­ti­vie­ren.

Der Recovery-Modus funk­tio­niert nur, wenn der Fehler früh genug ab­ge­fan­gen werden kann. Bei sehr tiefen PHP-Fehlern bleibt die E-Mail aus. In solchen Fällen müssen Sie den Fehler manuell per FTP oder Da­tei­ma­na­ger beheben, wie in den folgenden Ab­schnit­ten be­schrie­ben.

Feh­ler­quel­le 1: Plugins

Oft ist der White Screen of Death auf eine der folgenden Aktionen zu­rück­zu­füh­ren:

• Sie haben ein nicht korrekt funk­tio­nie­ren­des Plugin in WordPress aktiviert.
• Sie haben die Ein­stel­lun­gen für ein aktives Plugin geändert.
• Sie haben den Backend-Code eines aktiven Plugins geändert.

Falls Sie kürzlich eine dieser drei Än­de­run­gen vor­ge­nom­men haben, rufen Sie einfach die Plugins-Seite in WordPress auf und de­ak­ti­vie­ren jenes Plugin, das Sie zuletzt mo­di­fi­ziert haben. In vielen Fällen ist das Problem damit bereits behoben.

Falls das WordPress-Dashboard nicht mehr er­reich­bar ist, können Sie al­ter­na­tiv den Recovery-Modus von WordPress nutzen, sofern Sie die ent­spre­chen­de E-Mail erhalten haben. Wenn auch das nicht möglich ist, müssen Sie per FTP-Zugriff oder über den Da­tei­ma­na­ger Ihres Hostings auf Ihre WordPress-Dateien zugreifen, um die Plugins manuell zu de­ak­ti­vie­ren. Gehen Sie dazu wie folgt vor:

1. Öffnen Sie das Ver­zeich­nis, in dem Ihre WordPress-Dateien ge­spei­chert sind.
2. Öffnen Sie den Ordner wp-content.
3. Im Ordner wp-content finden Sie den Ordner plugins.
4. Benennen Sie den Ordner um, damit alle Plugins gleich­zei­tig de­ak­ti­viert werden.

Feh­ler­quel­le 2: Code­feh­ler

Wenn der Fehler nicht auf ein Plugin zu­rück­zu­füh­ren ist, könnte er auch daraus re­sul­tie­ren, dass Sie die Datei functions.php oder eine andere PHP-Datei über den WordPress-Theme-Editor mo­di­fi­ziert haben. In solchen Fällen zeigt WordPress häufig eine konkrete Feh­ler­mel­dung oder versetzt die Website in den Recovery-Modus. Typisch ist bei­spiels­wei­se folgende Meldung:

Parse error: syntax error, unexpected end of file in /home/name/public_html/wordpress/wp-content/themes/your_theme/functions.php on line 231

Das bedeutet, dass es einen Fehler in Ihrem Code gibt. Das gewählte WordPress-Theme bzw. WordPress-Framework kann dann nicht korrekt angezeigt werden. In diesem Fall müssen Sie den ur­sprüng­li­chen Zustand der be­trof­fe­nen Datei wie­der­her­stel­len.

Wenn kein Zugriff auf das WordPress-Dashboard möglich ist, können Sie die feh­ler­haf­te Datei über FTP oder den Da­tei­ma­na­ger Ihres Hostings ersetzen:

1. Öffnen Sie das Ver­zeich­nis, in dem sich Ihre WordPress-Dateien befinden.
2. Öffnen Sie den Ordner wp-content.
3. Im Ordner wp-content finden Sie den Themes-Ordner.
4. Öffnen Sie den Ordner Ihres aktiven Themes.
5. Suchen Sie die be­trof­fe­ne Datei.
6. Laden Sie an­schlie­ßend eine funk­tio­nie­ren­de Version der Datei hoch – entweder aus einem Backup oder aus der Ori­gi­nal­ver­si­on des Themes.

Al­ter­na­tiv können Sie das gesamte Theme de­ak­ti­vie­ren, indem Sie den Theme-Ordner um­be­nen­nen oder pro­be­hal­ber ein anderes Theme verwenden. WordPress greift dann au­to­ma­tisch auf ein Standard-Theme zurück, wodurch Sie wieder Zugriff auf das Backend erhalten. Kehren Sie an­schlie­ßend zu Ihrem Browser zurück und ak­tua­li­sie­ren Sie Ihre Website.

Un­be­kann­te Feh­ler­quel­le

Manchmal erscheint der White Screen of Death aus un­er­klär­li­chen Gründen: Sie haben weder Ihre Plugins mo­di­fi­ziert noch haben Sie den Code Ihres Themes um­ge­schrie­ben. In solchen Fällen ist es wichtig, sys­te­ma­tisch vor­zu­ge­hen. Ein zentraler Ansatz ist der Einsatz von WP_DEBUG: Ak­ti­vie­ren Sie den Debug-Modus, um konkrete Feh­ler­mel­dun­gen zu erhalten. Dadurch lassen sich feh­ler­haf­te Dateien und Code­zei­len gezielt iden­ti­fi­zie­ren und beheben.

Öffnen Sie dazu die Datei wp-config.php im Haupt­ver­zeich­nis Ihrer WordPress-In­stal­la­ti­on und setzen Sie die folgenden Zeilen:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Mit WP_DEBUG_LOG werden alle Feh­ler­mel­dun­gen in die Datei wp-content/debug.log ge­schrie­ben. WP_DEBUG_DISPLAY sollte auf false gesetzt bleiben, damit Fehler nicht öf­fent­lich auf der Website angezeigt werden – das ist besonders auf Live-Seiten wichtig, da Debug-Ausgaben sensible In­for­ma­tio­nen wie Da­ten­bank­pfa­de oder Ser­ver­kon­fi­gu­ra­tio­nen enthalten können. Die Feh­ler­ana­ly­se erfolgt dann direkt in der Log-Datei, auf die Sie per FTP oder Da­tei­ma­na­ger zugreifen können. Nach der Feh­ler­ana­ly­se sollten Sie den Debug-Modus wieder de­ak­ti­vie­ren, indem Sie alle drei Einträge auf false setzen.

Neben Plugins kommen auch andere Ursachen für den An­zei­ge­feh­ler infrage, die nicht auf den ersten Blick er­sicht­lich sind.

• Caching: Verwenden Sie ein Caching-Plugin, müssen Sie unter Umständen einfach den Cache Ihrer Seite löschen. Falls sich der Cache des Programms nicht löschen lässt, weil Sie immer noch nicht auf WordPress zugreifen können, löschen Sie den Browser-Cache.
• Be­schä­dig­te Datei(en): Ihre WordPress-Dateien sind mög­li­cher­wei­se be­schä­digt (z. B. aufgrund von Malware). Kon­tak­tie­ren Sie Ihren Webhoster und bitten Sie ihn um eine Pro­blem­dia­gno­se.
• Ser­ver­pro­ble­me: Ist der Server über­las­tet oder vor­über­ge­hend nicht er­reich­bar, kann dies ebenfalls zu einem White Screen führen. Prüfen Sie Ihr E-Mail-Postfach auf Hinweise Ihres Hosters oder wenden Sie sich an den Support.

2. Interner Ser­ver­feh­ler: 500 Internal Server Error

Die Feh­ler­mel­dung „500 Internal Server Error“ gehört insgesamt zu den häu­figs­ten Ser­ver­feh­lern. Bei WordPress ver­ur­sa­chen diesen Ser­ver­feh­ler oft die Plugins oder Probleme mit den Themes. Andere mögliche Ursachen sind be­schä­dig­te .htaccess-Dateien oder un­zu­rei­chen­der PHP-Speicher. Interne Server-Fehler können auch die WordPress-Admin-Seite betreffen, während der Rest der Website pro­blem­los funk­tio­niert.

Feh­ler­quel­le 1: Be­schä­dig­te .htaccess-Datei

Eine häufige Ursache für die Feh­ler­mel­dung „500 Internal Server Error“ ist eine be­schä­dig­te .htaccess-Datei. Prüfen Sie deshalb zunächst, ob die Datei betroffen ist: Loggen Sie sich via FTP-Zugang oder über den Da­tei­ma­na­ger Ihres Hosters auf Ihrem Server ein. Na­vi­gie­ren Sie zum Root-Ver­zeich­nis von WordPress und suchen Sie die .htaccess-Datei. Geben Sie dieser Datei über­gangs­wei­se einen anderen Namen. Laden Sie die Website an­schlie­ßend neu. Funk­tio­niert sie wieder, war die Datei sehr wahr­schein­lich die Ursache.

Erstellen Sie danach eine neue .htaccess, indem Sie sich im WordPress-Backend anmelden und unter „Ein­stel­lun­gen“ → „Per­ma­links“ die Ein­stel­lun­gen erneut speichern. WordPress schreibt die Stan­dard­re­geln dann au­to­ma­tisch neu.

Feh­ler­quel­le 2: Un­zu­rei­chen­der PHP-Speicher

Ein 500 Internal Server Error kann auftreten, wenn WordPress oder ein Plugin mehr PHP-Speicher benötigt, als auf dem Server verfügbar ist. Hinweise darauf finden sich häufig im Error-Log, etwa in Form von Meldungen wie „Allowed memory size exhausted“.

Ak­ti­vie­ren Sie für die Analyse das WordPress-Debugging mit Log-Ausgabe, um Fehler in einer Datei zu pro­to­kol­lie­ren. Bestätigt sich ein Spei­cher­pro­blem, kann eine Erhöhung von WP_MEMORY_LIMIT in der Datei wp-config.php helfen. Zu­sätz­lich sollten Plugins und Themes geprüft werden, da ein un­ge­wöhn­lich hoher Spei­cher­ver­brauch oft durch einzelne Er­wei­te­run­gen ver­ur­sacht wird.

Feh­ler­quel­le 3: Be­schä­dig­te Kerndatei

Es kommt zwar nicht häufig vor, aber ge­le­gent­lich führt auch eine be­schä­dig­te WordPress-Kerndatei dazu, dass ein interner Ser­ver­feh­ler gemeldet wird. In solch einem Fall sollten Sie einen neuen Satz Kern­da­tei­en hochladen, um die Feh­ler­quel­le zu eli­mi­nie­ren.

Melden Sie sich via FTP auf Ihrer Website an und erstellen Sie einen neuen wp-admin und wp-includes-Ordner. Än­de­run­gen in diesen Ordnern sollten Ihre per­sön­li­chen An­pas­sun­gen für WordPress nicht be­ein­flus­sen, außer Sie haben mo­di­fi­zier­te Dateien in diesen Ordnern ab­ge­spei­chert – das ist aber in der Regel nicht der Fall. Die Dateien im Ordner wp-content enthalten Ihr Theme, Ihre Plugins und andere Mo­di­fi­ka­tio­nen. Diesen Ordner dürfen Sie nicht erneuern, da Sie sonst die Inhalte Ihrer Website löschen.

Wenn alles andere fehl­schlägt, laden Sie eine frische WordPress-Version herunter und ersetzen Sie die Core-Dateien manuell. Löschen Sie dabei nicht den be­stehen­den Ordner wp-content und sichern Sie vorher die Datei wp-config.php sowie die Datenbank.

3. Fehler bei der Ver­bin­dung zur Datenbank: Error es­tab­li­shing a database con­nec­tion

Die Meldung „Error es­tab­li­shing a database con­nec­tion“ bedeutet, dass WordPress keine Ver­bin­dung zur Datenbank her­stel­len kann. Ohne diese Ver­bin­dung kann die Website weder Inhalte laden noch das Backend korrekt aufrufen. Häufig liegt die Ursache in feh­ler­haf­ten Zu­gangs­da­ten in der wp-config.php, einem falschen Datenbank-Host oder in einem Problem aufseiten des Servers.

Feh­ler­quel­le 1: Falsche Ver­bin­dungs­ein­stel­lun­gen

Prüfen Sie zuerst die Zu­gangs­da­ten in Ihrer wp-config.php. Ent­schei­dend sind diese vier Einträge:

define( 'DB_NAME', 'datenbankname' );
define( 'DB_USER', 'datenbankbenutzer' );
define( 'DB_PASSWORD', 'passwort' );
define( 'DB_HOST', 'localhost' );

Schon ein kleiner Tipp­feh­ler bei Da­ten­bank­na­me, Be­nut­zer­na­me, Passwort oder Host reicht aus, damit WordPress die Ver­bin­dung nicht aufbauen kann. Häufig wird bei­spiels­wei­se der Host bei einem Umzug des Servers nicht geändert oder das Passwort nicht geupdatet.

Der Wert für DB_HOST ist in der Regel localhost, aber dies ist nicht immer der Fall. Einige Hosting-Un­ter­neh­men verwenden ihre eigenen Werte bei der De­fi­ni­ti­on des Pa­ra­me­ters, andere Hosts de­fi­nie­ren eine URL zum MySQL-Da­ten­bank­ser­ver. In diesen Fällen müssen diese spe­zi­fi­schen Werte ein­ge­setzt werden. Manchmal klappt es auch, wenn man die Hosting-IP-Adresse anstelle einer MySQL-URL einfügt.

Feh­ler­quel­le 2: Ihre Datenbank ist be­schä­digt

Dieser Fehler ist nicht identisch mit dem „Fehler beim Aufbau einer Da­ten­bank­ver­bin­dung“, aber er ist mit ihm verwandt. Manchmal funk­tio­niert das Frontend Ihrer Website perfekt, aber trotzdem erscheint eine Feh­ler­mel­dung. Eine oder mehrere Da­ten­bank­ta­bel­len sind nicht verfügbar, und die Datenbank muss mög­li­cher­wei­se repariert werden.

Öffnen Sie Ihre wp-config.php-Datei und gehen Sie zu dem Abschnitt, der Ihren Da­ten­bank­na­men, Be­nut­zer­na­men, Ihr Passwort und den Host definiert. De­fi­nie­ren Sie Folgendes:

define('WP_ALLOW_REPAIR', true);

Jetzt speichern Sie Ihre wp-config.php und laden die Datei über FTP hoch. Rufen Sie die folgende URL https://www.Ihre-Seite.net/wp-admin/maint/repair.php auf. Auf der Seite werden Sie zwei Optionen sehen. Option eins ist die Schalt­flä­che „Repair Database“, und die zweite Option ist eine Schalt­flä­che „Re­pa­rie­ren und Op­ti­mie­ren der Datenbank“. An dieser Stelle sollten Sie sich nochmals ver­ge­wis­sern, dass Sie ein voll­stän­di­ges Backup Ihrer Datenbank erstellt haben.

Klicken Sie auf die Option „Datenbank re­pa­rie­ren“ und sobald der Re­pa­ra­tur­vor­gang ab­ge­schlos­sen ist, öffnen Sie einen neuen Tab in Ihrem Browser. Über­prü­fen Sie jetzt, ob Ihre Website feh­ler­frei angezeigt wird.

Feh­ler­quel­le 3: Der MySQL-Da­ten­bank­ser­ver ist her­un­ter­ge­fah­ren

Dieses Szenario kann eintreten, wenn der Server Ihres Hosting-Anbieters an seine Grenzen kommt. Wenn Ihre Website mit zu viel Traffic belastet wird, ist der Da­ten­bank­ser­ver eventuell zu stark be­an­sprucht. Bei einigen Anbietern kann es vorkommen, dass eine große Anzahl Websites auf denselben Server gepackt wird. Wenn es dann auf einer Website zu erhöhtem Traffic kommt, kann dies Probleme für den Rest der Seiten ver­ur­sa­chen.

Sie sollten zur Si­cher­heit den Support Ihres Hosting-Anbieters kon­tak­tie­ren und ihn bitten, den Status des Da­ten­bank­ser­vers zu über­prü­fen. Viel­leicht gibt es ein tech­ni­sches Problem oder Ihr Hosting-Un­ter­neh­men hat Ihnen noch keine E-Mail bezüglich einer geplanten Ser­ver­war­tung geschickt.

4. Ver­bin­dungs­zeit ab­ge­lau­fen: Con­nec­tion timed out

Die Meldung „Con­nec­tion timed out“ bedeutet, dass eine Anfrage nicht innerhalb der vor­ge­se­he­nen Zeit ab­ge­schlos­sen werden konnte. In WordPress passiert das meist dann, wenn der Server, ein Plugin, ein Theme oder ein externer Dienst zu langsam reagiert.

Feh­ler­quel­le 1: Server ist über­las­tet

Eine der häu­figs­ten Ursachen ist ein über­las­te­ter Server. Das kann bei Shared Hosting, zu vielen gleich­zei­ti­gen Anfragen oder res­sour­cen­in­ten­si­ven Prozessen passieren. Reagiert der Server nicht schnell genug, bricht der Browser oder ein interner WordPress-Prozess mit einem Timeout ab.

Feh­ler­quel­le 2: Feh­ler­haf­te Plugins oder Themes

Plugins und Themes können Timeouts ver­ur­sa­chen, wenn sie zu viele Abfragen auslösen, feh­ler­haf­te Prozesse starten oder externe Dienste an­spre­chen, die nicht recht­zei­tig antworten. De­ak­ti­vie­ren Sie testweise alle Plugins und prüfen Sie, ob der Fehler ver­schwin­det. Ak­ti­vie­ren Sie sie an­schlie­ßend nach­ein­an­der wieder. Falls nötig, wechseln Sie zu­sätz­lich vor­über­ge­hend auf ein Standard-Theme.

Feh­ler­quel­le 3: Aus­ge­reiz­te PHP-Spei­cher­gren­ze

Reicht der ver­füg­ba­re PHP-Speicher nicht aus, können Prozesse abbrechen oder un­ge­wöhn­lich lange hängen bleiben. In solchen Fällen kann es helfen, das WordPress-Spei­cher­li­mit in der wp-config.php zu erhöhen. Da WordPress stan­dard­mä­ßig bereits 40 MB bei Ein­zel­in­stal­la­tio­nen und 64 MB bei Multisite anfordert, sollte ein manueller Wert in der Regel höher angesetzt werden:

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

Sie sollten jedoch beachten, dass bei Shared-Web­hos­ting Ihre Spei­cher­gren­ze nur bis zu einer gewissen Grenze erhöhbar ist. Wollen Sie sie darüber hinaus erhöhen, müssen Sie Ihren Webhoster kon­tak­tie­ren, damit dieser die Spei­cher­gren­ze für Sie erhöht. Beachten Sie hierbei, dass viele Shared-Hosting-Provider die PHP-Spei­cher­gren­ze sehr niedrig halten.

Feh­ler­quel­le 4: Zu niedrige maximale PHP-Aus­füh­rungs­zeit

Ein Timeout kann auch dann auftreten, wenn ein PHP-Skript länger für die Aus­füh­rung benötigt, als auf dem Server erlaubt ist. In solchen Fällen erscheint häufig eine Meldung wie „Maximum execution time of 30 seconds exceeded“. Die relevante Ein­stel­lung dafür heißt max_execution_time und wird in der php.ini fest­ge­legt. Sie bestimmt, wie viele Sekunden ein Skript maximal laufen darf, bevor es beendet wird. Stan­dard­mä­ßig liegt dieser Wert im Web-Kontext oft bei 30 Sekunden.

Wenn Ihre Website bei be­stimm­ten Vorgängen re­gel­mä­ßig in ein Timeout läuft, etwa bei Importen, großen Uploads, Updates oder re­chen­in­ten­si­ven Plugins, kann eine Erhöhung dieses Werts helfen. In der php.ini sieht das zum Beispiel so aus:

max_execution_time = 60

5. WordPress speichert keine Än­de­run­gen

Wenn WordPress Än­de­run­gen nicht sichtbar übernimmt, bedeutet das nicht au­to­ma­tisch, dass sie nicht ge­spei­chert wurden. Sehr oft werden statt­des­sen noch alte, zwi­schen­ge­spei­cher­te Versionen Ihrer Website angezeigt. Die häu­figs­ten Ursachen sind der Browser-Cache, ein Caching-Plugin, ser­ver­sei­ti­ges Caching beim Hoster oder ein CDN.

Lösung 1: Seite voll­stän­dig neu laden

Browser speichern Inhalte im Cache, damit Seiten bei späteren Aufrufen schneller laden. Laden Sie die Seite deshalb einmal hart neu. Unter Windows funk­tio­niert das häufig mit [Strg] + [F5] oder [Strg] + [Shift] + [R], auf dem Mac meist mit [Cmd] + [Shift] + [R].

Lösung 2: Browser-Cache leeren

Wenn das harte Neuladen nicht hilft, leeren Sie den Browser-Cache komplett. Das ist sinnvoll, wenn der Browser weiterhin Dateien wie Style­sheets, Ja­va­Script oder Bilder aus einer alten Version lädt. Danach öffnen Sie die Seite erneut und prüfen, ob die Änderung sichtbar wird. Dieser Schritt ist besonders wichtig, wenn Sie an CSS, Theme-Dateien oder Layout-An­pas­sun­gen ge­ar­bei­tet haben.

Lösung 3: Cache in WordPress oder im Hosting löschen

Bleibt die alte Version weiterhin sichtbar, liegt die Ursache oft nicht mehr im Browser, sondern direkt auf dem Server. Viele WordPress-Websites nutzen heute zu­sätz­li­che Caching-Ebenen, zum Beispiel durch Cache-Plugins, ser­ver­sei­ti­ges Hosting-Caching oder ein CDN. Solche Systeme liefern Besuchern ab­sicht­lich zwi­schen­ge­spei­cher­te Versionen aus, damit die Website schneller lädt. Genau deshalb können Än­de­run­gen trotz korrekter Spei­che­rung zunächst un­sicht­bar bleiben.

Löschen Sie deshalb nach­ein­an­der:

• den Cache Ihres Caching-Plugins
• den ser­ver­sei­ti­gen Cache Ihres Hosters
• den CDN-Cache, falls ein CDN verwendet wird

Viele Hoster bieten dafür im Kun­den­me­nü oder direkt im WordPress-Dashboard eine Funktion wie „Cache leeren“, „Purge Cache“ oder „Flush Cache“ an.

Lösung 4: Än­de­rungs­spei­che­rung im Editor prüfen

Wenn die Seite nicht nur alte Inhalte anzeigt, sondern Än­de­run­gen im Editor selbst nicht über­nom­men werden, kann auch ein Problem beim ei­gent­li­chen Spei­cher­vor­gang vorliegen. Das ist vor allem im Block-Editor relevant, weil WordPress Inhalte dort über Ja­va­Script und die REST-API ver­ar­bei­tet. Tritt dabei ein Fehler auf, werden Än­de­run­gen unter Umständen nicht korrekt ge­spei­chert, auch wenn es zunächst so wirkt.

In solchen Fällen sollten Sie testweise alle Plugins de­ak­ti­vie­ren und prüfen, ob der Fehler weiterhin besteht.

Lösung 5: Upload und Pfad kon­trol­lie­ren

Wenn Sie Än­de­run­gen direkt an Dateien vor­ge­nom­men haben, zum Beispiel an CSS-, Template- oder Theme-Dateien, prüfen Sie zu­sätz­lich, ob die geänderte Datei wirklich auf den Server hoch­ge­la­den wurde und im richtigen Ordner liegt. Es kommt häufiger vor, dass lokal zwar die richtige Datei be­ar­bei­tet wurde, auf dem Server aber noch eine ältere Version liegt oder ver­se­hent­lich eine falsche Datei über­schrie­ben wurde.

Gerade bei Child-Themes oder mehreren Theme-Versionen auf dem Server lohnt sich ein genauer Blick auf den Pfad.

6. An­dau­ern­der War­tungs­mo­dus nach einem Upgrade

Wenn WordPress während eines Updates hängen bleibt, kann Ihre Website dauerhaft die Meldung anzeigen: „Briefly un­available for scheduled main­ten­an­ce. Check back in a minute.“ Ursache ist meist eine Datei namens .maintenance, die WordPress während eines Updates au­to­ma­tisch im Root-Ver­zeich­nis anlegt. Nor­ma­ler­wei­se wird sie nach Abschluss des Updates wieder gelöscht. Passiert das nicht, bleibt die Website im War­tungs­mo­dus hängen.

Die Lösung ist in den meisten Fällen einfach:

1. Melden Sie sich per FTP oder über den Da­tei­ma­na­ger Ihres Hosters an.
2. Öffnen Sie das Haupt­ver­zeich­nis Ihrer WordPress-In­stal­la­ti­on, also den Ordner, in dem sich auch die Datei wp-config.php befindet.
3. Löschen Sie dort die Datei .maintenance. Laden Sie die Website an­schlie­ßend neu.

Bleibt das Problem bestehen, war ver­mut­lich nicht nur die War­tungs­da­tei das Problem, sondern das ei­gent­li­che Update ist fehl­ge­schla­gen. In diesem Fall sollten Sie das zuletzt ak­tua­li­sier­te Plugin, Theme oder ge­ge­be­nen­falls das Core-Update prüfen und manuell neu in­stal­lie­ren oder ak­tua­li­sie­ren. Hilfreich sind außerdem die Server-Logs oder die WordPress-Feh­ler­pro­to­kol­le, weil dort oft erkennbar wird, warum das Update ab­ge­bro­chen ist.

7. Syn­tax­feh­ler

Ein Syn­tax­feh­ler wird in der Regel durch einen kleinen, aber ent­schei­den­den Fehler in Ihrer Code-Syntax ver­ur­sacht. Ein fehlendes Komma oder eine falsche Klammer un­ter­bricht unter Umständen das ganze Skript. Häufig tritt der Fehler auf, nachdem Code manuell in eine Theme-Datei, die functions.php, ein Plugin oder ein eigenes Snippet eingefügt wurde. Die Feh­ler­mel­dung nennt in vielen Fällen bereits die be­trof­fe­ne Datei und die Zei­len­num­mer. Daran können Sie erkennen, welche Stelle geprüft werden muss.

Um den Syn­tax­feh­ler zu beheben, müssen Sie den Code­ab­schnitt be­ar­bei­ten, der diesen Fehler ver­ur­sacht. Entweder entfernen Sie ihn ganz, oder Sie re­pa­rie­ren die Syntax. Am ein­fachs­ten gelingt das über FTP, den Da­tei­ma­na­ger des Hosters oder eine andere direkte Zu­griffs­mög­lich­keit auf die be­trof­fe­ne Datei.

Seit WordPress 5.2 kann außerdem der Recovery-Modus helfen: In vielen Fällen zeigt WordPress statt einer leeren Seite eine Feh­ler­mel­dung an und sendet einen Wie­der­her­stel­lungs­link per E-Mail an die Admin-Adresse.

8. Fehl­ge­schla­ge­nes au­to­ma­ti­sches Update: Automatic Update Fail

WordPress in­stal­liert viele kleinere und si­cher­heits­re­le­van­te Updates au­to­ma­tisch im Hin­ter­grund. Scheitert ein solches Update, kann die Website vor­über­ge­hend im War­tungs­mo­dus hängen bleiben oder eine Meldung wie „Update failed“ anzeigen.

Der erste Schritt ist meist einfach: Löschen Sie die Datei .maintenance im Root-Ver­zeich­nis Ihrer WordPress-In­stal­la­ti­on, also in dem Ordner, in dem sich auch wp-config.php befindet. Danach laden Sie die Website neu. Funk­tio­niert die Website danach wieder, sollten Sie prüfen, welches Update fehl­ge­schla­gen ist – also ob ein Plugin, ein Theme oder WordPress selbst betroffen war. Führen Sie das Update an­schlie­ßend erneut aus. Wenn das au­to­ma­ti­sche Update wieder scheitert, ist ein manuelles Update meist der sicherste Weg.

9. Probleme beim Hochladen von Bildern in WordPress

Wenn sich Bilder in WordPress nicht hochladen lassen, liegt die Ursache nicht immer direkt bei WordPress selbst. Häufig stecken feh­ler­haf­te Da­tei­be­rech­ti­gun­gen, zu niedrige Ser­ver­li­mits, Probleme bei der Bild­ver­ar­bei­tung oder Konflikte mit Plugins dahinter. Auch moderne Bild­for­ma­te wie WebP und AVIF können Schwie­rig­kei­ten ver­ur­sa­chen, wenn die be­nö­tig­ten Ser­ver­bi­blio­the­ken nicht korrekt ein­ge­rich­tet sind.

Ein erster Blick in „Werkzeuge“ → „Website-Zustand“ → „Infos“ lohnt sich fast immer. Dort finden Sie unter anderem Angaben zur Me­di­en­ver­ar­bei­tung, zu den Da­tei­sys­tem-Be­rech­ti­gun­gen und zu Ihrer Ser­ver­um­ge­bung. So erkennen Sie schneller, ob WordPress Bilder grund­sätz­lich ver­ar­bei­ten kann oder ob es bereits Hinweise auf ein Ser­ver­pro­blem gibt.

Lösung 1: Da­tei­be­rech­ti­gun­gen prüfen

Wenn Sie den Verdacht haben, dass Be­rech­ti­gun­gen die Ursache sind, verbinden Sie sich per FTP, SFTP oder über den Da­tei­ma­na­ger Ihres Hosters mit der Website und öffnen Sie den Ordner /wp-content/. Darin befindet sich das Ver­zeich­nis /uploads/.

Prüfen Sie zunächst die Be­rech­ti­gun­gen für das Ver­zeich­nis uploads und für alle darin liegenden Un­ter­ord­ner. Für Ver­zeich­nis­se ist in der Regel 755 der richtige Wert. An­schlie­ßend prüfen Sie die Dateien innerhalb dieses Ordners. Für Dateien ist nor­ma­ler­wei­se 644 korrekt. Diese Kom­bi­na­ti­on ent­spricht den üblichen WordPress-Emp­feh­lun­gen für Stan­dard­um­ge­bun­gen.

Lösung 2: Ser­ver­ein­stel­lun­gen

Ein weiterer häufiger Grund für Probleme beim Bil­de­ru­pload sind zu niedrige Ser­ver­ein­stel­lun­gen. Dazu gehören ins­be­son­de­re die PHP-Werte upload_max_filesize, post_max_size, memory_limit sowie die maximale Aus­füh­rungs­zeit. Diese Limits bestimmen, wie große Dateien hoch­ge­la­den und wie aufwendig Bilder ver­ar­bei­tet werden dürfen. Gerade bei hoch­auf­lö­sen­den Bildern oder wenn mehrere Bild­grö­ßen au­to­ma­tisch erzeugt werden, reichen die Stan­dard­wer­te vieler Hosting-Pakete oft nicht aus.

Prüfen Sie zunächst in Ihrem Hosting-Panel oder über die PHP-Info, wie hoch diese Werte aktuell gesetzt sind. Wenn Uploads fehl­schla­gen oder Feh­ler­mel­dun­gen auftreten, erhöhen Sie die Limits schritt­wei­se. Ori­en­tie­ren Sie sich dabei an folgenden Richt­wer­ten:

• upload_max_filesize: min­des­tens 64 MB, bei bild­las­ti­gen Seiten oder hoch­auf­lö­sen­den Fotos besser 128 MB oder höher
• post_max_size: min­des­tens so hoch wie upload_max_filesize
• memory_limit: min­des­tens 256 MB

Falls Sie keinen direkten Zugriff auf diese Ein­stel­lun­gen haben, wenden Sie sich an Ihren Hosting-Anbieter und lassen die Werte ent­spre­chend anpassen.

Lösung 3: Moderne Bild­for­ma­te

Wenn JPG- oder PNG-Dateien funk­tio­nie­ren, WebP- oder AVIF-Dateien aber nicht, liegt das Problem oft nicht am Upload-Ordner, sondern an der Bild­ver­ar­bei­tung auf dem Server. WordPress un­ter­stützt WebP seit Version 5.8 und AVIF seit Version 6.5 nativ – ein zu­sätz­li­ches Plugin ist dafür nicht er­for­der­lich. Ob Sie diese Formate tat­säch­lich nutzen können, hängt jedoch von Ihrer Hosting-Umgebung ab:

Für AVIF muss auf dem Server entweder Imagick oder LibGD mit AVIF-Un­ter­stüt­zung aktiviert sein. Zu­sätz­lich ist PHP 8.1 oder höher er­for­der­lich, damit die GD-Extension AVIF nativ ver­ar­bei­ten kann. Ob das der Fall ist, können Sie unter „Werkzeuge“ → „Website-Zustand“ → „Info“ → „Me­di­en­ver­ar­bei­tung“ prüfen. Fehlt diese Un­ter­stüt­zung, kann es zu Fehlern beim Upload oder bei der au­to­ma­ti­schen Bild­grö­ßen­ge­ne­rie­rung kommen.

10. Sidebar erscheint unter dem Haupt­in­halt

Wenn die Sidebar in WordPress unter dem Haupt­in­halt statt daneben angezeigt wird, liegt in der Regel ein Problem mit dem Layout vor. Die Seite wirkt dadurch schnell un­über­sicht­lich oder „kaputt“, ist aber meist mit wenigen An­pas­sun­gen wieder korrekt dar­stell­bar.

Wichtig ist zunächst die Ein­ord­nung: Nicht immer handelt es sich um einen echten Fehler. Viele moderne Themes ver­schie­ben die Sidebar auf kleineren Bild­schirm­grö­ßen bewusst unter den Inhalt, um die Les­bar­keit auf Smart­phones zu ver­bes­sern. Prüfen Sie daher zuerst, ob das Problem auch auf Desktop-Geräten besteht oder nur bei kleineren Bild­schirm­brei­ten auftritt.

Häufige Ursachen für das Problem

Eine klas­si­sche Ursache ist feh­ler­haf­ter HTML-Code, etwa durch nicht korrekt ge­schlos­se­ne Elemente. In solchen Fällen wird die Sei­ten­struk­tur un­ter­bro­chen, sodass die Sidebar nicht mehr korrekt neben dem Inhalt po­si­tio­niert werden kann. Ebenso häufig sind feh­ler­haf­te oder wi­der­sprüch­li­che CSS-Angaben. Wenn Haupt­in­halt und Sidebar zusammen mehr Platz benötigen, als im Layout vor­ge­se­hen ist, wird die Sidebar au­to­ma­tisch unter den Content ver­scho­ben. Das kann unter anderem durch folgende Punkte ausgelöst werden:

• zu große Brei­ten­an­ga­ben für Content oder Sidebar
• zu­sätz­li­ches Padding oder Margin
• falsche max-width-Werte
• feh­ler­haf­te Ein­stel­lun­gen bei Flexbox oder Grid-Layouts

Auch Än­de­run­gen an der CSS-Datei oder in­di­vi­du­el­les Custom CSS können dazu führen, dass sich das Layout un­er­war­tet ver­schiebt.

Ein weiterer häufiger Grund liegt in der Theme- oder Template-Struktur. Moderne WordPress-Themes – ins­be­son­de­re Block-Themes – arbeiten nicht mehr zwingend mit klas­si­schen Sidebars, sondern mit Layout-Blöcken oder Template-Dateien. Wenn bei­spiels­wei­se ein „Full Width“-Template aus­ge­wählt ist oder die Sidebar im Template entfernt wurde, erscheint sie nicht mehr neben dem Inhalt.

Darüber hinaus können Plugins oder Page Builder das Layout be­ein­flus­sen. Tools zur Per­for­mance-Op­ti­mie­rung, CSS-Kom­pri­mie­rung oder visuelle Builder greifen oft in die Dar­stel­lung ein und können un­be­ab­sich­tigt dazu führen, dass sich die Sidebar ver­schiebt.

Konkrete Hand­lungs­emp­feh­lung

Gehen Sie Schritt für Schritt vor, um die Ursache ein­zu­gren­zen:

1. Prüfen Sie, ob das Problem nur auf mobilen Geräten auftritt (Re­spon­si­ve Design).
2. Kon­trol­lie­ren Sie, ob ein anderes Seiten-Template (z. B. „Standard“ statt „Full Width“) aus­ge­wählt ist.
3. De­ak­ti­vie­ren Sie testweise kürzlich in­stal­lier­te Plugins oder Page Builder.
4. Über­prü­fen Sie in­di­vi­du­el­len HTML-Code auf nicht ge­schlos­se­ne Elemente (z. B. mit einem HTML-Validator).
5. Kon­trol­lie­ren Sie CSS-An­pas­sun­gen, ins­be­son­de­re Breiten, Abstände und Layout-Ein­stel­lun­gen.
6. Testen Sie, ob das Problem auch beim Wechsel auf ein Standard-Theme weiterhin besteht.

Wenn die Sidebar nach diesen Schritten weiterhin unter dem Inhalt erscheint, lohnt sich ein Blick in die Theme-Dateien oder die Un­ter­stüt­zung durch den Hosting- bzw. Theme-Support.