500 Interner Serverfehler

TL;DR — Ein 500 Internal Server Error bedeutet, dass der Server beim Erstellen der Seite einen Fehler hatte — nicht, dass Ihre URL, Ihr Browser oder der Such-Crawler schuld ist. Ein einzelner 500 wird von Google typischerweise erneut versucht. Das dokumentierte Risiko entsteht, wenn viele Seiten eine Zeit lang 500 liefern: Dann verlangsamt Google das Crawling und kann Seiten schließlich aus der Suche entfernen. Beginnen Sie mit den Server-Fehlerlogs, nicht mit dem Browser.

Was ein 500-Fehler ist

Ein 500 Internal Server Error bedeutet: Der Server erhielt die Anfrage, begann die Seite zu erstellen, stieß auf ein Problem und gab auf. Er liefert statt der Seite einen allgemeinen Fehler. Im Ahrefs-Leitfaden lautet die Definition: “encounters some kind of issue and doesn’t have a better or more specific error code.” (Übersetzung) Der Server stößt auf ein Problem und hat keinen besseren oder spezifischeren Fehlercode. Evidence for this claim A 500 response means the server encountered an unexpected condition that prevented it from fulfilling the request. Scope: RFC 9110 defines the generic response semantics; it does not diagnose the underlying server fault. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.1 — 500 Internal Server Error

Ein 500 ist ein Sammelcode. Er sagt, dass auf der Serverseite etwas kaputtging, aber nicht was. Die Ursache zu finden ist die eigentliche Aufgabe.

Es ist normalerweise ein Serverproblem, nicht Ihres

500-Fehler gehören zur 5xx-Familie der Serverfehler. Das unterscheidet sie von 4xx-Fehlern wie 404, welche die Anfrage betreffen. Bei 500 kann die URL in Ordnung sein; der Server konnte die Arbeit nicht beenden. 502, 503 und 504 sind verwandte serverseitige Codes für Gatewayfehler, vorübergehende Nichtverfügbarkeit und Timeout.

Schadet ein 500-Fehler der SEO?

Ein einzelner, gelegentlicher 500 wird von Google typischerweise erneut versucht. Lädt die Seite beim nächsten Abruf, ist die Sache meist erledigt. Google verspricht nicht pauschal, dass ein isolierter Fehler harmlos ist, dokumentiert aber auch keine Strafe für einen einmaligen Aussetzer.

Das dokumentierte Risiko sind anhaltende 500s auf vielen Seiten. Dann passiert Folgendes:

1. Google versucht es weiter, sieht die Fehler und verlangsamt das Crawling Ihrer Website. 2. Wenn die Fehler nicht verschwinden, entfernt Google die Seiten schließlich aus dem Index. Evidence for this claim Google reduces crawling in response to 5xx errors and eventually removes persistently failing URLs from its index. Scope: Google documents the general 5xx progression; it does not provide a guaranteed retry or recovery timeline for an individual URL. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Googles Dokumentation beschreibt eine schrittweise Erholung, sobald die Ursache behoben ist und Abrufe wieder erfolgreich sind, garantiert aber keinen Zeitplan oder Ausgang. “Recovery is usually quick” (Übersetzung) „Die Erholung ist normalerweise schnell“ beschreibt den Regelfall, kein Versprechen.

So beginnen Sie mit der Behebung

• Server-Fehlerlogs zuerst prüfen: Dort steht der Grund, nicht im Browser. - Jüngste Änderungen prüfen: Plugin, Theme, Modul, Deployment oder .htaccess. - Google Search Console prüfen: Der Bericht zur Seitenindexierung zeigt „Serverfehler (5xx)“. - Hoster fragen: Speicher- und Ressourcenlimits sind bei Shared Hosting häufig.\n.htaccess

Möchten Sie Googles Eskalation, die grobe 1-%-Faustregel, den Unterschied zwischen 500 und 503 sowie die vollständige Diagnose-Reihenfolge? Wechseln Sie zum Tab Fortgeschritten.

