HTTP-Statuscodes

Statuscodes mit curl prüfen

Der Browser verrät den Statuscode nur in den Entwicklerwerkzeugen und speichert Weiterleitungen zwischen. Mit curl bekommst du die ungeschönte Antwort des Servers. Nur die Kopfzeilen inklusive Statuszeile:

curl -sI https://example.de/seite/

Eine ganze Liste von URLs auf einmal, etwa nach einem Umzug (eine URL pro Zeile in urls.txt):

while read -r u; do
  printf '%s %s\n' "$(curl -s -o /dev/null -w '%{http_code}' "$u")" "$u"
done < urls.txt

Welche Codes dein Server tatsächlich ausliefert, zeigt eine Auswertung des Access-Logs. Der Pfad gilt für Plesk, die Spalte 9 für das übliche Combined-Logformat:

awk '{print $9}' /var/www/vhosts/example.de/logs/access_ssl_log | sort | uniq -c | sort -rn

404 oder 410?

Beide sagen „gibt es nicht“. 404 lässt offen, ob die Seite wiederkommt, 410 sagt ausdrücklich, dass sie dauerhaft weg ist. Google behandelt beide ähnlich, entfernt 410-URLs aber meist etwas schneller aus dem Index. Für normale gelöschte Seiten ist 404 völlig in Ordnung. 410 lohnt sich, wenn viele unerwünschte URLs schnell verschwinden sollen, typisch nach einem Hack mit eingeschleusten Spam-Seiten. Hat eine alte Seite einen inhaltlichen Nachfolger, ist eine 301-Weiterleitung besser als beides.

Soft-404: Fehlerseite mit Status 200

Eine Soft-404 ist eine Seite, die „nicht gefunden“ anzeigt, aber mit Status 200 ausgeliefert wird. Google erkennt solche Seiten und meldet sie in der Search Console. Häufige Ursachen: eigene Fehlerseiten, die per Weiterleitung statt per ErrorDocument eingebunden sind, leere Kategorie- oder Suchseiten, und das pauschale Umleiten aller alten URLs auf die Startseite. Prüfe mit curl, ob eine nicht existierende URL wirklich 404 liefert.

Wartung richtig ankündigen: 503 mit Retry-After

Während Wartungsarbeiten sollte der Server 503 Service Unavailable liefern, nicht 200 mit einem Hinweistext und nicht 404. Der Header Retry-After sagt Suchmaschinen, wann sie es wieder versuchen sollen (in Sekunden oder als Datum). So bleibt das Ranking unangetastet. Ein Beispiel für nginx:

# nginx (Plesk: Zusätzliche nginx-Direktiven): Wartungsmodus,
# solange die Datei .maintenance-on im Webroot liegt
if (-f $document_root/.maintenance-on) {
    return 503;
}
add_header Retry-After 3600 always;

WordPress liefert während Updates selbst einen 503 mit Retry-After, solange die Datei .maintenance im Webroot liegt. Bleibt sie nach einem abgebrochenen Update liegen, ist die Seite dauerhaft im Wartungsmodus: Datei löschen, fertig.

5xx-Fehler auf dem Server eingrenzen

• 500: zuerst das Fehlerlog der Domain (/var/www/vhosts/example.de/logs/error_log in Plesk) und das PHP-Log. Bei WordPress hilft WP_DEBUG_LOG.
• 502: läuft PHP-FPM? systemctl status plesk-php83-fpm (Version anpassen), dazu journalctl -u plesk-php83-fpm --since "1 hour ago".
• 503 und 504: sind alle PHP-FPM-Worker belegt? Im FPM-Log steht dann server reached pm.max_children. Langsame Abfragen findet das MySQL-Slow-Log.