Der vollständige Leitfaden zu HTTP-Fehlercodes: Ursachen, Lösungen und Auswirkungen auf SEO

HTTP-Fehlercodes sind wichtig für Webmaster, Entwickler, SEO-Spezialisten, Hosting-Teams und normale Nutzer, die verstehen möchten, warum eine Website oder Seite nicht lädt. 

In diesem Leitfaden erfahren Sie, was Fehler wie 502, 503, 504, 403 und SSL-bezogene Fehler bedeuten, warum sie auftreten, wie Sie sie beheben und wie sie sich auf SEO auswirken können.

Was sind HTTP-Fehlercodes und wie funktionieren sie?

HTTP-Fehlercodes sind Serverantworten, die erklären, was passiert ist, nachdem ein Browser, ein Suchmaschinen-Bot oder eine Anwendung eine Seite angefordert hat. Eine erfolgreiche Anfrage liefert in der Regel 200 OK. Wenn etwas schiefgeht, gibt der Server einen anderen Code zurück, der auf das Problem hinweist.

Diese Codes zeigen, ob eine Seite verfügbar, verschoben, gesperrt oder nicht vorhanden ist oder von einem Serverproblem betroffen ist. Für Website-Betreiber und SEO-Spezialisten helfen sie dabei, Probleme zu erkennen, die Crawling, Indexierung, Rankings und Nutzererfahrung beeinträchtigen können.

Wie die Kommunikation zwischen Client und Server funktioniert

Wenn ein Nutzer eine Website öffnet, sendet der Browser eine Anfrage an den Server. Der Server prüft URL, Berechtigungen, Dateien und Anwendungslogik und gibt dann einen Antwortcode zurück.

Ist die Anfrage erfolgreich, lädt die Seite. Schlägt sie fehl, zeigt der Browser möglicherweise 403 Forbidden, 502 Bad Gateway oder 504 Gateway Timeout an.

Bei HTTPS-Websites prüft der Browser außerdem das SSL- bzw. TLS-Zertifikat. Ein abgelaufenes, ungültiges oder nicht passendes Zertifikat kann eine Sicherheitswarnung auslösen.

Klassen von HTTP-Statuscodes

HTTP-Statuscodes sind in fünf Hauptgruppen unterteilt:

1xx-Codes sind informative Antworten. Sie bedeuten, dass die Anfrage empfangen wurde und der Vorgang noch läuft.

2xx-Codes bedeuten Erfolg. Das häufigste Beispiel ist 200 OK: Die Seite oder Ressource wurde korrekt geladen.

3xx-Codes sind Weiterleitungen. Sie teilen Browsern und Suchmaschinen mit, dass die angeforderte URL verschoben wurde oder eine weitere Aktion erforderlich ist.

4xx-Codes sind clientseitige Fehler. Sie bedeuten in der Regel, dass die Seite fehlt, die Anfrage fehlerhaft ist oder der Zugriff gesperrt ist. Häufige Beispiele sind 403 Forbidden und 404 Not Found.

5xx-Codes sind serverseitige Fehler. Sie bedeuten, dass die Anfrage zwar gültig sein kann, der Server sie aber nicht ausführen kann. Häufige Beispiele sind 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable und 504 Gateway Timeout.

Für SEO gilt: Wiederholte 4xx- und 5xx-Fehler können das Crawling blockieren, das Vertrauen der Nutzer verringern und die organische Sichtbarkeit schwächen.

Kurzübersicht: die wichtigsten Fehlercodes

HTTP-Statuscodes sind kurze Serverantworten, die erklären, was passiert ist, nachdem ein Browser, Bot oder eine Anwendung eine Anfrage gesendet hat. Der grundlegende Ablauf: Der Client sendet eine Anfrage, der Server verarbeitet sie, der Server gibt einen Antwortcode zurück. Dieser Code zeigt, ob die Seite geladen wurde, der Zugriff gesperrt wurde, der Server versagt hat oder keine sichere Verbindung hergestellt werden konnte.

Stellen Sie es sich wie eine Bestellung im Restaurant vor: 403 bedeutet, dass die Bedienung verweigert wird, 502, 503 oder 504 bedeuten, dass die Küche oder der Lieferant ein Problem hat, und SSL-Fehler bedeuten, dass das Restaurant nicht nachweisen kann, dass das Betreten sicher ist.

Diese fünf Fehler sind besonders wichtig, weil sie sich direkt auf Zugriff, Serververfügbarkeit, sichere Verbindungen, Nutzererfahrung und das Crawling durch Suchmaschinen auswirken.

Fehler 403 Forbidden: Bedeutung und Behebung

