Website vor dem Livegang testen: Die Checkliste zur Qualitätskontrolle

Website testen vor dem Livegang heißt, jede Seite, jedes Formular und jede technische Einstellung einer neuen Website systematisch zu prüfen, bevor echte Besucher sie sehen. In diesem Beitrag teile ich die Checkliste, die ich seit 2012 in Kundenprojekten nutze. Sie reicht von Browsern und Geräten über Formulare, Ladezeit und SEO Tags bis zu 404 Fehlern, Weiterleitungen, Tracking und Sicherheit. Konkret bekommen Sie eine Reihenfolge, die Sie in der Launchwoche direkt abarbeiten können.

Was bedeutet Website testen vor dem Livegang?

Website testen vor dem Livegang ist eine strukturierte Qualitätskontrolle, bei der Sie Funktion, Darstellung, Ladezeit, Sucheinstellungen, Tracking und Sicherheit auf einer Testumgebung prüfen, bevor die Seite online geht. Ziel ist es, Fehler vor Besuchern und Google zu finden. Jeder Prüfpunkt hat einen Verantwortlichen, ein Kriterium und ein schriftliches Ergebnis.

Das Kriterium ist dabei der entscheidende Punkt. „Das Formular funktioniert“ ist kein Ergebnis. Stattdessen schreiben Sie: „Formular abgeschickt, Benachrichtigung nach zwei Minuten im Postfach, Anfrage im CRM sichtbar.“ Somit gibt es später keine Diskussion darüber, wer was geprüft hat.

Zudem ist das Testen keine Aufgabe für eine einzelne Person. Die Designerin prüft die Darstellung, der Entwickler die Funktion, und das Marketing kümmert sich um Tracking und Texte. Aus meiner Erfahrung stecken die teuersten Fehler in Punkten, für die sich niemand zuständig fühlt. Deshalb steht in meiner Liste neben jeder Zeile ein Name.

Warum sollten Sie den Test vor dem Launch nie überspringen?

Weil ein Fehler nach dem Launch deutlich teurer ist als derselbe Fehler auf der Testumgebung. Ein defektes Kontaktformular verliert still jede Anfrage, bis es jemand bemerkt. Ein vergessenes noindex Tag kann zudem die gesamte Website aus den Suchergebnissen nehmen.

Außerdem gibt es keinen zweiten ersten Eindruck. Starten Sie eine Kampagne und landen Besucher auf einem kaputten Mobilmenü, haben Sie diese Klicks bereits bezahlt. Anders gesagt: Der Test ist keine Zusatzausgabe, sondern die Versicherung für Ihr Werbebudget und Ihre SEO Arbeit.

Das Szenario, das ich am häufigsten sehe, läuft so ab. Zunächst geht die Seite am Freitagabend online. Dann schaut am Wochenende niemand darauf. Am Montag fällt auf, dass die Formulare seit zwei Tagen keine E-Mail verschickt haben. Die Lösung ist einfach: Launchen Sie Anfang der Woche und schließen Sie die Tests am Vortag ab. So ist das Team erreichbar, falls etwas schiefgeht.

Beauftragen Sie eine neue Website, dürfen Sie die Testphase also ruhig als eigene Position im Angebot verlangen. In meinem Angebot für Webdesign ist die Qualitätskontrolle genau deshalb ein eigener Schritt.

Wie richten Sie eine Testumgebung richtig ein?

Eine Testumgebung ist eine separate Kopie der Website mit derselben Serversoftware, derselben PHP oder Node Version und möglichst realistischen Inhalten. In der Praxis lege ich sie meist auf eine Subdomain, etwa test.ihredomain.de. Allerdings muss sie für Suchmaschinen gesperrt bleiben.

Google Search Central erklärt, dass robots.txt nur das Crawling blockiert. Eine gesperrte Adresse kann trotzdem in den Ergebnissen erscheinen, wenn andere Seiten darauf verlinken. Daher schütze ich die Testumgebung mit einem HTTP Passwort, das Crawler und neugierige Besucher gleichermaßen aussperrt.

• Schützen Sie die Testumgebung mit Passwort, nicht nur mit robots.txt.
• Nutzen Sie dieselbe Serversoftware und dieselben Versionen wie live.
• Kopieren Sie keine echten Kundendaten; verwenden Sie realistische Testdaten.
• Betreiben Sie den Zahlungsanbieter im Testmodus.
• Leiten Sie Mails der Testumgebung an Team Postfächer, nicht an Kunden.

