𝟯 Post-Deployment-Checks, die ich nach jedem Cloudflare Pages Build durchführe

Ich habe zwei Wochen damit verbracht, Produktionsfehler zu beheben. Eine fehlerhafte Redirect-Regel blockierte meine Sitemap. Ein Bild-Upload schlug aufgrund von Deployment-Verzögerungen fehl.

Ich führe jetzt nach jedem Cloudflare Pages Build drei spezifische Checks durch. Ich nutze keine vollständige Test-Suite, sondern schnelle Prüfungen, die gezielt meine tatsächlichen Fehlerquellen anvisieren.

Ich verwende Astro 5 SSG auf drei Websites: aiappdex.com, findindiegame.com und ossfind.com.

Hier sind die drei Checks:

  1. Sitemap-Verifizierung Ich überprüfe, ob sitemap-index.xml auf allen Domains einen 200-Status zurückgibt. Ich prüfe auch sitemap-0.xml. Zudem stelle ich sicher, dass die Anzahl der URLs über einem festgelegten Schwellenwert bleibt. Für aiappdex.com erwarte ich mindestens 1.000 URLs. Wenn die Anzahl sinkt, ist meine Daten-Pipeline defekt.

Ich verwende curl ohne das Folgen von Redirects. So werden Fehler abgefangen, bei denen eine Redirect-Regel eine Sitemap im Browser zwar korrekt erscheinen lässt, sie aber für Crawler unbrauchbar macht.

  1. IndexNow-Einreichung Nachdem die Sitemap-Checks bestanden wurden, führe ich ein Skript aus, um die URLs an IndexNow zu übermitteln. Dies benachrichtigt Bing, Yandex, Naver und Seznam über neue Inhalte.

Ich führe dies manuell nach dem Deployment aus. So stelle ich sicher, dass ich nur URLs einreiche, die auch tatsächlich live sind. Wenn IndexNow einen 403-Fehler zurückgibt, weiß ich, dass meine Key-Verifizierungsdatei fehlt oder eine Redirect-Regel fehlerhaft ist. Das frühzeitige Erkennen verhindert Verzögerungen bei der Indexierung.

  1. Wöchentliche Lighthouse-Audits Ich führe jeden Montag um 04:30 UTC einen Lighthouse-Check durch. Dabei prüfe ich pro Website eine Startseite und eine tiefer liegende Unterseite.

Ich achte auf diese Metriken:

  • Performance unter 80
  • CLS über 0,1
  • Sinkende Accessibility-Scores

Da meine Websites statisches HTML und CSS verwenden, sollten die Scores stabil bleiben. Wenn sie sinken, hat wahrscheinlich eine kürzliche Änderung an Tailwind oder einer Komponente das Layout zerschossen. Ich nutze diese Ergebnisse eher zur Trendüberwachung als zum Blockieren von Builds.

Ich überwache weder die Uptime noch die API-Verfügbarkeit. Meine Websites sind statisch. Die Datenbank läuft nur zur Build-Zeit. Für ein statisches CDN-Deployment decken diese drei Checks meine Hauptrisiken ab.

Quelle: https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-39h6