Ein Fehler 403 Forbidden bedeutet, dass der Server die Anfrage verstanden hat, den Zugriff auf die Seite, die Datei oder das Verzeichnis aber verweigert. Die URL kann korrekt sein, der Server online und die Ressource vorhanden, doch dem Besucher, Bot oder der Anwendung fehlt die Berechtigung, sie zu öffnen.

Für Website-Betreiber tritt dieser Fehler häufig nach Migrationen, CMS-Updates, Änderungen an Berechtigungen, neuen Sicherheitsregeln oder Anpassungen der Firewall auf. Mit einem richtig konfigurierten Rocky Linux VPS können Teams das Problem in der Regel über Dateibesitz, Apache- oder Nginx-Regeln, SELinux-Einstellungen und Logs nachverfolgen.

Ein gut gewarteter AlmaLinux VPS erleichtert ebenfalls die Wiederherstellung nach Änderungen am Document Root, Updates des PHP-Handlers oder einer Sicherheitshärtung. In den meisten Fällen ist nicht die Seite defekt, sondern die Zugriffsregeln rund um sie.

Häufige Ursachen für 403-Fehler

Eine häufige Ursache sind falsche Datei- oder Verzeichnisberechtigungen. Webserver müssen Website-Dateien lesen und Website-Verzeichnisse betreten können. In vielen Linux-Setups haben Verzeichnisse die Berechtigung 755 und Dateien die Berechtigung 644. Sind die Berechtigungen zu restriktiv, kann der Server den Zugriff blockieren.

Ein weiterer häufiger Grund ist eine falsch konfigurierte .htaccess-Datei. Eine Regel kann alle Besucher, einen bestimmten IP-Bereich, einen geschützten Ordner oder das Durchsuchen von Verzeichnissen sperren.

Beispiel für eine restriktive .htaccess-Regel:

Deny from all

In älteren Apache-Konfigurationen verweigert diese Regel allen den Zugriff. In neueren Apache-Versionen kann eine ähnliche Einschränkung so aussehen:

Require all denied

Ein 403-Fehler kann auch durch WAF- oder Firewall-Regeln entstehen. Sicherheitstools können verdächtige Anfragen, bestimmte Länder, einzelne IP-Adressen, Bots, User Agents oder wiederholte Anmeldeversuche blockieren. Das schützt die Website, doch Fehlalarme können echte Nutzer oder Suchmaschinen-Crawler aussperren.

Eine fehlende Indexdatei ist eine weitere mögliche Ursache. Enthält ein Verzeichnis keine index.html, index.php oder andere konfigurierte Indexdatei und ist das Verzeichnislisting deaktiviert, kann der Server 403 Forbidden zurückgeben.

Apache-Logs verraten oft den Grund:

client denied by server configuration

Das deutet in der Regel auf Serverregeln, die Verzeichniskonfiguration, die .htaccess oder Einstellungen der Zugriffskontrolle hin.

So beheben Sie 403 Forbidden: Schritt für Schritt

 1. Prüfen Sie zuerst die URL

Stellen Sie sicher, dass die angeforderte URL korrekt ist. Eine falsche URL kann manchmal auf ein geschütztes Verzeichnis statt auf eine öffentliche Seite verweisen.

 2. Prüfen Sie die Datei- und Verzeichnisberechtigungen

Bei vielen Linux-Webservern sollten Verzeichnisse für den Webserver in der Regel lesbar und ausführbar sein, Dateien lesbar.

Beispielbefehl für ein Web-Verzeichnis:

chmod 755 /var/www/

Für Dateien und Verzeichnisse innerhalb der Website werden üblicherweise die Berechtigungen 644 für Dateien und 755 für Verzeichnisse verwendet:

find /var/www/ -type f -exec chmod 644 {} \;

find /var/www/ -type d -exec chmod 755 {} \;

ACHTUNG: Verwenden Sie chmod 777 nicht als schnelle Lösung. Damit erhalten alle Lese-, Schreib- und Ausführungsrechte, was ein ernsthaftes Sicherheitsrisiko darstellen kann. Ein öffentlich beschreibbares Website-Verzeichnis kann es Angreifern, Malware oder anfälligen Skripten ermöglichen, Dateien zu verändern.

 3. Prüfen Sie den Dateibesitz

Selbst wenn die Berechtigungen korrekt aussehen, kann der Besitz nach einer Migration oder einem manuellen Upload falsch sein. Der Webserver-Benutzer muss die Dateien lesen können. Je nach Stack kann dieser Benutzer www-data, apache, nginx oder ein anderer Systembenutzer sein.

 4. Überprüfen Sie die .htaccess-Regeln

