Client-Fehler

Zuletzt aktualisiert: 6. November 2026

Fehler mit einem Statuscode, der mit 4 beginnt, bedeuten, dass deine Website die Anfrage zwar erhalten hat, sie aber nicht ausführen wollte oder konnte: Die Seite existiert nicht, der Besucher hat keine Berechtigung, sie anzusehen, die Anfrage war zu groß oder es sind zu viele Anfragen auf einmal eingegangen. Im Gegensatz zu Serverfehlern bedeuten sie nicht, dass deine Website ausgefallen ist, sondern weisen meist auf eine Einstellung oder Datei hin, die du ändern kannst. Die Verfügbarkeitsüberwachung von Kinsta sendet keine Benachrichtigungen für die auf dieser Seite aufgeführten Fehler; sie warnt dich lediglich vor den Serverfehlern 500, 502 und 504 sowie vor Weiterleitungsschleifen.

401 Unauthorized

Ein 401-Fehler („Nicht autorisiert“) bedeutet, dass die Seite einen Benutzernamen und ein Passwort erfordert und der Besucher diese nicht oder falsch eingegeben hat.

Passwortschutz: Wenn der htpasswd-Schutz auf deiner Website oder in deiner Staging-Umgebung aktiviert ist, sehen Besucher eine Anmeldeaufforderung, bevor die Website geladen wird. Gib den in MyKinsta festgelegten Benutzernamen und das Passwort ein oder deaktiviere den htpasswd-Schutz, wenn die Website öffentlich sein soll.
API-Anfragen: Tools und Integrationen, die über die WordPress-REST-API eine Verbindung zu deiner Website herstellen, erhalten einen 401-Fehler, wenn ihre Anmeldedaten, wie z. B. ein Anwendungskennwort, fehlen, falsch sind oder widerrufen wurden. Überprüfe die Anmeldedaten in den Einstellungen des Tools.

403 Forbidden

Ein 403 Forbidden-Fehler bedeutet, dass die Anfrage absichtlich blockiert wurde. Es gibt mehrere Ebenen, die eine Anfrage an deine Website blockieren können, und jede zeigt eine andere Seite an – daher ist die Seite, die du siehst, der schnellste Weg, die Ursache zu finden.

Finde heraus, was die Anfrage blockiert hat

Öffne die Seite, auf der der Fehler angezeigt wird, und vergleiche sie mit der Liste unten. Wenn ein Besucher den Fehler gemeldet hat, bitte ihn um einen Screenshot.

Was auf der Seite angezeigt wird	Was hat die Anfrage blockiert?	In deinen Logs?
Nur die Überschrift „403 Forbidden“ in der oberen linken Ecke	Eine Zugriffsregel in MyKinsta: Bot-Schutz, eine Ausnahme vom Bot-Schutz oder das Tool „IP-Adresse blockieren“	Nein
Eine zentrierte „403 Forbidden“-Zeile mit einer Linie und „nginx“ darunter	Der Webserver, aufgrund der angeforderten Datei oder des angeforderten Ordners	Ja, als 403 im access.log
Eine Seite, auf der eine Firewall-Regel-ID angezeigt wird	Schutz vor Sicherheitslücken	Ja, als 403 im access.log
Eine Seite, die von einem Sicherheits-Plugin oder einem CDN gekennzeichnet ist	Das jeweilige Plugin oder der jeweilige Dienst	Hängt vom jeweiligen Plugin oder Dienst ab
Eine WordPress-Meldung, zum Beispiel „Tut mir leid, du hast keine Berechtigung, auf diese Seite zuzugreifen“	WordPress-Benutzerberechtigungen oder ein abgelaufener Link	Ja, als 403 im access.log

Befolge dann die unten aufgeführten Schritte für diese Art von Blockierung.

Durch eine Zugriffsregel in MyKinsta blockiert

Wenn auf der Seite nur die Überschrift „403 Forbidden“ angezeigt wird, wurde die Anfrage von den Zugriffsregeln deiner Website blockiert, bevor sie deine Website erreichte, sodass sie nicht in den Logs deiner Website erscheint.