TL;DR — RFC 9110 definiert 500 als unerwartete Bedingung, die den Server an der Erfüllung der Anfrage hinderte. Ursache, Dauer und Wiederholbarkeit gehören zur Diagnose. Googles dokumentierte Reaktion ist abgestuft: isolierte 500s werden typischerweise erneut versucht; anhaltende websiteweite 500s führen zu langsamerem Crawling und bei Fortbestehen zur Entfernung aus dem Index. Mueller nannte mehr als etwa 1 % Fehler als persönliche Faustregel, keine Google-Schwelle. Diagnose: zuerst Serverlogs, dann GSC Serverfehler (5xx) und Crawl Stats. 503 ist der vorgesehene „später wiederkommen“-Code mit etwa zweitägiger Kulanz; ein unkontrollierter 500 erhält sie nicht. Evidence for this claim RFC 9110 defines 500 as an unexpected condition encountered by the server that prevented it from fulfilling the request. Scope: web requests Confidence: high · Verified: 2026-07-16 RFC 9110: HTTP Semantics

Was ein 500 tatsächlich ist

RFC 9110 definiert 500 Internal Server Error als unerwartete Bedingung, die den Server an der Erfüllung der Anfrage hinderte. Der Code nennt weder Ursache, fehlernde Komponente, Dauer, Erfolg eines erneuten Versuchs noch Erholungswahrscheinlichkeit. Alles Weitere ist Diagnose und steht in Server-Fehlerlogs, nicht in Spezifikation oder Browser. Evidence for this claim A 500 response means the server encountered an unexpected condition that prevented it from fulfilling the request. Scope: RFC 9110 defines the generic response semantics; it does not diagnose the underlying server fault. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.1 — 500 Internal Server Error

Im Ahrefs-Leitfaden lautet die Praxisdefinition: Der Server stößt auf ein Problem und hat keinen besseren oder spezifischeren Fehlercode. Das ist ein Sammelcode und Symptom, keine Diagnose.

500 gehört neben 502 (Bad Gateway), 503 (Service Unavailable) und 504 (Gateway Timeout) zur 5xx-Familie. Der Statuscode enthält keine Diagnose; ein Neuladen erklärt nicht, warum es geschah. Die Serverlogs sind die Wahrheit.

Wie Googlebot einen 500 behandelt

Googles Crawler passt sich der Servergesundheit an; 5xx-Antworten sind Signale zum langsamer werden. 5xx und 429 senken vorübergehend die Crawl-Rate abhängig von betroffenen URLs; wiederholt fehlerhafte URLs können aus dem Index entfernt werden, während indexierte Inhalte bis zu einem erfolgreichen Abruf erhalten bleiben. Evidence for this claim Google reduces crawling in response to 5xx errors and eventually removes persistently failing URLs from its index. Scope: Google documents the general 5xx progression; it does not provide a guaranteed retry or recovery timeline for an individual URL. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers John Mueller beschrieb dieselbe Entwicklung in einer über Search Engine Journal wiedergegebenen Sitzung:\n5xx

„Dafür gibt es keine starken Schwellenwerte. Wir versuchen es bei 500-Fehlern erneut. Wenn wir sie weiter sehen, verlangsamen wir das Crawling. Wenn wir weiterhin 500-Fehler sehen, entfernen wir diese URLs aus dem Index.“

Das beschreibt dokumentiertes Verhalten — Wiederholen, langsamer crawlen, mögliche Entfernung — nicht einen festen Dreischritt mit garantiertem Zeitplan. Ein isolierter 500 wird typischerweise erneut versucht; das dokumentierte Risiko liegt bei Fehlern, die nicht verschwinden.

Warum websiteweite 500s schlimmer sind als isolierte

Wenn ein großer Teil Ihrer Website gleichzeitig 500 liefert, skaliert Googles Crawl-Reduzierung mit der Zahl betroffener URLs. Je größer der Ausfall, desto stärker wird das Crawling verlangsamt. Mueller hat dies als mögliche Überlastung durch Googles eigenes Crawling beschrieben.

„Wenn ein großer Teil einer Website dauerhaft 500-Fehler hat und wir annehmen, dass wir das Problem vielleicht verursachen, verlangsamen wir das Crawling der gesamten Website und entfernen irgendwann die Seiten.“