Benennen Sie die .htaccess vorübergehend um, um zu prüfen, ob sie das Problem verursacht. Funktioniert die Seite danach, überprüfen Sie Zugriffsregeln, Rewrite-Regeln, IP-Beschränkungen und alte Direktiven wie Deny from all.

 5. Prüfen Sie Firewall, WAF und Sicherheits-Plugins

Tritt der Fehler nur bei bestimmten Nutzern, Ländern, IP-Adressen oder Bots auf, überprüfen Sie die Firewall-Logs und WAF-Einstellungen. Auch Sicherheits-Plugins in WordPress und ähnlichen CMS-Plattformen können 403-Antworten auslösen.

 6. Prüfen Sie die Indexdatei

Stellen Sie sicher, dass das Verzeichnis eine gültige Indexdatei wie index.php oder index.html enthält. Fehlt die Indexdatei und ist das Verzeichnislisting deaktiviert, kann der Server 403 zurückgeben.

 7. Lesen Sie die Server-Logs

Logs sind der schnellste Weg, die eigentliche Ursache zu finden. Prüfen Sie die Logs von Apache, Nginx, PHP, WAF und Hosting-Panel auf Meldungen zu verweigertem Zugriff, Berechtigungsproblemen oder gesperrten IP-Adressen.

403 vs. 401: Was ist der Unterschied?

Ein Fehler 401 Unauthorized bedeutet, dass der Server nicht feststellen kann, wer der Nutzer ist. Die Authentifizierung fehlt, ist ungültig oder abgelaufen. Das kann passieren, wenn jemand nicht angemeldet ist, ein falsches Passwort verwendet oder ein ungültiges API-Token sendet.

Ein Fehler 403 Forbidden bedeutet, dass der Server die Anfrage versteht, der Zugriff aber nicht erlaubt ist. Der Nutzer ist möglicherweise bereits authentifiziert, verfügt aber trotzdem nicht über die erforderliche Rolle, Zugriffsebene, IP-Freigabe oder Serverberechtigung.

Der zentrale Unterschied ist einfach: Bei 401 geht es um Authentifizierung, bei 403 um Autorisierung. Die Authentifizierung fragt: „Wer sind Sie?“ Die Autorisierung fragt: „Dürfen Sie darauf zugreifen?“

Fehler 502 Bad Gateway: Ursachen und Lösungen

Ein Fehler 502 Bad Gateway bedeutet, dass ein Gateway oder Proxyserver von einem Upstream-Server eine ungültige Antwort erhalten hat. In der Praxis passiert das häufig, wenn ein Browser Nginx, Apache, einen Load Balancer, ein CDN oder einen Reverse Proxy erreicht, der nächste Dienst in der Kette aber nicht korrekt antwortet.

Der Anfragepfad sieht in der Regel so aus:

client → Nginx → PHP-FPM / upstream application server

Wenn Nginx die Anfrage annehmen kann, PHP-FPM, Node.js, Python, eine Backend-API oder ein anderer Upstream-Dienst aber keine gültige Antwort liefert, sieht der Nutzer möglicherweise 502 Bad Gateway. Deshalb sind 502-Fehler häufig bei dynamischen Websites, stark frequentierten E-Commerce-Projekten, API-basierten Plattformen und Websites, die in falsch konfigurierten VPS-Hosting-Umgebungen laufen.

Was verursacht einen 502-Fehler?

Ein Fehler 502 Bad Gateway bedeutet in der Regel, dass das Gateway den Upstream-Dienst erreicht, aber eine fehlerhafte oder ungültige Antwort erhalten hat. Häufige Ursachen sind ein abgestürzter PHP-FPM-Pool, ein gestoppter Node.js- oder Python-Prozess, eine überlastete Backend-Anwendung, falsche DNS-Einträge oder eine Firewall, die die Kommunikation zwischen Nginx und dem Upstream-Server blockiert.

Auch CDN-Einstellungen können 502-Fehler verursachen, wenn das CDN auf die falsche Origin-IP verweist oder keine Verbindung zum Server herstellen kann. Bei PHP-basierten Websites ist PHP-FPM oft die Schwachstelle, insbesondere wenn Speicherlimits, Worker-Limits oder Socket-Pfade falsch konfiguriert sind.

Eine typische Nginx-Logmeldung lautet:

upstream prematurely closed connection while reading response header

Bei Projekten mit hohem Traffic sorgt eine regelmäßige Überwachung von Upstream-Diensten, DNS und Proxy-Konfiguration dafür, dass die gesamte Anfragekette stabil bleibt.

So beheben Sie 502 Bad Gateway: Schritt für Schritt

Wenn Sie einen Fehler 502 Bad Gateway sehen, prüfen Sie die gesamte Anfragekette, statt blind alles neu zu starten. Das Problem liegt in der Regel zwischen dem Gateway, etwa Nginx, und dem Upstream-Dienst, etwa PHP-FPM, Node.js oder einem anderen Backend.