Geh in MyKinsta zu Websites > Websitename > Bot-Schutz und rufe den Bericht „Top-Traffic“ auf. Wähle die blockierte Traffic-Art aus, um die betroffenen IP-Adressen, Pfade, User-Agents und Länder anzuzeigen.
Überprüfe deine Schutzstufe. Strengere Stufen blockieren automatisierten Traffic, zu dem auch legitime Tools wie Verfügbarkeitsmonitore, Zahlungs-Webhooks und Plugin-Integrationen gehören können. Aktiviere Typische WordPress-Automatisierungen zulassen oder füge eine Ausnahmeregel für das jeweilige Tool hinzu. Weitere Informationen findest du unter „Bot-Schutz“.
Überprüfe deine Ausnahmen im Bot-Schutz auf eine Blockierregel, die mit der IP-Adresse, dem Pfad, dem User-Agent oder dem Land des Besuchers übereinstimmt.
Überprüfe, ob die IP-Adresse des Besuchers im Tool „IP-Adressen blockieren“ aufgeführt ist.

Wenn du mit deiner eigenen IP-Adresse testest, deaktiviere zunächst alle VPNs oder Datenschutz-Relays wie beispielsweise iCloud Private Relay. Andernfalls sieht deine Website die IP-Adresse des Relays statt deiner eigenen, und eine Ausnahme für deine IP-Adresse passt nicht.

Vom Webserver blockiert

Wenn unter der Überschrift „nginx“ angezeigt wird, hat der Webserver die Bereitstellung der angeforderten Datei oder des Ordners verweigert. Durchsuche die access.log-Datei deiner Website nach dem Code 403, um die URL zu finden, und überprüfe dann Folgendes:

Ein Ordner ohne Indexdatei: Wenn du einen Ordner aufrufst, der keine index.php– oder index.html-Datei enthält, wird ein 403-Fehler zurückgegeben, anstatt den Inhalt des Ordners aufzulisten. Füge eine Indexdatei hinzu oder verlinke stattdessen auf eine bestimmte Datei statt auf den Ordner.

Durch den Schwachstellenschutz blockiert

Wenn auf der Seite eine Firewall-Regel-ID angezeigt wird, hat der Schwachstellenschutz die Anfrage blockiert, da sie einer Regel für eine bekannte Schwachstelle in einem auf deiner Website installierten Plugin, Theme oder einer WordPress-Version entsprach. Diese Blockierungen werden als 403 in der access.log-Datei deiner Website protokolliert, sodass du dort nachsehen kannst, welche URLs wann blockiert wurden.

Das bedeutet in der Regel, dass ein Teil deiner Website veraltet ist. Manche Sicherheitslücken betreffen gängige Funktionen, wie zum Beispiel das Hochladen von Dateien über ein Formular, sodass eine Regel sowohl normale Besucher als auch Angreifer blockieren kann, bis das betroffene Plugin aktualisiert wurde.

Gehe in MyKinsta zu Websites > Websitename > Plugins und Themes und filtere die Liste nach Anfällige Plugins. Eine anfällige Version ist mit einem Ausrufezeichen gekennzeichnet, und ihre Versionsnummer ist rot hervorgehoben. Weitere Informationen findest du unter „Plugins und Themes verwalten“.
Aktualisiere zuerst die anfälligen Plugins sowie das Plugin, das für die gesperrte Seite oder Funktion zuständig ist. Wenn du nicht feststellen kannst, um welches Plugin es sich handelt, aktualisiere alle deine Plugins, Themes und den WordPress-Kern.
Teste die blockierte Seite oder Aktion erneut.
Um zu verhindern, dass das noch einmal passiert, aktiviere automatische Updates.

Der Schutz vor Sicherheitslücken kann nicht deaktiviert werden, und die Option Ausnahmen im Bot-Schutz zulassen hebt ihn nicht auf. Wenn der Fehler nach der Aktualisierung aller Komponenten weiterhin auftritt, wende dich an den Support und gib die auf der Seite angezeigte Firewall-Regel-ID an.

Durch ein Sicherheits-Plugin oder ein CDN blockiert

