„Bau mir eine Artikel-Website. Um den Rest kümmerst du dich!“
Die KI legt motiviert los: mehr Artikel, mehrere Sprachen, ähnliche Artikel, interne Links, eine Suche, Qualitätschecks, Sicherheitschecks und sogar automatische Reparaturen. Aus dem kleinen Kiosk um die Ecke wird eine riesige Fabrik mit Übersetzungsabteilung, Prüfabteilung, Revisionsbüro und einem „Ausschuss zur Freigabe von Kommas“.
Am Ende steht auf dem Bildschirm: BUILD FAILED.
KI: „Ist behoben.“ Nächster Build: fehlgeschlagen. KI: „Ich hab noch was anderes repariert.“ Wieder fehlgeschlagen. Man besiegt den Endgegner und schon taucht der nächste Endgegner auf. Hier erfährst du, warum das passiert und was du tun kannst, am Beispiel von Cloudflare Pages und Astro. Das ist eine allgemeine Erklärung, keine Diagnose für eine bestimmte Website.
1. Was macht ein Build eigentlich?
Deine Markdown-Texte, Bilder, das Design und der Code sind Zutaten, keine fertige Website. Der Build macht aus diesen Zutaten Seiten und Dateien, die ein Browser anzeigen kann. Astro legt die fertigen statischen Dateien normalerweise in einem Ordner namens dist ab.[1]
Der Text ist das Rezept, der Build ist das Kochen. Eine rohe Zwiebel und ein Kochbuch auf den Tisch stellen und „Essen ist fertig!“ rufen, kommt nicht gut an.
2. Was macht Cloudflare – und was nicht?
Cloudflare Pages kann deinen Code aus Git holen, den Build-Befehl ausführen, den du eingestellt hast, und das Ergebnis online stellen.[2] Die übliche Reihenfolge: Code holen → Werkzeuge installieren → vorab prüfen → Seiten erzeugen → Ergebnis kontrollieren → Deployment. Die genauen Schritte hängen von den Einstellungen deines Projekts ab.
Build heißt herstellen, Deployment heißt ausliefern und online stellen. Schlägt der neue Build fehl, geht diese Version nicht online. Die Halle stellt Cloudflare, aber das verwinkelte Fließband darin stammt oft aus dem eigenen Code der Website.
3. Eine Website, die selbst veröffentlicht, ist schon beschäftigt, bevor es eine einzige Seite gibt
Ein einfacher Blog macht aus Text HTML und fertig. Ein System, das automatisch veröffentlicht, packt davor und danach noch einiges drauf: Darf dieser Artikel online? Sind alle Übersetzungen da? Passen Artikel-ID und URL zusammen? Stimmen ähnliche Artikel und interne Links? Lassen sich die Suchdaten erzeugen? Halten Überschriften, Bildbeschreibungen, Werbung und Sicherheitsregeln alles ein?
Jeder einzelne Check ist für sich sinnvoll. Das Problem: Ändert man einen Satz, müssen alle Abteilungen wieder zur Morgenbesprechung antreten. Du wolltest nur einen Tippfehler korrigieren, und die ganze Belegschaft steht mit Bauhelm da.
4. Warum wird es mit vielen Seiten und Sprachen schwieriger?
10.000 Seiten heißen nicht automatisch 10.000-mal so viel Arbeit. Aber es werden mehr Dateien, die Artikel verlinken sich untereinander, und jede Sprache bringt eigene passende URLs und Suchdaten mit. Wenn jeder Build jeden Artikel mit allen anderen vergleicht, wird es mit wachsender Größe immer zäher.
Deshalb: nur neu berechnen, was sich geändert hat, wiederverwendbare Ergebnisse speichern und jeden Schritt stoppen. Was langsam ist, findet man mit Zahlen heraus, nicht mit Bauchgefühl. Wenn wegen eines neuen Buchs sämtliche Bibliotheken im Land ihre Regale neu sortieren müssten, würde die Bibliothekarin in Tränen ausbrechen.
5. Warum kommt nach jedem Fix der nächste Fehler?
Wenn die Schritte nacheinander laufen, verdeckt ein Fehler vorne alle dahinter. Die Artikelprüfung bricht ab, du behebst es. Jetzt läuft die Linkprüfung und bricht ab, du behebst es. Dann scheitert die Seitenerzeugung. Danach die Suchdaten.
Das heißt nicht, dass jeder Fix einen neuen Bug erzeugt hat. Die Probleme können von Anfang an da gewesen sein und nur Schlange gestanden haben. Umgekehrt kann eine Korrektur aber auch wirklich etwas Neues kaputt machen. Was davon zutrifft, zeigen die Logs und die Änderungshistorie. Man öffnet die Dungeon-Tür, dahinter wartet die nächste Tür, und auf jeder steht „LETZTES LEVEL“.
6. Die 6 häufigsten Gründe für einen fehlgeschlagenen Build
1) Code und Pakete: Tippfehler, fehlende Pakete, falsche Versionen. 2) Eingabedaten: fehlende Texte, falsches Format. 3) Prüfregeln: Die Seite lässt sich erzeugen, aber eine Regel blockiert sie. 4) Ressourcen: Grenzen bei Zeit, Arbeitsspeicher oder Dateianzahl. 5) Umgebung: Die Einstellungen auf deinem Rechner und bei Cloudflare unterscheiden sich. 6) Veröffentlichung: Endkontrolle oder Upload schlagen fehl.
Cloudflare Pages wertet einen Build als fehlgeschlagen, wenn der Build-Befehl mit einem Code ungleich 0 endet.[2] Das „Build failed“ ganz unten ist also das Ergebnis, nicht unbedingt die Ursache. Am Cover eines Krimis erkennst du auch nicht, wer der Täter ist.
7. Das Build-Log lesen: Such den ersten Fehler
Das Build log findest du in den Deployment-Details bei Cloudflare.[3] Starr nicht auf die letzte rote Zeile, sondern such den ersten Schritt, der wirklich fehlgeschlagen ist, und ordne ihn ein: Daten, Code, Regel, Ressourcen oder Umgebung? Wenn sich dieser Schritt einzeln ausführen lässt, stell den Fehler dort nach. Trenn schnelle Notlösungen von echten Fixes und prüf nach der Reparatur, ob auch die folgenden Schritte durchlaufen.
100-mal auf „alles neu starten“ klicken lässt keine fehlende Datei auftauchen. Du brauchst die Nummer der kaputten Maschine, nicht mehr Willenskraft.
8. Cloudflare hat nicht nur ein Limit
Laut offizieller Dokumentation mit Stand 10. Oktober 2026 bietet der kostenlose Pages-Tarif 500 Builds pro Monat, 1 Build gleichzeitig, maximal 20 Minuten pro Build und bis zu 20.000 statische Dateien pro Website.[4] Bei großen Websites zählt nicht nur HTML: Auch Bilder und Dateien für die Suche gehen in die Rechnung ein.
Workers hat eigene Grenzen für Anfragen und Laufzeit. Anfragen an Pages Functions können zwar aufs Workers-Kontingent angerechnet werden, aber ein aufgebrauchtes Workers-Kontingent beweist nicht, dass deshalb der Pages-Build fehlgeschlagen ist.[4][5] Wenn jemand „Budget aufgebraucht!“ ruft, frag zuerst: welches?
9. Raffiniert heißt nicht notwendig
Ein Datenleck mit persönlichen Daten, eine ernste Sicherheitslücke oder eine kaputte wichtige Seite müssen die Veröffentlichung stoppen. Aber die ganze Website anhalten, weil die Reihenfolge der ähnlichen Artikel nicht ganz passt? Das ist eine andere Frage.
Teil deine Checks in drei Gruppen: blockieren die Veröffentlichung / geben nur eine Warnung / laufen separat in regelmäßigen Abständen. Maßstab ist der echte Schaden für Leser und Betreiber, nicht wie beeindruckend der Name des Checks klingt. Wer die Fabrik für immer schließt, weil Staub am Türgriff der Prüfstelle ist, hat die Prüfstelle zum Chef gemacht.
10. Die „Mach du mal“-Falle
„Sorg dafür, dass wir bei Google besser ranken.“ „Mehr Sprachen.“ „Dass es nie wieder kaputtgeht.“ „Noch ein Check dazu.“ Die KI baut Funktionen blitzschnell ein. Jede wirkt richtig, aber hängt man alle hintereinander, landet man schnell bei einem System, in dem kein Artikel rausgeht, bevor jede Abteilung ihren Stempel gegeben hat.
Das ist kein reines KI-Problem: Auch menschliche Teams häufen zu viele Funktionen und technische Schulden an. Die KI macht es nur schneller. Du musst nicht jede Codezeile selbst schreiben, aber du musst festlegen, was geschützt werden muss, was warten kann und wo Schluss ist. Man bittet die KI, den Boden zu fegen, und sie gründet einen Aufsichtsrat für den Saugroboter. Der Boden ist immer noch dreckig.
11. In 3 Schritten wieder online
Blutung stoppen: neue Funktionen pausieren, die letzte Version sichern, die sauber online gegangen ist, und den ersten Fehler finden. Datenschutz- oder Sicherheitschecks nicht einfach mal eben abschalten.
Trennen: In jedem Build bleibt nur die Seitenerzeugung, die wirklich nötig ist. Schweres wie Analysen über die ganze Website oder kleinere Checks kommt in eigene Aufgaben. Cloudflare bietet Build watch paths (damit legst du fest, welche Änderungen einen Build auslösen) und Build-Caching.[6][7] Aber nur weil du das einschaltest, verarbeiten deine selbst geschriebenen Skripte für die ganze Website nicht plötzlich nur noch die Änderungen.
Vorbeugen: Halte fest, wie lange jeder Schritt dauert, welche Fehlerarten auftreten, wie viele Dateien entstehen, wie oft Veröffentlichungen klappen und wie lange die Reparatur dauert. Erfolg ist nicht „Die KI sagt, es ist behoben“, sondern eine Version, die alle Checks bestanden hat und wirklich online ist.
12. Fazit: Vielleicht ist der Endgegner die Verkabelung deiner eigenen Fabrik
Viele Artikel, viele Sprachen, Verlinkungen und Qualitätschecks zu stemmen, ist wirklich schwer. Aber nichts davon muss in einen einzigen Build gestopft werden. Frag dich, warum diese Warnung die Veröffentlichung blockiert, warum jedes Mal alles neu berechnet wird und welche Aufgaben für sich weiterlaufen könnten.
Ideal ist: Während du schläfst, werden riskante Artikel gestoppt, sichere gehen raus, und nur der kaputte Schritt meldet sich bei dir.
KI: „Alles fertig!“ Mensch: „Also ist es online?“ KI: „Build fehlgeschlagen.“
Vollautomatisch lief am Ende nur die Ausreden-Fabrik.
Quellen (7)
- Astro Docs, CLI reference: astro build docs.astro.build
- Cloudflare Docs, Build configuration (updated 2026-09-18) developers.cloudflare.com
- Cloudflare Docs, Debugging Pages (updated 2026-06-02) developers.cloudflare.com
- Cloudflare Docs, Pages limits (updated 2026-09-05) developers.cloudflare.com
- Cloudflare Docs, Workers limits (updated 2026-09-05) developers.cloudflare.com
- Cloudflare Docs, Build watch paths (updated 2026-04-21) developers.cloudflare.com
- Cloudflare Docs, Build caching (updated 2026-05-27) developers.cloudflare.com