•  Neu laden und aus einem anderen Netzwerk testen

Laden Sie die Seite neu, versuchen Sie es mit einem anderen Browser und testen Sie aus einem anderen Netzwerk. Tritt der Fehler nur an einem Standort auf, prüfen Sie CDN-Cache, DNS oder das lokale Routing.

•  Upstream-Dienst prüfen

Stellen Sie sicher, dass PHP-FPM, Nginx oder Ihr Backend-Prozess läuft.

systemctl status php-fpm

systemctl status nginx

Auf manchen Servern enthält der Name des PHP-FPM-Dienstes die Version, etwa php8.2-fpm.

•  Betroffene Dienste neu starten

Wenn der Dienst abgestürzt ist, starten Sie ihn neu und beobachten Sie, ob der Fehler erneut auftritt.

systemctl restart php-fpm

systemctl restart nginx

•  Logs prüfen

Überprüfen Sie die Logs von Nginx, PHP-FPM und der Anwendung auf Upstream-Fehler, Meldungen wie „connection refused“, Speicherprobleme oder Timeouts.

/var/log/nginx/error.log

/var/log/php-fpm/error.log

• Upstream-Konfiguration überprüfen

Prüfen Sie, ob Nginx auf den richtigen Socket, Port oder die richtige Upstream-Adresse verweist. Ein falscher PHP-FPM-Socket-Pfad oder Backend-Port kann sofort einen 502-Fehler verursachen.

• Firewall-Regeln prüfen

Stellen Sie sicher, dass das Gateway eine Verbindung zum Upstream-Dienst herstellen kann. Überprüfen Sie lokale Firewall-Regeln, Firewall-Einstellungen des Hostings, Security Groups und interne Netzwerkregeln.

• DNS- und CDN-Einstellungen überprüfen

Wenn Sie ein CDN nutzen, vergewissern Sie sich, dass es auf die richtige Origin-IP verweist. Prüfen Sie außerdem die DNS-Einträge für Domains, Subdomains, APIs und Upstream-Hostnamen.

• Serverressourcen prüfen

Hohe CPU-Auslastung, wenig RAM, voller Festplattenspeicher oder zu viele PHP-FPM-Worker können den Upstream instabil machen.

502 vs. 504: die wichtigsten Unterschiede

Ein Fehler 502 Bad Gateway bedeutet, dass das Gateway vom Upstream-Server eine ungültige oder fehlerhafte Antwort erhalten hat. Der Upstream-Dienst ist möglicherweise abgestürzt, hat die Verbindung zu früh geschlossen, fehlerhafte Header zurückgegeben oder ist ausgefallen, bevor er eine verwertbare Antwort senden konnte.

Ein Fehler 504 Gateway Timeout bedeutet, dass das Gateway nicht rechtzeitig eine Antwort erhalten hat. Der Upstream-Server läuft möglicherweise noch, ist aber zu langsam, überlastet, hängt an einer Datenbankabfrage fest oder wartet auf eine externe API.

Der Unterschied ist einfach: 502 bedeutet, dass das Gateway eine fehlerhafte Antwort erhalten hat, 504 bedeutet, dass es zu lange gewartet und nicht rechtzeitig eine Antwort erhalten hat. Beide betreffen die Kommunikation zwischen Servern, weisen aber auf unterschiedliche Probleme hin.

503 Service Unavailable: Warum der Fehler auftritt und was zu tun ist

Ein Fehler 503 Service Unavailable bedeutet, dass der Server die Anfrage vorübergehend nicht bearbeiten kann. Die Website ist nicht zwangsläufig dauerhaft defekt. Der Server kann überlastet sein, gewartet werden, zu wenig Ressourcen haben oder für geplante Arbeiten bewusst geschlossen sein.

Für SEO ist 503 bei vorübergehenden Ausfällen oft der richtige Statuscode. Er teilt Browsern und Suchmaschinen mit, dass die Seite später wieder verfügbar sein sollte, statt sie als gelöscht oder dauerhaft nicht verfügbar zu behandeln.

Häufige Ursachen für 503-Fehler

Ein 503-Fehler tritt in der Regel auf, wenn der Server Anfragen vorübergehend nicht verarbeiten kann, etwa wegen Traffic-Spitzen, hoher CPU-Auslastung, wenig RAM, überlasteter Datenbank, Hosting-Limits oder zu vieler aktiver PHP-Worker.

Auch geplante Wartungsarbeiten können einen 503 auslösen. Wenn eine Website aktualisiert, migriert oder repariert wird, ist dieser Status besser, als fehlerhafte Seiten anzuzeigen. Eine korrekte Wartungsantwort kann einen Retry-After-Header enthalten, der Crawlern und Clients mitteilt, wann sie es erneut versuchen sollen.

