HTTP Status Codes für SEO: 301 vs 302, Soft 404s und Redirect-Chains [Praxis-Guide]

HTTP Status Codes für SEO: Der ultimative Praxis-Guide

HTTP Status Codes. Das Thema, bei dem selbst Entwickler ungerne zugeben, dass sie die ganze Zeit falsch umgeleitet haben. Spoiler: Du wahrscheinlich auch.

Hier ist die harte Realität: Ein einziger falscher 302 statt 301 kostet dir langfristig Tausende von Euro in verlorenen SEO-Rankings. Ein Redirect Chain mit 5 Hops verschlingt 85 % deines Crawl Budget und schadet den Core Web Vitals. Und Soft 404s? Die sind das stille Gift in deiner Sitemap — Google indexiert sie, nennt sie aber schlicht “nicht hilfreich” und bestraft dich dafür.

Lass mich dir zeigen, wie du das Ganze durchschaust — mit curl, Screaming Frog und der Google Search Console.

Komplette HTTP Status Code Referenz für SEO

Bevor wir in die Details gehen, hier die komplette Übersicht aller Status Codes, die für technisches SEO relevant sind. Alles andere kannst du vergessen.

2xx — Erfolg

3xx — Redirects

4xx — Client-Fehler

5xx — Server-Fehler

200 OK — Nicht immer so OK wie du denkst

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

Das ist normal. Das ist gut. Google indexiert die URL, crawlt den Content, folgt den Links. Wenn 90 % deiner URLs 200er sind, läuft dein Setup.

Aber nicht alle 200er sind gleich. Eine 200er-Response mit leerer HTML oder nur JavaScript-Placeholder? Das ist technisch korrekt, SEO-technisch aber eine Katastrophe. Google sieht das. Screaming Frog sieht das. Du solltest es auch sehen.

Praktischer Check mit curl:

curl -s -o /dev/null -w "%{http_code} %{size_download} %{time_total}s\n" https://example.com/page

Dieser Befehl gibt dir drei Werte: Status Code, Download-Größe in Bytes und Gesamtzeit. Eine 200er-Response mit 500 Bytes ist verdächtig — normaler HTML-Content hat mindestens 5-10 KB. Das ist schneller als -i, wenn du viele URLs prüfen willst.

Für Batch-Checks über eine URL-Liste:

while IFS= read -r url; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "$url")
  echo "$code $url"
done < urls.txt | grep -v "^200"

Alles, was nicht 200 ist, landet in der Ausgabe. Simpel, schnell, effektiv.

Redirects: 301 vs 302 vs 307 vs 308

Hier wird’s ernst. Die Unterschiede sind klein aber existenziell für deine Rankings.

301 Moved Permanently — Das ist, was du willst

HTTP/1.1 301 Moved Permanently
Location: https://example.com/neue-url
Cache-Control: public, max-age=31536000

301 sagt Google: “Diese URL existiert nicht mehr. Für immer. Link-Juice fließt zur neuen URL.” Klingt einfach. Aber:

• Der Browser cached 301er bis zu 1 Jahr (max-age=31536000)
• Google verarbeitet 301er nicht augenblicklich — es dauert 6 bis 7 Monate, bis die alte URL vollständig aus dem Index verschwindet
• Bei großen Migrations-Projekten mit 300+ Redirects verlierst du Links durch Rundungseffekte
• Google überträgt ca. 95-99 % des Link-Juice — nicht 100 %. Bei jeder Chain-Stufe geht etwas verloren.

Wann 301? Permanente Umzüge. Domain-Migrations. URL-Struktur-Überarbeitungen. HTTPS-Umstellung. Slash/Non-Slash Normalisierung. www/non-www Konsolidierung.

In .htaccess:

<IfModule mod_rewrite.c>
    RewriteEngine On

    # Einzelne URL umleiten
    RewriteRule ^alte-url/?$ https://example.com/neue-url [R=301,L]

    # Ganzes Verzeichnis umleiten
    RewriteRule ^alter-bereich/(.*)$ https://example.com/neuer-bereich/$1 [R=301,L]

    # www zu non-www (kanonisch)
    RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
    RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

    # HTTP zu HTTPS
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

    # Trailing Slash erzwingen
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_URI} !(.*)/$
    RewriteRule ^(.*)$ https://example.com/$1/ [R=301,L]
</IfModule>