Der letzte Punkt ist wichtiger, als er aussieht. Eine versehentliche Rundmail an echte Kunden vom Testserver gehört zu den peinlichsten Pannen vor einem Launch. Zudem kann sie datenschutzrechtlich heikel werden.

Wie testen Sie Browser und Endgeräte?

Wenn Sie Ihre Website testen, planen Sie den Gerätetest nach den Browsern, die Ihre Besucher wirklich nutzen. Öffnen Sie dazu in GA4 den Bericht zur Technologie Ihrer bisherigen Website und notieren Sie die wichtigsten Browser und Bildschirmgrößen. Somit beruht Ihre Testmatrix auf Daten statt auf Vermutungen.

Meine übliche Auswahl sieht so aus: Chrome auf einem Android Smartphone, Safari auf dem iPhone, Chrome, Edge und Firefox am Desktop und dazu ein Tablet. Lassen Sie Safari auf dem iPhone nicht aus, denn manche CSS Regeln und Formularfelder verhalten sich dort anders. Die Entwicklertools im Browser liefern eine brauchbare Vorschau; ein echtes Gerät ersetzen sie allerdings nicht.

Auf jedem Gerät stellen Sie dann einfache Fragen. Öffnet und schließt sich das Menü? Passt der Text ohne Überlauf? Lassen sich Buttons bequem antippen? Erscheint ein horizontaler Scrollbalken? Mehr Details zur mobilen Seite finden Sie in meinem Beitrag zum Test der Mobilfreundlichkeit.

Testen Sie außerdem mit vergrößerter Systemschrift. Wer die Schrift am Handy größer gestellt hat, sieht womöglich Überläufe, die Ihnen nie auffallen. Dokumentieren Sie schließlich jeden Fehler mit Screenshot und Gerätename, denn so kann der Entwickler das Problem viel schneller nachstellen.

Wie prüfen Sie Formulare und Conversion Wege?

Beim Website testen prüfen Sie Formulare von Anfang bis Ende: Ausfüllen, Fehlermeldungen, Absenden, Dankeseite, Benachrichtigung und den Ort, an dem die Daten landen. Eine Erfolgsmeldung allein genügt also nicht. Entscheidend ist, ob die Anfrage bei der richtigen Person ankommt.

1. Senden Sie das Formular mit leeren Pflichtfeldern ab und prüfen Sie, ob die Fehlermeldung verständlich ist.
2. Probieren Sie ungültige E-Mail Adressen und Telefonnummern aus.
3. Senden Sie gültige Daten ab und prüfen Sie, ob die Dankeseite lädt.
4. Kontrollieren Sie, ob die Benachrichtigung bei Ihnen und die automatische Antwort beim Besucher ankommt.
5. Prüfen Sie, ob der Datensatz mit den richtigen Feldern im CRM oder im Backend erscheint.
6. Stellen Sie sicher, dass der Spamschutz keine echten Nutzer blockiert.

Ein häufiger Fehler: Benachrichtigungen landen im Spamordner. Meist fehlen dann SPF, DKIM oder DMARC Einträge. Die Einrichtung erkläre ich im Beitrag zur E-Mail mit eigener Domain. Das Design des Formulars selbst behandle ich im Artikel Formulare für Termin, Angebot und Demo optimieren; hier geht es also nur um den Test.

Wie messen Sie die Ladezeit vor dem Launch?

Wer vor dem Launch die Website testen will, misst mit Labortools, denn echte Nutzerdaten gibt es noch nicht. Lighthouse und PageSpeed Insights sind hier die Standardwerkzeuge. Allerdings erreicht PageSpeed Insights keine passwortgeschützte Testumgebung, deshalb nutzen Sie in dem Fall Lighthouse direkt in Chrome.

Als Zielwerte nehme ich die Core Web Vitals Schwellen, die Google auf web.dev veröffentlicht: LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1 gelten als gut. Trotzdem ist ein Laborwert nicht dasselbe wie echtes Nutzererlebnis. Deshalb messen Sie auch nach dem Launch weiter.