Dieser Fehler kann auch auftreten, wenn ein Hosting-Tarif für das Projekt zu klein ist. Treten 503-Fehler während Kampagnen, Spitzen im Checkout oder Bot-Aktivität auf, kann der Umzug einer wachsenden E-Commerce-Website auf eine richtig konfigurierte VPS USA-Lösung mit ausreichend CPU, RAM und Datenbankkapazität die Stabilität verbessern.

So beheben Sie 503 Service Unavailable: Schritt für Schritt

 1. Prüfen Sie, ob der Ausfall beabsichtigt ist

Beginnen Sie mit der einfachsten Frage: Befindet sich die Website im Wartungsmodus? Prüfen Sie die Einstellungen des Hosting-Panels, Deployment-Tools, Wartungs-Plugins des CMS und die Serverkonfiguration.

 2. Prüfen Sie die Serverressourcen

Sehen Sie sich CPU, RAM, Festplattenspeicher, aktive Prozesse und Datenbanklast an. Ist der Server ständig überlastet, kann ein Neustart der Dienste das Problem nur für wenige Minuten verdecken.

 3. Überprüfen Sie die Logs von Webserver und Anwendung

Prüfen Sie die Logs von Nginx, Apache, PHP, Datenbank und CMS. Achten Sie auf Speicherfehler, Worker-Limits, fehlgeschlagene Datenbankverbindungen, Plugin-Fehler oder wiederholte Anfragen von Bots.

 4. Starten Sie ausgefallene Dienste neu

Wenn ein Dienst gestoppt wurde, starten Sie ihn neu und beobachten Sie das Ergebnis.

systemctl restart nginx

systemctl restart apache2

systemctl restart php-fpm

systemctl restart mysql

Die Namen der Dienste können je nach Betriebssystem und Stack variieren.

 5. Deaktivieren Sie WordPress-Plugins zur Diagnose

In WordPress kann ein defektes Plugin nach einem Update oder bei einem Konflikt 503-Fehler auslösen. Benennen Sie den Ordner plugins vorübergehend um und prüfen Sie dann, ob die Website lädt.

Beispiel:

mv wp-content/plugins wp-content/plugins-disabled

Wenn die Website wieder erreichbar ist, stellen Sie den ursprünglichen Ordnernamen wieder her und deaktivieren Sie die Plugins einzeln, um die Ursache zu finden.

 6. Verwenden Sie eine korrekte Wartungsantwort

Wenn der Ausfall geplant ist, zeigen Sie eine Wartungsseite mit dem Status 503 und einem Retry-After-Header an. Das ist für SEO besser, als 200 OK mit einer Wartungsmeldung zurückzugeben.

Beispiel für eine Nginx-Konfiguration:

location / {

add_header Retry-After 3600 always;

return 503;

}

error_page 503 /maintenance.html;

location = /maintenance.html {

root /var/www/html;

}

Damit werden Clients angewiesen, es nach 3.600 Sekunden erneut zu versuchen.

 7. Ressourcen aufstocken oder den Stack optimieren

Treten 503-Fehler bei normalem Traffic auf, erhöhen Sie die Serverressourcen, optimieren Sie Datenbankabfragen, fügen Sie Caching hinzu, reduzieren Sie ressourcenintensive Plugins, begrenzen Sie missbräuchliche Bots oder verlagern Sie stark belastete Dienste auf eine separate Infrastruktur.

503 vs. 500: den Unterschied verstehen

Ein Fehler 503 Service Unavailable bedeutet, dass der Server die Anfrage vorübergehend nicht bearbeiten kann. Der Server kann überlastet sein, sich im Wartungsmodus befinden oder durch die verfügbaren Ressourcen eingeschränkt sein.

Ein Fehler 500 Internal Server Error bedeutet, dass beim Verarbeiten der Anfrage ein unerwarteter interner Fehler im Server aufgetreten ist. Ursache sind in der Regel Anwendungsfehler, eine fehlerhafte Konfiguration, Codefehler, Berechtigungen oder fehlgeschlagene Skripte.

Der praktische Unterschied ist wichtig: 503 sagt „Versuchen Sie es später erneut“, 500 sagt „Im Server oder in der Anwendung ist etwas fehlgeschlagen“. Bei geplanten Wartungsarbeiten und vorübergehender Überlastung ist 503 die sauberere und SEO-freundlichere Antwort.

504 Gateway Timeout: Diagnose und Behebung

Ein Fehler 504 Gateway Timeout bedeutet, dass ein Gateway oder Proxyserver innerhalb der zulässigen Zeit keine Antwort vom Upstream-Server erhalten hat. Die Anfrage hat die Serverkette erreicht, doch ein Teil dieser Kette hat zu lange für die Antwort gebraucht.

