Im letzten Jahr habe ich von Kund:innen mehrfach die Frage bekommen, was die Fehler/Warnungen im Website-Zustand (Site Health) bedeuten. Was früher nur als Plugin existierte, wurde ja mit WordPress 5.2 in den Core hinzugefügt und meldet die Ergebnisse auch in einem Dashboard-Widget. Doch die Hinweise sind ziemlich technisch, daher nun die Erklärung für die meisten Hinweise, die bei euch auftauchen können und wie sie gelöst werden können.

Inaktive Plugins/Themes sollten entfernt werden

Ja, das ist richtig, weil es häufig auch ausreicht, wenn ein Plugin nur installiert ist, um eine vorhandene Sicherheitslücke auszunutzen. Ob das Plugin/Theme aktiv ist, spielt dafür meistens keine Rolle.

Sofern keine Sicherheitslücken vorliegen, gibt es aber auch kein akutes Problem. Insofern ist das reine Prophylaxe.

Es ist empfohlen, nur die Plugins in der Site zu haben, die auch wirklich aktiv benötigt werden. Beim Entfernen darauf achten, ob die Daten des Plugins auch gelöscht werden sollen. Bei manchen Plugins muss das Löschen der Daten aktiv eingestellt werden, sonst bleiben die Daten zum Beispiel in der Datenbank gespeichert.

Auch Debugging-Tools wie Query Monitor oder Plugin Report sollten nicht in einer produktiv genutzten Site installiert sein. Nach Nutzung bitte wieder entfernen.

PHP veraltet (x.y) – empfohlen ist x.y oder höher

Theoretisch richtig, aber solange es nicht unter (aktuell) 8.2 ist, bist du noch mit Sicherheitspatches versorgt. Erst darunter gibt es gegebenenfalls (!) ein Problem.
Siehe auch: https://www.php.net/supported-versions.php

Da neuere PHP-Versionen meist auch performanter sind, ist es tatsächlich empfehlenswert, die PHP-Version möglichst aktuell zu halten. Da immer zwei PHP-Versionen aktiv entwickelt werden, ist meine Empfehlung immer auf die zweitaktuellste Version zu setzen, aktuell also 8.4. Das ist ein guter Kompromiss zwischen Aktualität und Stabilität.

Nur wenn die Version bei deinem Theme oder Plugins Probleme macht, wird auf die Versionen darunter ausgewichen, die nicht mehr aktiv entwickelt werden, aber noch Sicherheitsupdates bekommen.

PHP-Versionen, die keine Sicherheitsupdates bekommen, sollten nicht eingesetzt werden. Aber es bedeutet auch nicht, dass die Site sofort gehackt wird, wenn du diese Versionen noch nutzt. Aktiv ausgenutzte Sicherheitslücken in diesen Versionen sind mir zumindest nicht bekannt.

Ein oder mehrere empfohlene Module fehlen

Ist kein echtes Problem. Auf dem Server sollten bestimmte Module installiert sein, damit WordPress am besten funktioniert. Manche Module werden von WordPress daher empfohlen, aber es funktioniert auch mit Alternativen. IONOS nutzt zum Beispiel die GD Grafik-Bibliothek für die Bilderstellung. WordPress empfiehlt aber Image Magick, daher kommt die Warnung:

„Das optionale Modul imagick ist nicht installiert oder wurde deaktiviert“.

Für den Endanwender ist die genutzte Bibliothek aber egal, solange die gewünschten Funktionen funktionieren. Die Basisfunktionen können nämlich beide. Interessant wird es bei Spezialfällen, wie webP/AVIF-Erstellung o.ä. – das ist aber auch nichts, was du ändern könntest. Bei IONOS können nämlich keine eigenen Module nachinstalliert oder konfiguriert werden.

Aber wenn wir es nicht ändern können, kann zumindest die Warnung deaktiviert werden. Wie das geht, habe ich in diesem Artikel beschrieben:
https://torstenlandsiedel.de/2021/09/14/site-health-warnung-ueber-fehlende-module-ausblenden/

In dem Artikel findet ihr auch noch andere Module, für die es Warnungen gibt, wenn sie fehlen, obwohl die Alternativen installiert sind.

Veralteter SQL-Server

