PK Systems PK Systems
Web & Marketing

HTTP-Statuscodes — Vollständige Referenz

Suchen, lernen und debuggen Sie jeden HTTP-Statuscode — von 100 Continue bis 511 Network Authentication Required. Mit Bedeutung, Anwendungsbeispielen und Browser-Verhalten.

HTTP-Statuscodes — Vollständige Referenz

100 Continue #

Eine Zwischenantwort, die signalisiert, dass der Server die Request-Header empfangen hat und der Client mit dem Senden des Request-Body fortfahren soll. Definiert in RFC 9110 Abschnitt 15.2.1.

Häufige Ursache

Der Client sendete einen Expect: 100-continue-Header, um zu testen, ob der Server einen großen Body akzeptiert, bevor er ihn überträgt.

Wann verwenden

Verwendet zwischen Headern und Body langer Uploads (PUT, POST), damit der Client keine Bandbreite an einer Anfrage verschwendet, die der Server ablehnen würde.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 100 Continue
101 Switching Protocols #

Der Server stimmt zu, auf derselben TCP-Verbindung zu einem anderen Anwendungsprotokoll zu wechseln, das im Upgrade-Header aufgeführt ist. RFC 9110 §15.2.2.

Häufige Ursache

Der Client forderte ein Upgrade an (typischerweise auf WebSocket oder HTTP/2 über h2c) und der Server hat es akzeptiert.

Wann verwenden

WebSocket-Handshakes sind heute der dominante Fall. Nach 101 ist die Verbindung kein HTTP mehr.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 101 Switching Protocols
200 OK #

Standard-Erfolgsantwort — die Anfrage war erfolgreich und der Response-Body enthält die angeforderte Repräsentation. RFC 9110 §15.3.1.

Häufige Ursache

Die Anfrage war gültig, autorisiert und ohne Umleitung erfüllbar.

Wann verwenden

GETs, die Daten zurückgeben; POSTs/PUTs, die inline statt asynchron verarbeitet werden; gesunde API-Antworten.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 200 OK
201 Created #

Die Anfrage war erfolgreich und eine neue Ressource wurde als direktes Ergebnis erstellt. Der Location-Header SOLLTE auf die neue Ressource zeigen. RFC 9110 §15.3.2.

Häufige Ursache

Ein POST oder PUT hat eine Ressource erstellt (Datenbankzeile, Datei, Benutzer etc.).

Wann verwenden

Verwenden nach dem Erstellen von REST-Ressourcen. Geben Sie die neue Repräsentation im Body und einen Location-Header zurück.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 201 Created
202 Accepted #

Die Anfrage wurde zur Verarbeitung akzeptiert, ist aber noch nicht abgeschlossen. Die Verarbeitung kann letztendlich erfolgreich oder fehlerhaft sein. RFC 9110 §15.3.3.

Häufige Ursache

Asynchrone Verarbeitung wurde in die Warteschlange gestellt. Die Arbeit passiert später.

Wann verwenden

Hintergrundjobs, Stapelimport-Endpunkte, alles, was eine Job-Status-URL zurückgibt, während die Arbeit noch läuft.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 202 Accepted
204 No Content #

Die Anfrage war erfolgreich; die Antwort hat absichtlich keinen Body. Header können Metadaten enthalten. RFC 9110 §15.3.5.

Häufige Ursache

Ein Update oder Löschen, das keine Repräsentation zurückgeben muss.

Wann verwenden

DELETE-Antworten, PUT/PATCH wenn der Client bereits die neue Repräsentation hat, Save-and-stay-Endpunkte.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 204 No Content
206 Partial Content #

Der Server hat nur einen Teil der Repräsentation als Antwort auf eine Range-Anfrage zurückgegeben. RFC 9110 §15.3.7.

Häufige Ursache

Der Client hat einen Byte-Bereich über den Range-Header angefordert.

Wann verwenden

Resumable Downloads, Video-Streaming mit Seek und parallele Chunk-Downloads.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 206 Partial Content
301 Moved Permanently #

