Cloudflare Pages dropper _redirects over 100KB i det stille

Dokumentasjonen til Cloudflare Pages forteller deg at grensen er 2000 redirects. Den lyver ikke, men den peker på feil tall. Grensen som tok kritiske redirects av dette nettstedet i produksjon var filstørrelsesgrensen på 100KB, og feilmodusen er den verste sorten: stille. Ingen build-feil. Ingen deploy-advarsel. Ingen loglinje. _redirects-filen lastes opp, deployen blir grønn, og en del av reglene dine fyrer rett og slett aldri av.

Dette er en polemikk mot måten grensen læres bort på. “Hold deg under 2000 regler” er rådet alle gjentar, og det er rådet som lot filen vår vokse til omtrent 157KB mens den fortsatt var langt unna 2000 regler. Tallet som betydde noe sto aldri i setningen vi fulgte med på.

#Cloudflares _redirects-byte-grense: TL;DR i 4 punkter

• Cloudflare Pages begrenser _redirects på tre måter: 2000 statiske regler, 100 dynamiske regler og 100KB filstørrelse. Den første er den alle siterer; den tredje er den som knekker produksjon.
• Regler forbi 100KB-byte-grensen droppes når filen behandles ved deploy. Det er ingen advarsel. Den deployede filen slutter rett og slett å anvende regler ved en eller annen linje.
• Et nettsted på seks språk med lange beskrivende slugs krysser 100KB rundt 1200 til 1300 regler, langt under regeltallsgrensen. Så du treffer byte-veggen mens dashbordet fortsatt sier du har klaring.
• Fiksen er ikke “slett redirects”. Det er å flytte én-til-én-regler i bulk inn i en Pages Function, som er begrenset av en komprimert skriptstørrelse på 1MB, ikke 100KB-redirects-grensen.

#Ordliste: _redirects, Pages Functions, splat, 301

Denne saken hviler på noen få plattformkonsepter. Hvis noen er ukjent, er det verdt tretti sekunder, fordi feilen gjemmer seg akkurat i gapet mellom dem.

