Wordpress
Warum die WordPress-Site-Health-Warnungen oft übertrieben sind

Wenn Ihr im Backend unter Werkzeuge > Website-Zustand seht, dass WordPress “Kritische Probleme” oder “Empfohlene Verbesserungen” meldet, dann ist das meistens kein Grund zur Panik. Diese Hinweise sind oft generisch, technisch und nicht unbedingt auf Eure konkrete Installation oder Wartungsroutine zugeschnitten.

Da wir etwa 75 % der von uns erstellten Seiten durch ein Wartungspaket betreuen, erledigen wir Updates, Backups und Checks kontrolliert. Viele der WordPress-Hinweise sind dann eher Lärm als echte Alarmglocke. Im Folgenden zerlegen wir die häufigsten Meldungen und erklären, wieso sie weniger dramatisch sind als sie klingen — und wie wir damit umgehen.

“Kritische Fehler” – Typische Meldungen und unsere Einschätzung

Das Wort “kritisch” bei WordPress ist irreführend – praktisch nie handelt es sich um einen existenziellen Fehler, der sofort Eingreifen erfordert.

· Automatisch geladene Optionen können die Leistung beeinflussen

Was bedeutet das?
WordPress lädt in jeder Seitenanfrage alle Optionen, die in der Tabelle wp_options mit autoload = yes markiert sind („automatisch laden“). Wenn zu viele solcher Optionen existieren oder wenn sie sehr große Daten enthalten, kann das die Datenbankzugriffe verlangsamen.

Warum das oft übertrieben ist (und nicht “kritisch”):

Nicht alle autoloadbaren Optionen belasten spürbar — viele sind klein, häufig genutzt oder cachebar.
Wir kontrollieren bei unseren Projekten, welche Plugins und Themes wir einsetzen, und wissen, dass wir keine unnötigen oder überdimensionierten Optionen zulassen.
Wenn die Seite in der Praxis “schnell genug” ist und Besucher:innen keine Verzögerung merken, dann ist dieser Hinweis oft akademisch.

Wie wir damit umgehen:
Wir prüfen bei Bedarf die autoload-Datenbankeinträge (z. B. via wp-cli oder phpMyAdmin), insbesondere nach Deinstallationen von Plugins, und entfernen unerwünschte Einträge. So bleibt alles sauber. Falls uns nichts Auffälliges auffällt, kann man diese Warnung getrost als Hinweis betrachten, nicht als Alarm.

· Hintergrund-Updates funktionieren nicht wie erwartet

Was bedeutet das?
WordPress prüft und führt bestimmte automatische Hintergrundaktualisierungen durch (z. B. kleinere Sicherheits-Updates). Wenn diese Funktion “nicht wie erwartet funktioniert”, meldet WordPress das als kritisches Problem (Sicherheitsthema).

Warum diese Meldung oft harmlos ist:

Wir deaktivieren – bewusst – automatische Kernupdates oder automatische Updates für Plugins/Themes bei unseren Kundenprojekten. Der Grund: Wir möchten kontrolliert updates durchführen — mit Backups, Tests etc. Falls automatische Updates gewünscht sind, bitte sprecht uns an. Das können wir natürlich gerne freischalten.
Wenn man den automatischen Update-Mechanismus deaktiviert, erzeugt das zwangsläufig diese Warnung. Viele Hosts oder Wartungsverträge managen Updates ohnehin anders.

Wie wir damit umgehen:
Wir setzen Updates manuell oder zeitgesteuert mit vorheriger Sicherung um. Bei uns wird nichts wahllos automatisch live gebracht. Diese Meldung ignorieren wir bewusst — allerdings dokumentieren wir intern, dass das System aktuell “deaktiviert” ist, und wir gewährleisten, dass Updates trotzdem regelmäßig erfolgen, falls ein Wartungspaket bei uns beauftragt wurde.

· Seiten-Cache wurde nicht erkannt & Serverantwortzeit langsam

Was das heißt:
WordPress erkennt (über verschiedene Prüfungen) ob ein Full-Page-Cache vorhanden ist und ob die Antwortzeit des Servers (Time To First Byte etc.) akzeptabel ist. Wenn kein Cache erkannt wird oder der Server zu langsam reagiert, erscheint ein Warnhinweis.

Warum es selten ein echtes Drama ist:

Ein Cache-Plugin (z. B. WP Rocket, W3 Total Cache, LiteSpeed Cache) ist nicht in allen Projekten notwendig oder sinnvoll — manche Seiten sind so schlank oder so wenig besucht, dass der Overhead eines Caches nicht lohnend ist.
Wenn Besucher:innen die Seite subjektiv als “schnell genug” empfinden und keine Performanceprobleme auftreten, dann hat diese Warnung keine Priorität.
Der Hinweis ist eine Empfehlung, kein Beweis für einen Ausfall.
Wir prüfen bei Bedarf, ob ein Cache sinnvoll ist, und setzen ihn, wenn das Projekt, Traffic oder technische Voraussetzungen es rechtfertigen – sprecht uns einfach an.

