Wie man den max_execution_time-Fehler in WordPress behebt

Der max_execution_time-Fehler in WordPress tritt auf, wenn ein PHP-Skript die auf Serverebene konfigurierte maximale Ausführungsdauer überschreitet. PHP beendet das Skript und gibt einen schwerwiegenden Fehler zurück, den WordPress als weißen Bildschirm, eine Timeout-Meldung oder eine explizite „Maximum execution time exceeded”-Nachricht anzeigt.

Standardmäßig setzen die meisten Shared-Hosting-Umgebungen ein Limit von 30 Sekunden durch. Vorgänge wie das Importieren einer WooCommerce-Produkt-CSV, das Erstellen eines vollständigen Website-Backups oder die Installation eines großen Plugin-Pakets können diese Grenze leicht überschreiten. Das Erhöhen des Limits — über php.ini, .htaccess, wp-config.php oder die WordPress-Plugin-Ebene — behebt den Fehler, ohne die Serverstabilität zu gefährden, wenn es korrekt durchgeführt wird.

Warum das Limit existiert und wann es zum Problem wird

Die max_execution_time-Direktive von PHP ist ein Ressourcenschutzmechanismus, keine willkürliche Einschränkung. Sie verhindert, dass ein unkontrolliertes Skript die CPU-Zeit in einem gemeinsam genutzten Prozess-Pool monopolisiert, was besonders bei Multi-Tenant-Infrastrukturen kritisch ist.

Das Limit wird in folgenden Szenarien zu einem echten Hindernis:

• Große Datenbankimporte oder -exporte über phpMyAdmin oder WP-CLI, die Tausende von Zeilen verarbeiten
• Plugin- oder Theme-Installationen, die Archive mit mehr als 50 MB entpacken
• WooCommerce-Massenoperationen — Preisaktualisierungen, Bestandssynchronisierungen, Bestellexporte
• Vollständige Website-Migrationen mit Tools wie Duplicator oder All-in-One WP Migration
• Geplante Cron-Jobs, die Daten von externen APIs aggregieren
• Bildoptimierungs-Plugins, die Hunderte nicht optimierter Uploads in einem einzigen Stapel verarbeiten

Eine wichtige Nuance, die die meisten Anleitungen weglassen: max_execution_time misst die vom PHP-Prozess verbrauchte CPU-Zeit, nicht die Echtzeit. Auf einem stark ausgelasteten Server kann ein Skript 90 Sekunden in Echtzeit laufen, dabei nur 28 Sekunden CPU-Zeit verbrauchen und das Limit nie auslösen. Umgekehrt erreicht eine CPU-intensive Schleife das Limit schneller als erwartet. Diese Unterscheidung ist wichtig bei der Diagnose intermittierender Timeouts.

So überprüfen Sie Ihren aktuellen max_execution_time-Wert

Bevor Sie etwas ändern, bestätigen Sie das aktive Limit. Erstellen Sie eine temporäre Datei in Ihrem WordPress-Stammverzeichnis — lassen Sie sie nach dem Testen niemals öffentlich zugänglich:

<?php
phpinfo();

Laden Sie sie als phpinfo-test.php hoch, besuchen Sie https://yourdomain.com/phpinfo-test.php und suchen Sie in der Ausgabe nach max_execution_time. Löschen Sie die Datei sofort nach der Überprüfung.

Alternativ können Sie WP-CLI über SSH verwenden:

wp eval 'echo ini_get("max_execution_time");'

Dies gibt den Wert zurück, der aktuell für WordPress-Anfragen aktiv ist, der sich vom globalen php.ini des Servers unterscheiden kann, wenn bereits eine Verzeichnis-Überschreibung vorhanden ist.

Methode 1: Die php.ini-Datei bearbeiten (zuverlässigste Methode)

Das Bearbeiten von php.ini ist die zuverlässigste Methode, da sie die Direktive auf der Ebene des PHP-Interpreters setzt, nichts überschreibt und von nichts darunter in der Konfigurationshierarchie überschrieben wird — es sei denn, ein späterer ini_set()-Aufruf ersetzt sie zur Laufzeit.