• _redirects - en ren tekstfil i build-utdataen (her public/_redirects) der hver linje er én regel: en kildesti, en destinasjon og en valgfri statuskode. Cloudflare Pages leser den ved deploy og anvender reglene på edge før nettstedet ditt treffes.
• Statisk redirect - en bokstavelig én-til-én-regel, for eksempel /old-page/ /new-page/ 301. Ingen wildcards.
• Dynamisk redirect - en regel med en wildcard * eller en :splat-plassholder, for eksempel /blog/* /articles/:splat 301. Disse bruker Cloudflares stimal-motor og er begrenset til 100 per fil.
• 301 - HTTP-statusen for en permanent redirect. Den forteller Google at den gamle URL-en har flyttet for godt og at rangeringssignalet bør følge til den nye URL-en.
• Pages Function - et lite serverless-skript (her under functions/) som kjører på edge ved hver matchende forespørsel. Det kan lese en oppslagstabell og utstede redirects i kode, uten 100KB-tak.
• _middleware.ts - Pages Function-en som kjører ved hver forespørsel før ruting. Det naturlige stedet for et kart-oppslag og en 301 hvis stien matcher.

Disse skillene er usynlige helt til en redirect slutter å fyre av. Da er de hele historien.

#Hvordan en 157KB stor _redirects-fil knakk produksjon

Filen vokste ikke uvøren. Den vokste slik redirect-kartet til ethvert langlivet flerspråklig nettsted vokser: hver gang en slug ble ryddet opp, en utdatert URL pensjonert eller en språkvariant reorganisert, ble et par (gammel, ny) lagt til. Seks språk, beskrivende slugs som /pl/tworzenie-stron-internetowych-oraz-sklepow-wordpress/ og noen års rydding satte filen på omtrent 157KB og rundt 1890 regler.

Ingen var bekymret, fordi 1890 er under 2000. Det var feilen. Byte-grensen var krysset for lengst før regelgrensen var i nærheten.

Symptomet så først ikke ut som et redirect-problem. Det så ut som tre urelaterte branner:

• Google Merchant Center flagget to av tolv produkter som utilgjengelige produktsider. Feed-destinasjonene deres var redirects som lå nær bunnen av filen.
• Google Search Console rapporterte 388 URL-er med “Ikke funnet (404)”. En stor andel av dem hadde _redirects-oppføringer som på papiret skulle ha fanget dem.
• GSC-validering fortsatte å mislykkes gang på gang. Vi ba om validering, Google besøkte URL-en på nytt, traff samme 404 fordi redirecten aldri var live, og avviste valideringen. Løkken brøt ikke av seg selv.

Sidene, malene, builden, regeltallet, alt så friskt ut. Rutinglaget var i det stille amputert under en linje ingen så på.

#Hvordan bekrefte at halen blir droppet

Diagnosen er mekanisk så snart du slutter å stole på filen og begynner å stole på edge. Ikke stikkprøv regler tilfeldig; stikkprøv dem etter posisjon.

1. Ta en regel nær toppen av _redirects, en fra midten og en nær bunnen.
2. Be om hver kildesti i produksjon og les bare statuskoden: curl -s -o /dev/null -w "%{http_code}" https://nettstedet-ditt/kildesti/.
3. Sammenlign. På dette nettstedet returnerte regler rundt linje 9 til 130 301 rent. Regler forbi omtrent linje 200 returnerte 404, med noen falske beståtte der urelatert middleware-logikk (kryssspråklig slug-deteksjon, legacy-mønstre) tilfeldigvis fanget URL-en på en annen vei.

Når toppen av filen virker og halen 404-er mens begge reglene er committet og identiske i form, er konklusjonen ikke tvetydig: filen blir kuttet ved byte-grensen. Den nøyaktige avkuttingslinjen avhenger av hvor lang den gjennomsnittlige regelen din er, og det er derfor et nettsted på seks språk med lange slugs treffer den tidligere enn regeltallet antyder.

#Hvorfor byte-grensen er den bindende grensen, ikke regeltallet

Aritmetikken er hele argumentet. En kort regel som /a/ /b/ 301 er omtrent 12 byte. En realistisk flerspråklig regel, /pl/tworzenie-stron-wordpress/ /pl/tworzenie-stron-internetowych-oraz-sklepow-wordpress/ 301, ligger nærmere 90 byte. Ved 80 til 90 byte per regel er 100KB oppbrukt rundt 1200 til 1300 regler - hundrevis under de 2000 dokumentasjonen setter i forgrunnen. Grensen du følger med på bør være den du treffer først, og for nettsteder med beskrivende slugs er det byte, ikke linjer.

#Hva Cloudflare-dokumentasjonen sier, og hva den utelater

Redirects-dokumentasjonen lister opp alle tre grensene. 100KB-tallet står der svart på hvitt. Det siden ikke sier noe sted, er hva som skjer når du overskrider det: reglene forbi grensen droppes, og deployen lykkes likevel. Kontrasten med regeltallsgrensen betyr noe. Overskrid 2000 regler og builden bringer det frem; filen er for stor på en måte plattformen forteller deg om. Overskrid 100KB og plattformen kutter og holder seg stille.

Den asymmetrien er fellen. En grense som feiler høyt, trener deg til å respektere den. En grense som feiler i det stille, trener deg til å ignorere den, fordi ingenting noensinne blir rødt. Den samme problemklassen dukker opp i søsterfilen _headers, som bærer sine egne størrelsesbegrensninger, og i ethvert build-artefakt der “det deployet” forveksles med “det ble alt anvendt”. Plattformkontrakten du bør internalisere er ikke det største tallet på grensesiden; det er det minste tallet som feiler uten å fortelle deg det. Det samme tillitsgapet ligger til grunn for vår tidligere gjennomgang av hvordan AI-oversettelse ødelegger flerspråklig SEO på det strukturelle laget: i begge tilfeller ser den synlige utdataen korrekt ut mens rutinglaget under er ødelagt.

#Fiksen: flytt redirects i bulk inn i en Pages Function

_redirects er feil lagring for tusenvis av bokstavelige regler. Riktig lagring er en Pages Function som leser et kart. Functions er begrenset av komprimert skriptstørrelse, opptil 1MB, ikke av 100KB-redirects-grensen, så et 200KB redirect-kart passer med omtrent fem ganger klaringen.

Migreringen på dette nettstedet, levert i én enkelt commit den 2026-05-07, hadde tre deler:

1. functions/redirect-map.ts eksporterer et ReadonlyMap<string, string> av kilde-til-destinasjon-par. Nøklene normaliseres én gang - små bokstaver, etterfølgende skråstrek lagt til, gjentatte skråstreker slått sammen - så hver forespørsel er et enkelt O(1)-oppslag, ikke en skanning. Det startet på 1851 oppføringer og holder nå 2233.
2. functions/_middleware.ts utfører oppslaget mellom de eksisterende normaliseringstrinnene (skråstrek-sammenslåing, diakritikk-ASCIIfisering) og det etterfølgende skråstrek-trinnet. Det bygger den normaliserte nøkkelen, sjekker kartet og utsteder en direkte 301 til målet ved treff.
3. public/_redirects ble trimmet fra omtrent 157KB til grovt 3,3KB og 41 regler: en header-kommentar, fire Merchant Center-regler med høyest prioritet, og wildcard- eller :splat-reglene som virkelig trenger Cloudflares stimal-motor.

Tretti regler stikkprøvd tilfeldig fra det nye kartet returnerte alle 301 rent i produksjon. 404-løkken i Search Console endte så snart redirectene den fortsatte å forvente faktisk fantes på edge.

#Middleware-rekkefølge er en del av fiksen

Å flytte reglene inn i en Function er bare riktig hvis oppslaget kjører på rett punkt i forespørselen. _middleware.ts gjorde allerede ekte arbeid før migreringen: det gjør små bokstaver og slår sammen gjentatte skråstreker, ASCIIfiserer diakritikk slik at /pl/wdrozenia/ og en diakritikk-spekket variant løses til samme rute, og legger til en etterfølgende skråstrek. Kart-oppslaget må sitte etter normalisering og før den etterfølgende skråstrek-redirecten, ellers dukker to bugs opp.

Sett oppslaget for tidlig, før skråstreker slås sammen, og en nøkkel som ble normalisert ved build-tid (små bokstaver, enkle skråstreker, etterfølgende skråstrek) matcher aldri en rå innkommende sti med dobbel skråstrek eller blandet store/små bokstaver. Kartet bommer i det stille og URL-en faller gjennom til en 404, som ser akkurat ut som buggen du prøvde å fikse. Sett det for sent, etter at den etterfølgende skråstrek-redirecten allerede har utstedt en 301, og du betaler to hopp for hver omdirigerte forespørsel: ett for å legge til skråstreken, ett for å nå destinasjonen. To-hopps-redirects blør lenkeverdi og bremser crawlingen. Kartet må konsumere den allerede normaliserte nøkkelen og kortslutte med en enkelt 301. Edge-rutinglogikk er sekvensiell, ikke en pose med uavhengige regler, og rekkefølgen er like bærende som reglene selv. Flere gjennomganger om edge og plattformer ligger på wppoland-bloggen.

#Alternativer vi forkastet, og hvorfor

Et statisk kart kompilert inn i Function-en var ikke det eneste alternativet. To andre lå på bordet.

• Workers KV. Lagre redirect-parene i et nøkkel-verdi-namespace og slå dem opp ved kjøretid. Dette skalerer til millioner av oppføringer og kobler redirects fra deploys. Vi forkastet det for dette nettstedet: et KV-oppslag legger nettverkslatens til hver forespørsel som kan være en redirect, lesegrensene i gratisnivået er et reelt tak ved trafikken vår, og 2200 regler passer komfortabelt i et kompilert kart som leveres med Function-en og koster ingenting ved forespørselstid. KV gjør seg fortjent når redirect-settet er stort nok eller flyktig nok til at re-deploy for å endre det er smertefullt. Vårt er ingen av delene.
• Dele _redirects på flere mindre filer. Cloudflare Pages leser én _redirects-fil; det finnes ingen include-mekanisme, så dette var aldri reelt. Instinktet bak det - fortsette å bruke den plattformnative funksjonen - er det samme instinktet som lot filen vokse forbi grensen i utgangspunktet.

Det kompilerte kartet vant fordi det fjerner grensen fra ligningen helt mens det holder oppslag i minnet og kostnadsfrie per forespørsel. Beslutningen er ikke universell; den er riktig for et redirect-sett i de lave tusener som endres noen ganger i måneden.

#Hvordan holde redirect-laget friskt etterpå

Migreringen er ingen engangsflukt; uten disiplin sniker filen seg tilbake. Reglene som har holdt siden:

• Nye statiske én-til-én-redirects går i Function-kartet, aldri i _redirects. Legg til i functions/redirect-map.ts.
• Nye wildcard- eller :splat-redirects går i _redirects, som nå har grovt tretti ganger sin tidligere klaring under grensen.
• Følg med på byte-størrelsen, ikke regeltallet. En linje i CI som lar builden feile hvis public/_redirects krysser omtrent 50KB gir en bred margin før den stille 100KB-veggen. Regeltall er en forfengelighetsmetrikk her; byte er kontrakten.
• Stikkprøv etter posisjon etter enhver stor redirect-endring. Topp, midt, hale. Det tar tre curl-kall og fanger avkutting før Google gjør det.

Den dypere lærdommen overlever Cloudflare spesifikt. En plattformgrense som feiler i det stille er farligere enn en hard grense som feiler, fordi den grønne deployen trener deg til å stole på en fil som ikke lenger anvendes fullt ut. Når en grense er dokumentert som ett tall og håndhevet som et annet, er gapet der produksjon brister. Les grensesiden for hvert tall på den, verifiser deretter det som feiler i det stille mot den levende edge, ikke mot den committede filen.