Website-QA-Checkliste: Was vor dem Launch geprüft sein muss

Der klassische Launch-Fehler zeigt sich erst nach dem Launch: Das Kontaktformular sendet brav ab, die Dankeseite erscheint – aber die Mail kommt nie im Postfach an, weil der Mailversand auf dem Live-Server anders konfiguriert ist als auf der Testumgebung. Zwei Wochen lang gehen Anfragen verloren, bis es jemandem auffällt. Kein exotischer Fall, sondern einer der häufigsten überhaupt.

Gegen solche Fehler hilft keine Erfahrung allein, sondern eine Checkliste mit Reihenfolge und Zuständigkeiten. Diese hier ist in sechs Blöcke gegliedert – von der Funktionsprüfung bis zu den 48 Stunden nach dem Go-Live – und du kannst sie direkt für dein nächstes Projekt übernehmen.

Das Prinzip: Jeder Fund wird eine Aufgabe

Bevor es losgeht, eine Regel, die über den Nutzen der ganzen Liste entscheidet: Was beim Testen auffällt, wird sofort als Aufgabe erfasst – mit Fundort, Screenshot und verantwortlicher Person. Nicht in eine Mail, nicht in den Chat, nicht auf einen Zettel. Sonst passiert das, was in vielen Projekten passiert: Dieselbe Seite wird dreimal geprüft, weil niemand weiß, was vom letzten Durchgang übrig ist, und am Launch-Tag taucht ein Zettel mit „Footer!!“ auf, den keiner mehr deuten kann.

Am einfachsten geht das mit einem Feedback-Widget direkt auf der Testumgebung: Wer testet, markiert die Stelle im Screenshot, und die Meldung landet mit Browser- und Gerätedaten im Eingang. Was eine gute Meldung ausmacht, steht in der Bug-Report-Vorlage – für die QA-Phase reicht meist die Kurzform: Wo, was, Screenshot.

eure-website.de

Block 1: Funktion

• Jedes Formular testweise absenden – und die Zustellung prüfen: Kommt die Mail an, auch nicht im Spam?
• Bestätigungsseiten und Fehlermeldungen der Formulare prüfen (Pflichtfelder leer lassen, falsche Mailadresse eingeben)
• Login und geschützte Bereiche mit echtem Testkonto durchspielen
• Suche, Filter und Sortierungen mit realistischen Begriffen testen
• 404-Seite aufrufen: Existiert sie, hilft sie weiter?
• Bei Shops: einen kompletten Testkauf durchführen – inklusive Sonderfällen wie sehr langer Lieferadresse oder Umlauten im Namen
• Externe Links stichprobenartig prüfen, interne Links auf den Hauptseiten vollständig

Block 2: Inhalt

• Nach Platzhaltern suchen: „Lorem ipsum“, „TODO“, „XXX“ und Dummy-Bilder
• Rechtschreibung der Kernseiten – Startseite, Leistungen, Kontakt – von einer unbeteiligten Person lesen lassen
• Telefonnummern und Mailadressen: korrekt und klickbar (tel:- und mailto:-Links)
• Öffnungszeiten, Preise und Teamfotos auf Aktualität prüfen
• Bilder: richtige Zuschnitte, keine sichtbare Kompression, Alt-Texte für die wichtigsten Motive

Block 3: Technik & SEO

• Die noindex-Markierung der Testumgebung für den Livegang entfernen – und notieren, wer das wann macht
• Weiterleitungen: Alle wichtigen alten URLs führen per 301 auf ihre Nachfolger, nicht pauschal auf die Startseite
• HTTPS überall: Weiterleitung von http auf https, keine Mixed-Content-Warnungen
• Ladezeit mobil testen – mit gedrosselter Verbindung, nicht im Agentur-WLAN
• Darstellung auf echten Geräten prüfen: mindestens ein iPhone, ein Android-Gerät, ein Tablet
• Favicon, Seitentitel und Social-Media-Vorschau (Open Graph) der wichtigsten Seiten kontrollieren
• Sitemap erzeugen und in der Search Console einreichen
• Tracking mit Consent-Banner testen: Feuert nichts vor der Einwilligung, alles Gewünschte danach?

