Statuscode 413 Request Entity Too Large

Was ist der HTTP-Statuscode 413?

Der HTTP-Statuscode 413 „Request Entity Too Large“ bedeutet, dass ein Server eine Anfrage ablehnt, weil deren übertragener Inhalt das zulässige Größenlimit überschreitet. Die aktuelle Bezeichnung lautet „Content Too Large“. Der Fehler betrifft häufig Datei-Uploads, umfangreiche Formulare, API-Anfragen oder Importprozesse mit großen Datenmengen.

Was bedeutet der Fehler 413?

Der HTTP-Statuscode 413 „Request Entity Too Large“ gehört zur Klasse der 4xx-Statuscodes. Er zeigt an, dass der Server die Anfrage zwar erkannt hat, den enthaltenen Request-Body aufgrund seiner Größe aber nicht verarbeiten will oder kann.

Der Request-Body ist der Inhaltsbereich einer HTTP-Anfrage. Er kann beispielsweise eine hochgeladene Bilddatei, ein Video, Formulardaten, eine JSON-Datei oder einen umfangreichen Datensatz für eine Programmierschnittstelle enthalten. Überschreitet dieser Inhalt ein festgelegtes Limit, kann der Server mit dem Statuscode 413 antworten.

In der aktuellen HTTP-Terminologie heißt der Status „413 Content Too Large“. Ältere Systeme, Dokumentationen und Fehlermeldungen verwenden weiterhin die Bezeichnungen „Payload Too Large“ oder „Request Entity Too Large“. Alle drei Namen beschreiben im Kern denselben HTTP-Fehler.

Wie entsteht ein 413-Fehler?

Ein 413-Fehler entsteht, wenn mindestens eine beteiligte technische Komponente eine niedrigere maximale Anfragegröße erlaubt, als der Client übertragen möchte. Der Client kann ein Browser, ein Crawler, eine App, ein API-Programm oder ein anderes Serversystem sein.

Die Größenbegrenzung kann an mehreren Stellen innerhalb der technischen Infrastruktur greifen:

  • Ein Reverse Proxy oder ein Content Delivery Network lehnt die Anfrage bereits vor dem Webserver ab.
  • Der Webserver begrenzt die maximal erlaubte Größe des Request-Bodys.
  • Die Laufzeitumgebung setzt eigene Limits für Uploads und POST-Anfragen.
  • Ein Framework, ein CMS oder eine E-Commerce-Anwendung beschränkt bestimmte Dateitypen oder Datenmengen.
  • Eine Web Application Firewall blockiert große Anfragen als Sicherheitsmaßnahme.
  • Eine API definiert eine maximale Nutzlast pro Anfrage oder Datensatz.

Bei mehrstufigen Systemen gilt praktisch das niedrigste Limit. Erlaubt die Anwendung beispielsweise 50 Megabyte, während der vorgeschaltete Proxy nur 10 Megabyte akzeptiert, werden Anfragen oberhalb von 10 Megabyte abgewiesen.

Ein Bild mit 12 Megabyte kann trotz eines Upload-Limits von 20 Megabyte einen 413-Fehler auslösen, wenn der Reverse Proxy höchstens 8 Megabyte akzeptiert. Für eine erfolgreiche Übertragung müssen die Grenzwerte aller beteiligten Komponenten aufeinander abgestimmt sein.

Welche Anfragen sind häufig betroffen?

Der Fehler tritt besonders häufig bei Datei-Uploads auf. Typische Beispiele sind das Hochladen großer Produktbilder, Videos, PDF-Dokumente, Backups, Datenbankarchive oder Erweiterungspakete für ein CMS.

Auch Anfragen ohne klassische Datei können zu groß sein. Ein umfangreiches Kontaktformular mit Anhängen, eine API-Anfrage mit mehreren Tausend Datensätzen oder ein Produktimport mit eingebetteten Bilddaten kann den zulässigen Request-Body überschreiten.

Bei E-Commerce-Systemen können 413-Antworten Produktimporte, Feed-Verarbeitung, Medienverwaltung und Schnittstellen zu Warenwirtschaftssystemen unterbrechen. Die genaue Fehlerquelle lässt sich häufig erst erkennen, wenn die Protokolle von Proxy, Webserver und Anwendung gemeinsam geprüft werden.

