Wie man einen WordPress-Gesundheitscheck zur Fehlerbehebung durchführt (Leitfaden 2025)

Ein WordPress-Gesundheitscheck ist ein systematischer Diagnoseprozess, der die PHP-Version, Datenbankintegrität, aktive Plugins, Theme-Kompatibilität, Serverumgebung und Sicherheitslage Ihrer Website bewertet — alles über das WordPress-Admin-Dashboard oder dedizierte Tools. Die regelmäßige Durchführung dieses Checks verhindert Kaskadenausfälle, identifiziert Performance-Engpässe, bevor sie sich auf Rankings auswirken, und deckt Sicherheitslücken auf, bevor sie zu Sicherheitsverletzungen werden.

Das integrierte Site Health-Tool (eingeführt in WordPress 5.2) liefert einen automatisierten Statusbericht und ein Panel mit rohen Debug-Informationen, das erfahrene Entwickler als ersten Anlaufpunkt in jedem Fehlerbehebungs-Workflow nutzen. In Kombination mit dem Health Check & Troubleshooting-Plugin können Sie Produktionsprobleme in einer isolierten Sitzung reproduzieren, ohne die Live-Website zu berühren — eine Funktion, die das größte Einzelrisiko beim WordPress-Debugging eliminiert: Dinge für echte Besucher zu beschädigen, während Sie untersuchen.

Warum WordPress-Gesundheitschecks wichtiger sind, als die meisten Anleitungen zugeben

Die meisten Tutorials behandeln Site Health als eine Checkliste, die einmal abgehakt wird. In der Praxis ist es ein kontinuierliches Betriebssignal. Googles Core Web Vitals bestrafen langsame oder instabile Websites direkt. Ein einziges veraltetes Plugin mit einer bekannten CVE kann innerhalb von Stunden nach der öffentlichen Bekanntmachung zu einer vollständigen Website-Kompromittierung führen. PHP-Versionskonflikte zwischen Ihrem Server und den Mindestanforderungen eines Plugins verschlechtern die Performance still und leise, lange bevor sie einen fatalen Fehler auslösen.

Der Betrieb in einer gut konfigurierten VPS-Hosting-Umgebung gibt Ihnen direkte Kontrolle über PHP-Versionen, serverseitiges Caching und Sicherheitshärtung — eine Kontrolle, die Shared-Umgebungen schlicht nicht bieten können. Der unten beschriebene Gesundheitscheck-Workflow setzt voraus, dass Sie SSH-Zugang oder ein Control Panel haben, das serverseitige Einstellungen ändern kann, was die korrekte Ausgangsbasis für jede produktive WordPress-Bereitstellung ist.

Schritt 1: Zugriff auf das integrierte WordPress Site Health-Tool

Navigieren Sie in Ihrem WordPress-Admin-Dashboard zu Tools > Site Health. WordPress beginnt sofort mit der Durchführung automatisierter Checks und füllt den Status-Tab mit nach Schweregrad kategorisierten Ergebnissen.

Für diesen Schritt ist kein Plugin erforderlich. Site Health ist eine Kernfunktion, und ihre Ergebnisse werden serverseitig generiert, was bedeutet, dass sie die tatsächliche Laufzeitumgebung widerspiegeln — keine simulierte.

Was Site Health tatsächlich im Hintergrund prüft:

• PHP-Version, Speicherlimit und maximale Ausführungszeit
• Aktive WordPress-Version gegenüber der neuesten stabilen Version
• Ob die REST API zugänglich ist und gültige Antworten zurückgibt
• Status der geplanten Cron-Job-Ausführung (wp-cron)
• HTTPS-Durchsetzung und SSL-Zertifikatsgültigkeit
• Vorhandensein der debug.log-Datei an einem öffentlich zugänglichen Ort
• Loopback-Anfragefähigkeit (erforderlich für Hintergrundaktualisierungen und Plugin-Installationen)
• Datenbankserverversion und ob sie die WordPress-Mindestanforderungen erfüllt
• Datei- und Verzeichnisberechtigungen für sensible Pfade

