Cloudflare Pages mit Vite-SPA: Build-Zeit, große Assets und warum nur das Dashboard nicht reicht

Kurzfassung: Eure Marketing-SPA (z. B. Vite plus React) landet auf Cloudflare Pages als statischer Build plus optionale Functions. Viele Teams unterschätzen dabei eine Sache: Umgebungsvariablen für den Browser werden beim Build eingefroren. Wer nach dem Deploy nur das Cloudflare-Dashboard ändert, ohne neu zu bauen, wundert sich, warum Links, URLs oder Videos alt bleiben.

Das ist kein Cloudflare-Fehler, sondern erwartetes Verhalten bei clientseitig eingebetteten Konstanten.

Build-Zeit vs. Laufzeit (für VITE_-Präfixe)

• Alles, was im Frontend-Code als import.meta.env.VITE_… vorkommt, wird beim vite build aufgelöst und steht danach fest im JavaScript-Bundle.
• Nachziehen im Dashboard ersetzt keinen bereits hochgeladenen dist-Ordner. Für geänderte Marketing-URLs, Site-Origin oder externe Video-URLs braucht ihr in der Regel: .env.production anpassen, neu bauen, neu deployen.
• Für echte Laufzeit-Konfiguration bräuchtet ihr andere Muster (z. B. kleines JSON unter public, das zur Laufzeit geladen wird), bewusst planen, nicht improvisieren.

Direct Upload und Asset-Limits

• Beim Direct Upload über Wrangler gelten harte Grenzen pro Datei (praktisch relevant: sehr große MP4 oder Roh-Archive im dist).
• Lieber komprimierte Clips unter public, externe direkte MP4-URLs über konfigurierte Variablen zur Build-Zeit, oder media manifest, so bleibt der Upload zuverlässig.
• Das Deploy-Skript im Repo kann übergroße Dateien aus dist entfernen, damit der Upload nicht bricht, dann fehlt die Datei in Produktion absichtlich. Besser: vorher die Quelle verkleinern.

Edge Functions und Bot-Rendering

• Pages Functions (z. B. Middleware) laufen am Edge und können Bots anders bedienen als normale Browser (Pre-Rendering, Token-Schutz).
• Wenn ihr Pre-Rendering nutzt: Secrets im Projekt setzen, nicht nur lokal testen. Ohne korrektes Secret wirkt die Route wie eine reine SPA, das ist für manche Crawler okay, für andere suboptimal.
• Nach Änderungen an Functions gehört ein vollständiger Deploy dazu, nicht nur „Asset ersetzen“.

Operative Checkliste vor „wir gehen live“

1. .env.production enthält VITE_PUBLIC_SITE_URL (kanonische Marketing-Origin) und alle öffentlichen Flags, die das Bundle wirklich braucht.
2. npm run build lokal oder in CI grün; dist kurz inspizieren (existiert index.html, Assets, kritische Static Routes).
3. Große Medien prüfen: Größe, MIME, Cache, und ob der Pfad im gebauten Output stimmt.
4. Deploy mit dem gleichen Projektnamen wie im Dashboard; danach Smoke-Test auf der Production-URL und der Custom Domain (Redirect-Ketten, Trailing Slash, 404 auf Assets).
5. SEO-Dateien (sitemap, robots) im public nach Build aktualisieren lassen, wenn ihr sie aus Inhalten generiert, sonst alte URLs im Index.

Vertiefung zu sichtbaren Märkten und Crawlern: GEO und SEO für B2B-CRM. Produktkontext: IntroKI Produkt-Fakten, Preise, Enterprise.