In nginx:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;

    # Einzelne URL
    location = /alte-url {
        return 301 https://example.com/neue-url;
    }

    # Ganzes Verzeichnis mit Regex
    location ~ ^/alter-bereich/(.*)$ {
        return 301 https://example.com/neuer-bereich/$1;
    }

    # Map-Directive für große Redirect-Listen (performanter als viele location-Blöcke)
    # In http-Block definieren:
    # map $request_uri $redirect_target {
    #     /alte-seite-1   /neue-seite-1;
    #     /alte-seite-2   /neue-seite-2;
    # }
    if ($redirect_target) {
        return 301 $redirect_target;
    }
}

Nginx-Tipp: Bei mehr als 50 Redirects lohnt sich die map-Directive. Sie wird beim Server-Start einmal in eine Hash-Tabelle geladen und ist O(1) — egal ob du 50 oder 50.000 Redirects hast. Einzelne location-Blöcke werden sequentiell ausgewertet.

302 Found — Der Falschparker

HTTP/1.1 302 Found
Location: https://example.com/temporaer

302 ist temporär. Google behandelt 302er anders: Der ursprüngliche Link bleibt im Index. Der Link-Juice fließt nicht zur neuen URL. Das ist das Problem.

Aber hier kommt’s krass: Viele CMS (ich schau dich an, schlechte WordPress-Plugins) nutzen 302er als “Standard-Redirect”. Deshalb sehen wir in der Praxis ständig:

• Eine Seite rankt unter der alten URL
• Sie wird per 302 auf die neue URL redirected
• Die neue URL rankt nicht, weil Google die alte als “Haupt-URL” weiter sieht
• Traffic bleibt bei der alten URL — das ist technisch 200er, aber mit kaputtem Canonical oder JS-Redirect

Wann 302? Wirklich nur temporär. A/B-Tests. Wartungsarbeiten. Geo-Targeting. Und das bitte nur Tage, nicht Monate. Faustregel: Wenn der Redirect länger als 2 Wochen steht, sollte er ein 301 sein.

Reales Beispiel: Ein E-Commerce-Kunde hatte 1.200 Produkt-URLs, die während einer Rabattaktion per 302 auf Aktionsseiten weitergeleitet wurden. Die Aktion lief 3 Monate. Ergebnis: Google indexierte die Aktionsseiten nicht (weil 302 = temporär), die originalen Produktseiten verloren Rankings, weil sie keinen Content mehr lieferten. Doppelter Verlust.

# Alle Redirects einer URL-Kette anzeigen
curl -v -L https://example.com/seite 2>&1 | grep -E "< HTTP|< location"

Mit -L folgt curl automatisch Redirects. Du siehst dann alle HTTP-Codes in der Chain.

307 vs 308 — Die unterschätzten Cousins

307 und 308 sind 301/302-Replacements für das moderne Web. Der Unterschied: Sie behalten die HTTP-Method bei.

301/302: Können die HTTP-Method ändern (POST wird zu GET)
307/308: Behalten die HTTP-Method bei

Für SEO: Irrelevant. Google behandelt 308 wie 301 und 307 wie 302. Für APIs und Formulare? Kritisch. Wenn du POST-Anfragen redirecten willst, nimm 307/308.

Soft 404s: Das stille Gift in deiner Sitemap

Soft 404s sind das gefährlichste Status-Code-Problem, weil sie unsichtbar sind. Der Server antwortet mit 200 OK, aber der Content sagt “Seite nicht gefunden” oder ist quasi leer.

Google erkennt Soft 404s algorithmisch und markiert sie in der Search Console als “Soft 404” unter Seiten > Nicht indexiert. Das Problem: Du verschwendest Crawl Budget für URLs, die Google ohnehin nicht indexiert.

Wie Soft 404s entstehen

1. Fehlerhafte Fehlerseiten: Dein CMS zeigt eine “Seite nicht gefunden”-Nachricht, antwortet aber mit 200 statt 404
2. Leere Kategorieseiten: Filter-Kombination ohne Produkte, aber mit 200 OK
3. Paginierung ohne Content: Seite 47 eines Blogs hat keine Artikel, liefert aber 200 OK mit leerem <main>
4. JavaScript-SEO-Probleme: SPA liefert 200 OK mit <div id="app"></div>, aber das JS-Rendering schlägt fehl
5. Parametrisierte URLs: ?color=lila&size=xxxl existiert nicht als Variante, Shop zeigt trotzdem Template

