Zum Inhalt springen 
HTTP Status Codes steuern, wie Crawler anfragen, Inhalte laden und ob Seiten überhaupt in die Suche gelangen. Ich zeige, wie Antworten wie 200, 301, 404 oder 503 das Crawling, das Crawl-Budget und das Hosting zusammenspielen lassen und wo typische Bremsen liegen.
Zentrale Punkte
- Crawl-Budget hängt direkt von sauberen Status-Antworten ab.
- 2xx/3xx ermöglichen Indexierung, 4xx/5xx blockieren.
- Weiterleitungen nur ohne Ketten und Loops einsetzen.
- Serverzeiten und Uptime formen Crawler-Vertrauen.
- Monitoring mit Logs, GSC und Crawlern betreiben.
Warum Status Codes das Crawling steuern
Crawler prüfen zuerst den Statuscode, erst danach folgen Rendering und Bewertung des Inhalts. Ich priorisiere daher die Korrektheit der Antwort noch vor Title-Tags oder internen Links. Ein 200 OK lädt Inhalte sofort, während 4xx und 5xx Zeit, Budget und Vertrauen kosten. Häufen sich Fehler, reduziert der Bot die Abrufe und verzögert die Aufnahme neuer Inhalte. So entstehen stille SEO-Verluste, die sich mit klaren Regeln für Server-Antworten vermeiden lassen.
2xx: Der direkte Weg ins Index
Der 200 OK ist für Crawler ein Grünes Licht. Ich liefere 200 nur an echte, inhaltlich vollständige Seiten aus und verhindere Soft-404s, die zwar 200 senden, aber keinen Mehrwert bieten. Dünne Inhalte, fehlende H1 oder fast identische Texte sind Warnzeichen für solche Fehlkonfigurationen. Wer hier aufräumt, spart Crawl-Budget und stärkt thematische Relevanz. Zusätzlich optimiere ich Snippets und interne Verweise, damit Crawler und Nutzer mit einem Aufruf die richtigen Ziele erreichen.
3xx: Weiterleitungen ohne Verlust
301 verschiebt Inhalte dauerhaft und überträgt Signale an die neue URL, 302 steht für eine temporäre Lösung. Ich setze 301 ein, wenn Inhalte wirklich umgezogen sind, und ich entferne Ketten und Loops, weil jeder extra Hop Zeit und Budget verbrennt. Prüfe interne Links, denn eine interne 301-Kette ist ein selbstgebauter Stau. Für Umzüge plane ich konsistente Regeln, damit alles in einer sauberen Linie auf die Ziel-URL zeigt. Warum das so wichtig ist, zeige ich bei Redirect-Chains, die messbar Ladezeit und Crawling belasten.
4xx: Deutliche Signale für entfernte Inhalte
Ein 404 teilt klar mit: Diese Ressource gibt es nicht. Ich lasse 404 für wirklich entfernte Seiten stehen und vermeide Soft-404s, indem ich bei Fehlerseiten niemals 200 sende. 410 signalisiert noch eindeutiger, dass eine Seite dauerhaft entfernt wurde; für Alt-URLs mit keinen passenden Alternativen nutze ich das gezielt. Interne Links auf 404 verschwenden Budget, darum korrigiere ich sie zeitnah oder leite gezielt auf die beste thematische Alternative. So halte ich Crawler auf den Seiten, die echten Wert liefern.
5xx: Serverfehler bremsen Bots und Nutzer
5xx bedeuten: Der Server konnte die Anfrage nicht bedienen. Bei Häufung stufen Crawler die Site als unzuverlässig ein und besuchen seltener. Für Wartungen setze ich 503 mit „Retry-After“, damit Bots wissen, wann ein erneuter Abruf sinnvoll ist. Dauert ein 503 an, werte ich Logs aus und behebe Engpässe bei CPU, RAM, Datenbank oder Rate Limits. Für WordPress sammle ich praktische Hinweise in diesem Ratgeber zu 503-Fehlern, damit Wartungsfenster kontrolliert und kurz bleiben.
Caching, 304 und ETags: Budget sparen ohne Risiken
304 Not Modified spart Bandbreite, weil der Client seine Kopie weiterverwenden darf. Ich setze ETag oder Last-Modified sauber, damit Crawler If-Modified-Since korrekt nutzen können. So verkürzen sich Abrufe von unveränderten CSS, JavaScript und Bildern. Stimmt die Logik nicht, lädt der Bot unnötig viele Dateien oder verpasst Updates. Darum teste ich Varianten, prüfe Response-Header und halte die 304-Antworten konsistent über alle Assets.
Crawl-Budget: So halte ich es hoch
Crawl-Budget hängt an drei Faktoren: Code-Qualität, Performance und interner Struktur. Ich reduziere Zeitfresser wie Weiterleitungsketten, doppelte Inhalte und langsame TTFB. Interne Links führe ich auf wenige, klare Pfade, damit Bots Prioritäten schneller erkennen. Fehlerhafte oder verwaiste Seiten korrigiere ich zügig, bevor sie Budget ziehen. Dazu gehören auch Statuscodes für Paginierungen, Canonicals und Hreflang, die ohne Fehlersignale laufen müssen.
Hosting-Faktoren, die Status Codes beeinflussen
Gute Hardware, saubere Serverkonfiguration und kapazitätsgerechtes Caching verhindern 5xx-Spitzen. Ich achte auf genügend PHP-Worker, Datenbank-Parameter, Keep-Alive und HTTP/2 oder HTTP/3. Auch Rate Limits für Bots sollten sinnvoll gesetzt sein, damit echte Nutzer nicht blockieren. Bei hohen Lastspitzen helfen Edge-Caches und Regeln für statische Assets. Warum Status Codes und Hosting-Leistung zusammenhängen, zeige ich hier: HTTP-Status und Server-Power.
Monitoring: Logs, GSC und Crawler richtig nutzen
Ich starte mit Server-Logs, weil sie echte Anfragen zeigen und jede Antwort mitschreiben. Danach prüfe ich die Search Console auf Abdeckungsfehler, Sitemaps und Render-Status. Ein Desktop- und ein Mobile-Crawl mit einem SEO-Crawler deckt Weiterleitungen, 4xx und 5xx in einem Durchlauf auf. Für tiefe Analysen korreliere ich Fehler mit Zeitpunkten von Releases oder Traffic-Peaks. Das zeigt, ob ein Rollout, ein Plugin oder ein CDN-Regelwerk die Antworten verändert hat.
Schnellübersicht: Status Codes und Maßnahmen
Die folgende Tabelle ordnet typische Antworten den passenden Schritten zu und hebt Hosting-Punkte hervor. Ich nutze sie als Kompass für schnelle Entscheidungen im Alltag.
| Statuscode | Crawler-Reaktion | Aktion | Hosting-Hinweis |
|---|---|---|---|
| 200 OK | Inhalt wird abgerufen und gewertet | Echte Inhalte liefern, Soft-404 vermeiden | TTFB niedrig halten, Cache warm |
| 301 Moved Permanently | Signale an Ziel-URL | Ketten entfernen, interne Links aktualisieren | Rewrite-Regeln klar halten |
| 302 Found | Temporär, Quelle behält Signale | Nur kurzfristig einsetzen | Regelmäßig prüfen |
| 304 Not Modified | Cache nutzen, kein Download | ETag/Last-Modified korrekt setzen | Assets über CDN ausliefern |
| 404 Not Found | URL wird aus dem Index entfernt | Interne Links korrigieren, Soft-404 vermeiden | Fehlerseite schlank halten |
| 410 Gone | Schnellere Entfernung | Für dauerhaft entfernte Inhalte einsetzen | Weiterleitung nur bei echter Alternative |
| 500 Internal Error | Bot reduziert Besuche | Logs prüfen, Ursache beheben | Ressourcen und Limits erhöhen |
| 503 Service Unavailable | Wartungsmodus akzeptiert | „Retry-After“ setzen, Dauer kurz halten | Wartungsfenster planen |
Fehlerbehandlung: Was ich zuerst prüfe
Ich beginne mit dem Scope: Betrifft der Fehler alle Nutzer, nur Bots oder nur Mobile? Danach prüfe ich, ob die letzte Änderung am Server, an der Anwendung oder am CDN stattfand. Tritt der Fehler nur unter Last auf, erhöhe ich Ressourcen kurzfristig und suche in Traces nach Engpässen. Bei wiederkehrenden 5xx setze ich Alerts auf Log-Muster und Status-Endpunkte. So löse ich akute Probleme schnell und verhindere, dass sie das Crawl-Budget weiter senken.
Technische Checks vor Releases
Vor jedem Rollout teste ich kritische Pfade mit einem Staging-Crawl und vergleiche Statuscodes mit der Live-Variante. Ich halte eine Liste wichtiger URLs bereit: Startseite, Kategorie, Produkt, Filter, Suche, Sitemap, API. Danach prüfe ich Header wie Cache-Control, Vary, Redirect-Regeln und Canonicals. Für Feature-Flags setze ich klare Bedingungen, damit sie nicht unbeabsichtigt 302 oder 404 erzeugen. Erst wenn Statuscodes, Ladezeiten und Render-Ergebnisse stabil wirken, gebe ich den Release frei.
robots.txt, Sitemaps und Neben-URLs
Ich prüfe zuerst, ob robots.txt stabil mit 200 antwortet. 5xx oder 403 auf robots.txt verunsichern Crawler und drosseln das Crawling. Ein 404 auf robots.txt gilt zwar als „keine Restriktion“, ist aber ein schlechtes Signal bei Sites mit Crawl-Problemen. Für Sitemaps akzeptiere ich nur 200 und halte die Dateien klein, sauber gzipped und mit korrekten lastmod-Feldern. 3xx zur Sitemap sind technisch erlaubt, aber ich vermeide sie zugunsten einer direkten 200-Antwort. Für Feeds, AMP– oder API-Ressourcen achte ich darauf, dass sie nicht 404 oder 5xx zurückgeben, wenn die HTML-Seite 200 liefert – sonst bricht das Rendering oder die Auswertung strukturierter Daten inkonsistent ab.
Canonical, Hreflang und Pagination nur auf 200
Signale wie rel=canonical, hreflang oder Pagination entfalten ihren Effekt nur, wenn Ziel- und Referenz-URLs mit 200 final laden. Ich meide Canonicals auf 3xx, 404 oder noindex-URLs, weil das Crawler verwirrt. Für hreflang prüfe ich die Rückreferenz und dass jede Variante final auf 200 endet. Paginierte Listen (page=2,3,…) müssen stabil 200 liefern; ich verhindere, dass leere Seiten Soft-404 auslösen, indem ich bei fehlenden Ergebnissen klare Inhalte und interne Weiterwege anbiete, aber dennoch den korrekten Status sende.
429 und Rate Limits richtig nutzen
429 Too Many Requests ist mein Werkzeug für feingranulare Drosselung, wenn einzelne Bots zu aggressiv sind. Ich setze Retry-After mit einer sinnvollen Zeitangabe, damit Crawler ihre Abrufe staffeln. 429 ist kein Ersatz für 503-Wartungen und sollte niemals legitime Nutzer treffen. Im WAF oder CDN differenziere ich nach User-Agent, IP und Pfaden, damit Medien-Assets weiter 200/304 ausliefern, während HTML kurz gedrosselt wird. Wichtig: 429 darf nicht dauerhaft werden – sonst wertet der Bot die Site als schwer erreichbar und senkt das Budget.
401/403/451: gewollt gesperrt – aber konsistent
401 nutze ich für login-geschützte Bereiche, 403 für verbotene Zugriffe. Ich achte darauf, dass diese Antworten nicht versehentlich für Googlebot gelten, etwa durch strenge Bot-Filter. Bei Geo-Sperren oder rechtlichen Anforderungen setze ich 451 und dokumentiere die Gründe intern. Ich verzichte auf 200-Antworten mit Interstitials („Zugriff verweigert“) – solche Seiten wirken wie Soft-404s. Wo Alternativen bestehen, verlinke ich klar auf zugängliche Inhalte und lasse die gesperrte URL den korrekten 4xx-Status senden.
Parität der Antworten: Mobile, Desktop und dynamische Ausspielung
Ich stelle sicher, dass Mobile- und Desktop-Bot dieselben Statuscodes sehen. Dynamische Ausspielungen (A/B-Tests, Feature-Flags, Geo-Content) dürfen keine 302/403 für einzelne User-Agents auslösen. Ich nutze Vary-Header sparsam und bewusst (z. B. Accept-Language), um unnötige Cache-Splits zu vermeiden, und sorge dafür, dass jeder Pfad für alle Varianten konsistent auf 200/304 endet. Paritätsbrüche führen zu Indexierungsproblemen, wenn der Bot eine 404 sieht, während Nutzer 200 erhalten – solche Fälle beseitige ich mit klaren Regeln und Tests pro Variante.
HEAD, OPTIONS und API-Endpunkte
Viele Crawler schicken HEAD-Anfragen, um Verfügbarkeit und Größe zu prüfen. Mein Server antwortet darauf mit der gleichen Logik wie auf GET – nur ohne Body. Ich vermeide 405 auf HEAD, wenn GET 200 liefert. OPTIONS und CORS-Preflights behandle ich so, dass Assets aus Drittquellen sauber geladen werden können. Für API-Endpunkte, die beim Rendering Daten liefern, achte ich auf stabile 200/304 und klare 4xx bei echten Fehlern. Wenn APIs sporadisch 5xx liefern, markiere ich das in Logs separat, weil es Render-Fehler unter der Haube erklären kann, obwohl die HTML-Seite 200 sendet.
CDN-Regeln, Stale-Strategien und 5xx-Abschirmung
Im CDN cache ich 200, 301 und statische 404 kontrolliert – aber ich verhindere, dass 503 oder Admin-Seiten im Cache landen. Mit stale-if-error kann ich kurzzeitige 5xx überbrücken, ohne dass Bots Fehler sehen. Ich setze Surrogate-Control für Edge-Signale und halte TTLs für HTML kürzer als für Assets. ETags konfiguriere ich cluster-sicher (entweder überall gleich oder deaktiviert), damit 304 zuverlässig funktioniert und nicht durch abweichende Hashes verfällt. Wichtig: Weiterleitungen (301/302) sollten im CDN nicht ewig gecached werden, sonst bleiben alte Pfade als Ketten erhalten.
E-Commerce-Fälle: Ausverkauft, Varianten, Filter
Wenn Produkte vorübergehend nicht verfügbar sind, bleibt die Produktseite auf 200 mit klarer Kennzeichnung und sinnvollen internen Weiterwegen (Kategorie, Alternativen). Bei dauerhaft entfernten Produkten entscheide ich zwischen 301 auf die beste Ersatz-URL (nur bei echter Entsprechung) und 410, wenn es keine passende Alternative gibt. Ich vermeide Massen-Redirects auf die Startseite, da sie wie Soft-404s wirken. Für Filter- und Parameter-URLs nutze ich klare Regeln: Nur indexrelevante Kombinationen auf 200, alles andere via 301 auf die kanonische URL oder mit noindex – aber niemals 200 für leere oder nahezu identische Seiten, die den Soft-404-Detektor triggern.
Noindex, Robots und Statuscodes sauber trennen
noindex ist ein Inhalts-Signal, der Statuscode ist ein Transport-Signal. Ich vermeide Mischformen, die Crawler verwirren: keine 301 auf eine noindex-Seite, keine 200 mit „zugriffsbeschränkt“-Placeholder, wenn die Ressource nicht existiert. Entweder ist eine Seite indexierbar (200 + index) oder sie ist entfernt (404/410) oder temporär nicht verfügbar (503 mit Retry-After). robots.txt blockiert nur das Crawling – nicht die Indexierung bereits bekannter URLs. Darum setze ich für wirklich entfernte Inhalte 404/410 statt Robotssperren.
Kennzahlen und Schwellenwerte, die ich beobachte
- 5xx-Rate: dauerhaft deutlich unter 0,1%. Spikes sofort untersuchen.
- 4xx-Rate: je nach Site-Typ unter 1–2%. Interne 4xx sollten gegen 0% gehen.
- 3xx-Anteil: so niedrig wie möglich; Redirect-Ketten auf 0.
- 304-Anteil bei Assets: hoch ist gut – Indikator für funktionierendes Caching.
- TTFB für HTML: stabil niedrig; Ausreißer korreliere ich mit 5xx/429.
- Sitemap-Health: 200, valide lastmod, keine toten Links.
- Parität Mobile vs. Desktop: gleiche Statuscodes und Final-URLs.
Diese Metriken verknüpfe ich mit Deployments, Traffic-Spitzen und Infrastruktur-Events. So erkenne ich Muster, die das Crawl-Budget beeinflussen, lange bevor Rankings reagieren.
Edge-Cases: 1xx, 405, 410 vs. 404
1xx-Antworten sind für SEO praktisch irrelevant; ich stelle nur sicher, dass Server und CDN korrekt upgraden (z. B. HTTP/2/3). 405 Method Not Allowed taucht auf, wenn HEAD/POST blockiert sind, obwohl GET 200 liefert – das ist harmlos, sollte aber konsistent konfiguriert werden. Bei der Wahl 404 vs. 410 nutze ich 410 für bewusst entfernte Inhalte mit dauerhaftem Charakter, 404 für unbekannte oder versehentlich verlinkte Pfade. Wichtig ist die Konsistenz, damit Crawler aus wiederkehrenden Mustern lernen können.
Rollback-Strategien und Ausfallsicherheit
Ich plane Releases so, dass ich bei fehlerhaften Statuscodes schnell zurück kann: Blue/Green-Deployments, feingranulare Feature-Flags und reversible Rewrite-Regeln. Für Wartungen nutze ich Maintenance Pages, die 503 liefern, während Hintergrundjobs laufen. Auf Infrastruktur-Ebene halte ich Health-Checks, automatische Restarts und Rate-Limit-Grenzen bereit, die Angriffe abfangen, ohne legitimes Crawling lahmzulegen. Jede Maßnahme zielt darauf, 200/304 zu maximieren und 4xx/5xx im Störfall kontrolliert, kurz und verständlich zu halten.
Zusammenfassung: Saubere Signale, schnelleres Crawling
Ich sorge dafür, dass jeder Statuscode eine klare Botschaft trägt: 2xx für Inhalte, 3xx ohne Ketten, 4xx für entfernte Seiten und 5xx nur im echten Ausnahmefall. Caching mit 304 entlastet Server, während konsistente 200 Antworten dem Bot Vertrauen geben. Damit das klappt, kombiniere ich Log-Analysen, GSC-Daten und wiederkehrende Crawls. Auf Host-Seite halte ich Antwortzeiten niedrig, setze Limits sinnvoll und plane Wartungen sauber. So steigen Qualität, Indexierbarkeit und Sichtbarkeit – und das Crawl-Budget fließt dorthin, wo es am meisten bringt.