Schritt 1: Die richtige php.ini-Datei finden

Hier machen die meisten Administratoren einen Fehler. PHP kann je nach verwendeter SAPI (Server API) mehrere .ini-Dateien laden:

• CLI SAPI (/etc/php/8.x/cli/php.ini) — wird von WP-CLI und Cron-Jobs verwendet
• FPM SAPI (/etc/php/8.x/fpm/php.ini) — wird von Nginx + PHP-FPM-Stacks verwendet
• Apache mod_php (/etc/php/8.x/apache2/php.ini) — wird von Apache mit dem PHP-Modul verwendet

Das Bearbeiten der CLI-php.ini behebt WP-CLI-Timeouts, hat jedoch keinen Einfluss auf browser-ausgelöste Anfragen. Identifizieren Sie immer zuerst die richtige SAPI:

php -i | grep "Loaded Configuration File"

Überprüfen Sie für Web-Anfragen die phpinfo()-Ausgabe unter Loaded Configuration File.

Schritt 2: php.ini im Web-Stammverzeichnis bearbeiten oder erstellen

Auf Shared Hosting ohne Root-Zugriff können Sie eine benutzerspezifische php.ini im Stammverzeichnis Ihrer Website (public_html) ablegen. Greifen Sie darauf über den cPanel File Manager, FTP oder SSH zu:

nano ~/public_html/php.ini

Fügen Sie die Direktive hinzu oder aktualisieren Sie sie:

max_execution_time = 300

300 Sekunden (5 Minuten) sind für die meisten Vorgänge ausreichend. Für sehr große Migrationen sollten Sie vorübergehend 600 Sekunden in Betracht ziehen und nach Abschluss der Aufgabe wieder zurücksetzen.

Schritt 3: Überprüfen, ob die Änderung wirksam wurde

Führen Sie nach dem Speichern die phpinfo()-Prüfung oder den WP-CLI-Befehl von früher erneut aus. Wenn sich der Wert nicht geändert hat, erzwingt Ihr Host möglicherweise ein hartes Limit über max_execution_time in einer serverseitigen php.ini, die Ihre benutzerspezifische Datei überschreibt. Fahren Sie in diesem Fall mit Methode 4 fort.

Schritt 4: PHP-FPM neu starten (VPS und dedizierte Server)

Auf einem VPS oder dedizierten Server, auf dem Sie die Umgebung kontrollieren, ist ein PHP-FPM-Neustart erforderlich, damit die Änderung für Web-Anfragen wirksam wird:

sudo systemctl restart php8.2-fpm

Ersetzen Sie php8.2-fpm durch Ihre installierte PHP-Version. Apache mit mod_php erfordert stattdessen einen Apache-Neustart:

sudo systemctl reload apache2

Methode 2: Die .htaccess-Datei bearbeiten (nur Apache)

Die .htaccess-Methode funktioniert ausschließlich auf Apache-Servern, bei denen AllowOverride PHP-Konfigurationsdirektiven erlaubt. Sie funktioniert nicht auf Nginx, LiteSpeed mit bestimmten Konfigurationen oder einem Stack, bei dem PHP als FastCGI/FPM mit AllowOverride None läuft.

Schritt 1: Die .htaccess-Datei anzeigen und aufrufen

Die .htaccess-Datei ist standardmäßig ausgeblendet. Klicken Sie im cPanel File Manager oben rechts auf Einstellungen und aktivieren Sie Versteckte Dateien anzeigen (Dotfiles). Die Datei befindet sich in public_html.

Über SSH:

nano ~/public_html/.htaccess

Schritt 2: Die PHP-Direktive hinzufügen

Fügen Sie die folgende Zeile ein. Die Position ist wichtig — platzieren Sie sie außerhalb eines <IfModule>-Blocks, um sicherzustellen, dass sie global gilt:

php_value max_execution_time 300

Wenn Ihr Server PHP-FPM ausführt (erkennbar an PHP/x.x.x (fpm-fcgi) in phpinfo()), verursacht diese Direktive einen 500 Internal Server Error, da php_value in diesem Kontext nicht gültig ist. Verwenden Sie php_admin_value nur, wenn der Host dies ausdrücklich erlaubt, oder wechseln Sie zu Methode 1.