Praxisbeispiel: Bei einem Audit einer Next.js-basierten Tourismus-Plattform mit knapp 5.000 URLs fanden wir 230 Soft-404-Seiten, die mit HTTP 200 antworteten und nur eine “Sorry”-Meldung enthielten. Die Ursache war ein Catch-All-Routing im Framework, das bei nicht existierenden Pfaden kein 404 auslöste. Parallel entdeckten wir 316 interne 3xx-Redirects, davon 7 reine JavaScript-Redirects, die Googlebot nicht zuverlässig verarbeitet. Beide Probleme zusammen verschlangen erhebliches Crawl-Budget, ohne dass eine einzige sinnvolle Seite indexiert wurde.

Soft 404s erkennen

In der Google Search Console: Seiten > Nicht indexiert > “Soft 404”. Dort listet Google alle URLs auf, die es als Soft 404 klassifiziert hat. Exportiere die Liste und analysiere die Muster.

In Screaming Frog:

1. Crawl durchführen mit JavaScript-Rendering (Configuration > Spider > JavaScript Rendering: Chrome)
2. Filter: Status Code = 200
3. Sortiere nach Word Count aufsteigend
4. Alles unter 100 Wörtern ist verdächtig
5. Prüfe manuell, ob Content vorhanden ist oder nur ein Template-Shell

Mit curl und grep:

# Prüfe, ob eine URL echten Content liefert oder nur ein Shell ist
curl -s https://example.com/verdaechtige-seite | \
  grep -c '<p\|<h[1-6]\|<article\|<main'

# 0 = kein semantisches HTML = wahrscheinlich Soft 404

Soft 404s fixen

Die Lösung ist immer eine von drei Optionen:

1. Echten 404 oder 410 zurückgeben. Wenn die Seite keinen Content hat, sag das auch per Status Code.
2. Content hinzufügen. Wenn die Kategorieseite leer ist, zeige verwandte Produkte oder entferne die Seite aus der internen Verlinkung.
3. Auf die nächste sinnvolle Seite per 301 redirecten. Ein leeres /produkte/shirts/lila/ kann per 301 auf /produkte/shirts/ verweisen.

# .htaccess: Leere Parameterkombinationen auf Kategorie redirecten
RewriteCond %{QUERY_STRING} color=lila&size=xxxl
RewriteRule ^produkte/shirts/ /produkte/shirts/? [R=301,L]

Das ? am Ende der Ziel-URL entfernt den Query String — sonst hängt Apache ihn erneut an.

Redirect Chains und Loops — Erkennung und Bereinigung

Das Problem mit Redirect Chains

Szenario: Du migrierst deine Domain von alt.com zu neu.de. Dein Praktikant schreibt dann:

alt.com/page → temp.com/page → neu.de/page → neu.de/seite

Das ist eine 3-Hop-Chain. Google folgt maximal 10 Hops, bricht aber de facto nach 3-5 schon ab, wenn das Crawl Budget knapp ist.

Real-world Data: Wir haben bei einem E-Commerce-Kunden mit 150.000 Produktseiten eine 4-Hop-Redirect-Chain entdeckt (Domain-Migration + URL-Struktur-Rewrite + Parameter-Cleaning). Ergebnis: 40 % weniger Crawls pro Woche. Die schwächeren Kategorieseiten wurden gar nicht mehr gecrawlt.

Die Regel: 0 Hops, wenn möglich. 1 Hop, wenn nötig. Alles über 2 ist fahrlässig.

Redirect Loops erkennen

Redirect Loops sind schlimmer als Chains — der Browser hängt in einer Endlosschleife:

/seite-a → 301 → /seite-b → 301 → /seite-a → 301 → ...

Der Browser bricht nach ~20 Loops ab und zeigt “ERR_TOO_MANY_REDIRECTS”. Google gibt sofort auf.

# Redirect Chain/Loop manuell debuggen (max 10 Hops)
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" \
  --max-redirs 10 -L https://example.com/verdaechtige-url

# Jeden einzelnen Hop anzeigen
curl -s -D - -o /dev/null -L https://example.com/seite 2>&1 | \
  grep -E "^HTTP/|^location:" -i

Chains systematisch bereinigen

Screaming Frog: Reports > Redirect Chains. Dort siehst du jede Chain mit allen Hops. Exportiere die Liste nach Excel, sortiere nach Anzahl Hops (absteigend) und arbeite die schlimmsten zuerst ab.