cockpit.issuepilot.app

Block 4: Recht

Ohne Anspruch auf Rechtsberatung – diese Punkte gehören auf jede Liste, im Zweifel mit juristischer Prüfung:

• Impressum von jeder Seite aus erreichbar und inhaltlich aktuell
• Datenschutzerklärung deckt alle tatsächlich eingesetzten Dienste ab – auch das neue Tracking und eingebettete Inhalte
• Cookie-Consent: blockiert wirklich, was er zu blockieren behauptet, und lässt sich ablehnen wie akzeptieren
• Branchenspezifische Pflichtangaben geprüft (z. B. Berufsbezeichnungen, Aufsichtsbehörden)

Block 5: Der Go-Live-Tag

• Zeitpunkt bewusst wählen: vormittags an einem Werktag, wenn alle erreichbar sind – nicht Freitag 17 Uhr
• Backup des alten Stands ziehen, bevor irgendetwas umgestellt wird
• DNS umstellen und die Übergangszeit einplanen, in der beide Stände erreichbar sein können
• Direkt danach der Smoke-Test: Startseite, drei wichtigste Unterseiten, jedes Formular einmal absenden und Zustellung prüfen
• Den noindex-Check wiederholen – auf der Live-Domain, nicht auf der Testumgebung
• SSL-Zertifikat der Live-Domain kontrollieren

Block 6: Die 48 Stunden danach

• Formulareingänge mit der Erwartung abgleichen: Null Anfragen in zwei Tagen sind ein Alarmsignal, kein Zufall
• Search Console auf Crawling-Fehler und plötzliche 404-Häufungen prüfen
• Server-Logs oder Analytics auf tote Links und fehlgeleitete alte URLs durchsehen
• Rückmeldungen echter Besucher einsammeln und triagieren – jetzt zeigt sich, was alle Tests übersehen haben
• Offene Restpunkte aus der QA priorisieren: Was ist Nacharbeit diese Woche, was ist Backlog?

Rollen: Wer prüft was?

Zwei Besetzungsregeln verhindern die meisten Lücken. Erstens: Der Launch hat einen Owner – eine Person, die die Blöcke koordiniert, Freigaben einsammelt und im Zweifel entscheidet, ob verschoben wird. Zweitens: Wer etwas gebaut hat, prüft es nicht allein. Die eigene Arbeit liest man mit den Augen dessen, der sie gemeint hat, nicht dessen, der sie benutzt. Für den Inhaltsblock ist zusätzlich der Kunde die beste Testperson – wie diese Runde ohne Mail-Chaos abläuft, zeigt der Beitrag zur Website-Abnahme mit Kunden.

Häufige Launch-Fehler

• Das noindex bleibt aktiv – die neue Website ist live, aber für Google unsichtbar. Der Klassiker unter den teuren Kleinigkeiten.
• Formulare nur absenden statt zustellen: Der Test endet auf der Dankeseite, das Problem beginnt dahinter.
• „Das hatten wir doch schon getestet“: Nach jeder Änderung gilt der betroffene Block erneut – Änderungen am Freitag inklusive.
• Funde ohne Verantwortlichen: Eine Liste bekannter Probleme, um die sich niemand kümmert, ist Dekoration.
• Der Held-Launch: Eine Person macht alles am Abend allein – und niemand kann einspringen, wenn etwas hakt.

Praktisch abbilden lässt sich die ganze Liste als Projekt: jeder Prüfpunkt eine Aufgabe, die Blöcke als Struktur, Funde aus dem Widget im Eingang, und das Board zeigt den Reifegrad des Launches auf einen Blick – offen, in Arbeit, erledigt. Genau dafür ist IssuePilot bei Agenturen und Webteams im Einsatz. Die Checkliste als Projekt läuft schon im Free-Plan; das Kunden-Widget gehört zu den Pro-Funktionen, die bei der Registrierung 30 Tage enthalten sind – genug für einen kompletten Launch.

cockpit.issuepilot.app/board