Die häufigsten Bremsen, die ich auf Testumgebungen finde, sind unkomprimierte Titelbilder, Schriftdateien mit ungenutzten Schnitten und Plugins, die auf jeder Seite laden, obwohl nur eine Seite sie braucht. Bilder verkleinern Sie schnell mit meinem Tool Bild verkleinern.

Wenn Sie einen Lighthouse Bericht nicht sicher lesen können, hilft Ihnen mein Beitrag zum Lighthouse Test. Wie die Ladezeit das Ranking beeinflusst, erkläre ich zudem unter Ladezeit und SEO.

Wie prüfen Sie SEO Tags, wenn Sie die Website testen?

SEO Tags prüfen Sie pro Seitentyp: Startseite, Leistungsseite, Produktseite, Blogartikel und Kategorie. In jeder Vorlage kontrollieren Sie Title, Meta Description, Canonical, H1, Robots Meta Tag und gegebenenfalls hreflang.

Wenn ich eine Website teste, schaue ich beim Robots Meta Tag am genauesten hin. Auf der Testumgebung ist noindex richtig. Wandert diese Einstellung allerdings auf die Live Seite, verschwinden Ihre Seiten aus der Google Suche. Folglich ist der erste Check am Launchtag der Blick in den Quelltext der Live Seiten.

Weitere Punkte, die Sie dann prüfen sollten:

• Jede Seite hat genau eine eindeutige H1.
• Kein Title und keine Description ist leer oder doppelt.
• Das Canonical zeigt auf die Live Domain, nicht auf die Testdomain.
• Strukturierte Daten bestehen den Test für Rich Results ohne Fehler.
• Bilder haben aussagekräftige Alternativtexte.

Wie Title und Description in den Suchergebnissen aussehen, sehen Sie in meiner Google SERP Vorschau. Die Regeln fürs Schreiben stehen im Beitrag Meta Title und Meta Description schreiben.

Wie finden Sie 404 Fehler und defekte Links?

Um die Website testen zu können, brauchen Sie zunächst einen Crawler. Ein Werkzeug wie Screaming Frog läuft durch die Testumgebung und listet Adressen mit 404, defekte Bilder und fehlerhafte interne Links. Bei passwortgeschützten Seiten hinterlegen Sie dafür die Zugangsdaten im Crawler.

Beim Crawl achte ich vor allem auf drei Bereiche. Erstens auf Links in Hauptmenü und Footer. Zweitens auf fest eingetragene Links, die noch zur alten Domain oder zur Testumgebung führen. Drittens auf Bildpfade, die beim Umzug der Inhalte kaputtgegangen sind. Rutscht ein Link zur Testumgebung in die Live Seite, landen Besucher vor einer Passwortabfrage, und das kostet sofort Vertrauen.

Danach testen Sie die 404 Seite selbst. Eine nicht existierende Adresse muss einen echten 404 Statuscode liefern, nicht 200. Google Search Central markiert leere Seiten mit Status 200 als Soft 404. Zudem bietet eine gute 404 Seite ein Suchfeld und Links zu den Hauptbereichen.

Mit dem Launch endet die Linkprüfung also nicht. Beobachten Sie danach den Bericht zur Seitenindexierung in der Search Console; wie Sie ihn lesen, erkläre ich in meiner Search Console Anleitung.

Wie prüfen Sie Weiterleitungen vor dem Livegang?

Ersetzen Sie eine alte Website, braucht jede alte Adresse eine dauerhafte 301 Weiterleitung auf ihr neues Gegenstück. Ordnen Sie die Weiterleitungen zunächst in einer Tabelle zu und testen Sie dann jede Zeile. Google empfiehlt für dauerhafte Umzüge serverseitige permanente Weiterleitungen.

Pro Zeile prüfe ich drei Dinge. Liefert die Adresse wirklich 301? Gibt es eine Kette, bei der A auf B und B auf C zeigt? Und landet die Weiterleitung auf der passenden Seite, oder schickt sie alles pauschal auf die Startseite? Alles auf die Startseite zu leiten ist bequem, verwirrt allerdings Besucher und Google gleichermaßen.

Für Stichproben nutzen Sie meinen Redirect Checker. Bei Hunderten von Adressen geben Sie die Liste stattdessen an einen Crawler und prüfen sie gesammelt.

Kontrollieren Sie außerdem, dass HTTP auf HTTPS und www auf die Variante ohne www (oder umgekehrt) in einem einzigen Schritt weiterleitet. Den gesamten Umzug behandle ich in meiner Checkliste zur Website Migration; dieser Beitrag bleibt beim Testschritt.