Ahrefs Site Audit: Unter Issues > Redirects findest du Redirect Chains automatisch aufgelistet. Exportiere sie und priorisiere nach Backlink-Stärke — Seiten mit den meisten eingehenden Links zuerst fixen.

Die Lösung ist immer gleich: Jeden Redirect direkt auf das finale Ziel zeigen lassen. Aus A → B → C → D wird A → D, B → D, C → D. Kein Zwischenschritt.

404 vs 410 — Strategischer Einsatz

404 Not Found — “Vielleicht kommt die Seite wieder”

HTTP/1.1 404 Not Found
Content-Type: text/html

404 sagt Google: “Diese Seite gibt’s gerade nicht.” Google cached 404er und crawlt die URL über Wochen hinweg erneut, bevor sie aus dem Index fällt. Das kann nützlich sein, wenn du eine Seite temporär offline nimmst.

Problematisch wird’s, wenn 404-Seiten keine hilfreiche Fehlerseite liefern. Eine gute 404-Seite enthält:

• Suchfeld
• Links zu den wichtigsten Kategorien
• Hinweis, dass die Seite nicht existiert
• Einen echten 404 Status Code (nicht 200!)

410 Gone — “Vorbei. Für immer.”

HTTP/1.1 410 Gone

410 sagt Google: “Diese Seite wird nie wieder kommen. Bitte aus dem Index entfernen.”

Google deindexiert 410er deutlich schneller — innerhalb von ein bis zwei Wochen statt ein bis zwei Monaten bei 404. Das ist Gold wert, wenn du bewusst Content entfernen willst.

Wann 410 statt 404?

• Alte Features oder Produkte, die permanent entfernt wurden
• EOL-Seiten nach einer Übergangszeit mit 301
• Fehlerhafte oder duplizierte URLs, die nie existieren sollten
• Spam-URLs, die durch Hacking entstanden sind — schnelle Deindexierung ist hier kritisch

Wann 301 statt 410?

• Wenn es eine sinnvolle Nachfolge-URL gibt — immer 301.
• Bei Produkten, die durch ein Nachfolgemodell ersetzt wurden
• Bei umstrukturierten Kategorien

Wann 404 statt 410?

• Wenn du unsicher bist, ob die Seite zurückkommt
• Temporäre Offline-Phasen

# nginx: 410 für spezifische URL-Muster
location ~ ^/alte-kampagne/ {
    return 410;
}

# 410 für eine Liste bekannter URLs via map
map $request_uri $is_gone {
    /veraltetes-produkt-1  1;
    /veraltetes-produkt-2  1;
    /spam-seite-gehackt    1;
    default                0;
}

server {
    if ($is_gone) {
        return 410;
    }
}

Server-Fehler: 500, 502, 503 und das Ranking-Blutbad

500 Internal Server Error

HTTP/1.1 500 Internal Server Error

Das passiert, wenn dein Server abstürzt. Syntax-Fehler in PHP. Out-of-Memory. Datenbank offline.

Google sieht 500er und denkt: “Server ist down. Vielleicht temporär.” Dann crawlt es später nochmal. Passiert es 3x in 2 Wochen: raus aus dem Index — und zwar nicht nur die betroffene URL, sondern Google drosselt das Crawling der gesamten Domain.

Das Kranke: Du behebst den Fehler, aber Google crawlt deine URL erst nach Wochen nochmal. Rankings bleiben unten.

502 Bad Gateway — Der Proxy-Albtraum

502 tritt auf, wenn ein Reverse Proxy (nginx, Cloudflare, AWS ALB) keine Antwort vom Backend bekommt. Häufig bei:

• PHP-FPM Timeout
• Node.js-Prozess abgestürzt
• Docker-Container neu gestartet
• Origin Server unter Last

Für Google ist 502 = 500. Gleicher Effekt, gleiche Konsequenzen.

503 Service Unavailable — Der saubere Weg

HTTP/1.1 503 Service Unavailable
Retry-After: 3600

503 ist das, was du bei geplanten Wartungsarbeiten zurückgeben solltest. Mit dem Retry-After-Header sagst du: “Komm in 3600 Sekunden (1 Stunde) wieder.”

Google respektiert das. Die URL bleibt im Index. Rankings fallen nicht. Die richtige Konfiguration:

# .htaccess: Wartungsmodus mit 503 und Retry-After
<IfModule mod_rewrite.c>
    RewriteEngine On
    # Prüfe, ob maintenance.flag existiert
    RewriteCond %{DOCUMENT_ROOT}/maintenance.flag -f
    # Eigene IP ausnehmen (damit du testen kannst)
    RewriteCond %{REMOTE_ADDR} !^123\.456\.789\.
    # Nicht auf die Wartungsseite selbst anwenden
    RewriteCond %{REQUEST_URI} !^/wartung\.html$
    RewriteRule ^.*$ /wartung.html [R=503,L]
    Header always set Retry-After "3600"
    Header always set Cache-Control "no-store, no-cache, must-revalidate"
</IfModule>
ErrorDocument 503 /wartung.html

Wichtig: Verwende niemals 200 OK für Wartungsseiten. Das ist Soft 404 Light — Google indexiert deine Wartungsseite als echten Content.

429 Too Many Requests — Rate Limiting

Ein oft übersehener Status Code. Wenn dein Server Googlebot mit 429 antwortet, drosselt Google das Crawling deiner gesamten Domain. Das passiert bei:

• Aggressivem Rate Limiting ohne Bot-Whitelist
• WAF-Regeln (Cloudflare, Sucuri), die Googlebot als Angreifer klassifizieren
• Shared Hosting mit niedrigen Request-Limits

Prüfe deine Server-Logs: Wenn Googlebot 429er bekommt, whitelist seine IP-Ranges oder erhöhe das Rate Limit für verifizierte Crawler.

Firebase Hosting und Vercel: Redirects in modernen Stacks

Nicht jeder arbeitet mit Apache oder nginx. Hier die Konfiguration für JAMstack-Deployments:

Firebase Hosting (firebase.json)

{
  "hosting": {
    "redirects": [
      {
        "source": "/alte-url",
        "destination": "/neue-url",
        "type": 301
      },
      {
        "source": "/alter-bereich/:slug",
        "destination": "/neuer-bereich/:slug",
        "type": 301
      },
      {
        "source": "/kampagne-2024/**",
        "destination": "/archiv/kampagne-2024",
        "type": 301
      }
    ]
  }
}

Vercel (vercel.json)

{
  "redirects": [
    {
      "source": "/alte-url",
      "destination": "/neue-url",
      "statusCode": 301
    },
    {
      "source": "/blog/:slug",
      "destination": "/artikel/:slug",
      "statusCode": 301
    }
  ]
}

Next.js (next.config.js)

module.exports = {
  async redirects() {
    return [
      {
        source: '/alte-url',
        destination: '/neue-url',
        permanent: true, // 301
      },
      {
        source: '/temp-aktion',
        destination: '/angebote',
        permanent: false, // 302
      },
    ]
  },
}

Tipp: Bei Next.js ist permanent: true = 308, nicht 301. Google behandelt beides gleich, aber wenn du explizit 301 brauchst (z.B. für ältere Clients), nutze Middleware oder eine serverseitige Lösung.

hreflang und Status Codes — Die Falle bei internationalen Seiten

Szenario: Du hast internationale Seiten mit hreflang. Und dann:

<!-- Deutsche Seite: 200 OK -->
<link rel="alternate" hreflang="de" href="https://example.de/produkt" />
<link rel="alternate" hreflang="en" href="https://example.de/en/product" />

Aber die englische Version antwortet mit 301 auf example.de/en/product > example.com/product.

Google ist verwirrt. Die hreflang zeigt auf 301er. Die 301er führt zu einer anderen Domain. Hreflang broken, Rankings leiden in beiden Sprachversionen.

Die Search Console zeigt hreflang-Warnungen nicht immer. Screaming Frog aber schon: Reports > Hreflang > Status Code Audit. Dort siehst du URLs, die mit 404, 301 oder 410 antworten, während hreflang auf sie zeigt.

Die Regel: Alle hreflang-URLs müssen 200 OK sein. Keine Redirects. Keine 404er. Punkt.

JavaScript und der Status Code Wahnsinn

Single-Page-Applications (React, Vü, Angular) laden den Content über JavaScript nach. Das initiale HTML antwortet mit 200 OK. Aber Google sieht erst nach dem Rendering den echten Content.

Das Problem: Wenn das JS fehlschlägt, sieht Google trotzdem 200 OK. Soft 404. Wieder Crawl-Budget weg.

Für JavaScript-SEO ist das kritisch. Mit curl siehst du nur das initiale HTML:

# Was Google beim ersten Crawl sieht (ohne JS-Rendering)
curl -s https://example.com/spa-page | grep -o '<body[^>]*>.*</body>' | wc -c

# Unter 500 Bytes? Das ist nur ein App-Shell. Soft 404 Risiko.

Debugging: Nutze Screaming Frog mit JavaScript-Rendering (Configuration > Spider > JavaScript Rendering: Chrome). Dann crawlt Screaming Frog die Seite nach dem Rendering und erkennt, ob Content vorhanden ist.

Alternativ: Google’s Rich Results Test (search.google.com/test/rich-results) zeigt dir den gerenderten HTML-Output, wie Google ihn sieht.

Praktischer Debugging-Workflow: Von der Entdeckung zur Lösung

So sieht ein systematischer Status-Code-Audit aus, den wir bei jedem Kunden durchführen:

Schritt 1: Crawl mit Screaming Frog

1. Screaming Frog öffnen
2. URL eingeben (z. B. example.com)
3. Configuration > Spider > JavaScript Rendering: Chrome
4. Configuration > Spider > Crawl Limit je nach Seitengröße
5. Start > Crawl durchführen
6. Warte bis "Finished" angezeigt wird

Schritt 2: Status Code Distribution prüfen

Ziel: Mindestens 90 % der internen URLs sollten 200 OK sein.

Tab "Internal" > Filter nach Status Code
- 200: Sollte >90 % sein
- 301: Jeder einzelne prüfen -- zeigt er auf eine 200er URL?
- 302: Sind das wirklich temporäre Redirects?
- 404: Gibt es interne Links, die auf 404er zeigen? (= Broken Links)
- 5xx: Sofort fixen.

Schritt 3: Redirect Chains identifizieren

Menu > Reports > Redirect Chains
Exportiere die Liste.
Sortiere nach Anzahl Hops (absteigend).
Priorisiere nach eingehenden Links (Ahrefs-Daten).

Schritt 4: Soft 404s finden

Tab "Internal" > Filter: Status Code = 200
Sortiere nach Word Count (aufsteigend)
Alles unter 100 Wörtern: Manuell prüfen
Vergleiche mit GSC > Seiten > Nicht indexiert > "Soft 404"

Schritt 5: Google Search Console abgleichen

Screaming Frog > Menu > Configuration > API Access > Google Search Console
Login mit deinem GSC-Konto

Danach kannst du in Screaming Frog direkt sehen, welche gecrawlten URLs Google auch indexiert hat. Discrepancies sind Gold wert:

• URL mit 200 OK, aber nicht indexiert? Content-Problem oder Soft 404
• URL mit 404, aber noch indexiert? GSC-Abdeckungsbericht prüfen
• URL mit 301, aber alte URL noch im Index? Redirect-Verarbeitung dauert noch

Schritt 6: Laufendes Monitoring einrichten

Screaming Frog crawlt einmalig. Für kontinuierliches Monitoring:

Ahrefs Site Audit: Crawlt deine Seite wöchentlich und zeigt dir unter “Issues” alle Status-Code-Probleme sortiert nach Schweregrad. Besonders nützlich: Ahrefs erkennt Redirect Loops (301 > 302 > 301 > …), die Screaming Frog manchmal übersieht.

Google Search Console Alerts: Aktiviere E-Mail-Benachrichtigungen. Die GSC schickt dir automatisch eine Mail, wenn plötzlich viele 404-Fehler oder Crawling-Anomalien auftreten.

GTM-basiertes Soft-404-Monitoring:

// Google Tag Manager: Custom HTML Tag
// Feuert, wenn die Seite weniger als 100 Wörter hat
(function() {
  var wordCount = document.body.innerText.split(/\s+/).length;
  if (wordCount < 100) {
    dataLayer.push({
      'event': 'soft_404_detected',
      'page_url': window.location.href,
      'word_count': wordCount
    });
  }
})();

Damit kannst du in GA4 ein Event tracken, das dir automatisch Soft 404s meldet — ohne manuelles Crawling.

Häufige Migrations-Fehler mit Redirects

Wir haben dutzende Domain-Migrationen begleitet. Diese Fehler sehen wir immer wieder:

Fehler 1: 302 statt 301 bei permanenter Migration

Das CMS oder der Entwickler setzt den Default-Redirect auf 302. Bei einer Domain-Migration ist das fatal: Google behält die alte Domain im Index, Link-Juice fließt nicht. Prüfe nach jeder Migration sofort mit curl:

curl -s -o /dev/null -w "%{http_code}" https://alte-domain.de/
# Muss 301 zeigen, nicht 302

Fehler 2: Interne Links nicht aktualisiert

Du schreibst 50.000 301er-Redirects. Aber im HTML, im Menü, in der Sitemap, in den Canonical Tags steht noch die alte Domain. Ergebnis: Jeder interne Klick erzeugt einen Redirect. Google crawlt deine Seite und sieht nur Redirects statt Content.

Lösung: Interne Links immer auf die finale URL setzen. Redirects sind für externe Links und Bookmarks, nicht für deine eigene Navigation.

Fehler 3: Canonical Tags vergessen

Du redirectest alte-domain.de/seite per 301 auf neue-domain.de/seite. Aber der Canonical Tag auf der neuen Seite zeigt noch auf alte-domain.de/seite. Google sieht: 301 sagt “geh zu neu”, Canonical sagt “die alte ist kanonisch”. Ergebnis: Verwirrung, verzögerte Indexierung.

Fehler 4: Sitemap nicht aktualisiert

Die alte sitemap.xml enthält noch URLs der alten Domain. Google crawlt diese, bekommt 301er, folgt ihnen zur neuen Domain. Das funktioniert, verschwendet aber Crawl Budget und verzögert die vollständige Migration.

Fehler 5: Keine Übergangszeit

Du schaltest die alte Domain sofort ab. Kein Redirect. 50.000 Seiten liefern 404. Google braucht Monate, um die neue Domain zu entdecken und zu indexieren. Rankings: weg.

Die Regel: Redirects von der alten Domain mindestens 12 Monate aktiv lassen. Google empfiehlt offiziell “so lange wie möglich”, praktisch heißt das: mindestens 1 Jahr, besser 2.

Google Search Console: Coverage Report richtig lesen

Die GSC zeigt dir unter Seiten (ehemals Coverage), wie Google deine URLs sieht:

Praktik: Jeden Montag 10 Minuten in den Seitenbericht schauen. Wenn die Kurve “Indexiert” nach unten geht, stimmt etwas nicht. Exportiere die Änderungen der letzten 7 Tage und vergleiche mit deinem Deployment-Log.

Die Checkliste für dein nächstes Audit

• Mit curl die 10 Top-URLs testen. Alle 200 OK?
• Screaming Frog: Status Code Distribution. >90 % 200er?
• Redirect Chains: Keine Chain mit mehr als 1 Hop?
• 302er identifiziert: Sind das wirklich temporäre Redirects?
• Soft 404s: GSC-Report mit Screaming Frog abgeglichen?
• 410er gesetzt, wo Content permanent weg ist?
• Canonicals passen zu den Status Codes? Keine Cross-Domain-Canonicals zu 301ern?
• hreflang: Alle hreflang-URLs 200 OK?
• Sitemaps: Nur 200er-URLs in der sitemap.xml?
• JavaScript-Seiten: Mit Screaming Frog + JS-Rendering getestet?
• 503 mit Retry-After Header für Wartungsarbeiten konfiguriert?
• Ahrefs Site Audit: Redirect Loops ausgeschlossen?
• Interne Links: Zeigen alle direkt auf finale URLs (keine Redirects)?
• Rate Limiting: Googlebot nicht durch 429er ausgebremst?

Fazit: Status Codes sind nicht spannend — aber existenziell

Niemand trägt ein T-Shirt mit “301 Lover” auf der Brust. Aber ein einziger falscher Status Code kostet dich Rankings, Traffic, und letztlich Geld.

Die gute Nachricht: Richtig umgesetzt ist Status Code Management dein Wettbewerbsvorteil — ein fundamentaler Teil der OnPage-Optimierung. Während andere Agenturen noch über die alte Domain ranken und Soft 404s indexieren lassen, rankst du mit sauberer Redirect-Struktur und Crawl-Budget-Effizienz.

Nutze curl für schnelle Checks, Screaming Frog für systematische Audits, Ahrefs für laufendes Monitoring und die GSC als Frühwarnsystem. Verstehe die Unterschiede zwischen 301 und 302. Eliminiere Redirect Chains. Setz 410 ein, wo 404 zu langsam ist.

Brauchst du Hilfe bei der Umsetzung? Schau dir unsere SEO-Leistungen an.

Dann klettert dein organischer Traffic nicht nur wieder hoch — er bleibt oben.