Wenn die Seite von einem Sicherheits-Plugin wie Wordfence oder Solid Security oder von einem CDN oder einer Firewall eines Drittanbieters gekennzeichnet ist, hat dieser Dienst die Anfrage blockiert. Überprüfe dessen Einstellungen oder Protokolle auf die blockierte Anfrage und füge dort eine Ausnahme hinzu. Wenn du dein eigenes Cloudflare-Konto nutzt, aktiviere die WAF- oder Bot-Schutz-Funktionen von Cloudflare nicht zusätzlich zum Bot-Schutz von Kinsta, da beide legitimen Datentraffic blockieren können.

Von WordPress blockiert

WordPress zeigt eine eigene Meldung an, wenn die Rolle eines angemeldeten Benutzers eine Aktion nicht zulässt oder wenn ein Sicherheitslink abgelaufen ist:

„Leider hast du keinen Zugriff auf diese Seite“: Die Rolle des Benutzers verfügt nicht über die erforderliche Berechtigung. Überprüfe die Rolle des Benutzers unter Benutzer in WordPress oder melde dich als Administrator an.
„Der Link, dem du gefolgt bist, ist abgelaufen“: Die Seite war zu lange geöffnet oder wurde aus dem Cache geladen. Lade die Seite neu und versuche es erneut. Wenn diese Meldung beim Hochladen erscheint, ist die Datei möglicherweise auch zu groß; siehe 413 Request Entity Too Large.

Wann du den Support kontaktieren solltest

Wenn du nicht herausfinden kannst, was die Anfrage blockiert, wende dich an den Support und gib dabei die URL, die Uhrzeit und die Zeitzone des Fehlers, einen Screenshot der Fehlerseite sowie die IP-Adresse des Besuchers an, falls du sie kennst.

404 Not Found

Ein 404 Not Found-Fehler bedeutet, dass die angeforderte Seite oder Datei unter dieser URL nicht existiert. Ein paar 404-Fehler sind normal, z. B. wenn Besucher eine URL falsch eingeben oder Bots Dateien anfordern, die deine Website nicht enthält. Überprüfe die Ursache, wenn echte Seiten oder Dateien einen 404-Fehler zurückgeben oder wenn 404-Fehler nach einer Änderung an deiner Website auftreten.

Die access.log-Datei deiner Website protokolliert jeden 404-Fehler mit der angeforderten URL. Suche also darin nach 404, um zu sehen, welche URLs betroffen sind.

Alle Beiträge und Seiten geben 404-Fehler zurück, aber die Startseite funktioniert: Die Permalink-Einstellungen von WordPress müssen aktualisiert werden. Gehe in WordPress zu Einstellungen > Permalinks und klicke auf Änderungen speichern, ohne etwas zu ändern.
Nach einer Migration, einer Domainänderung oder einem Umgebungs-Push: Links und Dateipfade verweisen möglicherweise noch auf die alte Domain oder den alten Ordner. Nutze das Tool „Suchen und Ersetzen“, um alte URLs zu aktualisieren, und überprüfe, ob hochgeladene Dateien übernommen wurden.
Eine vorhandene Datei gibt einen 404-Fehler zurück: Der Webserver hat möglicherweise keine Berechtigung, sie zu lesen. Im „error.log“ deiner Seite steht open() "..." failed (13: Permission denied) zusammen mit dem Dateipfad. Das passiert oft nach dem Hochladen von Dateien über SFTP oder dem Deployment von Code. Überprüfe die Dateiberechtigungen in deinem SFTP-Client (die meisten zeigen sie an, wenn du mit der rechten Maustaste auf eine Datei klickst und die Berechtigungen oder Informationen öffnest) oder über SSH mit ls -l. Dateien sollten auf 644 und Ordner auf 755 eingestellt sein.
Eine Seite oder Datei wurde verschoben oder gelöscht: Richte eine Weiterleitung von der alten URL zur neuen ein, damit bestehende Links und Suchergebnisse weiterhin funktionieren.
Eine Seite, die du gerade veröffentlicht hast, zeigt immer noch einen 404-Fehler an: Der 404-Fehler ist möglicherweise im Cache gespeichert. Leere den Cache deiner Website und gegebenenfalls den CDN-Cache.

405 Method Not Allowed