Die Ziel-Ressource hat eine neue permanente URI. Clients SOLLTEN Bookmarks aktualisieren und Suchmaschinen aktualisieren ihre Indizes. RFC 9110 §15.4.2.

Häufige Ursache

Eine Änderung der kanonischen URL — Domain-Umbenennung, Slug-Korrektur, HTTPS-Migration.

Wann verwenden

Langzeit-Umleitungen. 301 vermeiden bei kurzlebigen Umleitungen, weil Clients und Vermittler aggressiv cachen.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 301 Moved Permanently
302 Found #

Die Ziel-Ressource liegt vorübergehend unter einer anderen URI. Clients sollten die neue URI ohne Änderung der Methodensemantik anfordern, aber historisch wandeln die meisten POST in GET um. RFC 9110 §15.4.3.

Häufige Ursache

Temporäre Umleitung mit eigenwilligem Methoden-Umschreibverhalten, beibehalten aus Legacy-Gründen.

Wann verwenden

Legacy-Code-Pfade. Bevorzugen Sie 303 oder 307 in neuen APIs, um eindeutig in der Methoden-Behandlung zu sein.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 302 Found
303 See Other #

Leitet zu einer Ressource um, die mit GET abgerufen werden soll, unabhängig von der ursprünglichen Methode. RFC 9110 §15.4.4.

Häufige Ursache

Nach einem nicht-idempotenten POST sendet der Server den Client zu einer Bestätigungsseite oder einer frisch erstellten Ressource.

Wann verwenden

Post/Redirect/Get-Pattern. Schreibt immer auf GET um, daher sicher nach einem Formular-Versand.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 303 See Other
304 Not Modified #

Die zwischengespeicherte Repräsentation, die der Client bereits hält, ist noch gültig; kein Body wird gesendet. RFC 9110 §15.4.5.

Häufige Ursache

Der Client sendete If-None-Match oder If-Modified-Since und die Validatoren stimmten mit der aktuellen Ressource überein.

Wann verwenden

Bedingte GET-Antworten für Caching. Spart Bandbreite bei unveränderten statischen Assets und API-Antworten.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 304 Not Modified
307 Temporary Redirect #

Wie 302, aber erhält Request-Methode und Body explizit. RFC 9110 §15.4.8.

Häufige Ursache

Eine kurzfristige Umleitung, bei der der ursprüngliche POST/PUT auf der neuen URI wiederholt werden muss.

Wann verwenden

Wartungs-Umleitungen, A/B-Routing oder Geo-Umleitungen, die die ursprüngliche Methode beibehalten müssen.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 307 Temporary Redirect
308 Permanent Redirect #

Wie 301, aber erhält Request-Methode und Body explizit. RFC 9110 §15.4.9.

Häufige Ursache

Eine kanonische URI-Änderung für nicht-GET-Methoden (HTTPS-Upgrade für POST-APIs, Routen-Umbenennungen).

Wann verwenden

Permanente REST-API-Umleitungen. Statt 301 verwenden, wenn die ursprüngliche Methode nicht umgeschrieben werden darf.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 308 Permanent Redirect
400 Bad Request #

Der Server kann die Anfrage wegen eines Client-Fehlers nicht verarbeiten: Syntaxfehler, ungültiges Framing, irreführendes Routing. RFC 9110 §15.5.1.

Häufige Ursache

Defektes JSON, fehlendes Pflichtfeld, fehlerhafter Header, übergroßes Cookie.

Wann verwenden

Generischer Client-Fehler-Fallback. Bevorzugen Sie spezifischere Codes (422, 411, 415), wenn sie passen.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 400 Bad Request
401 Unauthorized #

Der Anfrage fehlen gültige Authentifizierungs-Anmeldedaten. Die Antwort MUSS einen WWW-Authenticate-Header mit den akzeptierten Schemata enthalten. RFC 9110 §15.5.2.

Häufige Ursache