Ein typischer Ablauf sieht so aus:

client → Nginx or proxy → PHP, database, API, or application server

Dieser Fehler tritt häufig bei dynamischen Websites auf, deren Seiten von Datenbankabfragen, externen APIs, Zahlungs-Gateways, Suchfiltern, Berichten oder aufwendiger Backend-Logik abhängen. Ein gut konfigurierter High Load VPS hilft solchen Projekten, größere Anfragemengen zuverlässiger zu bewältigen, insbesondere in Kombination mit passenden Timeout-Einstellungen, Caching und Backend-Optimierung.

Was löst einen 504-Fehler aus?

Der häufigste Auslöser ist ein langsamer Upstream-Dienst. PHP verarbeitet möglicherweise ein aufwendiges Skript, die Datenbank hängt an einer komplexen SQL-Abfrage fest oder die Anwendung wartet auf eine externe API, die zu langsam antwortet.

Auch die Timeout-Einstellungen des Proxys können das Problem verursachen. Wartet Nginx nur 60 Sekunden, das Backend benötigt aber 90 Sekunden für die Aufgabe, kann Nginx 504 Gateway Timeout zurückgeben, obwohl das Backend noch arbeitet.

Datenbanken sind eine weitere häufige Quelle für 504-Fehler. Abfragen ohne Index, große Joins, überlastete MySQL- oder PostgreSQL-Server, gesperrte Tabellen und langsame Suchvorgänge können die Antwort so lange verzögern, bis das Gateway aufgibt.

Eine typische Nginx-Logmeldung sieht so aus:

upstream timed out (110: Connection timed out) while reading response header from upstream

Das bedeutet, dass Nginx auf den Upstream-Dienst gewartet, aber vor Ablauf des Timeout-Limits keinen Antwort-Header erhalten hat.

So beheben Sie 504 Gateway Timeout: Schritt für Schritt

Sie wissen nicht, was zu tun ist, wenn eine Seite immer wieder den Fehler 504 Gateway Timeout liefert? Beginnen Sie mit dem Anfragepfad und prüfen Sie dann Schritt für Schritt Server, Logs, Timeout-Einstellungen und Backend-Leistung.

 1. Prüfen Sie, ob der Fehler vorübergehend ist

Laden Sie die Seite neu, testen Sie ein anderes Netzwerk und prüfen Sie, ob das Problem eine einzelne URL oder die gesamte Website betrifft. Eine einzelne fehlerhafte Seite deutet oft auf ein langsames Skript, eine langsame Abfrage oder einen langsamen API-Aufruf hin.

 2. Prüfen Sie die Serverressourcen

Überprüfen Sie CPU, RAM, Festplattenauslastung, Load Average und Datenbankaktivität. Ist der Server überlastet, lässt sich die eigentliche Ursache durch längere Timeouts nicht beheben.

 3. Untersuchen Sie die Logs

Prüfen Sie die Logs von Nginx, Apache, PHP, Datenbank und Anwendung auf Timeout-Meldungen, langsame Abfragen, Speicherfehler oder fehlgeschlagene externe Anfragen.

 4. Erhöhen Sie die Nginx-Timeouts mit Bedacht

proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_send_timeout 300;

 5. Prüfen Sie die PHP-Limits

max_execution_time = 300

Überprüfen Sie auch PHP-FPM-Einstellungen wie request_terminate_timeout.

 6. Optimieren Sie das Backend

Beheben Sie langsame SQL-Abfragen, fügen Sie Indizes hinzu, cachen Sie aufwendige Vorgänge und verlagern Sie Importe, Berichte, Synchronisierungsaufgaben und langsame API-Aufrufe in Hintergrundjobs.

SSL/TLS-Zertifikatsfehler: vollständiger Leitfaden zur Fehlerbehebung

SSL- und TLS-Zertifikatsfehler treten auf, wenn ein Browser keine vertrauenswürdige sichere Verbindung zu einer Website herstellen kann. Das kann vor dem Laden der Seite, während des TLS-Handshakes oder dann passieren, wenn eine HTTPS-Seite unsichere HTTP-Ressourcen laden will.

Die häufigsten SSL-Fehlercodes und ihre Bedeutung

Die folgende Tabelle erklärt die SSL- und TLS-Fehler, die Nutzer am häufigsten im Browser sehen.

Diese Fehler entstehen häufig durch abgelaufene Zertifikate, eine fehlerhafte Installation, fehlende Zwischenzertifikate, falsche Domainnamen, nicht unterstützte TLS-Versionen oder eine falsche SSL-Konfiguration im CDN.