Ein 405-Fehler („Methode nicht zulässig“) bedeutet, dass die URL zwar existiert, aber die Art der gesendeten Anfrage nicht akzeptiert wird. Jede Anfrage verwendet eine Methode, wie z. B. GET, um eine Seite zu laden, oder POST, um ein Formular abzuschicken, und manche URLs akzeptieren nur bestimmte Methoden. Dieser Fehler tritt meist bei Formularen, Webhooks und Integrationen auf und nicht, wenn Besucher Seiten laden.
Durchsuche die „access.log“-Datei deiner Website nach 405, um zu sehen, welche URL und welche Methode verwendet wurden.

Ein Formular oder Tool sendet Daten an eine statische Datei: Das Absenden eines Formulars (eine POST-Anfrage) an eine statische Datei, wie z. B. eine .html-Datei oder ein Bild, führt zu einem 405-Fehler, da statische Dateien nur geladen werden können. Überprüfe, ob die „action“-Angabe des Formulars oder die URL des Tools auf eine WordPress-Website oder einen Endpunkt verweist, nicht auf eine Datei.
Ein Webhook oder eine Integration verwendet die falsche Methode: Zahlungsanbieter, Formular-Dienste und andere Integrationen benötigen genau die URL und Methode, die in ihrer Dokumentation angegeben sind. Überprüfe die Einstellungen der Integration und kopiere die URL erneut aus dem Plugin, das sie bereitstellt.
Eine Weiterleitung verändert die Anfrage: Wenn eine Anfrage weitergeleitet wird, zum Beispiel von http:// zu https:// oder von www. zur Nicht-www-Domain, senden viele Tools sie als GET-Anfrage erneut ab, sodass ein Endpunkt, der eine POST-Anfrage erwartet, diese ablehnt. Verwende in den Einstellungen des Tools die endgültige URL, einschließlich https:// und der richtigen Domain.

413 Request Entity Too Large

Ein 413-Fehler („Request Entity Too Large“) bedeutet, dass eine Anfrage – meist ein Datei-Upload – zu groß war, um akzeptiert zu werden. Deine Website hat zwei Upload-Limits, und je nachdem, welches eine Datei überschreitet, siehst du folgende Meldung:

Das Limit des Webservers (128 MB): Anfragen, die größer als 128 MB sind, werden abgelehnt, bevor sie WordPress erreichen. Tools wie curl und API-Clients zeigen den 413-Fehler an, aber Browser-Upload-Tools, wie zum Beispiel der WordPress-Medien-Uploader, zeigen stattdessen meist einen allgemeinen Upload-Fehler an. Die Datei „error.log“ deiner Website protokolliert die Anfrage als client intended to send too large body, gefolgt von der Größe in Byte.
Das PHP-Upload-Limit deines Tarifs: Die Anfrage erreicht WordPress, aber PHP verwirft die Datei, sodass kein Fehler 413 auftritt. Stattdessen zeigt WordPress eine eigene Meldung an, wie z. B. „Überschreitet die maximale Upload-Größe für diese Seite“ oder „Der Link, dem du gefolgt bist, ist abgelaufen“.

Das PHP-Upload-Limit deines Tarifs (upload_max_filesize und post_max_size) beträgt:

128 MB: Single mit bis zu 125.000 Besuchen, Single mit bis zu 65 GB Bandbreite, WP 2, Launch, Launch Plus, Build und Expand.
256 MB: Single ab 315.000 Besuchen, Single ab 125 GB Bandbreite, WP 5 und höher, Scale und Lead.
Dedizierte Server: Das Limit kann auf 500 MB erhöht werden. Wende dich an den Support, um dies zu ändern.

Wenn du Dateien hochladen musst, die größer sind als dein Limit, nutze eine der folgenden Optionen.

Große Dateien auf andere Weise hochladen: Lade große Dateien wie Videos, Backups oder Importdateien über SFTP statt über den Browser hoch. WordPress-Medien kannst du anschließend mit WP-CLI (wp media import) zur Medienbibliothek hinzufügen.
Reduziere die Dateigröße: Komprimiere Bilder und Videos oder teile große Importdateien in kleinere auf.
Große Datenbankimporte: Nutze WP-CLI wie unter „MySQL-Datenbank importieren“ beschrieben.
CDN eines Drittanbieters: Wenn du ein anderes CDN oder einen anderen Proxy nutzt, hat dieses möglicherweise ein niedrigeres Größenlimit als Kinsta. Überprüfe dessen Upload-Limit.

