Die Pre-Deployment-Checkliste für deine Web-App: Was du vor dem Go-Live prüfen musst

Jedes Team schiebt irgendwann ein kaputtes Deployment in Produktion. Der Unterschied zwischen einem kurzen Schluckauf und einem ausgewachsenen Vorfall ist, ob man die offensichtlichen Dinge vorher abgefangen hat. Diese Checkliste ist nicht theoretisch. Es ist exakt die Liste, die wir bei ADBEAM vor jedem Release für Kunden im DACH-Raum durchgehen.

Ob du ein SaaS-Produkt launchst, ein internes Tool oder eine E-Commerce-Plattform für Kunden in Deutschland, Österreich und der Schweiz: Diese Checks decken die Bereiche ab, die 90 % der Post-Launch-Brände verursachen: Authentifizierungslücken, fehlende Input-Validierung, Performance-Einbrüche, rechtliche Compliance-Lücken und der Klassiker „Wir können das nicht zurückrollen."

1. Authentifizierung & Autorisierung

Auth ist die Eingangstür deiner Anwendung. Wenn sie nicht richtig funktioniert, liegt alles dahinter offen: Nutzerdaten, Admin-Panels, Abrechnung. Vor dem Deployment sicherstellen, dass Nutzer nur auf das zugreifen können, was sie sollen.

• Alle Auth-Flows End-to-End getestet: Registrierung, Login, Logout, Passwort-Reset, OAuth/SSO
• Rollenbasierte Zugriffskontrolle verifiziert, sodass jede Rolle nur ihre eigenen Ressourcen erreicht
• Passwort-Reset-Links verfallen nach einmaliger Nutzung und nach einem Zeitlimit (z. B. 30 Minuten), damit alte E-Mails keine Account-Übernahmen ermöglichen
• Session-Tokens rotieren beim Login und werden beim Logout invalidiert
• MFA für Admin-Accounts und sensible Operationen aktiviert
• API-Endpunkte erfordern Authentifizierung ohne versehentlich öffentliche Routen

Prüfe meine Web-App auf Authentifizierungs- und Autorisierungsprobleme vor dem Deployment. Checke: Sind alle Auth-Flows (Signup, Login, Logout, Passwort-Reset, OAuth) End-to-End getestet? Ist rollenbasierte Zugriffskontrolle erzwungen, sodass Nutzer nur auf ihre eigenen Ressourcen zugreifen? Verfallen Passwort-Reset-Links nach einmaliger Nutzung und nach einem Zeitlimit? Rotieren Session-Tokens beim Login und werden sie beim Logout invalidiert? Ist MFA für Admin-Accounts aktiviert? Gibt es API-Endpunkte, die versehentlich öffentlich sind? Liste jedes Problem mit Schweregrad und Fix.

2. Input-Validierung & Sanitisierung

Schlechte Daten und Angriffe wie XSS, SQL-Injection und Command-Injection schlüpfen durch unvalidierte Eingaben. Die Regel ist einfach: Vertraue niemals dem Client. Validiere und bereinige alles auf dem Server.

• Server-seitige Validierung auf jedem Endpunkt (Client-seitige Validierung ist UX, nicht Sicherheit)
• Alle Nutzereingaben bereinigt bevor sie gerendert oder gespeichert werden, besonders HTML und Rich Text
• Parametrisierte Queries oder ORM überall im Einsatz mit null roher SQL-Konkatenation
• Datei-Uploads validiert nach Typ, Größe und Inhalt (nicht nur die Dateiendung)
• Unerwartete Felder werden per Allowlist-Ansatz abgelehnt, nicht per Blocklist

Überprüfe meine Codebasis auf Input-Validierungs- und Sanitisierungslücken. Checke: Gibt es Server-seitige Validierung auf jedem API-Endpunkt? Werden Nutzereingaben vor dem Rendern oder Speichern bereinigt (besonders HTML/Rich Text)? Sind alle Datenbank-Queries parametrisiert ohne rohe SQL-Konkatenation? Werden Datei-Uploads nach Typ, Größe und tatsächlichem Inhalt validiert? Werden unerwartete Felder per Allowlist abgelehnt? Zeige mir jeden Endpunkt oder jedes Formular, bei dem Validierung fehlt.

3. CORS & Rate Limiting

Eine offene API ist eine Einladung. CORS und Rate Limiting sind deine Türsteher. Sie entscheiden, wer reinkommt und wie oft.