Wie testen Sie Analytics und Conversion Tracking?

Analytics testen Sie, indem Sie beobachten, ob Ereignisse mit den richtigen Namen und Parametern ankommen. Genau dafür gibt es in GA4 die DebugView. Kombinieren Sie sie mit dem Vorschaumodus im Google Tag Manager, dann sehen Sie bei jedem Klick live, welches Tag auslöst.

Meine Tracking Liste enthält diese Fragen:

• Sendet jede Vorlage genau einen Seitenaufruf?
• Kommen Formularversand, Anrufklicks und WhatsApp Klicks als Ereignisse an?
• Löst das Google Ads Conversion Tag auf der Dankeseite aus?
• Hält das Cookie Banner die Tags bis zur Einwilligung zurück?
• Zeigt ein Besuch mit UTM Parametern die richtige Quelle?

Für den letzten Punkt erstellen Sie mit meinem UTM Generator einen Testlink und prüfen die Quelle in der DebugView. Ein Hinweis noch: Halten Sie den Testverkehr aus Ihrer Live Property heraus, also entweder mit einer eigenen Test Property oder mit einem Filter für internen Traffic.

Haben Sie noch nicht festgelegt, welche Conversions Sie messen, lesen Sie zuerst meinen Beitrag zu Conversion Zielen. Denn ein Ziel, das nie definiert ist, können Sie auch nicht testen.

Welche Sicherheitschecks gehören auf die Liste?

Der Sicherheitscheck vor dem Launch stellt sicher, dass Sie keine offensichtlichen Lücken live schalten. Ein vollständiger Penetrationstest ist bei größeren Projekten ein eigenes Vorhaben. Trotzdem braucht jede Website eine Grundabsicherung.

• Ist das SSL Zertifikat gültig und lädt jede Seite über HTTPS?
• Gibt es gemischte Inhalte, also HTTP Dateien auf HTTPS Seiten?
• Hat der Adminbereich ein starkes Passwort und eine Zwei Faktor Anmeldung?
• Ist der Debug Modus aus, sodass Fehlermeldungen keine Serverpfade verraten?
• Kann jemand Backups, die .env Datei oder den .git Ordner im Browser öffnen?
• Haben Formulare einen Schutz gegen Spam und schädliche Eingaben?

Für Risiken in Webanwendungen ist die OWASP Top 10 eine solide Referenz. Injection und fehlerhafte Zugriffskontrolle gehören dort zum Beispiel seit Jahren zu den festen Einträgen. Schreiben Ihre Formulare in eine Datenbank, fragen Sie Ihren Entwickler daher ganz konkret, wie er sich dagegen absichert.

Ein praktischer Hinweis zum Schluss: Gehen Sie vor dem Launch alle Adminkonten durch. Teams legen während der Tests oft temporäre Konten an und vergessen sie dann jahrelang. Starke Passwörter für die verbleibenden Konten erstellen Sie mit meinem Passwort Generator.

Wie testen Sie Zahlungen und Bestellungen?

Nimmt Ihre Website Zahlungen an, wächst der Testumfang, weil ein Fehler hier direkt Geld kostet. Zunächst schalten Sie den Zahlungsanbieter in den Testmodus. Dann spielen Sie mit den Testkarten des Anbieters erfolgreiche, abgelehnte und abgebrochene Zahlungen durch. Nach jedem Fall prüfen Sie, ob die Bestellung mit dem richtigen Status im Backend steht.

Zudem suche ich Antworten auf ein paar praktische Fragen. Geht ein Produkt bei Lagerbestand null offline? Stimmen die Versandkosten? Zieht ein Rabattcode den richtigen Betrag ab? Erhält der Kunde die Bestellbestätigung? Ist eine Buchhaltung oder Rechnungssoftware angebunden, stellen Sie außerdem sicher, dass Testbestellungen dort keine echten Belege erzeugen.

Schließlich schalten Sie den Testmodus aus, geben eine kleine echte Bestellung auf und spielen die Erstattung durch. So sehen Sie, dass Geldeingang und Rückzahlung live funktionieren. In E-Commerce Projekten übernehme ich diesen Schritt im Rahmen meiner E-Commerce Beratung.

