Website-Relaunch & DSGVO: Checkliste vor dem Go-live

Datenschutz früh in den Relaunch einplanen

Ein Relaunch wird häufig erst visuell abgenommen und kurz vor Veröffentlichung rechtlich betrachtet. Das ist riskant, weil Tracking, Fonts, Embeds und Formulare dann schon tief im System stecken.

Besser ist ein technischer Datenschutz-Check auf der Staging- oder Prelive-Seite. Wenn die Seite öffentlich erreichbar ist, kannst du bereits vor Go-live sehen, welche Dienste tatsächlich laden.

Go-live-Checkliste

• Cookie-Banner: Ohne Auswahl, nach Ablehnen und nach Akzeptieren testen. Nicht notwendige Dienste sollten nur im passenden Zustand laden.
• Tracking-Inventar: Analytics, Ads, Pixel, Tag Manager, Heatmaps und A/B-Testing vollständig erfassen.
• Fonts und Assets: Prüfen, ob Schriften, Icons oder Bibliotheken von externen Hosts geladen werden.
• Embeds: Videos, Karten, Social Posts, Kalender, Buchung und Chat auf Zwei-Klick- oder Consent-Kopplung prüfen.
• Formulare: Felder, Pflichtangaben, HTTPS, Empfänger und Datenschutzhinweise abgleichen.

Pflichttexte nicht einfach übernehmen

Alte Datenschutzerklärungen passen nach einem Relaunch selten vollständig. Neue Plattform, neue Plugins oder neue Marketing-Tools verändern die tatsächlichen Datenflüsse.

Prüfe deshalb erst die Technik und aktualisiere dann die Texte. Andersherum entstehen oft pauschale Datenschutztexte, die mit der realen Website nur teilweise übereinstimmen.

Staging und Passwortschutz

Eine passwortgeschützte Staging-Seite ist für externe Scanner nicht erreichbar. In diesem Fall kannst du manuell mit Browser-Tools prüfen oder kurzzeitig eine geschützte, aber scanbare Test-URL vorbereiten, wenn das intern zulässig ist.

Achte darauf, Staging-Seiten nicht indexieren zu lassen und keine echten personenbezogenen Daten im Testsystem zu verwenden, wenn das nicht notwendig ist.

Alt-Lasten aufspüren: was vom alten Auftritt übrig bleibt

Relaunches übernehmen selten nichts: Inhalte werden migriert, bewährte Snippets kopiert, alte Tracking-IDs weiterverwendet. Dabei wandern auch Dinge mit, die nie jemand bewusst entschieden hat — ein vergessener Pixel im Footer-Template, ein Analytics-Code aus einer früheren Agenturbeziehung, ein Chat-Widget, das längst gekündigt ist, dessen Skript aber weiter lädt.

Nimm dir deshalb die Übernahmen gezielt vor: Welche Tags, IDs und Einbindungen stammen aus dem alten Auftritt, und gibt es für jede davon eine aktive Entscheidung im neuen? Der Relaunch ist die beste Gelegenheit, Datenflüsse loszuwerden — danach schleppt man sie wieder Jahre mit.

Weiterleitungen, Subdomains und vergessene Bereiche

Mit dem Go-live verschwindet der alte Auftritt selten vollständig. Häufig bleiben Subdomains, Archiv-Stände, Test-Umgebungen oder alte Landingpages erreichbar — mit altem Cookie-Banner, alten Formularen und alter Datenschutzerklärung. Solche Bereiche werden bei der Prüfung gern übersehen, sind aber ganz normale öffentliche Seiten.

Erstelle deshalb eine Liste aller Domains und Subdomains, die zur Website gehören, und entscheide für jede: weiterleiten, abschalten oder bewusst weiterbetreiben — dann aber mit aktuellem Stand bei Consent und Pflichttexten. Alte URLs mit Formularen verdienen besondere Aufmerksamkeit, weil dort weiterhin personenbezogene Daten eingehen können.

Datenübernahme: Newsletter-Listen, Formulare und Konten

Ein Relaunch betrifft nicht nur Code und Design, sondern oft auch Datenbestände: Newsletter-Abonnenten wandern in ein neues Tool, alte Formular-Einsendungen liegen noch im alten CMS, Nutzerkonten werden migriert. Jede dieser Übernahmen ist eine Verarbeitung personenbezogener Daten und verdient eine bewusste Entscheidung statt eines pauschalen Komplett-Exports.

Bei Newsletter-Listen zählt die Nachweisbarkeit: Übernimm Einwilligungen nur mit ihrer Dokumentation (wann, wofür, wie eingeholt) und prüfe, ob der Zweck im neuen System derselbe bleibt. Listen ohne belastbaren Einwilligungsnachweis solltest du nicht einfach weiterverwenden — wie damit umzugehen ist, ist ein klassischer Fall für fachkundigen Rat.