Wie lässt sich der HTTP-Fehler 413 beheben?

Zur Fehlerbehebung muss zunächst festgestellt werden, welche Komponente den Statuscode ausliefert. Hilfreich sind die Antwort-Header, Serverprotokolle, Proxy-Protokolle, Firewall-Ereignisse und Anwendungslogs. Eine individuell gestaltete Fehlerseite allein behebt die Größenbeschränkung nicht.

Ein systematischer Prüfablauf umfasst folgende Schritte:

  • Ermittle die tatsächliche Größe der fehlgeschlagenen Anfrage einschließlich Anhängen und Kodierungsaufschlägen.
  • Prüfe, ob der Fehler bei jeder Anfrage oder erst ab einer bestimmten Größe auftritt.
  • Kontrolliere zuerst vorgeschaltete Systeme wie Proxy, Firewall oder Content Delivery Network.
  • Vergleiche anschließend die Limits von Webserver, Laufzeitumgebung und Anwendung.
  • Erhöhe nur die notwendigen Grenzwerte und teste danach kleinere sowie größere Anfragen.
  • Überwache Speicherbedarf, Verarbeitungslast und Antwortzeiten nach der Anpassung.

Typische Einstellungen auf dem Server

Bei Nginx wird die zulässige Größe des Request-Bodys häufig über client_max_body_size gesteuert. Apache kann Größenbeschränkungen unter anderem über LimitRequestBody vorgeben. In PHP-Anwendungen müssen zusätzlich Werte wie upload_max_filesize und post_max_size berücksichtigt werden.

Eine Änderung an nur einer Stelle reicht nicht immer aus. Wenn PHP einen Upload von 64 Megabyte erlaubt, der Webserver aber bei 16 Megabyte abbricht, bleibt der Fehler bestehen. Nach Konfigurationsänderungen kann außerdem ein Neustart oder Neuladen des jeweiligen Dienstes erforderlich sein.

Eine Alternative zur pauschalen Erhöhung besteht darin, große Dateien zu komprimieren, Uploads in mehrere Teile aufzuteilen oder umfangreiche API-Daten in mehreren kleineren Anfragen zu übertragen. Solche Chunk- und Batch-Verfahren reduzieren die Belastung einzelner Requests.

Warum sollte das Limit nicht unbegrenzt erhöht werden?

Größenlimits schützen Server vor übermäßigem Speicherverbrauch, langen Verarbeitungszeiten und missbräuchlichen Anfragen. Ein sehr hoher oder unbegrenzter Grenzwert kann die Angriffsfläche vergrößern und bei parallelen Uploads zu einer starken Auslastung führen.

Das passende Limit orientiert sich am tatsächlichen Anwendungsfall. Ein Formular für Textanfragen benötigt eine andere Grenze als eine Medienplattform oder ein Produktimport. Zusätzlich sollten Dateitypen, Benutzerrechte, Speicherquoten und Zeitlimits kontrolliert werden.

Welche Bedeutung hat der Statuscode 413 für SEO?

Ein 413-Statuscode ist normalerweise kein direktes Ranking-Signal, da Suchmaschinen-Crawler Webseiten überwiegend mit GET-Anfragen ohne großen Request-Body abrufen. Der Fehler kann die Suchmaschinenoptimierung jedoch indirekt beeinträchtigen, wenn technische Prozesse oder wichtige Website-Funktionen ausfallen.

Für SEO entsteht ein Risiko, wenn Redakteure keine Bilder oder Dokumente hochladen können, Produktimporte unvollständig bleiben oder Schnittstellen aktualisierte Inhalte nicht übertragen. Fehlerhafte Veröffentlichungsprozesse können dadurch fehlende Medien, veraltete Produktdaten oder unvollständige Seiten verursachen.

Bei einem technischen SEO-Audit sollten wiederkehrende 4xx-Antworten deshalb nach URL, HTTP-Methode und auslösender Anwendung getrennt untersucht werden. Ein gewöhnlicher Website-Crawl mit GET-Anfragen bildet Upload- und API-Probleme nicht in jedem Fall ab.