Fehlendes, abgelaufenes oder ungültiges Token; kein Authorization-Header, wo einer erforderlich ist.

Wann verwenden

API-Endpunkte hinter Authentifizierung. Unterscheidet sich von 403 — 401 ist "nicht authentifiziert", 403 ist "authentifiziert, aber nicht erlaubt".

curl -i -X HEAD https://example.com/path
# HTTP/1.1 401 Unauthorized
403 Forbidden #

Der Server hat die Anfrage verstanden, weigert sich aber, sie zu autorisieren. RFC 9110 §15.5.4.

Häufige Ursache

Der Benutzer ist authentifiziert, hat aber keine Berechtigung, oder die Ressource ist von der IP/Region des Benutzers blockiert.

Wann verwenden

Autorisierungs-Fehler, IP-Allowlists, rollenbasierte Zugriffskontrollen.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 403 Forbidden
404 Not Found #

Der Server kann keine aktuelle Repräsentation der Ziel-Ressource finden. Kann auch verwendet werden, um eine 403 zu verbergen. RFC 9110 §15.5.5.

Häufige Ursache

URL-Tippfehler, gelöschte Ressource oder Ressource, die nie existiert hat.

Wann verwenden

Standard-Antwort für fehlende Routen und Ressourcen. Cached weniger aggressiv als 410.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 404 Not Found
405 Method Not Allowed #

Die Methode wird auf der Ressource nicht unterstützt. Die Antwort MUSS einen Allow-Header mit den unterstützten Methoden enthalten. RFC 9110 §15.5.6.

Häufige Ursache

DELETE auf eine schreibgeschützte Sammlung aufrufen, POST auf einer Singleton-Ressource etc.

Wann verwenden

REST-APIs, die explizit über erlaubte Verben sein wollen.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 405 Method Not Allowed
406 Not Acceptable #

Der Server kann keine Repräsentation produzieren, die zu den Accept-*-Headern passt. RFC 9110 §15.5.7.

Häufige Ursache

Client fragte nach application/xml, aber nur application/json ist verfügbar.

Wann verwenden

Strikte Inhaltsvereinbarung. Viele APIs liefern stattdessen JSON aus, statt 406 zurückzugeben.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 406 Not Acceptable
408 Request Timeout #

Der Server hat aufgehört, auf den Client zu warten, der die Anfrage abschließt. RFC 9110 §15.5.9.

Häufige Ursache

Langsame Client-Verbindung, halb-fertiger Upload, Idle-Keep-Alive, der den Server-Timeout überschritten hat.

Wann verwenden

Reverse-Proxies und Load-Balancer vor langsamen Clients.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 408 Request Timeout
409 Conflict #

Die Anfrage steht im Konflikt mit dem aktuellen Zustand der Ressource. RFC 9110 §15.5.10.

Häufige Ursache

Zwei Clients haben denselben Datensatz parallel bearbeitet; Unique-Constraint-Verletzung; PUT mit veraltetem ETag.

Wann verwenden

Optimistische Nebenläufigkeitskontrolle, idempotente Erstellungs-Endpunkte.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 409 Conflict
410 Gone #

Die Ressource wurde absichtlich entfernt und wird nicht zurückkehren. RFC 9110 §15.5.11.

Häufige Ursache

Permanent gelöschte Inhalte; verworfener API-Endpunkt, der eingestellt wurde.

Wann verwenden

Entfernte Seiten, bei denen Crawler die URL schneller verwerfen sollen, als 404 das tun würde.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 410 Gone
411 Length Required #

Der Anfrage fehlt ein Content-Length-Header, wo der Server einen verlangt. RFC 9110 §15.5.12.

Häufige Ursache

Ein Streaming-Client, der den Body nicht gepuffert oder kein Chunked Transfer Encoding genutzt hat.

Wann verwenden

Server, die Chunked Uploads auf bestimmten Endpunkten verbieten.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 411 Length Required
413 Content Too Large #