Behandeln Sie diese Kausalformulierung als Muellers eigene Einordnung, nicht als wörtlichen aktuellen Dokumentationswortlaut. Praktisch kann Crawl-Last weitere 500s auslösen, Google verlangsamt die gesamte Website, und bei anhaltenden Fehlern fallen Seiten aus dem Index. Ein 500 kann daher auch durch Serverüberlastung und nicht nur durch einen Codefehler entstehen.

Wie viel ist „zu viel“?

Es gibt keine harte Linie; Googles Dokumentation veröffentlicht keinen Fehlerquoten-Schwellenwert. Mueller nannte in SEO Office Hours eine grobe persönliche Faustregel, die über Search Engine Journal weitergegeben wurde.

„Mein Gefühl ist: Wenn Sie etwas über einem Prozent sehen, klingt das so, als wäre etwas kaputt.“

Behandeln Sie etwa 1 % als inoffiziellen Geruchstest, nicht als Google-Limit. Darüber lohnt eine Untersuchung, aber weder ist das Überschreiten automatisch ein Auslöser noch das Unterschreiten eine Garantie. Google sagt öffentlich, dass es keine starken Schwellenwerte gibt.

500 vs. 503: der wichtige Unterschied

503 Service Unavailable ist der vorgesehene Weg, einem Crawler zu sagen: „Ich bin vorübergehend nicht verfügbar, kommen Sie später wieder.“ Google behandelt ihn als beabsichtigt und gewährt ein Zeitfenster. Googles Dokumentation ist eindeutig:

„Geben Sie bei Überlastung Ihres Servers für Googlebot-Anfragen vorübergehend die HTTP-Statuscodes 503 oder 429 zurück. Googlebot versucht diese URLs etwa zwei Tage lang erneut. Wenn Sie länger als einige Tage Codes für ‚keine Verfügbarkeit‘ zurückgeben, wird Google das Crawling von URLs Ihrer Website dauerhaft verlangsamen oder einstellen.“\n503 429

503 ist beabsichtigt und erhält etwa zweitägige Wiederholungs-Kulanz; ein unkontrollierter 500 ist unbeabsichtigt und erhält sie nicht. Für geplante Wartung geben Sie 503 mit Retry-After zurück, nicht 500 und nicht eine Fehlerseite mit 200.\nRetry-After

Einen 500 diagnostizieren

Arbeiten Sie schichtweise — Anwendung/Code, Plattform/CMS, Infrastruktur/Ressourcen und Konfiguration — zuerst das Günstigste und Wahrscheinlichste. WordPress-spezifische Schritte sind keine universellen Lösungen.

1. Server-Fehlerlogs wie error.log und access.log lesen und Zeitstempel, Stacktrace, PHP-Fatalfehler oder DB-Verbindungsfehler prüfen. 2. GSC Serverfehler (5xx) und Crawl Stats nach Antwort lesen. 3. Bing Webmaster Tools prüfen. 4. Als Bot reproduzieren mit URL Inspection, Fetch as Bingbot oder curl. 5. Plugin-/Theme-/Modulkonflikte einzeln isolieren. 6. Ressourcenmangel bei PHP, Datenbank, Hosting und Verkehr prüfen. 7. Konfiguration und jüngste Änderungen wie .htaccess, Deployment und DB-Zugangsdaten untersuchen.\nerror.log access.log curl .htaccess

So beheben Sie ihn (passend zur Ursache)

Passen Sie die Lösung an die diagnostizierte Schicht an. Die folgenden Muster sind häufig, aber weder Rangfolge noch universelle Liste:

• Konfiguration/Deployment: Änderung zurückrollen und .htaccess, Konfiguration oder Zugangsdaten korrigieren. - Ressourcenmangel: Limits erhöhen oder Hosting upgraden. - Plugin-/Modulkonflikt: Erweiterung entfernen oder ersetzen. - Codefehler: Code und Fehlerbehandlung reparieren. - Ursache unklar: Hoster mit Zeitstempeln und Logzeilen einschalten.\n.htaccess