Eine regelmäßige Überwachung der HTTP-Statuscodes erleichtert es, nicht erreichbare URLs und technische Fehlkonfigurationen frühzeitig zu erkennen. Der SEO-Technik-Crawler der Performance Suite kann Statuscodes und weitere technische Eigenschaften einer Website automatisiert kontrollieren.

Welche Auswirkungen hat der Fehler auf SEA und GEO?

Im SEA kann ein 413-Fehler die Conversion-Erfassung indirekt beeinträchtigen, wenn Nutzer auf einer beworbenen Landingpage Formulare mit Anhängen nicht absenden können. Der Seitenaufruf funktioniert dabei möglicherweise fehlerfrei, während erst der abschließende POST-Request scheitert.

Für GEO, die Generative Engine Optimization, besitzt der Statuscode ebenfalls vor allem indirekte Bedeutung. Wenn Content-, Produkt- oder API-Workflows aufgrund zu großer Anfragen abbrechen, können Informationen fehlen, die Suchmaschinen und KI-Systeme später als Quelle erfassen sollen.

Technische Tests sollten daher auch die Aktionen hinter einer Landingpage berücksichtigen. Neben dem HTTP-Status beim Seitenaufruf gehören dazu Formulare, Uploads, Suchfunktionen, Produktimporte und API-Endpunkte. Für eine umfassende Prüfung technischer und inhaltlicher Faktoren bietet sich ein kostenloser SEO-Check als erster Überblick an.

Abgrenzung zu ähnlichen HTTP-Statuscodes

StatuscodeBezeichnungBedeutungAbgrenzung zu 413
400Bad RequestDie Anfrage ist fehlerhaft aufgebaut.Bei 413 ist vor allem der Anfrageinhalt zu groß.
414URI Too LongDie aufgerufene Adresse oder Abfragezeichenfolge ist zu lang.413 betrifft den Request-Body, 414 die URI.
429Too Many RequestsDer Client sendet zu viele Anfragen in kurzer Zeit.429 begrenzt die Häufigkeit, 413 die Größe einer Anfrage.
431Request Header Fields Too LargeEinzelne Header oder die Gesamtheit der Header sind zu groß.413 bezieht sich auf den Inhalt hinter den Headern.
500Internal Server ErrorBei der serverseitigen Verarbeitung tritt ein unerwarteter Fehler auf.413 ist eine gezielte Ablehnung aufgrund eines bekannten Größenlimits.

Wenn 413-Fehler wiederholt Formulare, Schnittstellen oder Veröffentlichungsprozesse beeinträchtigen, sollte die gesamte Verarbeitungskette geprüft werden. Fragen zu technischen SEO-Problemen und ihrer Priorisierung lassen sich im Rahmen einer kostenlosen Erstberatung einordnen.

Häufige Fragen zum HTTP-Fehler 413

Kann der Browser einen 413-Fehler verursachen?

Der Browser löst den Fehler durch das Senden einer zu großen Anfrage aus, der Statuscode selbst wird jedoch gewöhnlich von einem Server, Proxy oder Sicherheitssystem zurückgegeben.

Kann ein 413-Fehler nur bei Datei-Uploads auftreten?

Nein. Auch große JSON-Daten, umfangreiche Formulare, XML-Importe oder andere POST- und PUT-Anfragen können das erlaubte Größenlimit überschreiten.

Hilft das Leeren des Browser-Caches bei einem 413-Fehler?

Das Leeren des Browser-Caches behebt ein serverseitiges Größenlimit normalerweise nicht. Es kann nur helfen, wenn eine veraltete Anwendung fehlerhafte Anfragen erzeugt.

Kann der Server bei einem 413-Fehler die Verbindung schließen?

Ja. Ein Server kann die Verbindung beenden, wenn er die zu große Anfrage nicht weiter empfangen oder verarbeiten möchte.

Sollte bei einem temporären Größenlimit ein Retry-After-Header gesendet werden?

Ist die Ablehnung nur vorübergehend, kann der Server mit dem Retry-After-Header angeben, wann der Client die Anfrage erneut versuchen sollte.


Sie haben noch Fragen?

Kontaktieren Sie uns

SEO Agentur kostenlose SEO Potentialanalyse


Weitere Inhalte