Die kurze Antwort
Die Veröffentlichung einer Website ist eine geschäftliche Abnahmeentscheidung und nicht bloss eine technische Bereitstellung. Bestimmen Sie die entscheidungsbefugte Person, definieren Sie Blocker und Rücksetzbedingungen, sammeln Sie vor und nach der Veröffentlichung Nachweise, testen Sie echte Anfragen und weisen Sie die Aufgaben der ersten 30 Tage klar zu. Eine freigegebene Ausnahmeliste hält kleinere Mängel sichtbar, ohne dass sich kritische Fehler dahinter verbergen.
- Definieren Sie vor der Veröffentlichung beobachtbare Abnahmekriterien und klare Blocker.
- Testen Sie Produktivdomain, Formulare und Bestätigungen, statt sich auf Nachweise aus der Testumgebung zu verlassen.
- Prüfen Sie nach der Bereitstellung Vorgaben für Suchmaschinen, Canonicals, Weiterleitungen und Sitemap.
- Führen Sie während 30 Tagen geplante Kontrollen mit klaren Zuständigkeiten und priorisierten Korrekturen durch.
Auf dieser Seite
Definieren Sie Abnahmekriterien und Entscheidungsbefugnisse
Eine Website ist bereit, wenn die vereinbarten Kundenaufgaben im Produktivsystem funktionieren und die verantwortlichen Personen die bekannten Risiken akzeptieren. Eine abgeschlossene Entwicklungsliste liefert nützliche Nachweise, ersetzt aber nicht die geschäftliche Entscheidung.
Bestimmen Sie je eine Person für den Veröffentlichungsentscheid, die technische Leitung, die Inhalte und die Zustellung von Anfragen. Legen Sie den Entscheidungszeitpunkt, Auslöser für eine Rücksetzung und den Kommunikationsweg fest. Entscheiden Sie, was die Veröffentlichung blockiert, bevor der Zeitdruck steigt.
Bei einer Website zur Leadgenerierung müssen beispielsweise ein defektes Formular, eine falsche Domain, eine versehentlich aktive Zugriffsbeschränkung aus der Testumgebung oder verlorene wichtige URLs die Veröffentlichung verhindern. Eine kleine gestalterische Unstimmigkeit kann mit Termin in die Nachbearbeitung aufgenommen werden, sofern sie die Aufgabe nicht behindert.
- Benennen Sie die Person mit der endgültigen Entscheidungsbefugnis für oder gegen die Veröffentlichung.
- Bestimmen Sie die Zuständigkeit für eine Rücksetzung und den spätesten sicheren Entscheidungszeitpunkt.
- Trennen Sie Blocker von akzeptierten Nacharbeiten.
- Legen Sie die Nachweise direkt bei den jeweiligen Abnahmepunkten ab.
| Punkt | Verantwortlich | Nachweis | Regel für den Entscheid | Erneuter Test |
|---|---|---|---|---|
| Anfrageformular | Verkaufsorganisation | Empfangene Nachricht aus dem Produktivsystem | Fehler blockiert die Veröffentlichung | Erforderlich |
| Kanonische Domain | Technische Leitung | Prüfung von Header und Weiterleitung | Falscher Host blockiert die Veröffentlichung | Erforderlich |
| Kleiner Abstandsfehler | Designverantwortliche Person | Screenshot | Kann in die Nachbearbeitung aufgenommen werden | Terminiert |
| Datenschutzhinweis | Geschäftsleitung | Freigegebene produktive Seite | Fehlende Freigabe blockiert die Veröffentlichung | Erforderlich |
Geben Sie Inhalte und Customer Journeys frei
Prüfen Sie die Website aus Sicht Ihrer Kundschaft. Kontrollieren Sie Leistungsbeschreibungen, Umfang, Kontakte, Standorte und Handlungsaufforderungen. Folgen Sie Navigation und internen Links auf Mobilgeräten und Desktop-Computern und beziehen Sie leere Zustände und Fehlersituationen ein.
Verwenden Sie benannte Abläufe statt einer allgemeinen Sichtkontrolle. Können Besuchende das Angebot erkennen, ihre Eignung beurteilen, relevante Nachweise finden und eine Anfrage senden? Können Mitarbeitende erklären, was den Besuchenden zugesagt wurde? Prüfen Sie Downloads, Telefonnummern und E-Mail-Adressen.
Sperren Sie kritische Texte während des Zeitfensters für die Bereitstellung. Kurzfristige Änderungen ohne Prüfung führen häufig wieder zu defekten Links oder nicht freigegebenen Aussagen.
- Geben Sie Aussagen, Kontakte, Handlungsaufforderungen und rechtliche Hinweise frei.
- Prüfen Sie Menüs, eine allfällige Suche, Downloads und Fehlerseiten.
- Testen Sie lange Inhalte und übersetzte Varianten.
- Dokumentieren Sie beabsichtigte Auslassungen und die dafür zuständigen Personen.
| Ablauf | Ausgangspunkt | Erfolgreicher Abschluss | Nachweis |
|---|---|---|---|
| Neue interessierte Person | Landingpage | Angenommene Anfrage und Bestätigung | Test auf Mobilgerät und Desktop |
| Wiederkehrender Käufer | Gespeicherte Leistungs-URL | Aktuelle Leistungsbeschreibung | Prüfung von Weiterleitung und Inhalt |
| Falsche URL | Nicht vorhandener Pfad | Hilfreiche Fehlerseite mit echtem 404-Status | HTTP-Antwort und Seitenprüfung |
| Sprachwechsel | Lokalisierte Leistungsseite | Entsprechende lokalisierte Seite | Test der Sprachgruppe |
Stellen Sie sicher, dass kritische Barrieren behoben sind
Führen Sie eine gezielte manuelle Prüfung der wichtigsten Abläufe durch. Der Tastaturfokus muss sichtbar sein, einer logischen Reihenfolge folgen und darf nicht verdeckt werden. Formularbeschriftungen und Fehlermeldungen müssen verständlich bleiben, und der Zoom darf keine wesentlichen Aktionen verbergen.
Die Easy Checks des W3C sind ausdrücklich als vorläufige Prüfung gedacht. Sie unterstützen die Priorisierung vor der Veröffentlichung, bestätigen aber keine Konformität. Ergänzen Sie sie mit automatisierten Ergebnissen, Komponententests und einer für das Projekt angemessenen weitergehenden Evaluation.
Führen Sie ungelöste Befunde samt Auswirkungen auf die Kundschaft und Zuständigkeit im Freigabeprotokoll auf. Navigationsfallen, unbedienbare Formulare und verborgene Aktionen sind Blocker und keine kosmetischen Nacharbeiten.
- Durchlaufen Sie den gesamten Ablauf mit der Tastatur.
- Prüfen Sie Fokus, Überschriften, Alternativtexte, Kontrast und die Korrektur von Formulareingaben.
- Testen Sie Zoom, Umbruch bei schmaler Ansicht und bewegte Inhalte.
- Prüfen Sie Korrekturen im Produktivsystem erneut.
Prüfen Sie Technik und Zuständigkeiten im Produktivsystem
Prüfen Sie HTTPS, Weiterleitungen auf den kanonischen Host, Einstellungen der Produktivumgebung, Fehlerbehandlung, Backups und Überwachung. Erfassen Sie externe Dienste für Formulare, Einwilligungen, Karten, Videos, Schriften und CRM-Verbindungen und bestimmen Sie für jedes Konto eine verantwortliche Person.
Testen Sie ausserhalb der angemeldeten Sitzungen des Projektteams. Gespeicherte Anmeldedaten und Administrator-Cookies können Fehler verdecken. Verwenden Sie nach Möglichkeit ein privates Browserfenster und ein Mobilfunknetz.
Die Übergabe sollte Domain, Hosting, Repository, Analyse- und Suchkonten, Wiederherstellungsverfahren, Lieferantenkontakte und Erneuerungspflichten umfassen. Vermeiden Sie eine Veröffentlichung, die nur so lange funktioniert, wie eine einzelne externe Fachperson verfügbar bleibt.
- Prüfen Sie das Verhalten von Domain und Zertifikat.
- Kontrollieren Sie Backups und benennen Sie eine realistisch zuständige Person für die Wiederherstellung.
- Testen Sie Fehlerseiten und externe Abhängigkeiten.
- Dokumentieren Sie Kontozuständigkeiten und Erneuerungstermine.
| Ressource | Geschäftsleitung | Technischer Zugriff | Wiederherstellung | Erneuerung oder Prüfung |
|---|---|---|---|---|
| Domain | Benannte Funktion im Unternehmen | Administratoren beim Registrar | Dokumentierter Wiederherstellungskontakt | Vor Ablauf |
| Hosting | Benannte Funktion im Unternehmen | Plattformteam | Rücksetz- und Supportweg | Vierteljährlich |
| Repository | Benannte Funktion im Unternehmen | Verantwortliche für die Pflege | Geschütztes Administratorkonto zur Wiederherstellung | Bei Personalwechseln |
| Formularzustellung | Verkaufsverantwortliche Person | Technische und E-Mail-Administratoren | Alternativer Kontaktweg | Nach jeder Veröffentlichung |
Schützen Sie die Auffindbarkeit in Suchmaschinen
Entwicklungsumgebungen blockieren häufig das Crawling oder enthalten noindex-Anweisungen. Bereiten Sie vor der Veröffentlichung die vorgesehenen robots-Regeln für das Produktivsystem und eine genaue Liste der Seiten vor, bei denen noindex entfernt werden muss. Heben Sie den Schutz der Testumgebung selbst nicht auf.
Prüfen Sie im Produktivsystem kanonische URLs, Weiterleitungszuordnungen, gegebenenfalls hreflang, strukturierte Daten und die Sitemap. Google empfiehlt bei dauerhaften URL-Änderungen permanente serverseitige Weiterleitungen. Gelöschte Seiten ohne passende Ersatzseite sollten einen echten 404- oder 410-Status zurückgeben, statt pauschal auf die Homepage umzuleiten.
Überprüfen Sie die relevanten Search-Console-Properties und reichen Sie die Sitemap ein. Google bezeichnet das Einreichen einer Sitemap als Hinweis, nicht als Garantie für Crawling oder Indexierung. Bei wenigen besonders wichtigen Seiten kann die URL-Prüfung Diagnose und Einreichung unterstützen.
- Entfernen Sie unbeabsichtigte noindex-Anweisungen und Crawling-Sperren im Produktivsystem.
- Validieren Sie kanonischen Host, Weiterleitungen und interne Links.
- Führen Sie vollständig ausgeschriebene kanonische URLs in der Sitemap auf.
- Erhalten Sie Zugriff und Verifizierung in der Search Console nach der Veröffentlichung.
Testen Sie Messung, Einwilligung und Zustellung von Anfragen
Die Messung sollte geschäftliche Fragen beantworten, ohne mehr Genauigkeit vorzutäuschen, als die Einrichtung bietet. Prüfen Sie die Analysekonfiguration im Produktivsystem, das Verhalten der Einwilligung, den Umgang mit internem Traffic und jene Ereignisse, die bedeutsame Handlungen abbilden.
Senden Sie eine realistische Anfrage vollständig über das Produktivsystem. Prüfen Sie Validierung, Fehlerbehandlung, Annahmestatus, Zustellung an den vorgesehenen Posteingang oder das CRM und den Weg zur persönlichen Nachbearbeitung. Die Annahme durch einen Dienstleister beweist nicht zwingend den Eingang im Zielpostfach. Kontrollieren Sie deshalb nach Möglichkeit das tatsächliche Ziel.
Verwenden Sie erkennbare und sichere Testdaten. Tragen Sie keine Passwörter, Kundendaten oder vertraulichen Informationen in Formulare ein.
- Prüfen Sie, ob das Einwilligungsverhalten der freigegebenen Einrichtung entspricht.
- Verifizieren Sie Seitenaufrufe und vereinbarte Conversion-Ereignisse.
- Testen Sie einen erfolgreichen und einen fehlgeschlagenen Formularweg.
- Stellen Sie sicher, dass das empfangende Team neue Anfragen erkennt und bearbeitet.
| Signal | Test im Produktivsystem | Geschäftliche Bedeutung | Verantwortlich |
|---|---|---|---|
| Formular angenommen | Absenden und Bestätigung prüfen | System hat den Zustellauftrag angenommen | Technisch verantwortliche Person |
| Nachricht empfangen | Vorgesehenes Ziel kontrollieren | Operative Übergabe funktioniert | Verkaufsverantwortliche Person |
| Conversion-Ereignis | Analyse-Debugging oder Bericht prüfen | Messung wurde mit der vorgesehenen Einwilligung ausgelöst | Für Analyse verantwortliche Person |
| Zustellung fehlgeschlagen | Wo unterstützt einen sicheren Fehler simulieren | Besuchende erhalten eine ehrliche Möglichkeit zur Fortsetzung | Technisch verantwortliche Person |
Treffen Sie die Entscheidung im Produktivsystem
Arbeiten Sie mit zwei Nachweisphasen. Vor der Bereitstellung geben Sie Inhalte, Migrationsregeln, Konfiguration und Abläufe frei. Danach prüfen Sie tatsächliche HTTP-Antworten, kanonische Domain, Formulare, Einwilligung, Sitemap und vorrangige Weiterleitungen. Nachweise aus der Testumgebung ersetzen die Prüfung im Produktivsystem nicht.
Halten Sie die Prüfung kurz genug, damit sie zuverlässig durchgeführt wird, und streng genug, damit sie ihren Zweck erfüllt. Jede Zeile benötigt eine zuständige Person, einen Status und einen Nachweislink. Unbekannt bedeutet nicht bestanden.
Falls eine Rücksetzung mehr Schaden verursachen würde als eine kontrollierte Korrektur, kann die entscheidungsbefugte Person eine eingeschränkte Veröffentlichung wählen. Ausnahme, Auswirkung auf die Kundschaft und Frist müssen dabei ausdrücklich dokumentiert werden.
- Phase eins: Konfiguration, Inhalte, Migration und Abnahmebereitschaft.
- Phase zwei: Antworten des Produktivsystems, Kundenaufgaben und Zustellung.
- Verlangen Sie für den Status Bestanden einen Nachweis.
- Stellen Sie dem Betriebsteam die freigegebene Ausnahmeliste bereit.
Steuern Sie die ersten 30 Tage anhand konkreter Nachweise
Mit der Veröffentlichung beginnt eine Betriebsphase. Arbeiten Sie nach einem geplanten Rhythmus, statt ständig Dashboards zu beobachten oder auf Beschwerden zu warten. Der folgende Zeitplan ist ein redaktionelles Modell und keine allgemeingültige Erholungsfrist.
Überwachen Sie am ersten Tag kritische Fehler, Formularzustellung, wichtige Weiterleitungen und die Analyse im Produktivsystem. Prüfen Sie in der ersten Woche Crawling- und Indexierungssignale, Kundenrückmeldungen und schwerwiegende Mängel. Priorisieren Sie an den Tagen 14 und 30 wiederkehrende Muster, Inhaltslücken und Beobachtungen zur Leistung.
Felddaten zu den Core Web Vitals entstehen aus echten Besuchen und sollten anhand des passenden Perzentils und geeigneter Seitengruppen interpretiert werden. Versprechen Sie nicht, dass sich die Sichtbarkeit in Suchmaschinen bis zu einem festen Datum stabilisiert. Google weist darauf hin, dass Migrationen Zeit benötigen können, während Seiten erneut gecrawlt und indexiert werden.
- Tag 1: Kritische Abläufe und Fehlerüberwachung prüfen.
- Tag 2 bis 7: Anfragen, Weiterleitungen, Crawling-Signale und dringende Rückmeldungen beurteilen.
- Tag 14: Wiederkehrende Probleme und Zuständigkeiten prüfen.
- Tag 30: Steuerung der Veröffentlichungsphase abschliessen und Verbesserungsprioritäten freigeben.
| Zeitpunkt | Prüfung | Eskalieren, wenn | Ergebnis |
|---|---|---|---|
| Tag der Veröffentlichung | Formulare, Fehler, Weiterleitungen, Domain | Kritische Aufgabe fehlschlägt | Korrektur, Rücksetzung oder dokumentierte Einschränkung |
| Erste Woche | Indexierungssignale, Anfragen, Rückmeldungen | Wichtige Seiten oder Anfragen ausfallen | Priorisierter Vorfall |
| Tag 14 | Wiederkehrende Fehler und Inhaltslücken | Muster Kundenentscheide beeinträchtigt | Verbindlicher Änderungsplan |
| Tag 30 | Leistung, Suche, Qualität der Anfragen, offene Arbeiten | Risiko ohne Zuständigkeit bleibt | Betriebsprüfung und nächste Prioritäten |
IHRE FRAGEN, BEANTWORTET
Häufig gestellte Fragen
Was sollte die Veröffentlichung einer Website blockieren?
Fehler bei kritischen Kundenaufgaben, der Zustellung von Anfragen oder Zahlungen, der Einrichtung der kanonischen Domain, der Datenschutzfreigabe, der Sicherheit oder dem Erhalt wertvoller URLs rechtfertigen häufig einen negativen Entscheid. Definieren Sie projektspezifische Blocker im Voraus.
Reicht ein Test des Kontaktformulars in der Testumgebung?
Nein. Testen Sie den produktiven Weg, die Bestätigung und das tatsächliche Ziel, da sich Umgebungseinstellungen und Zustellverknüpfungen unterscheiden können.
Garantiert das Einreichen einer Sitemap die Indexierung?
Nein. Google bezeichnet die Einreichung einer Sitemap als Hinweis. Sie unterstützt Auffindbarkeit und Überwachung, garantiert aber weder Crawling noch Indexierung.
Wie schnell sollten sich Rankings nach einem Relaunch stabilisieren?
Dafür gibt es keine feste Frist. Erneutes Crawling und Indexieren hängen von der Website und dem Umfang der Änderungen ab. Beobachten Sie technische Signale und Ergebnisse für die Kundschaft, ohne ein erfundenes Erholungsdatum zu versprechen.
Was gehört in die Prüfung der ersten 30 Tage?
Kritische Fehler, Zustellung von Anfragen, Weiterleitungen, Indexierungssignale, Kundenrückmeldungen, Leistungsnachweise und eine Liste offener Arbeiten mit klaren Zuständigkeiten. Passen Sie den Rhythmus an Risiko und Besucheraufkommen an.
GENAUER NACHLESEN
Quellen und Referenzen
- Google Search Central: Websiteumzüge mit URL-Änderungen
- Google Search Central: Eine neue E-Commerce-Website veröffentlichen
- Google Search Central: Sitemap erstellen und einreichen
- Google Search Central: Fehlerbehebung bei Crawling-Problemen
- web.dev: Schwellenwerte der Core Web Vitals definieren
- W3C WAI: Easy Checks
