7 Schritte
Von den Kriterien bis zur Freigabe – jedes Projekt derselbe Prozess.
42 Punkte
Die Checkliste in 6 Bereichen – frei kopier- und anpassbar.
4 Rollen
Umsetzung, Peer, Inhalte, Entscheidung – niemand prüft allein.
Was ein Website-Review ist – und was nicht
Drei Tätigkeiten werden ständig vermischt. Sie zu trennen ist die halbe Disziplin.
Ein Website-Review ist die strukturierte Prüfung eines Webprojekts gegen definierte Kriterien, bevor es live geht oder freigegeben wird. Es umfasst Inhalte, Design, Funktion, Responsive-Verhalten, Performance-Basics und rechtliche Pflichten – und es endet mit einer Entscheidung: Freigabe oder Mängelliste.
Es ist kein QA-Test (Prüfung gegen technische Vorgaben, meist durch Tester) und kein Feedback-Einholen (offene Reaktionen von Kunden oder Nutzern sammeln). Ein guter Review-Prozess enthält von beidem etwas – aber seine Aufgabe ist eine andere: ein belastbares „Das kann live" mit Belegen.
So läuft es meistens
„Schau nochmal kurz drüber, bevor wir live gehen"
- Keine Kriterien – jeder prüft, was ihm zufällig auffällt
- Funde verstreut über E-Mail, Chat und Telefonate
- Behobenes prüft niemand nach
- Livegang, weil die Deadline da ist – nicht, weil das Review fertig ist
Strukturiertes Review
Kriterien, Runden, Protokoll
- Eine Checkliste definiert, was „fertig" heißt
- Alle Funde an einem Ort, am Element verankert
- Jeder Fix wird von der meldenden Person gegengeprüft
- Eine dokumentierte Freigabe beendet das Review
Das Website-Review in 7 Schritten
Die Reihenfolge ist der Punkt: Jeder interne Schritt nimmt Funde aus der Kundenrunde – und die Kundenrunde ist die teure.
- 1
Umfang und Kriterien festlegen
Was prüft dieses Review (welche Seiten, welche Geräte, welche Zustände) und was heißt „fertig"? Ein Review ohne Kriterien produziert Meinungen, keine Ergebnisse.
- 2
Selbst-Review der Umsetzenden
Wer die Seite gebaut hat, geht sie einmal mit der Checkliste durch, bevor sie jemand anderes sieht. Jetzt ist ein Fund billig – in der Kundenrunde ist er peinlich.
- 3
Internes Peer-Review
Ein zweites Augenpaar aus dem Team: Design prüft die Umsetzungstreue, Entwicklung die Funktion. Interne Funde erreichen die Kundenliste nie.
- 4
Inhalts- und Datenprüfung
Jede Überschrift, jeder Preis, jede Telefonnummer, jede Rechtsseite gegen die Quelle. Inhaltsfehler kosten beim Kunden mehr Vertrauen als jeder Layout-Bug.
- 5
Kunden-Review-Runde
Ein Link, eine Frist, Anmerkungen direkt am Element. Der Kunde prüft die echte Seite auf Desktop und Handy – nicht ein PDF davon.
- 6
Beheben und gegenprüfen
Liste abarbeiten, jeden Punkt als erledigt markieren – und die Person gegenprüfen lassen, die ihn gemeldet hat. Ein Fix, den niemand nachprüft, ist ein Bug mit Verzögerung.
- 7
Freigabe mit Protokoll
Das Review endet mit einer dokumentierten Freigabe: wer hat welchen Stand wann freigegeben, mit welchen offenen Punkten. Dieses Protokoll beendet Projekte sauber.
Der häufigste Prozessfehler
42 Punkte in 6 Bereichen
Kopieren, anpassen, zur eigenen machen. Entscheidend ist nicht diese exakte Liste – sondern dass dein Review überhaupt eine hat.
1 · Inhalt & Texte
- Alle Texte final – kein Lorem ipsum, kein „kommt noch"
- Namen, Preise, Daten, Telefonnummern gegen die Quelle
- Rechtschreib- und Grammatikdurchgang (laut lesen hilft)
- Tonalität konsistent zur Markensprache
- Alle Bilder lizenziert, Bildnachweise wo nötig
- Rechtsseiten vorhanden: Impressum, Datenschutz, AGB
- 404-Seite existiert und hilft weiter
2 · Design & Konsistenz
- Abstands-Rhythmus über alle Sektionen konsistent
- Schriften, Größen und Gewichte wie im Designsystem
- Hover-, Fokus- und Aktiv-Zustände an allen Bedienelementen
- Bilder scharf auf Retina-Displays
- Favicon und Social-Vorschaubild gesetzt
- Leere Zustände und Ladezustände gestaltet
- Druckansicht nicht kaputt (falls relevant)
3 · Funktion
- Jedes Formular: Absenden, Validierung, Fehler- und Erfolgsfall
- Formular-Eingänge kommen wirklich an (Postfach testen)
- Alle internen Links funktionieren, keine verwaisten Seiten
- Externe Links öffnen korrekt (und sind gewollt)
- Suche, Filter und interaktive Elemente funktionieren
- Dritt-Integrationen laufen (Karte, Buchung, Chat)
- Cookie-Consent funktioniert – und blockt, was er verspricht
4 · Responsive & Geräte
- Echt-Geräte-Check: ein iPhone, ein Android, ein Tablet
- Kein horizontales Scrollen bei irgendeiner Breite
- Touch-Ziele groß genug (44 px+)
- Menüs mobil bedienbar – auch Untermenüs
- Bilder und Tabellen passen sich an statt überzulaufen
- Querformat nicht kaputt
- Texte ohne Zoomen lesbar
5 · Performance & SEO-Basics
- Ladezeit im 4G-Netz akzeptabel, nicht nur im Büro-WLAN
- Bilder komprimiert, moderne Formate im Einsatz
- Jede Seite mit eigenem Titel und eigener Description
- Überschriften strukturiert (eine h1, logische Reihenfolge)
- Weiterleitungen von alten URLs gesetzt (Relaunch)
- Sitemap und robots.txt korrekt, Indexierung erlaubt
- Analytics/Tracking feuert – consent-gebunden
6 · Datenschutz & Recht
- HTTPS überall, kein Mixed Content
- Consent-Banner, bevor irgendein Tracking lädt
- Datenschutzerklärung passt zu den tatsächlich genutzten Tools
- Formulare: nur nötige Felder, klarer Zweck
- Schriften und Einbettungen DSGVO-konform (keine CDN-Calls ohne Consent)
- Urheber- und Bildnachweise wo erforderlich
- Barrierefreiheit-Basics: Kontraste, Alt-Texte, Tastatur-Bedienung
Wer prüft was
Vier Perspektiven, vier verschiedene Funde. Die Umsetzenden finden die Kompromisse, der Peer die blinden Flecken, die Inhalte-Person die Fakten – und wer entscheidet, entscheidet.
Wer gebaut hat
Macht das Selbst-Review. Weiß, wo die Kompromisse vergraben sind – und prüft genau diese Stellen zuerst.
Die Kollegin / der Kollege
Design oder Entwicklung – aber nicht am Projekt beteiligt. Findet, wofür die Umsetzenden nach zwei Wochen in der Datei blind geworden sind.
Wer die Inhalte verantwortet
Prüft Fakten, Ton und Vollständigkeit gegen das Briefing – meist auf Kundenseite, bevor die Entscheider-Ebene draufschaut.
Wer entscheidet
Prüft zuletzt, entscheidet über offene Punkte und erteilt die Freigabe. Eine Person – ein Gremium unterschreibt nie.
Der Schritt, an dem Reviews normalerweise scheitern
Interne Durchgänge sind diszipliniert, weil du sie kontrollierst. Der Kundenrunde musst du Struktur geben – freundlich, aber konsequent.
Drei Regeln halten die Kundenrunde kurz. Ein Link: Der Kunde prüft die echte Seite im Browser – Desktop und Handy – und hinterlässt Anmerkungen direkt am Element, statt sie in einer E-Mail zu beschreiben. Eine Frist: Ein offenes Review ist ein offenes Projekt; 3–5 Werktage mit benanntem Endtermin funktionieren. Eine Liste: Jeder Fund landet am selben Ort, bekommt einen Status und wird nach dem Fix von der meldenden Person gegengeprüft.
Die Qualität der Runde hängt an der Qualität der Anmerkungen. „Auf der Über-uns-Seite stimmt was nicht" ist nicht prüfbar – welches Element, auf welchem Gerät, verglichen womit? Genau hier zahlt sich geführtes Feedback aus: Wenn vage Anmerkungen im Moment des Schreibens eine Rückfrage bekommen, kommt die Mängelliste umsetzbar bei dir an statt interpretierbar.
Das ganze Review direkt auf der Live-Seite
Mit bepeq prüft dein Kunde die echte Seite – Desktop, Tablet, Handy – und pinnt Anmerkungen ans exakte Element, ohne Login. Der Pilot fragt bei Vagem nach, Runden haben Fristen, und die Freigabe erzeugt ihr Protokoll von selbst.
bepeq kostenlos testenAbnahmeprotokoll automatisch erstellt
Stand: staging.kundenseite.de
04.07.2026 · 14:32 Uhr · IP dokumentiert
2 Restpunkte (Kategorie B) mit Frist
Passende Leitfäden und Vorlagen
Website-Feedback
Wie du Kundenfeedback einholst, das du direkt umsetzen kannst.
Website-Review-Tool
Die Software-Seite: Multi-Stakeholder-Review bis zur dokumentierten Freigabe.
Website testen
Der Test-Motor im Review: 6 Testarten, Geräte-Matrix, Bug-Reports ohne Rückfragen.
Website-Relaunch-Checkliste
40 Punkte in 5 Phasen – speziell für Relaunch-Projekte.
Abnahmeprotokoll
Die Vorlage für das Dokument am Ende des Reviews.
Häufige Fragen zum Website-Review
Was ist ein Website-Review?
Ein Website-Review ist die strukturierte Prüfung eines Webprojekts vor Livegang oder Freigabe: Inhalte, Design, Funktion, Responsive-Verhalten, Performance- und Rechts-Basics werden gegen definierte Kriterien geprüft, Funde an einem Ort gesammelt, behoben, gegengeprüft – und das Review endet mit einer dokumentierten Freigabe.
Was ist der Unterschied zwischen Review, QA-Test und Feedback?
QA-Tests prüfen gegen technische Vorgaben – validiert das Formular, antwortet die Schnittstelle, läuft es in jedem Browser. Ein Review ist breiter und bezieht Nicht-Techniker ein: Es bewertet auch Inhalt, Konsistenz und Zweckerfüllung und endet mit einer Geschäftsentscheidung (der Freigabe), nicht mit einem Testbericht. Feedback-Einholen wiederum sammelt offene Reaktionen – ein Review prüft gegen Kriterien.
Wer sollte eine Website vor dem Livegang prüfen?
Mindestens vier Perspektiven: die Person, die gebaut hat (Selbst-Review), eine unbeteiligte Kollegin oder ein Kollege (Peer-Review), wer die Inhalte verantwortet (Faktencheck) und die Person, die freigibt. In kleinen Projekten kann eine Person zwei Rollen tragen – nie alle vier.
Wie lange dauert ein Website-Review?
Bei einer typischen Website mit 5–10 Seiten: die internen Durchgänge einen halben Tag, die Kundenrunde braucht eine Frist von 3–5 Werktagen, Beheben plus Gegenprüfung noch 1–2 Tage. Der größte Zeitfresser ist nicht das Prüfen, sondern das Nachfassen bei vagem Feedback – strukturierte, am Element verankerte Anmerkungen halbieren die Gesamtdauer ungefähr.
Was gehört in eine Website-Review-Checkliste?
Sechs Bereiche: Inhalt und Texte (Fakten, Rechtschreibung, Rechtsseiten), Design-Konsistenz (Abstände, Schriften, Zustände), Funktion (Formulare, Links, Integrationen), Responsive-Verhalten (echte Geräte, beide Ausrichtungen), Performance- und SEO-Basics (Ladezeit, Titel, Indexierbarkeit) sowie Datenschutz/Recht (Consent, Impressum, Verschlüsselung). Die 42 Punkte auf dieser Seite decken alle sechs ab.