Schritt 2: Den Site Health-Statusbericht korrekt interpretieren

Die Statusseite kategorisiert Befunde in drei Stufen. Zu verstehen, was jede Stufe tatsächlich bedeutet — und was sie nicht bedeutet — verhindert sowohl Gleichgültigkeit als auch unnötige Panik.

Kritische Probleme, die sofortige Aufmerksamkeit erfordern:

• Veraltete PHP-Version — PHP 7.4 hat im November 2022 das End-of-Life erreicht. Der Betrieb bedeutet keine Sicherheits-Patches. WordPress 6.x empfiehlt offiziell PHP 8.1 oder 8.2.
• Inaktive Plugins noch installiert — Inaktive Plugins sind weiterhin vom Dateisystem lesbar und können ausnutzbaren Code enthalten. Löschen Sie sie, deaktivieren Sie sie nicht nur.
• REST API blockiert — Viele moderne Plugins, der Block-Editor (Gutenberg) und WooCommerce sind auf die Verfügbarkeit der REST API angewiesen. Eine blockierte REST API erzeugt stille Fehler, die notorisch schwer zu verfolgen sind.
• Loopback-Anfragefehler — Wenn WordPress keine Loopback-HTTP-Anfrage an sich selbst stellen kann, werden automatische Hintergrundaktualisierungen und geplante Aufgaben still scheitern.
• WP_DEBUG auf einer Live-Website aktiviert — Der Debug-Modus schreibt sensible Konfigurationsdaten und Stack-Traces in debug.log. Wenn sich diese Datei in wp-content/ ohne serverseitige Zugriffsbeschränkungen befindet, ist sie öffentlich lesbar.

Ein häufig übersehener Sonderfall: Site Health meldet einen „Gut”-Status für Object-Caching, wenn *irgendein* Object-Cache erkannt wird — einschließlich eines dateibasierten. Dateibasiertes Object-Caching auf stark frequentierten Websites kann die I/O-Last tatsächlich erhöhen statt verringern. Die korrekte Lösung ist ein Redis- oder Memcached-Backend, das eine serverseitige Konfiguration erfordert, die Site Health nicht bereitstellen kann.

Schritt 3: Das Debug-Informationspanel extrahieren und nutzen

Klicken Sie auf der Site Health-Seite auf den Info-Tab. Dieses Panel ist für die Fehlerbehebung wohl wertvoller als der Status-Tab, da es rohe Umgebungsdaten offenlegt.

Wichtige Abschnitte und worauf zu achten ist:

• WordPress — Bestätigt das aktive Theme, ob Multisite aktiviert ist und ob WP_DEBUG aktiv ist.
• Verzeichnisse und Größen — Zeigt, ob wp-content/uploads/ auf eine Größe angewachsen ist, die die Festplatten-I/O oder Backup-Prozesse belastet.
• Aktive Plugins — Listet jedes aktive Plugin mit seiner Version auf. Gleichen Sie es mit der WordPress Vulnerability Database (wpscan.com) auf bekannte CVEs ab.
• Server — Zeigt PHP-Version, PHP-Speicherlimit, maximale Upload-Größe, maximale Ausführungszeit und ob mod_rewrite oder gleichwertiges URL-Rewriting aktiv ist.
• Datenbank — Bestätigt MySQL- oder MariaDB-Version und den Datenbank-Zeichensatz. utf8mb4 ist für vollständige Emoji- und Mehrsprachigkeitsunterstützung erforderlich; utf8 (3-Byte) wird bestimmte Zeichen still abschneiden.
• Must-Use-Plugins — Oft übersehen. MU-Plugins laden vor allen anderen Plugins und können nicht über die Admin-Oberfläche deaktiviert werden. Wenn ein Hosting-Anbieter ein MU-Plugin eingefügt hat (bei Managed Hosting üblich), erscheint es hier.

Praktische Nutzung der Schaltfläche „Website-Informationen in die Zwischenablage kopieren”:

Wenn Sie ein Support-Ticket öffnen oder in einem Entwicklerforum posten, fügen Sie diese Ausgabe direkt ein. Es eliminiert das Hin und Her grundlegender Umgebungsfragen und ermöglicht es erfahrenen Ingenieuren, Konfigurationsanomalien sofort zu erkennen — zum Beispiel ein memory_limit von 40M, wenn WooCommerce ein Minimum von 128M erfordert, oder ein max_execution_time von 30 Sekunden, wenn ein großer Importprozess 300 erfordert.

Schritt 4: Das Health Check & Troubleshooting-Plugin für Safe-Mode-Debugging verwenden

Das Health Check & Troubleshooting-Plugin (kostenlos im WordPress-Plugin-Repository verfügbar) ermöglicht einen sitzungsisolierten Safe Mode. Dies ist die korrekte Methode zur Diagnose von Plugin- und Theme-Konflikten auf einer Live-Produktionswebsite.

Wie die Sitzungsisolierung technisch funktioniert:

Das Plugin setzt ein Browser-Cookie, das WordPress bei jeder Anfrage liest. Wenn das Cookie vorhanden ist, lädt WordPress nur das Standard-Theme und deaktiviert alle nicht wesentlichen Plugins — aber *nur für die Browser-Sitzung, die dieses Cookie trägt*. Alle anderen Besucher erleben die Website genau so, wie sie vorher war. Dies ist keine Staging-Umgebung; es ist ein Laufzeitfilter, der auf der WordPress-Bootstrap-Ebene angewendet wird.

Installation und Aktivierung:

# If you have WP-CLI available on your server (recommended)
wp plugin install health-check --activate

Oder navigieren Sie zu Plugins > Neu hinzufügen, suchen Sie nach „Health Check & Troubleshooting” und klicken Sie auf Jetzt installieren, dann auf Aktivieren.

Durchführung einer Fehlerbehebungssitzung:

1. Gehen Sie zu Tools > Site Health und klicken Sie auf den Fehlerbehebung-Tab.
2. Klicken Sie auf Fehlerbehebungsmodus aktivieren. Ihre Sitzung läuft jetzt mit allen deaktivierten Plugins und dem aktiven Standard-Theme (Twenty Twenty-Four ab WordPress 6.5+).
3. Reproduzieren Sie das Problem. Wenn es verschwunden ist, ist ein Plugin oder Theme verantwortlich.
4. Aktivieren Sie Plugins einzeln über die Plugin-Liste des Fehlerbehebungs-Tabs wieder. Laden Sie nach der Aktivierung jedes Plugins die betroffene Seite neu und testen Sie.
5. Sobald das Problem wieder auftritt, ist das zuletzt aktivierte Plugin die Konfliktquelle.
6. Klicken Sie auf Fehlerbehebungsmodus deaktivieren, um die vollständige Produktionsumgebung wiederherzustellen.

Sonderfälle und Fallstricke:

• Wenn das Problem auch im Safe Mode bestehen bleibt (keine Plugins, Standard-Theme), liegt das Problem auf der Server- oder WordPress-Core-Ebene — kein Plugin-Konflikt. Überprüfen Sie als nächstes php_error.log und das WordPress-Debug-Log.
• MU-Plugins werden durch den Safe Mode nicht deaktiviert. Wenn Sie ein MU-Plugin verdächtigen, müssen Sie es in wp-content/mu-plugins/ manuell über SFTP oder SSH umbenennen.
• Das Fehlerbehebungs-Cookie ist browserspezifisch. Wenn Sie auf einem Mobilgerät testen, müssen Sie den Fehlerbehebungsmodus in dieser Browser-Sitzung separat aktivieren.

Schritt 5: Plugin- und Theme-Konflikte diagnostizieren und lösen

Plugin-Konflikte fallen in zwei Kategorien, die unterschiedliche Lösungsstrategien erfordern:

Typ 1: Direkte PHP-Konflikte — Zwei Plugins versuchen, dieselbe Funktion oder Klasse zu definieren. Dies erzeugt sofort einen fatalen Fehler. Das Fehlerprotokoll enthält Cannot redeclare function oder Cannot redeclare class.