429 Too Many Requests

Ein „429 Too Many Requests“-Fehler bedeutet, dass innerhalb kurzer Zeit zu viele Anfragen von derselben Quelle eingegangen sind, sodass der Webserver deiner Seite diese vorübergehend begrenzt hat. Anfragen, die das Limit überschreiten, werden abgelehnt, bis die Rate sinkt; andere Besucher sind davon nicht betroffen.

Die Datei „error.log“ deiner Website protokolliert jede begrenzte Anfrage alslimiting requests, excess: ... by zone "phpzone".

Bots und Scraper: Automatisierter Traffic, der viele Seiten schnell durchforstet, ist die häufigste Ursache. Nutze den „Top-Traffic“-Bericht im Bot-Schutz, um die Quelle zu finden, und blockiere sie dann oder erhöhe deine Schutzstufe.
Plugins und Integrationen: Tools, die deine Website synchronisieren, importieren oder überprüfen, können Anforderungsspitzen auslösen, zum Beispiel an admin-ajax.php oder die WordPress-REST-API. Reduziere die Ausführungshäufigkeit oder stelle sie so ein, dass sie Anfragen in kleineren Stapeln senden.
Lasttests: Tools, die hohen Traffic von einer einzigen Quelle simulieren, werden schnell in ihrer Rate begrenzt. Lasttests sind bei Kinsta nicht erlaubt; weitere Informationen findest du in unseren Nutzungsbedingungen.

Falls legitimer Datentraffic eingeschränkt wird, wende dich bitte an den Support und gib den Zeitpunkt der Fehler sowie die betroffene IP-Adresse oder das betreffende Tool an.

451 Unavailable For Legal Reasons

Ein 451-Fehler („Aus rechtlichen Gründen nicht verfügbar“) bedeutet, dass der Zugriff auf die Seite blockiert wurde, um einem Gesetz oder einer gerichtlichen Anordnung nachzukommen. Dieser Fehler stammt in der Regel weder von deiner Website noch von Kinsta.

Besucher in einem bestimmten Land sehen den Fehler: Ihr Internetdienstanbieter oder die Regierung blockiert deine Website höchstwahrscheinlich auf Netzwerkebene. Deine Website funktioniert weiterhin, Besucher an anderen Standorten können sie nach wie vor aufrufen, und es muss nichts in MyKinsta oder WordPress geändert werden.
Ein Plugin blockiert Besucher nach Standort: Manche Plugins schränken den Zugriff aus bestimmten Ländern aus Datenschutzgründen oder zur Einhaltung gesetzlicher Vorschriften ein und geben einen 451-Fehler zurück. Überprüfe die Einstellungen deiner Plugins oder deaktiviere sie nacheinander, um das verantwortliche Plugin zu finden.

Wenn du ein Land selbst mit einer Ausnahme im Bot-Schutz blockiert hast, sehen Besucher aus diesem Land einen 403-Fehler, keinen 451; siehe 403 Forbidden.

499 Client Closed Request

Besucher sehen niemals einen 499-Fehler. Er wird im „access.log“ deiner Website protokolliert, wenn der Browser des Besuchers oder ein anderer Dienst, der eine Verbindung zu deiner Website herstellt, die Verbindung schließt, bevor deine Website die Antwort vollständig gesendet hat.

Ein paar 499er-Fehler sind normal: Sie werden protokolliert, wenn ein Besucher einen Tab schließt, wegklickt oder das Laden einer Seite unterbricht.
499er mit einer Anforderungsdauer von etwa 180 Sekunden: Die Anfrage hat das 180-Sekunden-Limit erreicht, Cloudflare hat die Verbindung geschlossen und der Besucher hat einen 524-Timeout-Fehler gesehen. Behandle diese als Timeouts; siehe 504 Gateway-Timeout-Fehler.
Viele 499er-Fehler von demselben Tool: Ein Verfügbarkeitsmonitor, eine Integration oder ein anderer Dienst hat möglicherweise ein kürzeres Timeout als deine Website zum Antworten benötigt. Überprüfe die Timeout-Einstellung des Tools oder nutze das APM-Tool von Kinsta, um herauszufinden, warum die Anfrage so langsam ist.