• CORS so konfiguriert, dass nur zugelassene Origins mit deiner API kommunizieren können, ohne Wildcard „*" in Produktion
• Rate Limiting aktiv, damit Spam und Brute-Force-Angriffe dein Backend nicht in die Knie zwingen
• Sensible Endpunkte (Login, Passwort-Reset, Zahlung) aggressiver gedrosselt
• Korrekte 429-Responses mit Retry-After-Headern
• Rate-Limit-State über Instanzen hinweg persistiert (Redis o. Ä.) bei mehreren Servern

Prüfe meine API-Konfiguration auf CORS und Rate Limiting. Checke: Ist CORS auf bestimmte zugelassene Origins beschränkt (kein Wildcard „*" in Produktion)? Ist Rate Limiting auf allen öffentlichen Endpunkten aktiv? Werden sensible Endpunkte (Login, Passwort-Reset, Zahlung) aggressiver gedrosselt? Geben rate-limitierte Responses 429 mit Retry-After-Header zurück? Wird der Rate-Limit-State bei mehreren Server-Instanzen geteilt (z. B. via Redis)? Liste alle Fehlkonfigurationen.

4. Sicherheits-Header & Datenschutz (DSGVO)

Wer Nutzer in Deutschland, Österreich oder der Schweiz bedient, für den ist DSGVO-Compliance nicht optional. Es ist Gesetz. Aber auch über die rechtlichen Anforderungen hinaus verhindern saubere Security-Header ganze Angriffsklassen.

1. 1HTTPS überall erzwungen ohne Mixed Content, HSTS-Header gesetzt
2. 2Security-Header konfiguriert: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy
3. 3Cookie-Consent implementiert und konform mit TTDSG und DSGVO
4. 4Datenschutzerklärung veröffentlicht und von jeder Seite verlinkt
5. 5Auftragsverarbeitungsverträge (AVV) mit allen Drittanbietern abgeschlossen
6. 6Impressum-Seite live und vollständig (Pflicht nach TMG § 5)

Prüfe meine Web-App auf Security-Header und DSGVO-Datenschutz-Compliance vor dem Launch. Verifiziere: Ist HTTPS überall mit HSTS erzwungen? Sind Security-Header gesetzt (CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy)? Ist ein Cookie-Consent implementiert und TTDSG/DSGVO-konform? Gibt es eine veröffentlichte Datenschutzerklärung, die von jeder Seite verlinkt ist? Sind Auftragsverarbeitungsverträge (AVV) mit allen Drittanbietern abgeschlossen? Ist ein vollständiges Impressum nach TMG § 5 live? Liste jede Lücke.

5. Frontend-Fehlerbehandlung

Deine Nutzer sollten saubere Fallback-Zustände sehen statt Abstürze. Ein weißer Bildschirm oder ein roher Stack-Trace zerstört Vertrauen schneller als jeder Bug.

• Globale Error Boundary fängt unbehandelte Exceptions ab und zeigt einen freundlichen Fallback
• API-Fehlerzustände zeigen verständliche Nachrichten statt technischer Details oder Stack-Traces
• Lade- und Skeleton-Zustände für alle asynchronen Daten vorhanden
• Individuelle 404- und 500-Fehlerseiten gestaltet, gebrandetund getestet
• Offline- und Netzwerkausfall-Zustände werden elegant aufgefangen

Prüfe mein Frontend auf vollständige Fehlerbehandlung. Checke: Gibt es eine globale Error Boundary, die unbehandelte Exceptions abfängt und einen nutzerfreundlichen Fallback zeigt? Zeigen API-Fehlerzustände verständliche Nachrichten statt Stack-Traces? Sind Lade-/Skeleton-Zustände für alle asynchronen Daten vorhanden? Sind individuelle 404- und 500-Fehlerseiten gestaltet und getestet? Gibt es einen Offline-/Netzwerkausfall-Fallback? Zeige mir jede Komponente oder Route, die ohne sauberen Fallback abstürzen könnte.

6. Performance, Core Web Vitals & Datenbank

Google nutzt Core Web Vitals als Ranking-Signal, und deine Nutzer im DACH-Raum auf mobilen Verbindungen warten nicht. Performance ist kein Nice-to-have. Sie beeinflusst direkt Conversions und SEO.

1. 1Core-Web-Vitals-Ziele erreicht: LCP < 2,5 s, CLS < 0,1, INP < 200 ms
2. 2Bilder optimiert (WebP oder AVIF), unterhalb des Folds lazy-loaded
3. 3CDN konfiguriert mit Edge-Nodes in Europa für niedrige Latenz im DACH-Markt
4. 4JavaScript-Bundle-Größe geprüft ohne ungenutzte Dependencies auszuliefern
5. 5Datenbank-Indizes auf allen wichtigen Queries angelegt, damit sie unter Produktionslast schnell bleiben
6. 6N+1-Query-Muster eliminiert durch Prüfung der ORM-Logs
7. 7Connection Pooling konfiguriert und unter gleichzeitiger Last getestet

Analysiere meine Web-App auf Performance und Datenbank-Bereitschaft vor dem Produktions-Deployment. Checke: Werden Core-Web-Vitals-Ziele erreicht (LCP < 2,5s, CLS < 0,1, INP < 200ms)? Sind Bilder optimiert und lazy-loaded? Ist ein CDN mit EU-Edge-Nodes konfiguriert? Ist die JS-Bundle-Größe angemessen ohne ungenutzte Dependencies? Sind Datenbank-Indizes auf allen häufig abgefragten Spalten gesetzt? Gibt es N+1-Query-Muster? Ist Connection Pooling konfiguriert? Liste jedes Performance-Risiko mit geschätztem Impact.

7. SEO & Meta-Tags

• Canonical URLs auf jeder Seite gesetzt, um Duplicate-Content-Probleme zu vermeiden
• hreflang-Tags für mehrsprachige Seiten konfiguriert (besonders DE/EN)
• Open-Graph- und Twitter-Card-Meta-Tags mit korrekten Bildern vorhanden
• Strukturierte Daten (JSON-LD) hinzugefügt: Organization, BreadcrumbList, FAQ wo relevant
• XML-Sitemap generiert und bei Google Search Console eingereicht
• robots.txt geprüft, sodass nichts Wichtiges versehentlich blockiert wird
• Seitentitel und Meta-Descriptions pro Seite einzigartig und innerhalb der Zeichenlimits

Prüfe meine Web-App auf SEO- und Meta-Tag-Vollständigkeit vor dem Launch. Checke: Hat jede Seite eine Canonical URL? Sind hreflang-Tags für mehrsprachige Seiten gesetzt (besonders DE/EN)? Sind Open-Graph- und Twitter-Card-Meta-Tags mit korrekten Bildern vorhanden? Sind strukturierte Daten (JSON-LD) für Organization, BreadcrumbList und FAQ-Schemas hinzugefügt? Ist eine XML-Sitemap generiert und eingereicht? Ist robots.txt geprüft? Sind Seitentitel und Meta-Descriptions einzigartig und innerhalb der Zeichenlimits? Liste jedes fehlende oder fehlerhafte Element.

8. Barrierefreiheit (WCAG 2.2 / BFSG)

Barrierefreiheit ist nicht nur Ethik. Es ist zunehmend Gesetz. Das Barrierefreiheitsstärkungsgesetz (BFSG) verpflichtet seit Juni 2025 viele digitale Produkte in Deutschland zur Einhaltung von WCAG-Standards.

• Vollständige Tastaturnavigation funktioniert, sodass jedes interaktive Element ohne Maus erreichbar ist
• Farbkontrast erfüllt 4,5:1-Verhältnis für normalen Text
• Alle Bilder haben beschreibende Alt-Texte
• ARIA-Labels auf interaktiven Elementen ohne sichtbaren Text
• Fokus-Indikatoren sichtbar und gestylt
• Screenreader-Test durchgeführt (VoiceOver, NVDA oder vergleichbar)

Prüfe meine Web-App auf WCAG 2.2 Barrierefreiheit und BFSG-Konformität. Verifiziere: Kann jedes interaktive Element per Tastatur allein erreicht und bedient werden? Erfüllt der Farbkontrast das 4,5:1-Verhältnis für normalen Text? Haben alle Bilder beschreibende Alt-Texte? Sind ARIA-Labels auf interaktiven Elementen ohne sichtbaren Text vorhanden? Sind Fokus-Indikatoren sichtbar und gestylt? Teste die Haupt-User-Flows so, wie ein Screenreader-Nutzer sie erleben würde. Liste jede Barrierefreiheits-Verletzung mit WCAG-Kriterium und Fix.

9. Umgebung & Konfiguration

1. 1Umgebungsvariablen getrennt ohne Secrets im Quellcode oder Git-Verlauf
2. 2Produktions-Umgebungsvariablen gesetzt und verifiziert (API-Keys, Datenbank-URLs, Drittanbieter-Tokens)
3. 3Individuelle Fehlerseiten (404, 500) deployed und korrekt gerendert
4. 4URL-Redirects für geänderte Routen oder Legacy-Pfade konfiguriert
5. 5DNS-Einträge verifiziert und propagiert mit aktivem und auto-erneuerndem SSL-Zertifikat
6. 6Hosting-Region als EU bestätigt (wichtig für DSGVO-Datenresidenz), z. B. Hetzner, IONOS oder AWS Frankfurt

Überprüfe meine Deployment-Umgebung und Konfiguration auf Produktionsbereitschaft. Checke: Sind alle Secrets in Umgebungsvariablen gespeichert und nicht im Quellcode oder Git-Verlauf? Sind Produktions-Umgebungsvariablen gesetzt und verifiziert (API-Keys, DB-URLs, Drittanbieter-Tokens)? Sind individuelle 404- und 500-Fehlerseiten deployed und rendern korrekt? Sind URL-Redirects für geänderte Routen oder Legacy-Pfade konfiguriert? Sind DNS-Einträge verifiziert und propagiert mit aktivem auto-erneuerndem SSL-Zertifikat? Ist die Hosting-Region als EU für DSGVO-Datenresidenz bestätigt? Markiere alles, was falsch aussieht.

10. Logging & Alerts

Logging, damit du sehen kannst, was in Produktion kaputtgegangen ist. Alerts, damit du von Problemen erfährst, bevor deine Nutzer es tun. Ohne beides fliegst du blind.

• Strukturiertes Logging (JSON-Format) in Produktion aktiviert statt console.log
• Error-Tracking-Service (Sentry, Datadog o. Ä.) angeschlossen und getestet
• Uptime-Monitoring konfiguriert mit Check-Intervallen unter 1 Minute
• Alert-Schwellenwerte definiert: Fehlerrate-Spikes, Latenz P95, Festplatten- und Speicherauslastung
• Log-Aufbewahrungsrichtlinie festgelegt, die lang genug zum Debuggen und kurz genug für DSGVO-Konformität ist
• Alerts an die richtigen Kanäle geroutet (Slack, PagerDuty, E-Mail) mit klarer Zuständigkeit

Prüfe mein Logging-, Monitoring- und Alerting-Setup auf Produktionsbereitschaft. Checke: Ist strukturiertes Logging (JSON) statt console.log aktiviert? Ist ein Error-Tracking-Service (Sentry, Datadog etc.) angeschlossen und getestet? Ist Uptime-Monitoring mit Sub-1-Minuten-Intervallen konfiguriert? Sind Alert-Schwellenwerte für Fehlerrate-Spikes, P95-Latenz, Festplatten- und Speicherauslastung definiert? Ist die Log-Aufbewahrungsrichtlinie DSGVO-konform? Sind Alerts an die richtigen Kanäle mit klarer Zuständigkeit geroutet? Sag mir, was fehlt oder falsch konfiguriert ist.

11. Rollback-Plan

Ein schlechtes Deployment darf nicht zum vollständigen Vorfall werden. Wenn du ein Release nicht schnell rückgängig machen kannst, hast du keinen Deployment-Prozess. Du hast ein Glücksspiel.

• Ein-Befehl-Rollback auf die vorherige Version getestet und dokumentiert
• Datenbank-Migrations-Rollback-Skripte geschrieben und verifiziert
• Feature Flags für riskante oder inkrementelle Änderungen implementiert
• Deployment-Fenster an das Team kommuniziert mit klarem Ansprechpartner
• Post-Deploy-Smoke-Test-Checkliste bereit, um kritische Pfade innerhalb von 5 Minuten durchzugehen

Bewerte meinen Rollback- und Deployment-Sicherheitsplan. Checke: Kann ich mit einem einzigen Befehl auf die vorherige Version zurückrollen? Ist der Rollback-Prozess getestet und dokumentiert? Sind Datenbank-Migrations-Rollback-Skripte geschrieben und verifiziert? Sind Feature Flags für riskante Änderungen implementiert? Ist das Deployment-Fenster an das Team kommuniziert mit klarem Ansprechpartner? Gibt es eine Post-Deploy-Smoke-Test-Checkliste, die kritische User-Pfade innerhalb von 5 Minuten abdeckt? Identifiziere Lücken und schlage Verbesserungen vor.

Diese Checkliste fängt nicht alles ab. Aber sie fängt die Dinge ab, an denen die meisten Launches scheitern: die Auth-Lücke, die Daten leakt, der fehlende Index, der die Performance unter Last in den Keller zieht, das fehlende Rollback, das aus einem 5-Minuten-Fix einen 5-Stunden-Ausfall macht.

Geh sie vor jedem Produktions-Deployment durch. Druck sie aus, häng sie neben deinen Monitor, baue sie in deine CI-Pipeline ein. Die 30 Minuten, die sie kostet, sparen dir Tage an Feuerlöschen.