.avif){kind=spacer}
Webseite vor dem Launch prüfen: die Checkliste mit klaren Freigabekriterien
Ein defektes Formular, ein toter Menüpunkt oder eine versehentliche Sperre für Suchmaschinen kosten Anfragen, bevor es jemand merkt. Diese Checkliste zeigt, was Sie vor der Veröffentlichung prüfen und woran Sie erkennen, dass Ihre Webseite startklar ist.
- Startklar ist eine Webseite, wenn acht Freigabeprüfungen bestanden sind. Zu jeder gehören ein erwartetes Ergebnis, ein Nachweis und eine verantwortliche Person.
- Stoppen Sie den Start bei einem toten Hauptweg, einem nicht testbaren Formular, falschen Indexierungsregeln oder einem unklaren Rückfallweg.
- Staging beweist nicht alles. Weiterleitungen, Zustellung und Indexierungssignale prüfen Sie nach der Veröffentlichung erneut.
- Kleine redaktionelle Restpunkte dürfen Sie bewusst nachgelagert behandeln, kritische Nutzerwege nicht.
Warum eine reine Aufgabenliste nicht reicht
„Mobile geprüft“ kann bedeuten, dass jemand eine Seite kurz schmal gezogen hat. Es kann aber auch bedeuten, dass die wichtigsten Seiten auf echten Zielbreiten, mit Menü, Formular, Videos und Fehlermeldungen getestet wurden. Nur die zweite Variante liefert eine brauchbare Entscheidungsgrundlage.
Formulieren Sie deshalb jeden Punkt in 4 Teilen:
- Test: Was wird konkret ausgeführt?
- Bestanden, wenn: Welches sichtbare Ergebnis wird erwartet?
- Nachweis: Womit wird das Ergebnis belegt? Geeignet sind beispielsweise Screenshots, URLs, Zeitstempel oder Fehlerprotokolle.
- Verantwortlich: Wer behebt den Fehler oder gibt den Punkt frei?
Damit wird die Checkliste zum Freigabeprotokoll. Sie zeigt nicht nur, was erledigt wirkt, sondern auch, wo noch ein echtes Risiko offen ist.
Die 8 Freigabeprüfungen auf einen Blick
| Prüfung | Kernfrage | Bestanden, wenn |
|---|---|---|
| Inhalte und Links | Sind Aussagen, Daten, Downloads und Ziele korrekt? | Kritische Seiten sind freigegeben. Interne Links und primäre CTAs führen zum erwarteten Ziel. |
| Responsive und Browser | Bleibt die Seite auf relevanten Breiten nutzbar? | Kein horizontaler Seitenüberlauf. Text, Navigation und Bedienelemente bleiben lesbar und erreichbar. |
| Navigation und Interaktionen | Funktionieren Menü, Akkordeons, Slider, Filter und Videos? | Pointer und Tastatur erzeugen konsistente Zustände. Versteckte Medien laufen nicht unnötig weiter. |
| Formulare und Zustellung | Wird eine Anfrage vollständig angenommen und korrekt zugestellt? | Validierung, Bestätigung, Empfänger und Speicherung sind mit freigegebenen Testdaten geprüft. |
| Medien und Performance | Laden Bilder, Schriften und Videos passend? | Keine defekten Ressourcen. Wichtige Medien haben geeignete Formate und Größen. Labormessung zeigt keine offensichtliche Regression. |
| Barrierefreiheit | Ist der zentrale Weg auch ohne Maus und mit reduzierter Bewegung nutzbar? | Fokus ist sichtbar, Reihenfolge logisch, Formulare beschriftet und Bewegung respektiert Systemeinstellungen. |
| SEO und Indexierung | Sind Suchsignale für den Zielzustand korrekt? | Titel, Beschreibung, Überschriften, bevorzugte URLs und Indexierungsregeln passen zur vorgesehenen Umgebung. |
| Veröffentlichung und Prüfung der veröffentlichten Webseite | Ist das richtige Ziel veröffentlicht und danach erneut geprüft? | Nur die freigegebenen Ziele wurden gewählt. Die öffentliche URL, kritische Nutzerwege und das Monitoring wurden nach der Veröffentlichung geprüft. |
Freigeben oder stoppen: Diese Fehler verhindern den Start
Ein Launch sollte nicht freigegeben werden, wenn mindestens einer dieser Punkte offen ist:
- Der primäre CTA oder eine zentrale Navigation führt ins Leere.
- Ein geschäftskritisches Formular kann nicht vollständig getestet werden oder die Zustellung ist ungeklärt.
- Die Zielumgebung besitzt falsche Indexierungsregeln, etwa ein unbeabsichtigtes
noindex, oder eine Sperre aus der Testumgebung wurde ungeprüft übernommen. - Bei einem Relaunch fehlen Zuordnungen und permanente Redirects für wichtige alte URLs.
- Das falsche Veröffentlichungsziel oder eine nicht freigegebene Domain ist ausgewählt.
- Für einen kritischen Fehler ist keine verantwortliche Person benannt und es gibt keinen sicheren Rückfallweg.
Kleine redaktionelle Restpunkte können bewusst akzeptiert werden. Ein kritischer Nutzerweg, eine falsche Indexierbarkeit oder ein unklarer Rollback gehören nicht in diese Kategorie.
Phase 1: Auf Staging vollständig prüfen
Inhalte, Ziele und Navigation
Beginnen Sie nicht bei einzelnen Tippfehlern, sondern beim wichtigsten Nutzerweg. Öffnen Sie die Startseite, folgen Sie der Hauptnavigation, prüfen Sie die wichtigsten Leistungs- oder Produktseiten und führen Sie jeden primären CTA bis zum vorgesehenen Ziel aus. Kontrollieren Sie anschließend sekundäre Wege wie Footer, Kontakt, Artikel, Downloads und 404-Seite.
Für jeden Link zählt nicht nur der Statuscode. Prüfen Sie auch, ob das Ziel inhaltlich richtig ist, ob ein neuer Tab sinnvoll ist und ob der Linktext ohne den umgebenden Absatz verständlich bleibt. Google empfiehlt echte <a href>-Links und aussagekräftige Ankertexte. Dieselbe Klarheit hilft auch Nutzern.
Responsive Darstellung und Browser
Testen Sie festgelegte Breiten statt nur „Desktop und Mobile“. Sinnvoll sind mindestens eine große Ansicht, eine typische Laptopbreite, die relevanten Webflow-Breakpoints und ein schmales Smartphone. Ergänzen Sie reale Browser, die Ihre Zielgruppe wahrscheinlich verwendet.
Prüfen Sie pro Breite:
- Navigation öffnen, schließen und nach einem Seitenwechsel erneut bedienen.
- Überschriften, lange Wörter, Tabellen und Buttons auf Umbruch kontrollieren.
- Horizontalen Dokumentüberlauf messen. Absichtlich scrollbare Tabellen separat bewerten.
- Beim Scrollen fixierte Elemente, Dialoge und Cookie-Einstellungen auf Überdeckung prüfen.
- Eingabefelder mit eingeblendeter Bildschirmtastatur kontrollieren, sofern das Formular zum Prüfumfang gehört.
Ein Screenshot ist nützlich, ersetzt aber keine Interaktion. Der Nachweis sollte Breite, Browser, URL und getesteten Weg enthalten.
Interaktionen, Medien und Bewegung
Menüs, Akkordeons, Slider und Tabs brauchen konsistente Zustände. Ein sichtbarer Inhalt sollte zur aktiven Steuerung passen. Ausgeblendete Videos und Endlosschleifen sollten pausieren, wenn sie weit außerhalb des Viewports liegen oder das Dokument nicht sichtbar ist. Bei prefers-reduced-motion: reduce müssen nicht notwendige Bewegung und automatische Übergänge ausbleiben.
Testen Sie Bedienelemente mit Pointer sowie Tastatur. Links und Buttons brauchen einen sichtbaren Fokus. Eine Komponente, die nur auf click an einem unbeschrifteten div reagiert, ist noch nicht vollständig freigegeben.
Formulare bis zum Ergebnis testen
Ein Formular ist nicht bestanden, nur weil die Schaltfläche zum Absenden reagiert. Prüfen Sie Pflichtfelder, verständliche Fehlermeldungen, die Bestätigung nach erfolgreicher Annahme, den Eintrag im vorgesehenen System und die Zustellung an den richtigen Empfänger. Webflow weist darauf hin, dass Änderungen erneut veröffentlicht und Formulare im Zielzustand getestet werden sollen.
Eine echte Testübermittlung wirkt außerhalb der Seite, etwa durch E-Mail-Benachrichtigungen oder Einträge im Anfragesystem. Verwenden Sie nur freigegebene Testdaten und klären Sie vorher, ob Benachrichtigungen ausgelöst werden dürfen.
Performance mit der richtigen Aussagekraft prüfen
Kontrollieren Sie defekte Ressourcen, Bildabmessungen, Videoformate, unnötige automatische Wiedergabe und sehr große Downloads. Erfassen Sie im Labortest LCP (Ladezeit des größten sichtbaren Inhalts) und CLS (Verrutschen von Inhalten). INP (Reaktionszeit auf Eingaben) prüfen Sie mit echten Interaktionen oder später in den Felddaten.
Labordaten helfen vor dem Launch, reproduzierbare Probleme zu finden. Felddaten zeigen erst später, was reale Besucher erleben. Eine gute Labormessung beweist daher nicht automatisch eine gute Nutzungserfahrung.
Barrierefreiheit vor der Freigabe prüfen
Die Easy Checks der W3C Web Accessibility Initiative nennen unter anderem Tastaturbedienung und Fokus, Überschriftenstruktur, Formularbeschriftungen und Fehlermeldungen sowie Bewegung und Medien. Nutzen Sie diese Punkte als frühe Freigabeprüfung. Sie ersetzen keine vollständige Prüfung der Barrierefreiheit.
Eine kompakte Vorabprüfung umfasst:
- sinnvolle Überschriftenreihenfolge und erkennbare Seitenregionen
- sichtbaren Fokus und logische Tab-Reihenfolge
- erreichbare Menüs, Dialoge und interaktive Komponenten
- programmatisch erkennbare Namen für Icons und Bedienelemente
- Alternativtexte für informative Bilder und leere Alt-Texte für reine Dekoration
- lesbaren Kontrast und verständliche Fehlermeldungen
- einen ruhigen Zustand bei reduzierter Bewegung.
SEO- und Indexierungssignale
Prüfen Sie pro indexierbarer Seite Titel, Meta-Beschreibung, eine klare Hauptüberschrift, logisch geordnete Zwischenüberschriften, interne Links und die bevorzugte URL.
Bei einer Sitemap sollten absolute bevorzugte URLs verwendet werden. Google beschreibt die Sitemap als Hinweis, der beim Auffinden von URLs und bei der Wahl der kanonischen URL hilft. Eine Garantie für Crawling oder Indexierung ist sie nicht.
Verwechseln Sie außerdem Crawling und Indexierung nicht: Eine Regel in robots.txt steuert den Zugriff von Crawlern, ist aber kein verlässlicher Weg, eine URL aus Suchergebnissen herauszuhalten. Deshalb gehören robots.txt, noindex, Canonical-Signale und Sitemap jeweils als eigene Prüfpunkte in das Protokoll.
Phase 2: Unmittelbar vor der Umschaltung
Kurz vor der Veröffentlichung ändern sich die Fragen. Jetzt geht es weniger um Gestaltung und mehr um Ziel, Verantwortlichkeit und Rückfallweg:
- Ist das exakt freigegebene Veröffentlichungsziel ausgewählt?
- Gibt es einen aktuellen Sicherungs- oder Wiederherstellungspunkt?
- Ist dokumentiert, welche Änderung bei einem Abbruch zurückgenommen wird?
- Sind die Verantwortlichen für Domain, SSL, DNS und Zugangsdaten benannt, soweit diese Bereiche betroffen sind?
- Sind geplante Redirects importiert und stichprobenartig geprüft?
- Ist klar, wer die Webseite veröffentlicht und wer das Ergebnis anschließend prüft und freigibt?
In Webflow lassen sich die Webflow-Subdomain und verbundene Domains als Veröffentlichungsziele auswählen. Kontrollieren Sie unmittelbar vor der Veröffentlichung, welche Ziele ausgewählt sind, und prüfen Sie danach, wo die Änderung tatsächlich erschienen ist.
Phase 3: Die veröffentlichte Webseite erneut prüfen
Staging kann nicht alles beweisen. Prüfen Sie nach der Veröffentlichung mindestens:
- HTTP-Status und Weiterleitungskette der Startseite sowie kritischer URLs.
- Titel, Canonical- und Indexierungssignale im ausgelieferten HTML und im gerenderten DOM.
- Navigation und primären CTA sowie, nur mit Freigabe, das Formular bis zur tatsächlichen Zustellung.
- Medien, Schriftdateien, Konsole und fehlgeschlagene Ressourcen in einem frischen Browserkontext.
- Mobile Darstellung und tatsächliche domainabhängige Einbindungen.
- Monitoring, Fehlerprotokoll und benannten Ansprechpartner für die Beobachtungsphase.
Dokumentieren Sie nicht nur „Publish erfolgreich“. Der belastbare Nachweis ist der frisch geladene Zielzustand.
Zusatzblock nur für einen Relaunch
Bei einem Relaunch kommen alte URLs hinzu. Erstellen Sie vorab eine vollständige URL-Liste und ordnen Sie jeder relevanten alten URL ein neues Ziel oder eine bewusste Entscheidung zu. Für dauerhafte Umzüge nennt Google serverseitige 301- oder 308-Redirects. Prüfen Sie nach dem Launch mehrere reale alte URLs, interne Links, Sitemap und wichtige Canonical-Signale.
Die Strategie und Verantwortlichkeiten dafür gehören in einen eigenen Relaunch-Plan. Nutzen Sie dazu den Leitfaden Webseiten-Relaunch planen. Die vorliegende Checkliste bildet nur die abschließende Freigabeprüfung ab.
Kompaktes Freigabeprotokoll zum Kopieren
| Bereich | Test | Bestanden, wenn | Nachweis | Verantwortlich |
|---|---|---|---|---|
| Inhalte und Links (Hauptweg) | Navigation und primären CTA ausführen | Ziel korrekt, kein toter Schritt | URL + Screenshot | Projektverantwortung |
| Responsive und Browser | kritische Seiten auf definierten Breiten bedienen | kein Dokumentüberlauf, alles erreichbar | Breite + Browser + Screenshot | Design/Frontend |
| Navigation und Interaktionen | Menü, Akkordeons, Slider, Videos testen | Pointer, Tastatur und Zustand konsistent | Kurzprotokoll | Frontend |
| Formulare und Zustellung | Validierung bis Zustellung testen | Bestätigung, Speicherung und Empfänger korrekt | freigegebene Test-ID | Verantwortlich für das Formular |
| Medien und Performance | Netzwerk und sichtbare Medien prüfen | keine defekte Ressource, keine unnötige Endlosschleife außerhalb des sichtbaren Bereichs | Netzwerkprotokoll | Frontend |
| Barrierefreiheit | Tastatur, Fokus, Struktur, Bewegung | zentrale Wege ohne Maus, ruhiger Zustand bei reduzierter Bewegung | Prüfliste | QA |
| SEO und Indexierung | Titel, H1, Canonical, Indexierung, Sitemap | Zielzustand pro URL nachvollziehbar | Abgleich von HTML und DOM | SEO |
| Veröffentlichung | Ziele und Rollback kontrollieren | nur freigegebene Ziele, Rückfallweg benannt | Abgleich mit dem aktuellen Stand beim Anbieter | Verantwortlich für die Veröffentlichung |
| Prüfung der veröffentlichten Webseite | kritischen Weg frisch wiederholen | ausgelieferter Zielzustand entspricht Freigabe | Öffentliche URL + Zeitstempel | QA/Verantwortlich |
Häufige Fragen zur Webseiten-Launch-Checkliste
Reicht ein Test auf Staging aus?
Nein. Staging eignet sich für Layout, Inhalte und viele Interaktionen. Domainabhängige Weiterleitungen, SSL/DNS, echte Zustellung, Indexierungssignale der veröffentlichten Webseite und Monitoring müssen nach der Veröffentlichung erneut geprüft werden.
Wie viele Geräte und Browser muss ich testen?
Es gibt keine universelle Zahl. Leiten Sie die Testmatrix aus Zielgruppe, Technik und Risiko ab. Wichtig ist, dass Breiten und Browser vorab benannt sind und der wichtigste Nutzerweg auf jeder Kombination tatsächlich bedient wird.
Muss jede kleine Abweichung den Launch stoppen?
Nein. Entscheidend sind Schwere, Nutzerwirkung und Rückfallweg. Defekte Primärwege, falsche Indexierbarkeit, fehlende Weiterleitungen beim Relaunch oder ein unklares Ziel der Veröffentlichung sind Gründe gegen eine Freigabe. Eine dokumentierte, nicht kritische redaktionelle Korrektur kann bewusst nachgelagert werden.
Warum muss ein Formular auf der veröffentlichten Webseite erneut getestet werden?
Weil die Testumgebung nicht sämtliche Bedingungen der veröffentlichten Webseite abbildet. Dazu gehören die Domain, der Anbieter, die Empfänger und die Zustellung. Die Testübermittlung braucht jedoch eine ausdrückliche Freigabe und sichere Testdaten.
Ersetzt diese Checkliste eine vollständige Prüfung von Barrierefreiheit, SEO oder rechtlichen Fragen?
Nein. Sie ist eine Prüfung vor der Veröffentlichung, die sich an den jeweiligen Risiken orientiert. Vertiefte Prüfungen und rechtliche Freigaben benötigen passende Fachverantwortliche. Die Hinweise hier sind keine Rechtsberatung.
Quellen
- Webflow Help: Webseite veröffentlichen oder Veröffentlichung aufheben, aktualisiert am 04.08.2026.
- Webflow Help: Form submissions, aktualisiert am 01.08.2026.
- Google Search Central: Einführung in robots.txt, aktualisiert am 10.12.2025.
- Google Search Central: Sitemap erstellen und einreichen, aktualisiert am 08.07.2026.
- W3C WAI: Easy Checks, aktualisiert am 09.08.2023.
- web.dev: Web Vitals, aktualisiert am 31.10.2024.