Warum ist das Korrekturlesen ein eigener Schritt?

Weil technische Teams Funktionen testen, aber selten Texte lesen. Folglich rutschen Tippfehler, alte Preise, eine falsche Telefonnummer oder ein vergessener Blindtext in die Live Seite. Solche Fehler wirken klein, schaden dem Vertrauen allerdings direkt.

Deshalb gebe ich die Textkontrolle an die Menschen, die das Geschäft am besten kennen: an die Inhaberin oder das Vertriebsteam. Sie erkennen veraltete Preise, Adressen, Öffnungszeiten oder Leistungsumfänge auf einen Blick. Ebenso prüfen Sie, ob Impressum, Datenschutzerklärung und Cookie Hinweise vorhanden und aktuell sind; in Deutschland ist das Impressum für geschäftliche Websites Pflicht.

Um lange Absätze und unklare Sätze zu finden, prüfen Sie wichtige Seiten mit meinem Tool Lesbarkeit prüfen. So senden Ihre Texte eine klarere Botschaft an Besucher und Suchmaschinen.

Klicken Sie schließlich jeden Telefon und E-Mail Link an. Ein tel: Link startet auf dem Handy direkt einen Anruf. Enthält die Nummer allerdings einen Tippfehler, ruft Ihr Besucher einen Fremden an. Ein winziges Detail, und trotzdem einer der ärgerlichsten Fehler, die ich in der Praxis sehe.

Wie testen Sie die Barrierefreiheit vor dem Launch?

Beginnen Sie mit automatischen Tools und schließen Sie mit manuellen Checks ab. Der Bereich Barrierefreiheit in Lighthouse und Browsererweiterungen wie axe finden schnell zu geringe Kontraste, fehlende Alternativtexte und unbeschriftete Formularfelder.

Automatische Tools übersehen allerdings viel. Deshalb bediene ich jede Website zusätzlich nur mit der Tastatur. Öffnet die Tabulatortaste das Menü? Ist der Fokusrahmen sichtbar? Sendet Enter das Formular ab? Dieser schnelle Test deckt in den meisten Projekten echte Probleme auf.

Die zentrale Referenz sind die WCAG 2.2 Richtlinien des W3C. Für Unternehmen, die in der EU verkaufen, ist Barrierefreiheit zudem keine reine Kür mehr, denn das Barrierefreiheitsstärkungsgesetz setzt den European Accessibility Act für bestimmte digitale Dienste um. Verkaufen Sie online an Verbraucher, schieben Sie diesen Punkt also nicht ans Ende.

Wie sieht eine QA Checkliste vor dem Launch als Tabelle aus?

Die folgende Tabelle fasst zusammen, wie ich in Projekten jede Website testen lasse. Jede Zeile zeigt Bereich, Prüfpunkt, Werkzeug und Kriterium. Ergänzen oder streichen Sie Zeilen passend zu Ihrer Website.

Übertragen Sie die Tabelle am besten in eine geteilte Tabellenkalkulation und ergänzen Sie Spalten für Verantwortliche und Datum. Dann liegt die Antwort auf „Wer hat das geprüft?“ beim Launchtermin für alle sichtbar auf dem Tisch.

Welche Checks wiederholen Sie am Launchtag?

Am Launchtag bestätigen Sie schnell, dass alles, was auf der Testumgebung bestanden hat, auch live besteht. Denn beim Deployment ändern sich Einstellungen. Umgebungsvariablen, Mailkonfiguration, Caching und robots.txt gehen am häufigsten kaputt.

1. Prüfen Sie, dass im Quelltext der Live Seiten kein noindex steht.
2. Kontrollieren Sie, dass robots.txt nicht die ganze Website sperrt.
3. Schicken Sie aus jedem Formular eine Testanfrage.
4. Suchen Sie Ihren eigenen Besuch im Echtzeitbericht von GA4.
5. Rufen Sie einige alte Adressen auf und prüfen Sie die 301.
6. Reichen Sie die XML Sitemap in der Search Console ein.

Fehlt die Sitemap oder ist sie veraltet, erstellen Sie sie mit meinem XML Sitemap Generator. Für robots.txt hilft der robots.txt Generator; lesen Sie die Live Version allerdings immer selbst.

Was Sie in den Wochen nach dem Launch beobachten, ist ein eigenes Thema. Wer die Website vor dem Livegang testet, sorgt für einen sauberen Start. Danach brauchen Sie also eine eigene Messroutine.