Wiederholung verhindern

5xx-Raten überwachen, Änderungen vor dem Deployment in Staging testen, Lasttests durchführen und bei echter Überlastung bewusst 503/429 zurückgeben, statt unkontrollierte 500s entstehen zu lassen.\n503 429

FAQ

Schadet ein 500 der SEO? Das Risiko betrifft vor allem anhaltende Fehler im großen Maßstab. Isolierte 500s werden typischerweise erneut versucht; anhaltende websiteweite 500s verlangsamen Crawling und können zur Deindexierung führen.

Wie lange dauert die Deindexierung einer Seite mit 500? Es gibt keinen festen Zeitplan. Google versucht es zunächst erneut und verlangsamt das Crawling; aus dem Index fällt eine URL erst, wenn die Fehler anhalten. Bei erfolgreichen Abrufen kehren Seiten meist zurück.

Warum liefert meine Website für Googlebot 500, im Browser aber nicht? Bot-spezifische 500s bedeuten meist Kapazitäts-, Firewall-, Bot-Regel- oder Crawl-Last-Probleme. Vertrauen Sie den Logs, nicht einem manuellen Browsercheck.

Können 500s das Crawling der ganzen Website verlangsamen? Ja. Die Kürzung skaliert mit der Zahl fehlerhafter URLs; ein großer Anteil von 500s verlangsamt das Crawling websiteweit. Muellers Erklärung zur vermuteten Überlastung ist seine Einordnung, kein wörtlicher Dokumentationssatz.

Was verursacht einen 500 in WordPress? Häufig genannt werden Plugin-/Theme-Konflikte, eine beschädigte .htaccess oder ein erreichtes PHP-Speicherlimit. Das ist keine universelle Ursachenrangfolge; beginnen Sie mit Logs und jüngsten Änderungen.\n.htaccess

Ist automatisches Wiederholen nach 500 sicher? Nur nach Prüfung von Methode und Idempotenz. GET, HEAD, PUT und DELETE sind meist sicher wiederholbar; ein einfaches POST meist nicht ohne Idempotency-Key. Blindes Wiederholen kann Doppelbestellungen oder Abbuchungen erzeugen. Backoff, Versuchsgrenze und Retry-Budget verwenden.\nGET HEAD PUT DELETE POST

KI-Zusammenfassung

Eine verkürzte Fassung der Advanced-Version:

• 500: unerwartete Bedingung aus RFC 9110, Symptom statt Diagnose; Ursache aus Serverlogs ermitteln. Unterscheiden Sie ihn von 4xx-Fehlern und den 5xx-Geschwistern 502, 503 und 504. - Google: Crawl-Reduzierung abhängig von betroffenen URLs und mögliche Entfernung anhaltend fehlerhafter URLs; Wiederholen → langsamer crawlen → entfernen beschreibt Verhalten, keinen festen Timer. - Websiteweite 500s: stärkerer Crawl-Effekt und möglicher Rückkopplungskreis. - 1 %: Muellers Faustregel, keine Google-Schwelle. - 500 vs. 503: 503 oder 429 ist das vorgesehene „später wiederkommen“-Signal; für geplante Ausfälle 503 mit Retry-After. - Diagnose: Logs → GSC → Bing → Bot-Reproduktion → Konflikte → Ressourcen → Konfiguration. - Retry: Idempotente Methoden meist sicher, einfaches POST meist nicht; Backoff und Budget verwenden.\nRetry-After

Offizielle Dokumentation

Primärquellen der Suchmaschinen und der HTTP-Spezifikation.

Google - Google-Such-Crawlingfehler untersuchen — Serverfehler und 503/429 bei Überlastung. - Ausführlicher Leitfaden zur Google-Suche — Crawl-Scheduler und 5xx als langsamer werden. - Crawl-Stats-Bericht — Aufschlüsselung nach Antwort. - Googlebot-Crawl-Rate reduzieren — bewusstes Drosseln statt unkontrollierter 500s.\n503 429 5xx

