404-Fehler bei statischen Dateien verlangsamen die Website

Wenn Sie in WordPress eine Adresse aufrufen, die nicht existiert, gibt es einen 404-Fehler „Seite nicht gefunden“ im Design Ihres eigenen Themes zurück. Das ist sinnvoll, weil der Besucher in einer vertrauten Navigation bleibt.

Das Problem entsteht, wenn eine Seite ein Bild, CSS oder JavaScript anfordert, das nicht existiert, und die Serverkonfiguration auch diese Anfrage an WordPress weiterleitet. Das passiert nicht auf jedem Server: Bestätigen Sie zuerst, welcher Prozess die 404-Antwort erzeugt.

Es lohnt sich, den Kostenunterschied zu verstehen. In einer Konfiguration, die statische Ressourcen direkt ausliefert, muss für eine vorhandene Datei kein PHP starten; die tatsächliche Zeit hängt von Server und Netz ab. Eine Datei, die nicht existiert, landet im Routing von WordPress, das die ganze Anwendung startet, die Plugins lädt, die Datenbank abfragt und die 404-Seite Ihres Themes zusammensetzt. In einem echten, auf unseren Servern gemessenen Fall lieferte jeder dieser 404-Fehler 28 KB gerenderte Seite, während derselbe Fehler vom Webserver 796 Bytes groß war.

Wenn das 404-Template selbst die fehlende Ressource erneut anfordert, kann jeder Fehler zusätzliche Anfragen erzeugen. Um sie mit einer Überlastung in Verbindung zu bringen, prüfen Sie, ob sie in Uhrzeit und Pfad mit dem Anstieg der Prozesse oder der Antwortzeit übereinstimmen.

So erkennen Sie es

Hohe CPU-Last und mehrere PHP-Prozesse auf index.php sind Hinweise, keine bestätigte Ursache. Um den Zusammenhang zu prüfen, sehen Sie in cPanel unter Metrics → Raw Access ins Zugriffsprotokoll.

Suchen Sie darin nach derselben URL, die sich oft wiederholt. Ein Beispiel nach dem echten Fall, mit Dokumentationsadresse und -domain:

192.0.2.10 - - [09/Aug/2026:22:36:03 +0200] "GET /wp-content/plugins/popup-maker/dist/packages/block-library-style.css?ver=7424eb959f91acb8bbb2 HTTP/1.1" 404 28113 "-" "WordPress/6.8.7; https://www.midominio.com"

Zwei Details verraten das Problem:

• Die IP stimmt mit der des Servers überein, und der User-Agent gibt WordPress an. In diesem konkreten Fall war es eine interne Anfrage; in einem anderen Protokoll müssen Sie beide Angaben prüfen, bevor Sie das behaupten.
• Der Code ist 404 und die Größe lag bei mehreren Dutzend Kilobyte. Diese Messung passte zu einer vom Theme gerenderten Seite, aber Sie müssen Ihre eigene Antwort prüfen.

In diesem konkreten Fall forderte die Website dasselbe nicht vorhandene CSS etwa sechsmal pro Minute an, ununterbrochen über Wochen, und schöpfte damit das CPU-Limit des Kontos aus.

Die Lösung: WordPress diese 404 nicht verarbeiten lassen

Die eigentliche Lösung ist, den Verweis auf den nicht vorhandenen Inhalt zu entfernen. Wenn Sie bestätigt haben, dass diese Anfragen in WordPress landen, dient die folgende Regel als Sicherheitsnetz: Der Server antwortet für die angegebenen Endungen früher.

Laden Sie vor der Änderung eine Kopie der aktuellen .htaccess herunter, damit Sie sie wiederherstellen können, falls die Website einen Fehler 500 zurückgibt. Um die Verarbeitung von 404-Fehlern bei statischen Dateien abzuschalten, fügen Sie dann folgenden Block ein:

# BEGIN 404 ESTATICOS
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} \.(gif|jpe?g|png|webp|avif|svg|ico|css|js|map|woff2?|ttf|eot)$ [NC]
RewriteRule ^ - [R=404,L]
</IfModule>
# END 404 ESTATICOS

Die ersten beiden Bedingungen lassen jede vorhandene Datei und jedes vorhandene Verzeichnis durch, sodass die Regel nur auf Fehlendes wirkt. Die dritte beschränkt sie auf Endungen statischer Inhalte und lässt normalerweise Adressen der Website ohne Endung außen vor. Es lohnt sich, Schriftarten (woff, woff2, ttf, eot) und Source Maps (map) einzuschließen, denn sie erzeugen bei einem Theme die meisten stillen 404-Fehler.

