Cloudflare Pages verwirft _redirects über 100KB still und leise

Die Dokumentation von Cloudflare Pages sagt Ihnen, das Limit liege bei 2.000 Redirects. Sie lügt nicht, aber sie zeigt auf die falsche Zahl. Das Limit, das auf dieser Website kritische Redirects in der Produktion ausgeschaltet hat, war die Dateigröße-Grenze von 100KB, und der Fehlermodus ist von der schlimmsten Sorte: still. Kein Build-Fehler. Keine Deploy-Warnung. Keine Logzeile. Die _redirects-Datei lädt hoch, der Deploy wird grün, und ein Teil Ihrer Regeln greift einfach nie.

Dies ist eine Polemik gegen die Art, wie das Limit gelehrt wird. “Bleiben Sie unter 2.000 Regeln” ist der Rat, den alle wiederholen, und es ist der Rat, der unsere Datei auf etwa 157KB wachsen ließ, während sie noch nirgends nahe an 2.000 Regeln war. Die Zahl, auf die es ankam, stand nie in dem Satz, den wir beobachteten.

#Die _redirects-Byte-Grenze von Cloudflare: TL;DR in 4 Punkten

• Cloudflare Pages begrenzt _redirects auf drei Arten: 2.000 statische Regeln, 100 dynamische Regeln und 100KB Dateigröße. Die erste zitiert jeder; die dritte zerstört die Produktion.
• Regeln jenseits der 100KB-Byte-Grenze werden verworfen, wenn die Datei beim Deploy verarbeitet wird. Es gibt keine Warnung. Die deployte Datei hört ab einer bestimmten Zeile einfach auf, Regeln anzuwenden.
• Eine Website in sechs Sprachen mit langen beschreibenden Slugs überschreitet 100KB bei etwa 1.200 bis 1.300 Regeln, weit unter dem Limit der Regelanzahl. Sie stoßen also gegen die Byte-Wand, während das Dashboard noch behauptet, Sie hätten Puffer.
• Der Fix lautet nicht “Redirects löschen”. Es ist, Eins-zu-eins-Regeln in Massen in eine Pages Function zu verschieben, die durch eine komprimierte Skriptgröße von 1MB statt der 100KB-Redirects-Grenze begrenzt ist.

#Glossar: _redirects, Pages Functions, Splat, 301

Dieser Fall ruht auf einigen Plattformkonzepten. Falls Ihnen eines unbekannt ist, lohnen sich dreißig Sekunden, denn der Fehler versteckt sich genau in der Lücke zwischen ihnen.