Bing / Microsoft - Bing Webmaster Tools — Liste der Crawl-Fehlerwarnungen — Gruppierung von Server Errors (5xx) und betroffene URLs.

HTTP-Spezifikation / Referenz - MDN — 500 Internal Server Error — Definition. - RFC 9110 §15.6.1 — 500 Internal Server Error — maßgebliche HTTP-Semantik.

Zitate aus der Quelle

Dokumentierte Aussagen. JavaScript-gerenderte oder sekundär vermittelte Quellen sind mit einem small-Hinweis gekennzeichnet.\n<small>

Google — der Eskalationsweg

• “We don’t have any strong thresholds on that. But essentially what happens with 500 errors is we’ll try to retry them. And if we continue to see …the 500 errors then we will …slow down crawling. And if we continue to see that there are 500 errors then we will drop those URLs from the index.” (Übersetzung) „Dafür gibt es keine starken Schwellenwerte. Im Wesentlichen versuchen wir es bei 500-Fehlern erneut. Wenn wir sie weiterhin sehen, verlangsamen wir das Crawling, und wenn die 500-Fehler anhalten, entfernen wir diese URLs aus dem Index.“ — John Mueller, Google. Berichterstattung Über ein Transkript weitergegeben; gegen das Originalvideo prüfen. - “But if a large part of a site consistently has 500 errors and we might assume that maybe we’re causing the problem and we’ll slow down crawling of the whole site and at some point we’ll say well, it looks like these pages are really gone, we’re going to drop them.” (Übersetzung) „Wenn ein großer Teil einer Website dauerhaft 500-Fehler hat und wir annehmen, dass wir das Problem verursachen, verlangsamen wir das Crawling der gesamten Website und entfernen irgendwann die Seiten.“ — John Mueller, Google. Berichterstattung Wörtlich gegen das Originalvideo prüfen. - “My feeling is if you’re seeing something more than one percent then that sounds like something is kind of broken.” (Übersetzung) „Mein Gefühl ist: Wenn Sie etwas über einem Prozent sehen, klingt das so, als wäre etwas kaputt.“ — John Mueller. Berichterstattung Wörtlich gegen das Originalvideo prüfen.

Google — das vorgesehene „langsamer werden“-Signal (Dokumentation, verifiziert)

• “Return 503 or 429 HTTP response status codes temporarily for Googlebot requests when your server is overloaded. Googlebot will retry these URLs for about 2 days. Note that returning ‘no availability’ codes for more than a few days will cause Google to permanently slow or stop crawling URLs on your site.” (Übersetzung) „Geben Sie bei Überlastung Ihres Servers für Googlebot-Anfragen vorübergehend die HTTP-Statuscodes 503 oder 429 zurück. Googlebot versucht diese URLs etwa zwei Tage lang erneut. Wenn Sie länger als einige Tage Codes für keine Verfügbarkeit zurückgeben, wird Google das Crawling dauerhaft verlangsamen oder einstellen.“ Zum Zitat springen

Patrick Stox — die Definition (Ahrefs, verifiziert)

• “500 Internal Server Error – The server encounters some kind of issue and doesn’t have a better or more specific error code.” (Übersetzung) „500 Internal Server Error – Der Server stößt auf ein Problem und hat keinen besseren oder spezifischeren Fehlercode.“ Zum Zitat springen

Checkliste zur 500-Fehler-Triage

Arbeiten Sie die Liste von oben nach unten ab, sobald 500s auftauchen:

• Server-Fehlerlogs mit dem echten Fehler gefunden. - [ ] Jüngste Änderungen geprüft. - [ ] GSC Serverfehler (5xx) geöffnet. - [ ] GSC Crawl Stats nach Antwort gelesen. - [ ] Bing Webmaster Tools geprüft. - [ ] Als Bot reproduziert. - [ ] Ressourcenmangel ausgeschlossen. - [ ] Plugin-/Modulkonflikt isoliert. - [ ] Bei geplanter Wartung 503 mit Retry-After statt unkontrolliertem 500 verwendet. - [ ] Fehlerquote wieder unter dem inoffiziellen 1-%-Geruchstest.\n.htaccess curl 503 Retry-After

