HTTP-200-Statuscode

Was diese Prüfung macht

Schickt einen GET-Request an die auditierte URL und liest den finalen HTTP-Statuscode. Die Prüfung besteht nur bei 200 OK. Sie meldet:

• 3xx-Weiterleitungen (die URL ist nicht die kanonische)
• 4xx-Fehler (404 Seite nicht gefunden, 410 weg, 403 verboten)
• 5xx-Fehler (Server-Crash, Gateway-Timeout)

Der Crawler folgt einer begrenzten Anzahl von Weiterleitungen, damit er dir auch den finalen Status am Ende der Kette nennen kann.

Warum es zählt

Suchmaschinen und KI-Crawler behandeln Nicht-200-Antworten als “diese URL nicht indexieren.”

• 301/302 — die URL rankt nicht; das Redirect-Ziel rankt. Wenn du example.com/old-post geteilt hast und sie via 301 auf example.com/new-post leitet, zeigen jeder Backlink, jeder Social-Share, jede Featured-Snippet-Auswahl auf eine URL, die Google innerhalb von Wochen aus dem Index nimmt.
• 404 / 410 — die URL wird aus dem Index entfernt. Wenn das versehentlich passiert ist (Tippfehler in einer Redirect-Regel, fehlender Trailing Slash, gelöschte Seite mit noch bestehenden Backlinks), verlierst du still Traffic.
• 500 / 502 / 503 / 504 — Google versucht es erneut und deindexiert nach einigen Tagen mit Fehlern. Schlimmer: Googlebot reduziert das Crawl-Budget für die gesamte Domain.

Eine Seite, die etwas anderes als 200 zurückgibt, ist unsichtbar.

So behebst du es

Schau zuerst genau, was der Server zurückgibt. curl -I zeigt die volle Kette:

curl -ILso /dev/null -w "%{http_code} %{url_effective}\n" https://example.com/page

Füge -L und -w "%{http_code} -> %{redirect_url}\n" hinzu, um jeden Hop zu kartieren. Siehst du mehrere 30x-Zeilen vor dem finalen 200, hast du eine Weiterleitungskette — auch wert, behoben zu werden.

Wenn die URL 200 zurückgeben sollte, aber 301/302 liefert:

Häufige Übeltäter:

• WWW- oder Trailing-Slash-Mismatch — example.com/page leitet via 301 auf example.com/page/. Wähle eine kanonische Form (mit oder ohne Slash) und verlinke konsistent darauf. Verlinke intern nicht auf die weiterleitende Form.
• HTTPS-Upgrade — http://example.com/page leitet via 301 auf https://example.com/page. Erwartet, aber stelle sicher, dass alle internen Links und die Sitemap HTTPS nutzen, damit Crawler nie auf den Redirect treffen. Siehe HTTP auf HTTPS weiterleiten.
• Locale-Redirect auf dem Root-Pfad — / leitet via 302 auf /en/ basierend auf Accept-Language. Googlebot crawlt aus den USA mit en-US, also wird / zu einer Weiterleitung auf /en/. Mach entweder / so, dass es direkt englischen Inhalt liefert (mit hreflang für andere Locales) oder nutze einen 302 plus x-default-hreflang.

Wenn die URL versehentlich 404 zurückgibt:

• Prüfe die Routing-Konfig (nginx try_files, Next.js [...slug].tsx, Astro getStaticPaths).
• Prüfe Groß-/Kleinschreibung — /About und /about sind auf Linux-Servern verschiedene URLs.
• Prüfe die Datenbank — eine CMS-Seite, die auf “Entwurf” steht, gibt in den meisten Templates 404 zurück.

Ist die Seite tatsächlich weg, gib 410 Gone statt 404 zurück — Google deindexiert 410er etwa doppelt so schnell. Richte eine eigene 404-Seite ein, damit die Antwort für Menschen trotzdem hilfreich ist.

Wenn die URL 5xx zurückgibt:

Das ist ein Server-Problem, kein Konfigurationsproblem. Prüfe die Anwendungs-Logs zum Zeitpunkt, an dem MetricSpot das Audit ausgeführt hat. Häufige Ursachen: Datenbank-Connection-Pool erschöpft, Out-of-Memory bei einer Serverless-Funktion, Drittanbieter-API, von der die Seite abhängt, hat ein Timeout zurückgegeben.

Rezepte:

# nginx — explizit 200 für eine Route, kein Redirect
location = /pricing {
  try_files /pricing.html =404;
}

// Express — 410 für dauerhaft entfernte URLs zurückgeben
app.get("/old-product/:id", (req, res) => res.status(410).send("Gone"));

// Next.js (App Router) — 410 aus einem Route-Segment zurückgeben
import { notFound } from "next/navigation";
export default async function Page({ params }) {
  const product = await getProduct(params.id);
  if (!product) notFound(); // gibt standardmäßig 404 zurück
  // ...
}

Für statische Astro-Seiten muss ein 410 von deinem Host ausgeliefert werden (nginx return 410; oder Cloudflare Worker), da Astros statische Ausgabe nur 404er für fehlende Routen emittiert.

Häufig gestellte Fragen

Ist 301 immer schlecht?

Nein. Ein 301 ist korrekt, wenn die URL tatsächlich umgezogen ist — alter Slug auf neuen Slug, HTTP auf HTTPS, www auf non-www. Schlecht ist es nur, wenn MetricSpot die URL auditiert, die du als kanonisch beabsichtigst, und sie via 301 wegspringt — das bedeutet, du hast uns (und Google, und jedem Backlink) die falsche URL gegeben.

Soll ich für fehlende Seiten 200 mit einer “nicht gefunden”-Nachricht zurückgeben?

Nein. 200 mit “Seite nicht gefunden”-Body-Inhalt zurückzugeben heißt Soft 404. Google erkennt das (anhand des Content-Musters) und behandelt es ohnehin als 404, aber es verwirrt Analytics und bläht dein Crawl-Budget auf. Gib immer den korrekten HTTP-Status zurück.

Was ist mit 304 Not Modified?

304 ist eine erfolgreiche bedingte Antwort — der Browser hat die Seite bereits im Cache. Kein Problem; MetricSpot sendet keine If-Modified-Since-Header, also wirst du sie normalerweise nicht in unserem Crawl sehen. Wenn doch, ist dein CDN beim Cachen von Antworten auf nicht-authentifizierte GETs zu aggressiv.