Der Anfrage-Body ist größer als der Server zu akzeptieren bereit ist. RFC 9110 §15.5.14. In RFC 9110 von "Payload Too Large" umbenannt.

Häufige Ursache

Upload über das konfigurierte Größenlimit, Datei jenseits der maximalen Formulargröße.

Wann verwenden

Datei-Upload-Endpunkte, JSON-APIs mit Body-Größenlimits.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 413 Content Too Large
414 URI Too Long #

Die Request-URI ist länger, als der Server zu interpretieren bereit ist. RFC 9110 §15.5.15.

Häufige Ursache

Riesige Query-Strings (oft von Formularen mit method=GET) oder URL-eingebettete Tokens.

Wann verwenden

Wenn Nutzer Ihren Endpunkt mit ungewöhnlich langen URLs treffen — schalten Sie das Formular auf POST um.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 414 URI Too Long
415 Unsupported Media Type #

Der Server lehnt es ab, den Body in dem im Content-Type-Header beschriebenen Format zu akzeptieren. RFC 9110 §15.5.16.

Häufige Ursache

application/xml an einen JSON-only-Endpunkt senden, fehlender oder falscher Content-Type.

Wann verwenden

REST-APIs, die strikt nur einen oder zwei Medientypen akzeptieren.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 415 Unsupported Media Type
418 I'm a teapot #

Ein Aprilscherz aus RFC 2324 (HTCPCP). Manche Server geben ihn als generischen "Brüh-Verweigerung"-Fehler zurück. Kein echter Produktionsstatus.

Häufige Ursache

Software, die 418 absichtlich zurückgibt — oft um Missbrauchs-Fallen oder Witze zu markieren.

Wann verwenden

Nur Easter Eggs. Nicht in echten APIs verwenden — viele Proxies und Clients erkennen ihn nicht.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 418 I'm a teapot
422 Unprocessable Content #

Die Syntax ist in Ordnung, aber der Server kann den semantischen Inhalt nicht verarbeiten. RFC 9110 §15.5.21. Ursprünglich von WebDAV (RFC 4918) eingeführt.

Häufige Ursache

Validierungsfehler bei strukturell gültigem JSON-Payload — Pflichtfeld leer, Wert außerhalb des Bereichs.

Wann verwenden

Formular-Validierung in modernen APIs. Sauberer als 400, weil die Anfrage syntaktisch gültig ist.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 422 Unprocessable Content
423 Locked #

Die Ressource ist gesperrt. RFC 4918 (WebDAV).

Häufige Ursache

WebDAV-Ressource, auf der ein anderer Benutzer eine exklusive Sperre hält.

Wann verwenden

Dokument-Kollaborationsserver, Versionskontroll-Frontends.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 423 Locked
425 Too Early #

Der Server ist nicht bereit, eine Anfrage zu verarbeiten, die wiederholt werden könnte — typischerweise weil sie in TLS 1.3 0-RTT (Early Data) gesendet wurde. RFC 8470.

Häufige Ursache

TLS-1.3-0-RTT-Anfrage, die der Server als Replay-unsicher behandelt.

Wann verwenden

Schutz nicht-idempotenter Endpunkte vor Replays während 0-RTT-Handshakes.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 425 Too Early
428 Precondition Required #

Der Origin-Server verlangt, dass die Anfrage bedingt ist. RFC 6585.

Häufige Ursache

Der Server möchte, dass Clients If-Match / If-Unmodified-Since verwenden, um Lost-Update-Konflikte zu vermeiden.

Wann verwenden

APIs mit optimistischer Sperrung, die unbedingte Schreibvorgänge ablehnen.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 428 Precondition Required
429 Too Many Requests #

Der Benutzer hat in einem bestimmten Zeitraum zu viele Anfragen gesendet. RFC 6585.

Häufige Ursache

Rate-Limit erreicht; die Antwort enthält normalerweise einen Retry-After-Header.

Wann verwenden

Rate-limitierte APIs, Login-Throttling, Missbrauchs-Eindämmung.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 429 Too Many Requests
431 Request Header Fields Too Large #