Typ 2: Stille Verhaltenskonflikte — Zwei Plugins haken sich beide in dieselbe WordPress-Aktion oder denselben Filter ein und erzeugen unerwartete Ausgaben oder Datenbeschädigungen, ohne einen Fehler auszulösen. Diese sind erheblich schwieriger zu diagnostizieren und erfordern eine methodische Einzelisolierung.

Lösungs-Workflow:

# Check the WordPress debug log for fatal errors
tail -n 100 /path/to/wp-content/debug.log

# Enable WP_DEBUG temporarily via wp-config.php if debug.log is empty
# Add these lines to wp-config.php before the "stop editing" comment:
# define('WP_DEBUG', true);
# define('WP_DEBUG_LOG', true);
# define('WP_DEBUG_DISPLAY', false);

Wenn ein Plugin als bestätigte Konfliktquelle identifiziert wurde:

1. Überprüfen Sie das Changelog des Plugins auf ein aktuelles Update, das den Konflikt behebt.
2. Suchen Sie im Support-Forum des Plugins auf wordpress.org nach Berichten über denselben Konflikt.
3. Wenn keine Lösung verfügbar ist, identifizieren Sie ein alternatives Plugin mit gleichwertiger Funktionalität.
4. Wenn das Plugin geschäftskritisch ist, kontaktieren Sie den Plugin-Autor mit dem spezifischen Fehler aus Ihrem Debug-Log — geben Sie Ihre PHP-Version, WordPress-Version sowie den Namen und die Version des konfliktierenden Plugins an.

Schritt 6: PHP- und Datenbankserverversionen aktualisieren

Dies ist die einzelne wirkungsvollste Wartungsmaßnahme für Performance und Sicherheit. PHP 8.1 und 8.2 liefern messbare Durchsatzverbesserungen gegenüber PHP 7.4 — Benchmarks zeigen konsistent 20–30% schnellere Ausführung für typische WordPress-Workloads aufgrund von JIT-Kompilierung und verbessertem OPcache-Verhalten.

PHP-Versionskompatibilitätsmatrix für WordPress:

PHP über cPanel aktualisieren (für VPS mit cPanel-Umgebungen):

1. Melden Sie sich bei WHM (Root-Zugang) oder cPanel (Benutzerebene, wenn MultiPHP Manager aktiviert ist) an.
2. Navigieren Sie unter dem Abschnitt Software zu MultiPHP Manager.
3. Wählen Sie Ihre Domain und wählen Sie die Ziel-PHP-Version aus dem Dropdown-Menü.
4. Klicken Sie auf Anwenden.

PHP über die Befehlszeile aktualisieren (Ubuntu/Debian):

# Add the Ondrej PHP PPA (Ubuntu)
sudo add-apt-repository ppa:ondrej/php
sudo apt update

# Install PHP 8.2 with common WordPress extensions
sudo apt install php8.2 php8.2-mysql php8.2-curl php8.2-gd php8.2-mbstring 
  php8.2-xml php8.2-zip php8.2-intl php8.2-bcmath php8.2-imagick

# Switch the CLI default (if using WP-CLI)
sudo update-alternatives --set php /usr/bin/php8.2

Kritischer Schritt vor dem Upgrade: Bevor Sie die PHP-Version in der Produktion ändern, testen Sie Ihr Theme und jedes aktive Plugin gegen die neue Version. Verwenden Sie WP-CLI in einer Staging-Umgebung:

wp core check-update
wp plugin list --update=available --format=table
wp theme list --update=available --format=table

Überlegungen zur Datenbankversion:

WordPress erfordert MySQL 5.7+ oder MariaDB 10.3+. MariaDB 10.6 und 10.11 (LTS) sind die aktuell empfohlenen Versionen. Der Betrieb einer älteren Datenbankserverversion führt sowohl zu Sicherheitsrisiken als auch zu fehlenden Query-Optimizer-Verbesserungen, die Websites mit großen Post-Tabellen oder WooCommerce-Bestellvolumen beeinflussen.