So beheben Sie SSL-Zertifikatsfehler: Schritt für Schritt

 1. Prüfen Sie den Zertifikatsstatus

Überprüfen Sie Domain, Ablaufdatum, Aussteller und Zertifikatskette. Das live verwendete Zertifikat können Sie so testen:

openssl s_client -connect domain.com:443

 2.  Erneuern oder installieren Sie das Zertifikat neu

Wenn das Zertifikat abgelaufen oder falsch installiert ist, erneuern Sie es. Auf vielen Linux-Servern ist Let’s Encrypt die einfachste Option:

certbot --nginx -d domain.com -d www.domain.com

 3. Prüfen Sie die abgedeckten Domains

Stellen Sie sicher, dass das Zertifikat genau den aufgerufenen Hostnamen abdeckt, einschließlich www, Subdomains und API-Domains.

 4. Beheben Sie Mixed Content

Ersetzen Sie alle internen http://-Ressourcen durch https://. Das betrifft Bilder, Skripte, CSS-Dateien, Schriftarten, Einbettungen und Canonical-URLs.

 5.  Überprüfen Sie die Serverkonfiguration

Prüfen Sie die SSL-Einstellungen von Nginx oder Apache, Zwischenzertifikate, unterstützte TLS-Versionen und Weiterleitungen von HTTP auf HTTPS.

SSL-Fehler mit CDN: Cloudflare, AWS CloudFront

SSL-Fehler im CDN treten häufig auf, wenn das CDN für Besucher HTTPS verwendet, aber keine sichere Verbindung zum Origin-Server herstellen kann. Verwenden Sie in Cloudflare den Modus „Full (strict)“ mit einem gültigen Origin-Zertifikat. Konfigurieren Sie bei AWS CloudFront das Zertifikat im AWS Certificate Manager und gleichen Sie es mit den richtigen Domain-Aliasen ab.

Wie HTTP-Fehler SEO beeinflussen: Crawl-Budget, Indexierung, Rankings

Suchmaschinen können nur Seiten ranken, die sie erreichen, crawlen und verstehen können. Liefern wichtige URLs HTTP-Fehler, wird das Crawling weniger effizient, die Indexierung instabil, und Nutzer landen möglicherweise auf defekten oder nicht verfügbaren Seiten. Eine zuverlässige Serverumgebung, korrekte Antwortcodes und schnelles NVMe-VPS-Hosting helfen, große Websites bei Traffic-Spitzen, Katalog-Updates und Crawls durch Suchmaschinen erreichbar zu halten.

4xx-Fehler und SEO

4xx-Fehler bedeuten in der Regel, dass eine Seite fehlt, gesperrt ist oder aufgrund von Berechtigungen nicht verfügbar ist. Ein 404 ist unbedenklich, wenn eine Seite absichtlich entfernt wurde. Er wird jedoch zum Problem, wenn wertvolle Produktseiten, Leistungsseiten oder Artikel diesen Code versehentlich zurückgeben.

Ein Fehler 403 Forbidden ist riskanter, weil er Suchmaschinen den Zugriff auf öffentliche Inhalte verwehren kann. Können Crawler wiederholt nicht auf eine URL zugreifen, kann die Seite an Sichtbarkeit verlieren oder aus dem Index fallen.

5xx-Fehler und SEO

5xx-Fehler bedeuten, dass der Server eine gültige Anfrage nicht verarbeiten konnte. Ein kurzer Ausfall ist in der Regel verkraftbar, häufige Fehler 500, 502, 503 oder 504 können jedoch das Crawling reduzieren und die Indexierung verzögern.

Ein geplanter 503 mit Retry-After ist akzeptabel. Wiederholte 503-Fehler bei normalem Traffic signalisieren eine instabile Serverumgebung.

Weiterleitungsketten und ihre Auswirkungen

Weiterleitungsketten zwingen Crawler und Nutzer, mehrere URLs zu durchlaufen, bevor die endgültige Seite lädt. Das verlangsamt das Crawling, verschlechtert die Nutzererfahrung und kann die Wirkung interner Links verringern.

Verfolgen Sie diese Probleme in der Google Search Console über die Indexierungsberichte, die URL-Prüfung, Beispiele für Serverfehler, gesperrte Seiten und Weiterleitungswarnungen. Beginnen Sie mit URLs, die Traffic, Umsatz, Backlinks oder Leads bringen.

Tools zur Diagnose von HTTP-Fehlern

HTTP-Fehler lassen sich leichter beheben, wenn Sie sehen, wo die Anfrage scheitert: im Browser, auf dem Server, im CDN oder in der Anwendung. Nutzen Sie mehrere Tools zusammen, statt sich nur auf die sichtbare Fehlerseite zu verlassen.