Runbook: „Die Website wirft 500s — was prüfe ich zuerst?“

Eine Reihenfolge ohne Panik. Führen Sie diese Schritte nacheinander aus und stoppen Sie, sobald die Ursache gefunden und behoben ist.

0. Umfang bestimmen (2 Minuten). Eine URL ist weniger kritisch, websiteweit ist es ein Notfall, der Google zum langsameren Crawlen der gesamten Website bringt.

1. Server-Fehlerlogs lesen. Zuerst error.log; Zeitstempel mit Fehlern abgleichen und PHP-Fatalfehler, DB-Verbindungsfehler, Segfault oder Out-of-Memory-Abbruch suchen.\nerror.log

2. Mit „was hat sich geändert?“ abgleichen. Deployment, Plugin/Theme/Modul, .htaccess, DB-Zugangsdaten und Config-Push prüfen. Wenn möglich, zuerst zurückrollen, dann diagnostizieren.\n.htaccess

3. Suchmaschinenansicht bestätigen. GSC Seitenindexierung → Serverfehler (5xx), danach Crawl Stats → nach Antwort; Bing-Crawl-Fehlerwarnungen gegenprüfen.

4. So reproduzieren, wie der Bot es sieht. URL Inspection, Abruf als Bingbot oder curl -A "Googlebot" <url> verwenden. Nur-Bot-500er deuten auf Kapazität, Firewall-/Bot-Regeln oder Crawl-Last hin.

5. Übliche Verdächtige halbieren. Plugins und Module einzeln testen, PHP-Speicher/DB-Verbindungen/Hostingkapazität prüfen und .htaccess oder Serverkonfiguration auf eine bekannte funktionierende Version zurücksetzen.\n.htaccess

6. Wenn Crawling der Auslöser ist, nicht nur hinnehmen. Bewusst 503/429 mit Retry-After zurückgeben, statt unkontrollierte 500s auszugeben. Google behandelt 503 etwa zwei Tage als „später wiederkommen“.\n503 429 Retry-After

7. Erholung verifizieren. Fehlerquote unter dem inoffiziellen 1-%-Geruchstest, saubere Logs und erfolgreiche Abrufe in GSC. Entfernte Seiten kehren bei erfolgreichen Crawls meist zurück.

Eskalationsmuster: gelegentlicher 500 → Wiederholung → anhaltender 500 → Crawling wird langsamer → weiterhin anhaltend → URLs fallen aus dem Index.

Welchen Servercode sollte ich zurückgeben?

Verwenden Sie dies, wenn Sie entscheiden, was ausgeliefert werden soll oder eine beobachtete Antwort einordnen.

Ist der Fehler beabsichtigt? - Ja: 503 Service Unavailable mit Retry-After zurückgeben; Google versucht etwa zwei Tage erneut. Keine Fehlerseite mit 200 und kein Durchfallen in 500. - Nein: fortfahren.\n503 Retry-After

Erhält jeder den Fehler oder nur der Crawler? - Jeder: Code-, Config- oder DB-Problem; Logs prüfen und Änderungen zurückrollen. - Nur Googlebot/Bingbot: Kapazität, Bot-Erkennung/Firewall oder Crawl-Last vermuten und als Bot reproduzieren.

Ist es eine URL oder ein großer Teil der Website? - Eine URL/gelegentlich: geringe Dringlichkeit, Isolation bestätigen. - Websiteweit/anhaltend: Notfall; Dienst zuerst wiederherstellen, Ursache danach.

Liegt die Fehlerquote über etwa 1 %? - Ja: als echtes Problem untersuchen — Muellers inoffizielle Faustregel, keine Google-Schwelle. - Nein: wahrscheinlich in Ordnung, aber den Trend überwachen.

Prompt: Einen 500 mit Logs und Deployment abgleichen

Diagnose this HTTP 500 incident from the sanitized evidence I provide. Build a
timeline across deployment events, request IDs, access logs, application errors,
resource signals, and affected URL patterns. Rank likely causes by evidence, separate
the fastest service-restoration action from the root-cause fix, and give exact
validation and rollback checks. Do not invent missing stack traces or thresholds.