-- Check current database version from within WordPress or phpMyAdmin
SELECT VERSION();

-- Check table storage engines (InnoDB is required for full-text search and transactions)
SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_wordpress_database';

Wenn Tabellen MyISAM als Engine anzeigen, konvertieren Sie diese zu InnoDB für bessere Crash-Recovery und gleichzeitige Schreib-Performance:

ALTER TABLE wp_options ENGINE=InnoDB;

Schritt 7: Website-Performance messen und optimieren

Site Health misst keine Frontend-Performance — dafür sind externe Tools erforderlich. Verwenden Sie Google PageSpeed Insights (misst Core Web Vitals unter realen Bedingungen), GTmetrix (Wasserfallanalyse) und WebPageTest (mehrere Standorte, erweiterte Konfiguration) als ergänzende Tools.

Performance-Optimierung nach Schicht:

Server-Schicht:

• Aktivieren Sie OPcache für PHP-Bytecode-Caching. Auf einem ordnungsgemäß konfigurierten VPS reduziert dies allein die PHP-Ausführungszeit um 40–60%.

; Add to php.ini or a custom .ini file
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.jit_buffer_size=100M
opcache.jit=1255

• Verwenden Sie Redis für persistentes Object-Caching. Installieren Sie das redis-server-Paket und das Redis Object Cache-WordPress-Plugin, dann fügen Sie zu wp-config.php hinzu:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE', true);

Anwendungsschicht:

• Bildoptimierung — Verwenden Sie das WebP-Format mit JPEG/PNG-Fallbacks. Die Plugins Imagify oder ShortPixel übernehmen die Massenkonvertierung und automatische WebP-Auslieferung über .htaccess-Rewrite-Regeln.
• Lazy Loading — WordPress 5.5+ fügt loading="lazy" automatisch zu Bildern hinzu, aber überprüfen Sie, ob es nicht von Ihrem Theme überschrieben wird.
• Datenbankoptimierung — Führen Sie OPTIMIZE TABLE monatlich auf stark frequentierten Tabellen (wp_options, wp_postmeta) aus. Das Plugin WP-Optimize automatisiert dies.

# Optimize all WordPress tables via WP-CLI
wp db optimize

• Caching-Plugins — W3 Total Cache mit Redis-Backend oder WP Rocket (Premium) sind die zwei leistungsfähigsten Optionen. Vermeiden Sie den gleichzeitigen Betrieb von zwei Caching-Plugins — sie werden in Konflikt geraten.

CDN-Integration:

Ein CDN lagert die Auslieferung statischer Assets aus und reduziert die TTFB für geografisch verteilte Besucher. Cloudflares kostenloser Tarif bietet für die meisten Websites ausreichende CDN-Funktionalität. Für medienintensive Websites bietet BunnyCDN ein besseres Preis-Leistungs-Verhältnis. Konfigurieren Sie Ihr CDN so, dass statische Assets aggressiv gecacht werden, aber das WordPress-Admin (/wp-admin/) und alle dynamischen Endpunkte ausgeschlossen werden.

Schritt 8: Sicherheit härten und eine Routine zur Schwachstellenüberwachung etablieren

Sicherheit ist keine einmalige Konfiguration — es ist eine fortlaufende Betriebspraxis. Das Site Health-Tool deckt einige Sicherheitsprobleme auf, führt jedoch kein Schwachstellen-Scanning durch.

Mehrschichtiger Sicherheitsansatz:

Auf Serverebene (erfordert VPS- oder Dedicated-Server-Zugang):

# Disable XML-RPC if not required (common attack vector for brute force amplification)
# Add to .htaccess
# <Files xmlrpc.php>
#   Order Deny,Allow
#   Deny from all
# </Files>

# Restrict wp-config.php access
chmod 600 /path/to/wp-config.php

# Verify file permissions across the WordPress installation
find /path/to/wordpress/ -type f -name "*.php" -perm /022
# Any PHP file writable by group or world is a security risk

Auf Anwendungsebene:

• Wordfence Security — Bietet eine Web Application Firewall (WAF), Malware-Scanner und einen Echtzeit-Bedrohungsintelligenz-Feed. Der kostenlose Tarif ist für die meisten Websites ausreichend; der Premium-Tarif fügt Echtzeit-Firewall-Regelaktualisierungen hinzu.
• Anmeldeversuche begrenzen — Das Plugin Limit Login Attempts Reloaded oder der integrierte Brute-Force-Schutz von Wordfence. Stellen Sie die Sperrung nach 3–5 fehlgeschlagenen Versuchen ein.
• Zwei-Faktor-Authentifizierung — Erzwingen Sie 2FA für alle Administratorkonten mit den Plugins WP 2FA oder Google Authenticator.
• SSL/HTTPS-Durchsetzung — Jede WordPress-Website muss über HTTPS laufen. Besorgen und installieren Sie ein SSL-Zertifikat; wenn Sie eines benötigen, sind SSL-Zertifikate von Ihrem Hosting-Anbieter der unkomplizierteste Weg. Fügen Sie Folgendes zu wp-config.php hinzu, um HTTPS auf Anwendungsebene zu erzwingen:

define('FORCE_SSL_ADMIN', true);

Und in .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Automatisierte Schwachstellenüberwachung:

Abonnieren Sie die E-Mail-Benachrichtigungen der WPScan Vulnerability Database für die von Ihnen verwendeten Plugins. Das WPScan CLI-Tool kann in einen Cron-Job integriert werden, um Sie zu benachrichtigen, wenn eine neue CVE für ein installiertes Plugin veröffentlicht wird:

# Install WPScan (requires Ruby)
gem install wpscan

# Run a vulnerability scan against your site
wpscan --url https://yourdomain.com --api-token YOUR_API_TOKEN 
  --enumerate vp,vt,u --plugins-detection aggressive

Datenbank-Backups als Sicherheitskontrolle:

Ein sauberes, aktuelles Backup ist Ihr zuverlässigster Wiederherstellungsmechanismus nach einer Kompromittierung. Automatisieren Sie tägliche Backups an einen externen Speicherort (S3-kompatibler Objektspeicher, Remote-SFTP). Das Plugin UpdraftPlus erledigt dies zuverlässig. Überprüfen Sie die Wiederherstellungsverfahren vierteljährlich — ein Backup, das Sie nie getestet haben, ist kein Backup.

WordPress-Gesundheitscheck: Entscheidungsmatrix und wichtigste Erkenntnisse

Verwenden Sie diese Matrix, um die korrekte Maßnahme basierend auf dem zu bestimmen, was Site Health meldet:

Operative Checkliste für laufende WordPress-Gesundheit:

• Führen Sie monatlich eine Site Health-Statusüberprüfung durch; behandeln Sie kritische Befunde als Vorfälle.
• Halten Sie PHP auf einer unterstützten Version (mindestens 8.1; bevorzugt 8.2 oder 8.3).
• Löschen Sie inaktive Plugins und Themes — deaktivieren Sie sie nicht nur.
• Aktivieren Sie Redis Object-Caching auf jeder Website mit mehr als 500 täglichen Besuchern.
• Automatisieren Sie tägliche externe Datenbank-Backups mit verifiziertem Wiederherstellungstest.
• Abonnieren Sie Schwachstellenbenachrichtigungen für jedes Plugin und Theme in Ihrem Stack.
• Erzwingen Sie HTTPS sitewide und setzen Sie FORCE_SSL_ADMIN in wp-config.php.
• Verwenden Sie WP-CLI für Batch-Updates und Datenbankoperationen — es ist schneller und skriptfähig.
• Konfigurieren Sie auf einem Dedicated Server oder VPS einen serverseitigen Cron-Job anstatt sich auf wp-cron zu verlassen — wp-cron wird nur ausgelöst, wenn ein Besucher die Website aufruft, was es auf Websites mit geringem Traffic unzuverlässig macht.

# Replace wp-cron with a real cron job (add to crontab)
# First, disable wp-cron in wp-config.php:
# define('DISABLE_WP_CRON', true);