Browser-DevTools: Registerkarte „Network“

Mit den Chrome DevTools können Sie Anfragen in Echtzeit untersuchen. Öffnen Sie die Registerkarte „Network“, laden Sie die Seite neu und prüfen Sie Statuscode, Anfrage-URL, Antwort-Header, Weiterleitungen und fehlgeschlagene Ressourcen. Das ist hilfreich, um 403, 404, 502, Mixed Content und Weiterleitungsketten zu finden.

curl und die Kommandozeile verwenden

curl is a fast way to check server responses without a browser:

curl -I https://example.com

Es zeigt den HTTP-Statuscode, Weiterleitungen, Cache-Header und manchmal Details zum CDN oder Server. Für umfassendere SEO-Prüfungen verwenden Sie Google Search Console, Screaming Frog oder Ahrefs Site Audit. Mit einem VPS mit cPanel ist die Diagnose einfacher, weil sich Prüfungen über die Kommandozeile mit Panel-Logs, SSL-Tools, Weiterleitungen und Domain-Einstellungen kombinieren lassen.

Analyse der Server-Logs: Nginx, Apache

Server-Logs zeigen, was hinter dem Fehler tatsächlich passiert ist. Prüfen Sie die Fehler-Logs von Nginx oder Apache auf Upstream-Ausfälle, verweigerten Zugriff und Timeouts.

upstream timed out while reading response header from upstream

Nützliche Filter:

grep "502" /var/log/nginx/error.log

grep "504" /var/log/nginx/error.log

grep "client denied" /var/log/apache2/error.log

Verwenden Sie Browser-Tools, um zu bestätigen, was der Nutzer sieht, Prüfungen über die Kommandozeile, um die unverarbeitete Serverantwort zu verifizieren, und Server-Logs, um den genauen technischen Grund für den Fehler zu finden.

Fehlerbehebung: kurzer Entscheidungsbaum

Verwenden Sie diesen kurzen Entscheidungsbaum, wenn Sie schnell einen ersten Schritt brauchen. Bei einem 4xx-Fehler prüfen Sie Zugriff, Berechtigungen und gesperrte URLs. Bei einem 5xx-Fehler prüfen Sie Serverlast, Upstream-Dienste, DNS, Firewall und CDN-Konfiguration.

Wir empfehlen, mit den sichersten Prüfungen zu beginnen und dann zu Server-Logs, Firewall-Regeln, CDN-Einstellungen und Backend-Optimierung überzugehen, falls der Fehler immer wieder auftritt.

FAQ

Was ist der Unterschied zwischen 502 Bad Gateway und 504 Gateway Timeout?

Ein 502 bedeutet, dass das Gateway vom Upstream-Server eine ungültige Antwort erhalten hat. Ein 504 bedeutet, dass der Upstream-Server nicht rechtzeitig geantwortet hat.

Kann ein Fehler 403 Forbidden durch ein Problem mit dem SSL-Zertifikat verursacht werden?

In der Regel nicht. Ein 403 ist ein Problem mit Zugriff oder Berechtigungen. SSL-Probleme zeigen sich normalerweise als Zertifikatswarnungen oder TLS-Verbindungsfehler, bevor die Seite lädt.

Wie wirken sich HTTP-Fehler auf die Google-Rankings meiner Website aus?

Häufige 4xx- und 5xx-Fehler können das Crawling blockieren, die Indexierung verzögern, Seiten aus den Suchergebnissen entfernen und die Nutzererfahrung beeinträchtigen.

Was sollte ich tun, wenn auf meiner WordPress-Website ein 503-Fehler erscheint?

Prüfen Sie den Wartungsmodus, deaktivieren Sie kürzlich aktualisierte Plugins, überprüfen Sie die Serverlast und untersuchen Sie die Logs von PHP oder Webserver.

Warum erhalte ich immer wieder SSL-Zertifikatsfehler, obwohl mein Zertifikat gültig ist?

Häufige Ursachen sind fehlende Zwischenzertifikate, nicht abgedeckte Domains, Probleme mit dem SSL-Modus im CDN, Mixed Content oder zwischengespeicherte Browser- und DNS-Daten.

Ist ein 500 Internal Server Error dasselbe wie ein 502 Bad Gateway?

Nein. Ein 500 bedeutet, dass der Server intern versagt hat. Ein 502 bedeutet, dass ein Gateway von einem anderen Server eine fehlerhafte Antwort erhalten hat.

Wie kann ich meine Website automatisch auf HTTP-Fehler überwachen?

Nutzen Sie Uptime-Monitoring, Google Search Console, Alarme auf Basis der Server-Logs, Screaming Frog, Ahrefs Site Audit oder eigene Prüfungen mit curl und cron.