Schritt 3: Auf 500-Fehler testen

Laden Sie nach dem Speichern sofort Ihre Startseite. Ein 500-Fehler bedeutet, dass die Direktive mit Ihrer Serverkonfiguration nicht kompatibel ist. Entfernen Sie die Zeile und verwenden Sie eine alternative Methode.

Methode 3: wp-config.php mit set_time_limit() bearbeiten

Die set_time_limit()-Funktion setzt den Ausführungstimer ab dem Zeitpunkt ihres Aufrufs zurück. Dies ist ein PHP-Laufzeitaufruf, keine Konfigurationsdirektive, was bedeutet, dass sie unabhängig davon funktioniert, ob der Server php.ini– oder .htaccess-Überschreibungen erlaubt — solange die disable_functions-Liste von PHP sie nicht enthält.

Schritt 1: wp-config.php finden

Die Datei befindet sich im WordPress-Installationsstammverzeichnis, bei einigen Serverkonfigurationen eine Ebene über public_html oder direkt darin.

find ~/public_html -maxdepth 2 -name "wp-config.php"

Schritt 2: Die Direktive hinzufügen

Öffnen Sie wp-config.php und fügen Sie die folgende Zeile vor dem /* That's all, stop editing! Happy publishing. */-Kommentar hinzu:

set_time_limit(300);

Der Aufruf von set_time_limit(0) deaktiviert das Limit für diese Anfrage vollständig. Verwenden Sie dies nur als temporäre Diagnosemaßnahme — niemals in der Produktion — da es das Sicherheitsnetz gegen Endlosschleifen entfernt.

Wichtiger Vorbehalt: set_time_limit() betrifft nur die aktuelle Skriptausführung. Es ändert nicht die serverweite PHP-Konfiguration. Wenn ein Plugin intern einen Unterprozess startet oder eine blockierende HTTP-Anfrage stellt, wird dieser Unterprozess von diesem Aufruf nicht abgedeckt.

Methode 4: Ein WordPress-Plugin verwenden

Für Benutzer, die Serverdateien nicht direkt bearbeiten möchten, stellen mehrere Plugins PHP-Konfigurationswerte über die WordPress-Administratoroberfläche bereit. Dieser Ansatz ist für nicht-technische Website-Betreiber auf verwaltetem Hosting geeignet.

Empfohlene Optionen:

• WP Maximum Execution Time Exceeded — zielt speziell auf diesen Fehler ab und versucht mehrere Überschreibungsmethoden
• PHP Settings — bietet eine Dashboard-Ansicht aktiver PHP-Direktiven und ermöglicht sichere Überschreibungen, wo der Host dies erlaubt

Zur Installation: Navigieren Sie im WordPress-Dashboard zu Plugins > Neu hinzufügen, suchen Sie nach dem Plugin-Namen, installieren und aktivieren Sie es. Folgen Sie der Einstellungsseite des Plugins, um Ihre gewünschte Ausführungszeit festzulegen.

Einschränkung: Plugins können zur Laufzeit nur set_time_limit() oder ini_set() aufrufen. Wenn der Host max_execution_time über open_basedir-Einschränkungen oder eine fest kodierte Serverkonfiguration gesperrt hat, schlägt das Plugin stillschweigend fehl, das Limit zu erhöhen. Überprüfen Sie die Änderung nach der Aktivierung immer mit phpinfo().

Methode 5: Ihren Hosting-Anbieter kontaktieren

Wenn keine der oben genannten Methoden eine verifizierte Änderung in der phpinfo()-Ausgabe erzeugt, wird das Limit auf Serverebene von Ihrem Host durchgesetzt. Dies ist bei Einsteiger-Shared-Hosting-Plänen üblich, bei denen der Anbieter eine harte Obergrenze zum Schutz gemeinsam genutzter Ressourcen setzt.

Wenn Sie den Support kontaktieren, geben Sie Folgendes an:

• Die genaue Fehlermeldung und die WordPress-Aktion, die sie auslöst
• Den aktuellen max_execution_time-Wert aus phpinfo()
• Den benötigten Wert (z. B. 300 Sekunden) und den Grund (z. B. großer WooCommerce-Import)

Seriöse Hosts passen entweder das Limit für Ihr Konto an oder verweisen Sie auf eine Systemsteuerungsoption (z. B. einen PHP-Selektor in cPanel), wo Sie es selbst konfigurieren können.

Vergleich aller fünf Methoden

Diagnose anhaltender Timeouts nach Erhöhung des Limits

Wenn Sie bestätigt haben, dass das neue Limit in phpinfo() aktiv ist, der Fehler jedoch weiterhin besteht, liegt der Engpass wahrscheinlich nicht bei max_execution_time. Berücksichtigen Sie diese alternativen Ursachen:

FastCGI- oder Nginx-Timeout-Direktiven — Nginx hat seine eigene fastcgi_read_timeout-Direktive, getrennt von PHP:

fastcgi_read_timeout 300;

Diese muss im Nginx-Serverblock gesetzt werden und erfordert einen Nginx-Neustart.

Apache-TimeOut-Direktive — Apaches eigenes Verbindungs-Timeout kann eine Anfrage beenden, bevor PHPs Limit erreicht wird:

TimeOut 300

PHP-FPM request_terminate_timeout — In der PHP-FPM-Pool-Konfiguration (/etc/php/8.x/fpm/pool.d/www.conf) beendet diese Direktive unabhängig Worker-Prozesse:

request_terminate_timeout = 300

MySQL wait_timeout und interactive_timeout — Lang laufende Datenbankabfragen können dazu führen, dass die MySQL-Verbindung mitten in der Ausführung abbricht, was PHP als Skriptfehler statt als Datenbankfehler anzeigt. Überprüfen Sie mit:

SHOW VARIABLES LIKE '%timeout%';

WooCommerce- oder Plugin-eigene Timeouts — Einige Plugins implementieren ihre eigene interne Timeout-Logik mit PHPs set_time_limit() mit einem niedrigeren Wert, der den Zähler zurücksetzt und Ihre Konfiguration überschreiben kann.

Leistungsüberlegungen und Best Practices

Das Erhöhen von max_execution_time ist eine gezielte Lösung, keine dauerhafte architektonische Lösung. Wenn ein bestimmter Vorgang routinemäßig 30–60 Sekunden überschreitet, sollte der zugrunde liegende Prozess optimiert oder umstrukturiert werden:

• Stapelverarbeitung: Teilen Sie große Importe in kleinere Teile auf, indem Sie AJAX-basiertes Chunking verwenden (wie es WP All Import nativ tut), anstatt alles in einer einzigen HTTP-Anfrage zu verarbeiten
• Hintergrundverarbeitung: Verwenden Sie WP-Cron oder eine geeignete Aufgabenwarteschlange (Action Scheduler, verwendet von WooCommerce), um lang laufende Arbeiten aus dem Web-Anfrage-Lebenszyklus auszulagern
• WP-CLI für Massenoperationen: Die CLI-Ausführung unterliegt keinen Web-Server-Timeouts und ist das richtige Werkzeug für Datenbankimporte, Such-Ersetzen-Operationen und Massenmedienverarbeitung
• Langsame Abfragen optimieren: Verwenden Sie das Query Monitor-Plugin, um Datenbankabfragen zu identifizieren, die unverhältnismäßig viel Ausführungszeit verbrauchen
• Hosting-Stufe upgraden: Wenn Ihre Arbeitslast konsistent erweiterte Ausführungszeiten erfordert, gibt Ihnen ein VPS mit cPanel volle Kontrolle über die PHP-Konfiguration und dedizierte Ressourcen, die nicht mit anderen Mietern konkurrieren

Für rechenintensive Workloads wie KI-gesteuerte Produktempfehlungen oder groß angelegte Bildverarbeitungs-Pipelines lagert GPU-Hosting die intensive Berechnung vollständig von der PHP-Ebene aus.

Praktische Entscheidungs-Checkliste

Verwenden Sie diese Checkliste vor und nach der Anwendung einer Lösung:

• Bestätigen Sie den aktuellen max_execution_time-Wert über phpinfo() oder WP-CLI, bevor Sie Änderungen vornehmen
• Identifizieren Sie Ihren Server-Stack (Apache + mod_php, Apache + FPM, Nginx + FPM), bevor Sie eine Methode wählen
• Wenden Sie jeweils nur eine Methode an — das gleichzeitige Stapeln von php.ini-, .htaccess– und wp-config.php-Änderungen macht das Debuggen unmöglich
• Überprüfen Sie nach einer Änderung den aktiven Wert in phpinfo() erneut — gehen Sie nicht davon aus, dass die Änderung funktioniert hat
• Testen Sie, indem Sie die ursprünglich fehlgeschlagene Aktion reproduzieren, nicht nur durch Laden der Startseite
• Wenn der Fehler behoben ist, überlegen Sie, ob der zugrunde liegende Vorgang optimiert werden kann, um innerhalb des ursprünglichen Limits zu laufen
• Setzen Sie eine Kalender-Erinnerung, um temporäre Limit-Erhöhungen (z. B. set_time_limit(0)) nach Abschluss der einmaligen Aufgabe zurückzusetzen
• Dokumentieren Sie auf Shared Hosting, was der Host als maximal zulässigen Wert für Ihren Plan bestätigt hat
• Wenn Timeouts nach Bestätigung der Erhöhung des PHP-Limits weiterhin bestehen, überprüfen Sie Nginx fastcgi_read_timeout, Apache TimeOut und PHP-FPM request_terminate_timeout unabhängig voneinander

FAQ

Was ist der sicherste Wert für max_execution_time in WordPress?

300 Sekunden (5 Minuten) decken die überwiegende Mehrheit ressourcenintensiver WordPress-Vorgänge ab, einschließlich großer Plugin-Installationen, WooCommerce-Importe und Theme-Updates. Werte über 600 Sekunden sollten als temporär behandelt und nach Abschluss der spezifischen Aufgabe zurückgesetzt werden.

Warum erscheint meine max_execution_time-Änderung nach dem Bearbeiten von php.ini nicht in phpinfo()?

Sie bearbeiten höchstwahrscheinlich die falsche php.ini-Datei. PHP lädt verschiedene Konfigurationsdateien für CLI, Apache mod_php und PHP-FPM. Führen Sie php -i | grep "Loaded Configuration File" für CLI aus und überprüfen Sie die Zeile Loaded Configuration File auf einer browser-zugänglichen phpinfo()-Seite, um die richtige Datei für Web-Anfragen zu identifizieren.

Betrifft das Erhöhen von max_execution_time alle Benutzer auf meinem Server?

Auf einem gemeinsam genutzten Server betrifft das Bearbeiten einer benutzerspezifischen php.ini in Ihrem Web-Stammverzeichnis nur Ihr Konto. Das Bearbeiten der globalen Server-php.ini (was Root-Zugriff erfordert) betrifft alle PHP-Prozesse auf diesem Server. Auf einem dedizierten Server kontrollieren Sie die globale Konfiguration und tragen die volle Verantwortung für deren Auswirkungen.

Funktioniert die .htaccess-Methode auf einem Nginx-Server?

Nein. Die .htaccess-Datei ist ein Apache-spezifischer Mechanismus. Nginx verarbeitet keine .htaccess-Dateien. Bei Nginx + PHP-FPM-Stacks müssen Sie die PHP-FPM-Pool-Konfiguration oder die serverseitige php.ini bearbeiten, was beides SSH-Zugriff erfordert.

Kann ein WordPress-Plugin max_execution_time dauerhaft erhöhen?

Nein. Plugins werden innerhalb der PHP-Laufzeit ausgeführt und können nur set_time_limit() oder ini_set() aufrufen, die nur die aktuelle Anfrage betreffen. Sie können nicht in php.ini schreiben oder Konfigurationsänderungen über Anfragen hinaus speichern. Für eine dauerhafte Erhöhung müssen Sie php.ini, .htaccess oder eine PHP-FPM-Pool-Konfigurationsdatei auf Serverebene ändern.