Der Server lehnt die Verarbeitung der Anfrage ab, weil ihre Header-Felder zu groß sind. RFC 6585.

Häufige Ursache

Ein übergroßes Cookie, ein extrem langer Referer- oder Authorization-Header.

Wann verwenden

Wenn Session-Cookies über den Reverse-Proxy-Buffer hinauswachsen; Trimmen oder Status in den Body verschieben.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 431 Request Header Fields Too Large
451 Unavailable For Legal Reasons #

Die Ressource ist aus rechtlichen Gründen nicht verfügbar — Take-down-Anweisung, Geo-Block oder DMCA. RFC 7725.

Häufige Ursache

Gerichtsbeschluss, regulatorische Take-down-Anweisung, GDPR-Recht-auf-Vergessen-Antwort.

Wann verwenden

Compliance-Teams, die transparent sein müssen, warum eine Seite blockiert ist.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 451 Unavailable For Legal Reasons
500 Internal Server Error #

Der Server ist auf eine unerwartete Bedingung gestoßen, die ihn an der Erfüllung der Anfrage hinderte. RFC 9110 §15.6.1.

Häufige Ursache

Unbehandelte Ausnahme, Anwendungsfehler, defekte Abhängigkeit, durchgegangene Abfrage.

Wann verwenden

Auffang-Server-Fehler. Loggen Sie immer einen Stack-Trace und eine Request-ID, damit Nutzer sie zitieren können.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 500 Internal Server Error
501 Not Implemented #

Der Server unterstützt nicht die zur Erfüllung der Anfrage erforderliche Funktionalität. RFC 9110 §15.6.2.

Häufige Ursache

Unbekannte Methode, Feature-Flag deaktiviert, Code-Pfad noch leer.

Wann verwenden

API-Endpunkte, die existieren, aber noch nicht gebaut sind. Bevorzugen Sie 405, wenn die Methode falsch ist, andere aber funktionieren.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 501 Not Implemented
502 Bad Gateway #

Das Gateway oder der Proxy hat eine ungültige Antwort vom Upstream-Server erhalten. RFC 9110 §15.6.3.

Häufige Ursache

Upstream gab fehlerhaftes HTTP zurück, die Verbindung brach mitten in der Antwort ab oder die Anwendung stürzte ab.

Wann verwenden

Reverse-Proxies (Nginx, Cloudflare, ALB), wenn die dahinter liegende Anwendung versagt.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 502 Bad Gateway
503 Service Unavailable #

Der Server kann die Anfrage derzeit nicht bedienen, typischerweise wegen Wartung oder Überlastung. RFC 9110 §15.6.4.

Häufige Ursache

Wartungsfenster, Warteschlange voll, Autoscaler nicht hinterhergekommen, absichtliches Brown-out.

Wann verwenden

Geplante Ausfallzeit oder Überlastungsschutz. Setzen Sie immer Retry-After, damit Clients zurückgehen können.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 503 Service Unavailable
504 Gateway Timeout #

Das Gateway oder der Proxy hat keine zeitgerechte Antwort vom Upstream-Server erhalten. RFC 9110 §15.6.5.

Häufige Ursache

Upstream brauchte länger als der konfigurierte Timeout des Proxys, um zu antworten.

Wann verwenden

Langsamer Anwendungscode, blockierte Datenbankabfragen, hängengebliebene Drittanbieter-APIs.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 504 Gateway Timeout
505 HTTP Version Not Supported #

Der Server unterstützt die Major-HTTP-Version der Anfrage nicht. RFC 9110 §15.6.6.

Häufige Ursache

Client spricht HTTP/2 mit einem Server, der nur HTTP/1.0 spricht, oder sendet ein nicht erkanntes Versions-Token.

Wann verwenden

In der Praxis selten. Falsch konfigurierte Edges oder sehr alte Clients.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 505 HTTP Version Not Supported
511 Network Authentication Required #