WordPress empfiehlt MySQL 8 und MariaDB 10.6 oder höher (https://de.wordpress.org/about/requirements/) – funktioniert aber auch mit MySQL 5.5.5 oder höher.

Wenn die Installation schon älter ist, dann kann es gut sein, dass beim Hoster die Datenbank auf einer älteren Version erstellt wurde. MySQL 5.7 war lange im Einsatz und kann es noch sein – daher die Warnung. Die wenigsten Hoster aktualisieren im laufenden Betrieb eine Datenbank proaktiv. Technisch notwendig ist das Update in den wenigsten Fällen. Neuere Versionen sind jedoch schneller/effizienter, aber für den Endanwender dürfte das kaum sichtbar sein.

Es gibt aber einen anderen Grund, um MySQL upzudaten. MySQL 5.7, die letzte Version vor MySQL 8 (Version 6 und 7 wurden übersprungen und nur intern genutzt), wurde nur bis zum 21. Oktober 2023 supportet. Es erhält daher keine Sicherheitsupdates mehr. Ein Update ist also dringend anzuraten, wenn diese Warnung kommt und der Hoster das Problem nicht selbst löst.

Wenn noch Datenbanken in deinem Tarif frei sind, kannst du eine neue leere Datenbank erstellen (mit MySQL 8+ oder MariaDB 10.6+, wie empfohlen). Dann exportierst du die bisherige WordPress-Datenbank und importierst sie in die neue leere Datenbank. Zuletzt stellst du die Datenbank-Zugangsdaten in der wp-config.php auf die neue Datenbank um.

Ein geplantes Ereignis ist verspätet

Dazu muss man verstehen, wie WordPress ein „Event“ (z.B. ein Cache aufräumen, Geplanten Beitrag veröffentlichen, etc.) steuert. Dazu wird jeder Besuch benutzt. Bei dem Request wird auch eine Funktion aufgerufen, die testet, ob ein Event vorliegt. Wenn zu dem geplanten Zeitpunkt jedoch kein Traffic (=Besucher) da sind, dann wird auch nichts getriggert und das Event „verspätet“ sich.

Wenn es sich dabei um Wartungsmaßnahmen handelt, ist das ja aber alles nicht zeitkritisch. Dann passiert es eben später, sobald der nächste Besucher es triggert. Es wäre theoretisch lösbar über einen Cronjob, aber das bietet zum Beispiel IONOS gar nicht an. Bei anderen Hostern, wie all-inkl.com, ist es nur als Webcron vorhanden und auch nur in höheren Tarifen.

Die Warnung kann bei wenig Traffic häufig vorkommen und stellt trotzdem kein ernsthaftes Problem dar. Es kann aber auch auf ein größeres Problem mit geplanten Ereignissen hinweisen. Das müsste dann tiefer geprüft werden, wenn es da weitere Probleme gibt.

Es gibt ein paar Plugins, die bei der Analyse helfen, wie WP Crontrol o.ä.:
https://wordpress.org/plugins/tags/cron/

Du solltest einen persistenten Objekt-Cache verwenden

Häufige Anfragen (Queries) an die Datenbank werden über einen Objekt-Cache zwischengespeichert, um schneller direkt aus dem Cache ausgegeben werden zu können, was DB-Anfragen beschleunigt.

Das funktioniert allerdings nur dann, wenn die notwendigen Module auf dem Server auch installiert und aktiviert sind. Und es ergibt auch nur Sinn, wenn viel Traffic passiert, sodass der Cache auch seinen Zweck erfüllt, also schnell hintereinander die gleiche Abfrage gestellt wird, sodass ein positiver Effekt entsteht.

IONOS hat zum Beispiel meines Erachtens keinen persistenten Objekt-Cache und daher ist das gar nicht lösbar in diesem Fall. Bei anderen Hostern kann es (ggf. auch je nach Tarif) selbst aktiviert oder beim Hoster angefragt werden.

In beiden Fällen wird aber auch noch ein Plugin benötigt, was diese Funktion steuert. Selbst wenn es aktivierbar wäre (ggf. über den Support), wäre die Frage, ob es bei deinem Traffic viel bringt.

Typische Vertreter wären Redis, memcached oder APCu. Query Monitor übrigens weist daraufhin, wenn die Module auf dem installiert sind, aber kein Plugin dafür vorhanden ist. Das ist aber noch keine Garantie dafür, dass es auch aktivierbar ist. Am besten sprecht ihr dazu euren Hoster an, sofern die Datenbank denn wirklich ein Flaschenhals bei euch ist und ihr hohen Traffic habt.

Ich vermute, dass dies am häufigsten als Empfehlung vorhanden ist, obwohl es keine Möglichkeit gibt, dies zu ändern, wenn es der Hoster nicht anbietet. In diesem Fall wäre nur ein höherer Tarif oder sogar ein Hoster-Wechsel die einzige Lösung. Etwas übertrieben, wenn diese Performance gar nicht benötigt wird. Ein Deaktivieren dieser Empfehlung wäre zumindest insofern eine „Lösung“, dass nicht ständig auf etwas hingewiesen wird, was wir aktuell nicht ändern können.

Seiten-Cache wurde nicht erkannt und die Antwortzeit des Servers ist langsam

WordPress hat keinen Cache erkannt und hat gemessen, dass es mehr als 600ms zum Laden benötigt. Die Lösung wäre somit, ein Caching-Plugin zu installieren oder andere Maßnahmen zu ergreifen, um die Ladezeit zu verbessern. Beim Seiten-Caching werden fertige HTML-Seiten generiert und bereitgehalten, sodass WordPress die Seiten nicht immer via PHP/MySQL neu zusammenbauen muss. Das entlastet die Server und beschleunigt die Website. Setzt aber voraus, dass diese PHP/MySQL-Nutzung auch wirklich der Flaschenhals ist. Muss also nicht zwingend helfen … in diesem Fall muss weiter recherchiert werden, warum die Ladezeit so hoch ist.

Die Erkennung eines Cache anhand von http Headern ist übrigens nicht zwingend und nur ein Hinweis. Sie hängt vom verwendeten Plugin und der Serverkonfiguration ab. Cachify setzt zum Beispiel beim HDD-Caching via .htaccess keine Header. Sofern der Server keine automatischen Header setzt, die WordPress erkennt, wird kein Caching erkannt, obwohl eines existiert.

Automatisch geladene Optionen können die Leistung beeinflussen

Einstellungen (Optionen) werden in WordPress über die Settings API in der Datenbank gespeichert. Leider wurde dabei in der Vergangenheit die Entscheidung getroffen, dass alle Options immer automatisch geladen werden, falls sie irgendwann gebraucht werden. Bei kleinen Optionen, wie AN/AUS, Zahlen, etc. ist das auch harmlos. Es gibt aber auch Themes oder Plugins, die in den Options riesige Datenmengen speichern. Zum Beispiel die Gesamtliste aller Google Fonts. Da diese Einstellungen bei jedem Request immer geladen werden, ist das irgendwann ein Performance-Problem.

Die Warnung kommt immer dann, wenn der Grenzwert von 800 KB an Daten überschritten wurde. Dabei werden die Daten aller automatisch geladenen Options addiert.

Um herauszufinden, welche Einstellung dies bei dir genau ist, installiere „AAA Option Optimizer“ und prüfe, welche Einstellung(en) so groß sind, dass sie zusammen über 800 KB ergeben und „autoload“ auf „yes“ steht.
https://de.wordpress.org/plugins/aaa-option-optimizer/

Ein bekanntes Problem ist zum Beispiel _transient_dirsize_cache. Der Website-Zustand rechnet ja auch im Info-Tab die Größe der Installation zusammen. Damit die Ordner nicht immer wieder neu ausgelesen werden müssen, speichert dieses Feature die Ordner in einer Einstellung ab. Leider wird diese Einstellung automatisch geladen und bei großen Installation mit vielen Ordnern kommen eine Menge Daten zusammen. Und die Core-Entwickler:innen haben sich unglücklicherweise dagegen entschieden dies retroaktiv zu fixen. Das müssen wir leider manuell machen.
Siehe: https://core.trac.wordpress.org/ticket/54221

---

Ich hoffe, dass ich damit ein paar Fragen beantworten konnte. Wenn irgendwas unklar geblieben ist, dann meldet euch gerne in den Kommentaren!