Welche Fehler übersehen Teams am häufigsten?

Die meisten übersehenen Fehler liegen in den Lücken zwischen den Rollen, wo niemand „das ist meine Aufgabe“ sagt. Diese Punkte finde ich in eigenen Projekten und bei übernommenen Websites immer wieder:

• Ein noindex Tag oder eine sperrende robots.txt auf der Live Seite.
• Canonicals und interne Links, die noch zur Testumgebung zeigen.
• Formulare, deren Benachrichtigungen nie ankommen oder im Spam landen.
• Ein Conversion Tag, das doppelt auslöst und Werbeberichte aufbläht.
• Ein Kontaktbutton, der mobil fehlt oder nicht reagiert.
• Vergessene Testkonten und offen liegende Backups.

Auffällig ist: Keiner dieser Punkte ist technisch schwierig. Es sind einfache Checks, die durchrutschen. Deshalb sollte auch ein erfahrenes Team nie ohne Checkliste arbeiten, denn das Gedächtnis ist am müden Launchabend das unzuverlässigste Werkzeug.

Besonders teuer ist das doppelt auslösende Conversion Tag. Die Smart Bidding Strategien in Google Ads lernen aus Conversion Daten, falsche Daten lenken das Budget somit in die falsche Richtung. Diesen Punkt prüfe ich deshalb auch im Rahmen der Google Ads Verwaltung.

Wie lange dauert der Test und wer sollte ihn übernehmen?

Die Dauer hängt von Umfang und Funktionen ab. Hier eine Startspanne aus meiner Praxiserfahrung, keine Garantie: Für eine Unternehmenswebsite mit 10 bis 20 Seiten plane ich ein bis drei Arbeitstage ein, für eine mittelgroße Website mit Formularen und Mitgliederbereich etwa eine Woche. Ein Onlineshop braucht länger, weil Zahlungs und Lagerfälle die Zahl der Szenarien vervielfachen.

Bei der Frage nach dem Wer bewähren sich drei Ebenen. Der Entwickler testet seine eigene Arbeit, die Projektleitung arbeitet die Checkliste ab, und die Inhaberin gibt Inhalte und Abläufe frei. So fängt jede Ebene auf, was die vorherige übersehen hat.

Sind Sie ein kleines Unternehmen ohne eigenes QA Team, gilt trotzdem eine Regel: Wer die Website gebaut hat, gibt sie nicht allein frei. Eigene Fehler sieht man schlecht. Schon fünfzehn Minuten mit einem frischen Blick machen einen echten Unterschied.

Wünschen Sie vor dem Launch eine Prüfung von außen, erreichen Sie mich über die Kontaktseite. Planen Sie zur neuen Website auch Ihre Sichtbarkeit in der Suche, erkläre ich auf der Seite zur SEO Beratung, wie ich arbeite.

Wie wird das Website Testen zur festen Routine?

Das Website testen vor dem Livegang ist keine einmalige Phase. Stattdessen wiederholen Sie es bei jeder größeren Änderung. Fügen Sie eine neue Vorlage, ein neues Formular oder ein Plugin hinzu, dann arbeiten Sie den passenden Teil der Liste erneut ab.

Eine Checkliste soll das Team nicht bremsen, sondern den Kopf frei machen. Mit der Liste in der Hand grübeln Sie nicht, ob Sie etwas vergessen haben. Ihre Energie fließt somit in die Probleme, die echtes Nachdenken verlangen. Zudem arbeitet ein neues Teammitglied mit derselben Liste vom ersten Tag an auf demselben Niveau.

Andererseits sollten Sie die Liste nicht aufblähen. Eine Checkliste mit Hunderten Punkten liest bald niemand mehr. Ich halte daher höchstens zehn Punkte pro Bereich und verschiebe selten nützliche Checks in einen Anhang für Großprojekte.

Mein Rat: Machen Sie aus der Tabelle oben Ihre eigene Vorlage, kopieren Sie sie in jedes Projekt und ergänzen Sie eine Zeile, sobald etwas durchgerutscht ist. Mit der Zeit wird die Liste so zu einem Qualitätsnachweis für genau Ihre Website. Kurz gesagt: Eine gute Checkliste ist aufgeschriebene Erfahrung.