# Then add to crontab (crontab -e):
*/15 * * * * php /path/to/wordpress/wp-cron.php > /dev/null 2>&1
# Or with WP-CLI (preferred):
*/15 * * * * wp --path=/path/to/wordpress cron event run --due-now > /dev/null 2>&1

Wenn Sie Hosting-Umgebungen für eine WordPress-Bereitstellung evaluieren, bieten VPS Control Panels den serverseitigen Zugang, der notwendig ist, um jede in diesem Leitfaden beschriebene Optimierungs- und Härtungsmaßnahme umzusetzen — PHP-Versionsverwaltung, Redis-Konfiguration, serverseitiger Cron und Firewall-Regeln erfordern alle Root- oder Sudo-Zugang, den Shared-Umgebungen nicht bieten.

FAQ

Was ist der Unterschied zwischen dem Site Health-Status-Tab und dem Info-Tab?

Der Status-Tab führt automatisierte Checks durch und kategorisiert Befunde nach Schweregrad (Gut, Empfohlen, Kritisch). Der Info-Tab zeigt rohe Umgebungsdaten an — PHP-Konfiguration, aktive Plugins mit Versionen, Datenbankdetails und Verzeichnisgrößen — ohne jegliches Bestanden/Nicht-bestanden-Urteil. Der Info-Tab wird hauptsächlich für die manuelle Diagnose und die Weitergabe an Support-Ingenieure verwendet.

Beeinflusst die Aktivierung des Fehlerbehebungsmodus Live-Besucher?

Nein. Der Fehlerbehebungsmodus verwendet ein Browser-Cookie, um die Safe-Mode-Umgebung ausschließlich auf Ihre Sitzung anzuwenden. Besucher ohne das Cookie erleben die Website normal. Die einzige Ausnahme ist, wenn ein fataler Fehler in einem Plugin den Serverprozess selbst zum Absturz bringt — in diesem Fall sind alle Besucher betroffen, unabhängig vom Aktivierungsstatus des Plugins in Ihrer Sitzung.

Welche PHP-Version sollte ich für WordPress im Jahr 2025 verwenden?

PHP 8.2 ist die empfohlene Version für produktive WordPress-Websites im Jahr 2025. Sie wird aktiv mit Sicherheits-Patches gepflegt, bietet messbare Performance-Verbesserungen gegenüber 8.0 und 8.1 und wird von allen wichtigen WordPress-Plugins unterstützt. PHP 8.3 ist stabil und für neue Bereitstellungen geeignet, aber überprüfen Sie die Plugin-Kompatibilität, bevor Sie eine bestehende Website upgraden.

Warum meldet Site Health „Gut”, obwohl meine Website eindeutig langsam ist?

Site Health prüft Konfiguration und Sicherheitslage — es misst keine Frontend-Performance-Metriken wie Largest Contentful Paint (LCP) oder Time to First Byte (TTFB). Eine Website kann alle Site Health-Checks bestehen und trotzdem schlecht bei Core Web Vitals abschneiden, aufgrund nicht optimierter Bilder, fehlender Caching-Schicht, einer langsamen Datenbank oder eines geografisch weit entfernten Servers. Verwenden Sie Google PageSpeed Insights oder WebPageTest für Performance-Messungen.

Wie behebe ich einen Loopback-Anfragefehler in WordPress Site Health?

Ein Loopback-Fehler bedeutet, dass WordPress keine HTTP-Anfrage an seine eigene URL vom Server aus stellen kann. Häufige Ursachen sind: eine Firewall, die ausgehende Verbindungen vom Webserverprozess blockiert, ein hosts-Dateieintrag, der die Domain falsch weiterleitet, ein SSL-Zertifikatsfehler bei der Loopback-Anfrage oder ein Sicherheits-Plugin, das die Anfrage blockiert. Beginnen Sie damit, Ihr Sicherheits-Plugin vorübergehend zu deaktivieren und Site Health erneut auszuführen. Wenn das das Problem löst, setzen Sie die eigene IP des Servers in den Firewall-Einstellungen des Sicherheits-Plugins auf die Whitelist.