• _redirects - eine reine Textdatei in der Build-Ausgabe (hier public/_redirects), in der jede Zeile eine Regel ist: ein Quellpfad, ein Ziel und ein optionaler Statuscode. Cloudflare Pages liest sie beim Deploy und wendet die Regeln am Edge an, bevor Ihre Website getroffen wird.
• Statischer Redirect - eine wörtliche Eins-zu-eins-Regel, zum Beispiel /old-page/ /new-page/ 301. Keine Wildcards.
• Dynamischer Redirect - eine Regel mit einer Wildcard * oder einem :splat-Platzhalter, zum Beispiel /blog/* /articles/:splat 301. Diese nutzen die Pfad-Template-Engine von Cloudflare und sind auf 100 pro Datei begrenzt.
• 301 - der HTTP-Status für einen permanenten Redirect. Er sagt Google, dass die alte URL endgültig umgezogen ist und das Ranking-Signal der neuen URL folgen soll.
• Pages Function - ein kleines Serverless-Skript (hier unter functions/), das am Edge bei jeder passenden Anfrage läuft. Es kann eine Lookup-Tabelle lesen und Redirects im Code ausstellen, ohne 100KB-Decke.
• _middleware.ts - die Pages Function, die bei jeder Anfrage vor dem Routing läuft. Der natürliche Ort für einen Map-Lookup und einen 301, wenn der Pfad passt.

Diese Unterscheidungen sind unsichtbar, bis ein Redirect aufhört zu greifen. Dann sind sie die ganze Geschichte.

#Wie eine 157KB große _redirects-Datei die Produktion zerstörte

Die Datei wuchs nicht leichtsinnig. Sie wuchs so, wie die Redirect-Map jeder langlebigen mehrsprachigen Website wächst: jedes Mal, wenn ein Slug bereinigt, eine veraltete URL stillgelegt oder eine Sprachvariante reorganisiert wurde, wurde ein Paar (alt, neu) angehängt. Sechs Sprachen, beschreibende Slugs wie /pl/tworzenie-stron-internetowych-oraz-sklepow-wordpress/ und ein paar Jahre Pflege brachten die Datei auf grob 157KB und etwa 1.890 Regeln.

Niemand machte sich Sorgen, denn 1.890 liegt unter 2.000. Das war der Fehler. Die Byte-Grenze war längst überschritten, bevor das Regellimit auch nur in die Nähe kam.

Das Symptom sah zunächst nicht nach einem Redirect-Problem aus. Es sah aus wie drei unzusammenhängende Brände:

• Google Merchant Center markierte zwei von zwölf Produkten als nicht verfügbare Produktseiten. Ihre Feed-Ziele waren Redirects, die nahe dem Ende der Datei lagen.
• Google Search Console meldete 388 URLs “Nicht gefunden (404)”. Ein großer Teil davon hatte _redirects-Einträge, die sie auf dem Papier hätten abfangen müssen.
• Die GSC-Validierung scheiterte wiederholt. Wir forderten die Validierung an, Google besuchte die URL erneut, traf auf denselben 404, weil der Redirect nie live war, und lehnte die Validierung ab. Die Schleife brach nicht von selbst.

Die Seiten, die Templates, der Build, die Regelanzahl, alles sah gesund aus. Die Routing-Schicht war still und leise unterhalb einer Zeile amputiert worden, auf die niemand sah.

#Wie Sie bestätigen, dass das Ende abgeschnitten wird

Die Diagnose ist mechanisch, sobald Sie aufhören, der Datei zu vertrauen, und beginnen, dem Edge zu vertrauen. Stichproben Sie Regeln nicht zufällig; stichproben Sie sie nach Position.

1. Nehmen Sie eine Regel nahe dem Anfang von _redirects, eine aus der Mitte und eine nahe dem Ende.
2. Rufen Sie jeden Quellpfad in der Produktion auf und lesen Sie nur den Statuscode: curl -s -o /dev/null -w "%{http_code}" https://ihre-website/quellpfad/.
3. Vergleichen Sie. Auf dieser Website gaben Regeln um Zeile 9 bis 130 sauber 301 zurück. Regeln jenseits von etwa Zeile 200 gaben 404 zurück, mit ein paar falschen Durchläufen, bei denen unzusammenhängende Middleware-Logik (sprachübergreifende Slug-Erkennung, Legacy-Muster) die URL zufällig auf anderem Weg abfing.

Wenn der Anfang der Datei funktioniert und das Ende 404 liefert, während beide Regeln committet und in der Form identisch sind, ist der Schluss nicht mehrdeutig: Die Datei wird an der Byte-Grenze abgeschnitten. Die genaue Abschneidezeile hängt davon ab, wie lang Ihre durchschnittliche Regel ist, weshalb eine Website in sechs Sprachen mit langen Slugs früher darauf stößt, als die Regelanzahl vermuten lässt.

#Warum die Byte-Grenze die bindende Grenze ist, nicht die Regelanzahl

Die Arithmetik ist das ganze Argument. Eine kurze Regel wie /a/ /b/ 301 umfasst etwa 12 Bytes. Eine realistische mehrsprachige Regel, /pl/tworzenie-stron-wordpress/ /pl/tworzenie-stron-internetowych-oraz-sklepow-wordpress/ 301, liegt näher bei 90 Bytes. Bei 80 bis 90 Bytes pro Regel sind 100KB bei etwa 1.200 bis 1.300 Regeln erschöpft - Hunderte unter den 2.000, die die Dokumentation in den Vordergrund stellt. Die Grenze, die Sie beobachten, sollte die sein, gegen die Sie zuerst stoßen, und für Websites mit beschreibenden Slugs sind das Bytes, nicht Zeilen.

#Was die Cloudflare-Doku sagt und was sie auslässt

Die Redirects-Dokumentation listet alle drei Grenzen auf. Die Zahl 100KB steht dort schwarz auf weiß. Was die Seite nirgends sagt, ist, was passiert, wenn Sie sie überschreiten: Die Regeln jenseits der Grenze werden verworfen, und der Deploy gelingt trotzdem. Der Kontrast zum Regellimit ist entscheidend. Überschreiten Sie 2.000 Regeln, bringt der Build es ans Licht; die Datei ist auf eine Weise zu groß, von der die Plattform Ihnen erzählt. Überschreiten Sie 100KB, schneidet die Plattform ab und bleibt still.

Diese Asymmetrie ist die Falle. Eine Grenze, die laut fehlschlägt, erzieht Sie dazu, sie zu respektieren. Eine Grenze, die still versagt, erzieht Sie dazu, sie zu ignorieren, weil nie etwas auf Rot geht. Dieselbe Problemklasse taucht in der Schwesterdatei _headers auf, die ihre eigenen Größenbeschränkungen trägt, und in jedem Build-Artefakt, in dem “es wurde deployt” mit “es wurde alles angewendet” verwechselt wird. Der Plattformvertrag, den Sie verinnerlichen sollten, ist nicht die größte Zahl auf der Limit-Seite; es ist die kleinste Zahl, die versagt, ohne es Ihnen zu sagen. Dieselbe Vertrauenslücke liegt unserer früheren Aufarbeitung darüber zugrunde, wie KI-Übersetzung mehrsprachiges SEO auf der strukturellen Schicht zerstört: in beiden Fällen sieht die sichtbare Ausgabe korrekt aus, während die Routing-Schicht darunter kaputt ist.

#Der Fix: Redirects in Massen in eine Pages Function verschieben

_redirects ist der falsche Speicher für Tausende wörtlicher Regeln. Der richtige Speicher ist eine Pages Function, die eine Map liest. Functions sind durch die komprimierte Skriptgröße von bis zu 1MB begrenzt, nicht durch die 100KB-Redirects-Grenze, sodass eine 200KB große Redirect-Map mit etwa fünffachem Puffer passt.

Die Migration auf dieser Website, ausgeliefert in einem einzigen Commit am 2026-05-07, hatte drei Teile:

1. functions/redirect-map.ts exportiert eine ReadonlyMap<string, string> aus Quell-Ziel-Paaren. Die Schlüssel werden einmal normalisiert - kleingeschrieben, mit angehängtem Slash am Ende, mit zusammengefassten wiederholten Slashes - sodass jede Anfrage ein einzelner O(1)-Lookup ist, kein Scan. Sie begann mit 1.851 Einträgen und hält nun 2.233.
2. functions/_middleware.ts führt den Lookup zwischen den bestehenden Normalisierungsschritten (Slash-Zusammenfassung, Diakritika-ASCIIfizierung) und dem Slash-am-Ende-Schritt durch. Es baut den normalisierten Schlüssel, prüft die Map und stellt bei einem Treffer einen direkten 301 zum Ziel aus.
3. public/_redirects wurde von etwa 157KB auf grob 3,3KB und 41 Regeln gekürzt: ein Header-Kommentar, vier Merchant-Center-Regeln höchster Priorität und die Wildcard- oder :splat-Regeln, die wirklich die Pfad-Template-Engine von Cloudflare brauchen.

Dreißig zufällig aus der neuen Map gezogene Regeln gaben in der Produktion alle sauber 301 zurück. Die 404-Schleife in der Search Console endete, sobald die Redirects, die sie weiter erwartete, am Edge tatsächlich existierten.

#Die Middleware-Reihenfolge ist Teil des Fixes

Die Regeln in eine Function zu verschieben ist nur dann korrekt, wenn der Lookup an der richtigen Stelle der Anfrage läuft. _middleware.ts leistete schon vor der Migration echte Arbeit: Es schreibt klein und fasst wiederholte Slashes zusammen, ASCIIfiziert Diakritika, sodass /pl/wdrozenia/ und eine diakritikadurchsetzte Variante auf dieselbe Route auflösen, und fügt einen Slash am Ende hinzu. Der Map-Lookup muss nach der Normalisierung und vor dem Slash-am-Ende-Redirect sitzen, sonst tauchen zwei Bugs auf.

Setzen Sie den Lookup zu früh, vor dem Zusammenfassen der Slashes, dann passt ein Schlüssel, der zur Build-Zeit normalisiert wurde (kleingeschrieben, einzelne Slashes, Slash am Ende), nie zu einem rohen eingehenden Pfad mit doppeltem Slash oder gemischter Groß-/Kleinschreibung. Die Map verfehlt still, und die URL fällt durch zu einem 404, was genau wie der Bug aussieht, den Sie zu beheben versuchten. Setzen Sie ihn zu spät, nachdem der Slash-am-Ende-Redirect bereits einen 301 ausgestellt hat, dann zahlen Sie zwei Hops für jede umgeleitete Anfrage: einen, um den Slash hinzuzufügen, einen, um das Ziel zu erreichen. Zwei-Hop-Redirects bluten Link-Equity aus und bremsen das Crawling. Die Map muss den bereits normalisierten Schlüssel konsumieren und mit einem einzigen 301 kurzschließen. Edge-Routing-Logik ist sequenziell, kein Sack unabhängiger Regeln, und die Reihenfolge ist so tragend wie die Regeln selbst. Mehr Aufarbeitungen zu Edge und Plattformen finden Sie im wppoland-Blog.

#Verworfene Alternativen und warum

Eine in die Function kompilierte statische Map war nicht die einzige Option. Zwei weitere lagen auf dem Tisch.

• Workers KV. Speichern Sie die Redirect-Paare in einem Schlüssel-Wert-Namespace und schlagen Sie sie zur Laufzeit nach. Das skaliert auf Millionen Einträge und entkoppelt Redirects von Deploys. Wir haben es für diese Website verworfen: Ein KV-Read fügt jeder Anfrage Netzwerklatenz hinzu, die ein Redirect sein könnte, die Read-Limits des kostenlosen Tarifs sind bei unserem Traffic eine reale Decke, und 2.200 Regeln passen komfortabel in eine kompilierte Map, die mit der Function ausgeliefert wird und zur Anfragezeit nichts kostet. KV verdient sein Geld, wenn die Redirect-Menge groß oder volatil genug ist, dass ein erneutes Deployen zur Änderung schmerzt. Unsere ist keines von beidem.
• _redirects auf mehrere kleinere Dateien aufteilen. Cloudflare Pages liest eine _redirects-Datei; es gibt keinen Include-Mechanismus, also war das nie real. Der Instinkt dahinter - das plattformeigene Feature weiter zu nutzen - ist derselbe Instinkt, der die Datei überhaupt erst über die Grenze wachsen ließ.

Die kompilierte Map gewann, weil sie die Grenze ganz aus der Gleichung nimmt und dabei Lookups im Speicher und pro Anfrage kostenlos hält. Die Entscheidung ist nicht universell; sie ist richtig für eine Redirect-Menge im niedrigen Tausenderbereich, die sich ein paar Mal im Monat ändert.

#Wie Sie die Redirect-Schicht danach gesund halten

Die Migration ist keine einmalige Flucht; ohne Disziplin schleicht die Datei zurück. Die Regeln, die seither gehalten haben:

• Neue statische Eins-zu-eins-Redirects kommen in die Function-Map, nie in _redirects. Hängen Sie an functions/redirect-map.ts an.
• Neue Wildcard- oder :splat-Redirects kommen in _redirects, das jetzt grob den dreißigfachen Puffer unter der Grenze hat.
• Achten Sie auf die Byte-Größe, nicht auf die Regelanzahl. Eine Zeile in CI, die den Build fehlschlagen lässt, wenn public/_redirects etwa 50KB überschreitet, gibt einen weiten Spielraum vor der stillen 100KB-Wand. Die Regelanzahl ist hier eine Vanity-Metrik; Bytes sind der Vertrag.
• Prüfen Sie nach jeder großen Redirect-Änderung nach Position. Anfang, Mitte, Ende. Es kostet drei curl-Aufrufe und fängt das Abschneiden, bevor Google es tut.

Die tiefere Lektion überlebt Cloudflare im Besonderen. Eine Plattformgrenze, die still versagt, ist gefährlicher als eine harte Grenze, die einen Fehler wirft, weil der grüne Deploy Sie dazu erzieht, einer Datei zu vertrauen, die nicht mehr vollständig angewendet wird. Wenn eine Grenze als eine Zahl dokumentiert und als eine andere erzwungen wird, ist die Lücke der Ort, an dem die Produktion bricht. Lesen Sie die Limit-Seite für jede Zahl auf ihr, dann verifizieren Sie die, die still versagt, gegen den lebenden Edge, nicht gegen die committete Datei.