[PASTE TIMELINE, HEADERS, LOGS, AND RECENT CHANGES]

Prompt: Einen Stacktrace in einen sicheren Testplan umwandeln

Explain this stack trace in plain language, identify the failing component and its
inputs, and propose the smallest reversible test that distinguishes code, dependency,
configuration, and resource-exhaustion causes. Include what evidence would falsify
each hypothesis and how to confirm the URL returns a stable non-5xx response afterward.
Redact secrets and do not suggest exposing debug output publicly.

[PASTE SANITIZED STACK TRACE]

Shell: Eine URL-Liste auf 5xx-Antworten prüfen

Führen Sie dies mit einer absoluten URL pro Zeile in urls.txt aus.\nurls.txt

while IFS= read -r url; do
  curl -sS -o /dev/null -w '%{http_code},%{time_total},%{url_effective}\n' "$url"
done < urls.txt

Die Ausgabe trennt isolierte Routen von einem breiten Ausfall und erfasst Latenz, ohne Antwortkörper herunterzuladen.

PowerShell: Dieselbe Statusprobe exportieren

Get-Content .\urls.txt | ForEach-Object {
  $r = Invoke-WebRequest -Uri $_ -SkipHttpErrorCheck
  [PSCustomObject]@{ Status = $r.StatusCode; Url = $_ }
} | Export-Csv .\status-sample.csv -NoTypeInformation

Shell: 5xx-Status in einem Access-Log zählen

Passen Sie die Position des Statusfelds an Ihr dokumentiertes Logformat an, bevor Sie sich auf das Ergebnis verlassen.

awk '$9 ~ /^5[0-9][0-9]$/ { count[$9]++ } END { for (code in count) print code, count[code] }' access.log

Werkzeuge zum Finden und Diagnostizieren von 500s

• Server-Fehlerlogs — error.log/access.log und Plattform-Viewer; prüfen Sie dabei konkrete 500-Antworten. - GSC-Seitenindexierung — Serverfehler (5xx) mit betroffenen URLs. - GSC-Crawl-Stats — Aufschlüsselung nach Antwort. - URL Inspection — einzelne URL wie Google abrufen. - Bing Webmaster Tools — Serverfehler und Crawl Information. - curl — einen beliebigen User-Agent mit curl -I -A "Googlebot" <url> reproduzieren. - Crawler-/Site-Audits — 5xx-Muster finden. - Uptime-/Statusmonitoring — Alarmierung vor Google.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Texte - HTTP-Statuscodes: Ein Leitfaden zu SEO- und UX-Auswirkungen — vollständige Statuscode-Referenz einschließlich 500. - Der Einsteigerleitfaden für technisches SEO — Serverfehler im technischen Gesamtbild.

Meine Vorträge - How Search Works (SlideShare) — Überblick über Crawling und die Rückkopplung der Servergesundheit. (Hinweis: „Das ist mein Verständnis der Systeme … nicht zu 100 % vollständig oder korrekt.“)

Aus der Branche - Wie 500-Fehlercodes die Indexierung beeinträchtigen — Bericht mit Muellers Zitaten. - So beheben Sie den Serverfehler (5xx) in der Google Search Console — GSC-Schritte. - Serverfehler (5xx) in der Google Search Console beheben — Erklärung und Behebung. - Einen internen Serverfehler 500 auf Ihrer Website beheben — WordPress-Fixliste. - 5xx-Serverfehler: Leitfaden zum Finden und Beheben von 5xx-Problemen — technischer Audit. - 5xx-Serverfehler in der Google Search Console beheben — GSC-Leitfaden.\n.htaccess

Videos

• Google Search Central (YouTube) — SEO-Office-Hours-Archiv mit Muellers Hinweisen zu Serverfehlern und Crawling. Kanal

Testen Sie Ihr Wissen: 500 Internal Server Error

Fünf kurze Fragen dazu, was ein 500 ist und wie er SEO beeinflusst. Wählen Sie jeweils eine Antwort und prüfen Sie die Antwort anschließend.

Änderungsprotokoll