Wo der Block hingehört

Suchen Sie in der Datei die Zeile # BEGIN WordPress und fügen Sie den Block direkt darüber ein. Setzen Sie ihn nicht in einen Block, den ein Plugin automatisch verwaltet.

Er gehört über # BEGIN WordPress, weil genau dieser Block alles, was nicht auf der Festplatte existiert, an index.php schickt. Steht er danach, hat WordPress die Anfrage bereits übernommen.

Setzen Sie ihn nicht vor die Regeln von LiteSpeed Cache: Sie könnten eine URL abfangen, die das Plugin umschreiben muss. Da die Blöcke je nach Installation unterschiedlich sind, testen Sie ein vorhandenes optimiertes Bild und eine erfundene URL, bevor Sie die Änderung beibehalten.

Prüfen Sie auch, dass ErrorDocument 404 nicht auf PHP zeigt. Wenn Sie ErrorDocument 404 /404.shtml verwenden, prüfen Sie, dass diese Datei existiert, statisch ist und nicht wieder über WordPress läuft.

Prüfen, ob es funktioniert

Öffnen Sie nach dem Speichern der Datei diese drei Adressen im Browser und ersetzen Sie midominio.com durch Ihre Domain.

1. Ihre Website, um einen Tippfehler auszuschließen

https://midominio.com/

Sie muss normal laden. Erscheint direkt nach der Änderung ein 500 oder eine weiße Seite, stellen Sie die Kopie wieder her und sehen Sie ins Protokoll. Es kann ein Tippfehler, eine nicht erlaubte Direktive oder eine Wechselwirkung mit anderen Regeln sein; der Code allein unterscheidet die Ursache nicht.

2. Eine statische Datei, die nicht existiert, mit erfundenem Namen

https://midominio.com/esto-no-existe.css

Sie muss mit dem Code 404 und einer schlanken Seite antworten, die ohne das Design von WordPress ausgeliefert wird. Wie sie genau aussieht, hängt von der Serverkonfiguration und von ErrorDocument ab.

Sehen Sie stattdessen die Seite „nicht gefunden“ im Design Ihres Themes, mit Menü und Fußzeile, prüfen Sie die Reihenfolge der Regel und ErrorDocument: Möglicherweise schickt Letzteres den Fehler wieder an PHP.

3. Eine Seite Ihrer Website, die nicht existiert

https://midominio.com/esta-pagina-no-existe/

Hier müssen Sie weiterhin die 404-Seite Ihres Themes im gewohnten Design sehen. Die Regel fängt nur nicht vorhandene Adressen ab, die auf eine der angegebenen Endungen enden. Wenn Ihre Anwendung virtuelle Routen mit diesen Endungen nutzt, fügen Sie eine gezielte Ausnahme hinzu und testen Sie diese Routen, bevor Sie die Regel beibehalten.

Das ist ein Sicherheitsnetz, nicht die Lösung

Der Block macht den Fehler billiger, aber die Anfrage nach der fehlenden Datei findet weiterhin statt. Suchen Sie die Herkunft mit dem Tab Netzwerk in den Entwicklertools des Browsers, der Ihnen zeigt, welche Ressource angefordert wird und von wo.

Der Tab Initiator und das Protokoll zeigen, welche Seite oder Komponente die Ressource angefordert hat. Installieren Sie ein Plugin nur dann neu, wenn Sie bestätigt haben, dass die Datei zu diesem Paket gehören sollte; stammt der Verweis aus einem Cache, leeren Sie diesen Cache, nachdem Sie ihn korrigiert haben.

Wenn Sie die Leistung Ihrer Installation genauer untersuchen möchten, gibt es die Anleitung zur WordPress-Optimierung und die zu LiteSpeed Cache.

Verwenden Sie beim Test einer nicht vorhandenen URL auch Abfrageparameter und Großbuchstaben in der Endung. Prüfen Sie vor dem Deployment jeden virtuellen Endpunkt, der auf .js, .css oder eine andere enthaltene Endung endet: Die Regel kann ihn nicht von einer fehlenden Datei unterscheiden. Vergleichen Sie HTTP-Code und Last vorher und nachher, und behandeln Sie die Korrektur des Verweises weiterhin als Hauptaufgabe.