Alte Formular-Einsendungen und inaktive Konten sind die Gelegenheit zum Aufräumen: Was keinen aktuellen Zweck mehr hat, wird gelöscht oder anonymisiert statt mitmigriert. Das alte System sollte nach erfolgreicher Übernahme nicht unbegrenzt als Datenfriedhof weiterlaufen — plane seine Abschaltung mit ein.

Rollen und Zeitplan für den Datenschutz-Check

Kurz vor Go-live ist für gründliche Korrekturen selten Zeit. Plane den technischen Datenschutz-Check deshalb als festen Meilenstein ein — idealerweise so früh, dass Befunde noch ohne Termindruck behoben werden können, und mit klarer Zuständigkeit: Wer prüft, wer behebt, wer gibt frei?

Bewährt hat sich eine einfache Aufteilung: Die technische Bestandsaufnahme (was lädt, was ist gekoppelt, welche Texte passen nicht) kann das Projektteam leisten. Die fachliche Bewertung strittiger Punkte — etwa zu Rechtsgrundlagen oder Drittlandfragen — gehört zu Datenschutzbeauftragten oder juristischer Beratung. Diese Trennung hält den Zeitplan und die Verantwortlichkeiten sauber.

Die ersten Wochen nach Launch: dranbleiben statt abhaken

Die riskanteste Phase für schleichende Abweichungen sind die Wochen nach dem Go-live. Jetzt werden Kampagnen gestartet, Pixel nachgerüstet, Inhalte ergänzt und letzte Wünsche umgesetzt — oft unter Zeitdruck und von verschiedenen Beteiligten. Genau dann entstehen die Tracker, die beim sorgfältig geprüften Launch noch nicht da waren.

Zwei einfache Gewohnheiten fangen das ab. Erstens ein Änderungs-Log: Jede nachträgliche Einbindung — Tag, Embed, Formular — wird mit Datum und Verantwortlichem notiert. Zweitens ein fester Wiederholungs-Check nach den ersten Wochen, wenn der Nachbesserungs-Schwung abgeebbt ist: derselbe Drei-Zustände-Test wie vor dem Launch, plus Abgleich mit dem Änderungs-Log.

Wer die Website fortlaufend betreut, kann diese Kontrolle auch dauerhaft einplanen — wichtig ist weniger das Werkzeug als die Regelmäßigkeit: Eine Website ist nach dem Relaunch nicht fertig, sie fängt gerade erst an, sich zu verändern.

Nach Go-live erneut messen

Produktionsumgebung und Staging sind nicht immer identisch. CDN, Analytics, Consent-Mode, Sentry, Chat-Widgets oder A/B-Tests werden manchmal erst live aktiviert. Deshalb ist ein zweiter Check nach Veröffentlichung sinnvoll.

Dokumentiere die Befunde und priorisiere technische Korrekturen: zuerst Tracker vor Consent, fehlende Pflichttexte, unsichere Formularflüsse und offensichtliche externe Assets ohne Zweck.

Häufige Fragen

Wann sollte der DSGVO-Check im Relaunch stattfinden?

Idealerweise vor Go-live auf einer realistischen Test-URL und erneut kurz nach Veröffentlichung, weil Produktionsdienste abweichen können.

Kann ich eine passwortgeschützte Staging-Seite scannen?

Nicht mit einem normalen öffentlichen Scan. Wenn die Seite nicht erreichbar ist, muss sie manuell geprüft oder kontrolliert scanbar bereitgestellt werden.

Welche Befunde zuerst beheben?

Priorisiere nicht notwendige Tracker vor Consent, fehlende oder widersprüchliche Pflichttexte, Formularprobleme und offensichtliche Drittanbieter-Embeds.

Darf ich Newsletter-Abonnenten einfach ins neue System übernehmen?

Mit dokumentierten Einwilligungen und gleichbleibendem Zweck ist eine Übernahme in der Regel möglich. Ohne belastbaren Nachweis der Einwilligung wird es heikel — diese Fälle solltest du vor der Migration fachkundig klären, nicht danach.

Was passiert mit dem alten CMS nach dem Relaunch?

Plane seine Abschaltung aktiv ein: Daten exportieren oder löschen, Zugänge schließen, Subdomain stilllegen oder weiterleiten. Ein vergessenes Altsystem mit Formulardaten ist ein typischer Befund späterer Audits.

Kann ich die Consent-Einstellungen aus dem alten Auftritt übernehmen?

Die Konfiguration ja, die Wirkung nicht ungeprüft: Auf der neuen Website laden andere Dienste, andere Templates und oft ein anderer Tag-Aufbau. Übernimm das Consent-Tool gern, aber teste die Kopplung auf der neuen Technik vollständig neu — sonst verwaltet das Banner Kategorien, die mit den echten Skripten nichts mehr zu tun haben.