Der Client muss sich authentifizieren, um das Netzwerk zu nutzen — typischerweise ein Captive Portal. RFC 6585.

Häufige Ursache

Hotel- oder Flughafen-WLAN, das Verkehr abfängt, bis der Login erfolgt.

Wann verwenden

Captive Portals in temporären Netzwerken. Server geben dies normalerweise nicht selbst zurück.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 511 Network Authentication Required

Was sind HTTP-Statuscodes?

Ein HTTP-Statuscode ist die dreistellige Zahl, die ein Server zu Beginn jeder Antwort zurückgibt. Sie gruppieren sich in fünf Familien: 1xx informativ, 2xx Erfolg, 3xx Umleitung, 4xx Client-Fehler und 5xx Server-Fehler. Der genaue Code teilt dem Client mit, wie er die Antwort behandeln soll — von Erfolg über Umleitung, Caching, Authentifizierung bis hin zu Fehlerbehandlung.

So nutzen Sie die Referenz

Tippen Sie einen Code oder Teil eines Namens in das Suchfeld, oder filtern Sie nach Familie über die Chips. Jede Karte öffnet sich, um die technische Beschreibung, häufige Ursachen und einen Tab mit anpassbarem Snippet zu zeigen. Jeder Code hat Beispiele in cURL, Python, JavaScript und PHP.

Statuscode-Familien auf einen Blick

Bereich Familie Bedeutung
1xxInformativVorläufige Antworten; in der Anwendungsschicht selten gesehen.
2xxErfolgAnfrage wurde empfangen, verstanden und akzeptiert.
3xxUmleitungWeitere Aktion ist nötig (andere URL, Cache-Validierung etc.).
4xxClient-FehlerDie Anfrage hatte ein Problem (falsche Eingabe, fehlende Auth, falsche Methode).
5xxServer-FehlerDer Server konnte eine scheinbar gültige Anfrage nicht erfüllen.

Häufig gestellte Fragen

Woher kommen diese Codes?
RFC 9110 ist die kanonische Spezifikation aus 2022, die die ältere RFC-7231-Reihe konsolidiert. Zusätzliche Codes leben in RFC 6585 (428, 429, 431, 511), RFC 7725 (451), RFC 4918 (WebDAV) und RFC 8470 (425).
Sollte ich 401 oder 403 verwenden?
401 bedeutet "Sie sind nicht authentifiziert". 403 bedeutet "Sie sind authentifiziert, aber nicht berechtigt". Eine 401 muss einen WWW-Authenticate-Header mit den akzeptierten Schemata enthalten; eine 403 sollte das nicht, weil die Zugangsdaten bereits korrekt sind.
Was ist der Unterschied zwischen 301 und 308?
Beide signalisieren eine permanente Umleitung. 301 wandelt POST in vielen Clients historisch in GET um, 308 erhält Methode und Body explizit. Verwenden Sie 308 in neuen APIs.
Wann gibt mein CDN 502 vs. 504 zurück?
502 (Bad Gateway) bedeutet, dass der Upstream fehlerhafte Daten zurückgegeben oder die Verbindung geschlossen hat. 504 (Gateway Timeout) bedeutet, dass der Upstream zu lange gebraucht hat. CloudFront, Cloudflare und Nginx markieren sie in Logs unterschiedlich.
Sollte ich 404 oder 410 für gelöschte Inhalte zurückgeben?
Verwenden Sie 410, wenn die Ressource absichtlich und dauerhaft entfernt wurde und Crawler sie schnell verwerfen sollen. 404 ist gut für Tippfehler und Inhalte, die zurückkommen könnten; auch eine vertretbare Antwort für eingeschränkte Ressourcen, deren Existenz Sie nicht enthüllen wollen.
Sind die Snippets sicher zu kopieren?
Ja — sie sind minimale Beispiele, die direkt im Browser laufen oder in einer Sandbox getestet werden können. Vor dem Produktionseinsatz Auth-Header, Fehlerbehandlung und Timeouts prüfen.