Wie wir damit umgehen:
Wir schauen uns bei größeren Projekten die Performance an (Ladezeiten, Nutzererfahrung). Wenn ein Cache merkliche Vorteile bringt, implementieren wir ihn im Rahmen eines Performance-Sprints.

„Empfohlene Verbesserungen“ – und wie wir sie sehen

Diese Kategorie enthält Hinweise, die WordPress als “nicht kritisch, aber wünschenswert” einstuft. Für viele dieser Hinweise gilt: gut, dass sie existieren — aber nicht alle müssen umgesetzt werden.

· Inaktive Plugins sollten entfernt werden

Was dahinter steht:
Ein Plugin, das deaktiviert ist, aber im System verbleibt, ist oft ein potenzielles Sicherheitsrisiko (weil veraltet) und eine unnötige Belastung für Updates, Backups und Codepflege.

Warum wir nicht blind löschen:

In einigen Fällen halten wir inaktive Plugins bereit, z. B. wenn Änderungen oder Erweiterungen später notwendig werden.
Wenn ein Plugin deinstalliert wird, hinterlässt es oft Datenbankeinträge oder Konfigurationen, die man beim Reaktivieren wieder benötigt — ein vorschnelles Löschen kann Arbeit kosten.
Wir sorgen intern dafür, dass wirklich unnötige Plugins entfernt werden, sobald wir sicher sind, dass sie nicht gebraucht werden.

Unser Vorgehen:
Wir löschen inaktive Plugins konsequent, wenn sie nicht mehr gebraucht werden. Vor jeder Löschung machen wir Backup, testen ggf. auf Staging und dokumentieren, falls Rückfall nötig ist. Die Warnung ist also sinnvoll, aber bei uns kontrolliert umgesetzt.

· Ein Standard-Theme zur Verfügung haben

Was das heißt:
WordPress empfiehlt, stets mindestens ein offizielles Standard-Theme (wie Twenty Twenty-X) installiert und verfügbar zu halten, falls das aktive Theme ausfällt.

Warum das oft irrelevant wird:

In professionell betreuten Seitenumgebungen nutzen wir eigene Themes oder Child-Themes mit vollständiger Kontrolle.
Wenn ein Theme ausfällt, greifen wir über Wartung, Backups oder manuellen Eingriff ein, ohne auf ein Standard-Theme zurückgreifen zu müssen.
Der Standard-Theme-Sicherheitsmechanismus ist eher eine Notfalllösung für einfache Installationen ohne Agenturbetreuung.

Unsere Position:
Wir stimmen zu, dass ein Standard-Theme rein zur Sicherheit nicht schadet. Aber bei uns ist das selten erforderlich, da wir das gesamte Theme-Ökosystem kontrollieren. Wenn Ihr unbedingt ein offizielles Theme behaltet, können wir das optional einrichten.

· Du solltest einen persistenten Objekt-Cache verwenden

Erklärung:
Ein persistent object cache (z. B. über Redis oder Memcached) erlaubt es, Datenbankabfragen und Teile von Objekten zwischen Anfragen im Speicher zu halten, anstatt sie bei jeder Anfrage neu zu berechnen. Das kann die Performance besonders bei datenintensiven Seiten oder bei hoher Last verbessern.

Warum dieser Hinweis umstritten ist:

Diese Warnung wurde erst mit WordPress 6.1 eingeführt.
Für viele Websites bringt der persistente Objekt-Cache kaum messbare Vorteile, besonders wenn Traffic und Datenbanklast gering sind. Einige Betreiber berichten sogar, dass die ständige Warnung im WordPress-Backend unnötig Verunsicherung auslöst: Sie klingt, als würde ohne Redis oder Memcached sofort ein Leistungsproblem drohen. In Wahrheit ist das Feature aber nur für sehr große oder stark frequentierte Installationen relevant. Wer eine normale Unternehmens- oder Projektseite betreibt, muss sich davon also nicht einschüchtern lassen.
Der Server bzw. Hosting muss Redis / Memcached unterstützen — oft ist dies auf Shared-Hosting-Umgebungen nicht verfügbar.
In manchen Fällen kann ein falsch konfigurierter object cache sogar dynamische Inhalte “ver Kaschieren” und Fehler erzeugen.

Wie wir entscheiden:
Wir prüfen, ob der technische Rahmen (Hosting, Serverzugriff) Redis oder Memcached zulässt, und ob das Projekt von einem persistent object cache profitieren würde. Wenn ja, setzen wir ihn ein, machen Tests und überwachen. Wenn nicht, lassen wir es bleiben und ignorieren die Warnung — bewusst und mit Begründung.

Schlussgedanken & Empfehlungen (mit Drohung gegen Panik)

Die Wortwahl “Kritisch” in WordPress ist oft überzogen. Nur in sehr seltenen Fällen handelt es sich um sofort zu behebende Notfälle.
Die “Empfohlenen Verbesserungen” sind Hinweise, nicht Ultimaten. Sie bieten Orientierung, aber nicht zwingende Maßnahmen.
Bei einem Wartungspaket: Wir kümmern uns um Updates, Backups und Kontrolle — also müsst Ihr Euch nicht durch alle Warnungen stressen lassen.