gekennzeichnet. 
Kategorien: Datenschutz und Security
Ein Relaunch bringt neue Technik, neue Plugins und neue Einbettungen, und damit neue Risiken für Sicherheit und Datenschutz. Vor, während und nach dem Go-live gibt es einiges zu prüfen, und auch die PHP-Lücken vom Oktober 2026 gehören dazu.
Relaunches werden meist nach Design und Suchmaschinen-Platzierung geplant. Sicherheit und Datenschutz folgen oft als Nachgedanke, kurz vor dem Start oder gar nicht. Beim Website-Relaunch gehören Sicherheit und Datenschutz von Anfang an mit auf die Liste, denn der Neustart ist der Moment, in dem alte Annahmen nicht mehr gelten: Dienste, Server, Verträge und Zuständigkeiten ändern sich gleichzeitig.
Eine nüchterne Prüfliste folgt vier Phasen, von der Planung bis zur Kontrolle nach dem Start. Als aktuelles Beispiel dienen die beiden kritischen PHP-Schwachstellen vom 21.10.2026. Der Text ist keine Rechtsberatung und ersetzt keinen Sicherheitstest. Stand der Angaben zur PHP-Lage ist der 22.10.2026, sie können sich ändern.
Website-Relaunch Sicherheit: Warum der Neustart ein riskanter Moment ist
Bei einem Website-Relaunch wird selten nur ein neues Aussehen eingespielt. Meist wechseln das Content-Management-System (CMS), das Theme, mehrere Plugins, manchmal auch der Hoster und die Agentur. Dazu kommen Datenmigration, Zeitdruck und ein fester Starttermin. Fehler entstehen an den Übergängen von alt zu neu: Eine Testseite bleibt öffentlich, eine Einstellung wird nicht übernommen, ein alter Zugang bleibt aktiv.
Hilfreich ist ein fester Rahmen. Sicherheit und Datenschutz gehören als Anforderung ins Lastenheft und nicht erst in die Abnahme. Als roter Faden dienen vier Phasen: Planung, Staging, Go-live und die Zeit danach. In jeder Phase gibt es einen Blick auf die Sicherheit und einen auf den Datenschutz.
Die Phasen bauen aufeinander auf. Was in der Planung nicht geklärt wird, fehlt später bei der Abnahme. Und was nach dem Start nicht erneut geprüft wird, veraltet still.
Planung: Anforderungen, Zuständigkeiten und Verträge klären
Am Anfang steht die Frage, wer die Website betreibt, wer sie pflegt und wer bei einem Vorfall reagiert. Sind Betreiber, Agentur und Hoster nicht klar benannt, bleiben Updates liegen, weil jeder annimmt, der andere kümmere sich.
Für den Datenschutz ist wichtig, dass Agenturen und Hoster in der Regel personenbezogene Daten im Auftrag verarbeiten. Diese sogenannte Auftragsverarbeitung (Verarbeitung im Auftrag und nach Weisung des Betreibers) braucht einen Vertrag, wie ihn Artikel 28 DSGVO vorsieht. Beim Wechsel des Hosters oder der Agentur ist zu prüfen, ob der Vertrag für den neuen Dienstleister vorliegt.
Sinnvoll ist außerdem eine Liste aller geplanten Dienste: Schriftarten, Karten, Videos, Newsletter, Statistik, Chat. Jeder Eintrag wird mit Zweck, Anbieter und Vertragsstand versehen. Der Grundsatz der Datenminimierung hilft dabei: Was das neue Konzept nicht braucht, wird gar nicht erst eingebaut. Das gilt für Formularfelder genauso wie für Tracking.
Ein weiterer Punkt betrifft die Zugänge. Die Agentur sollte mit eigenen, personengebundenen Konten arbeiten und nur die Rechte erhalten, die sie braucht. Gemeinsam genutzte Zugangsdaten sind ein häufiges Einfallstor, weil sie später niemand mehr zuordnen kann. Zum Projektende werden die Konten der Agentur gesperrt oder gelöscht. Das ist Teil des Vertrags und gehört in die Planung.
Die Laufzeitumgebung: PHP-Version, Hosting und das Beispiel vom 21.10.2026
Ein CMS ist nur die obere Schicht einer Website. Darunter liegt die Laufzeitumgebung, bei vielen Websites die Programmiersprache PHP, und darunter Webserver und Betriebssystem. Jede Schicht braucht eigene Sicherheitsupdates. Ein frisch installiertes CMS mit aktuellen Plugins sagt deshalb noch nichts darüber aus, ob PHP auf dem Server gepatcht ist.
Das aktuelle Beispiel zeigt, warum diese Prüfung zum Relaunch gehört. Am 21.10.2026 veröffentlichte das PHP-Team Sicherheitsupdates für zwei Schwachstellen, die als CVE-2026-109618 und CVE-2026-109619 geführt werden. Eine CVE-Nummer ist eine eindeutige Kennung für eine bekannte Schwachstelle. Beide Einträge sind nach CVSS 4.0, einer Skala von 0 bis 10 für den Schweregrad, mit 9,2 als kritisch bewertet. Es geht um die Ausführung fremden Programmcodes aus der Ferne (Remote Code Execution, RCE) ohne Anmeldung. Laut Advisory ist die Angriffskomplexität hoch, und es müssen bestimmte Voraussetzungen erfüllt sein.
Die Versionsangaben unterscheiden sich je nach Quelle. Die GitHub-Advisories nennen die Zweige PHP 8.2 bis 8.5, betroffen jeweils vor 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Das PHP-Projekt bestätigt diese Fixversionen in seiner Sicherheitsmeldung vom 21.10.2026 und nennt zusätzlich Backports für 7.4, 8.0 und 8.1. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) spricht in seinem Sicherheitshinweis vom 21.10.2026 von allen PHP-Versionen bis mindestens PHP 5 und stuft die Lage mit Kritikalität 3 (Orange) ein.
Wichtig ist die Trennung von Belegtem und Unbelegtem. Laut BSI gibt es keine bestätigten Angriffe, aber unbestätigte Berichte, und eine breite Ausnutzung nach der Veröffentlichung des Patches wird als wahrscheinlich eingeschätzt. Eine belastbare Zahl verwundbarer Websites nennt weder das PHP-Team noch das BSI. Klar ist nur: PHP läuft auf einem sehr großen Teil aller Websites (siehe Sicherheitslücke PHP2Shell).
Für den Relaunch ergibt sich daraus eine Lehre ohne Panik. Die PHP-Version samt Patchstand wird dokumentiert, die Zuständigkeit für Updates der Laufzeitumgebung wird festgelegt, und es wird eine Reaktionszeit vereinbart. Dazu zählt auch das Support-Ende: PHP 8.2 erhält laut php.net bis zum 31.12.2026 Sicherheitsupdates. Ein Neuaufbau auf diesem Zweig ist damit schon bei der Planung ein Ablaufdatum.
Reicht es beim Relaunch, das neue CMS und die Plugins zu aktualisieren, damit die Website sicher ist?
Ein externer Test von außen kann PHP-Version und Serverkonfiguration nur begrenzt beurteilen. Die Security-Checks von wwwschutz.de liefern eine technische Außensicht, ersetzen aber nicht den Blick des Hosters auf den Server selbst.
Staging-Umgebung im Relaunch: Zugangsschutz, keine Echtdaten, danach abschalten
Staging bezeichnet eine Testumgebung, in der die neue Website vor dem Start aufgebaut und geprüft wird. Sie ist oft unter einer Subdomain erreichbar und enthält unfertige Inhalte, Testkonten und mitunter Kopien echter Daten. Für diese Umgebung gilt eine feste Reihenfolge beim Schutz: Zuerst ein Zugangsschutz per Passwort (HTTP-Authentifizierung) oder IP-Beschränkung, dann die Anweisung „noindex“ gegen die Aufnahme in Suchmaschinen. Eine robots.txt allein reicht nicht, denn laut Google Search Central dient sie der Steuerung des Crawlings und hält Seiten nicht zuverlässig aus der Suche.
Echtdaten gehören nicht auf Staging. Eine Kopie der Produktivdatenbank mit Kundendaten, Anfragen oder Newsletter-Adressen verlagert personenbezogene Daten in eine schwächer geschützte Umgebung. Besser sind Testdaten oder eine bereinigte Kopie.
Aus der Praxis ist ein häufiger Fehler bekannt: Die noindex-Einstellung der Testumgebung wird mit auf die Live-Seite übernommen, und die neue Website verschwindet aus den Suchergebnissen. Das ist eine Erfahrung aus Relaunch-Projekten und keine Norm, sie lässt sich aber leicht prüfen. Nach dem Go-live wird die Staging-Umgebung abgeschaltet, einschließlich des DNS-Eintrags. Wie vergessene Testumgebungen zu einem Risiko werden, beschreibt der Beitrag zu vergessenen Subdomains und Staging-Altlasten.
Datenschutz im neuen Auftritt: Einwilligung, Drittdienste und Datenschutzerklärung
Neue Plugins, Schriften, Karten, Videos und Statistik-Tools verändern, welche Daten die Seite an Dritte sendet. Die Datenschutzerklärung beschreibt dagegen den Zustand der alten Seite. Nach dem Neustart sollte sie deshalb mit den tatsächlich geladenen Diensten abgeglichen werden. Die Pflicht zur Information über die Datenverarbeitung ergibt sich aus Artikel 13 DSGVO. Fehlt ein Dienst in der Erklärung oder steht ein längst entfernter Dienst noch darin, stimmen Text und Technik nicht überein. Die Datenschutzerklärung nach dem Relaunch zu aktualisieren gehört zu jeder Abnahme.
Zur Einwilligung: Werden Informationen auf dem Endgerät gespeichert oder ausgelesen, ist nach § 25 TDDDG grundsätzlich eine Einwilligung nötig, sofern keine Ausnahme greift. Beim Wechsel von Theme oder Consent-Tool gehen Einstellungen des alten Cookie-Banners erfahrungsgemäß leicht verloren, oder das Banner blockiert die neuen Dienste nicht mehr. Das ist Praxiswissen und kein Beleg für eine bestimmte Software. Geprüft wird daher im Browser: Was wird vor der Entscheidung geladen, und was passiert nach einer Ablehnung?
Auch das Impressum wandert mit. Die Pflichtangaben nach § 5 DDG sind zu übernehmen und auf Aktualität zu prüfen, etwa bei geänderter Anschrift oder Rechtsform.
Formulare, Konten und Daten: Was bei der Migration mitwandert
Bei der Migration stellt sich die Frage, welche Daten überhaupt in das neue System gehören. Alte Formularanfragen, Newsletter-Listen, Benutzerkonten, Kommentare und Protokolldateien enthalten häufig personenbezogene Daten. Was nicht mehr gebraucht wird oder dessen Aufbewahrungsfrist abgelaufen ist, wird nicht migriert, sondern gelöscht. Das folgt dem Grundsatz der Datenminimierung und spart zugleich Angriffsfläche.
Werden Benutzerkonten übernommen, ist das Passwort-Verfahren zu prüfen. Passwörter dürfen nur als Hash gespeichert sein, und das neue System muss das alte Hash-Verfahren lesen oder die Nutzer zum Zurücksetzen auffordern. Zugriffsrechte werden neu vergeben, nicht einfach kopiert. Standardkonten wie „admin“ und Test-Logins der Entwicklung werden entfernt.
Sicherungen und Exporte gehören nicht in öffentlich erreichbare Verzeichnisse. Ein Datenbank-Dump im Webroot ist ein klassischer Fund bei Angriffen von außen. Die Pflicht, ein dem Risiko angemessenes Schutzniveau zu gewährleisten, regelt Artikel 32 DSGVO. Für den Relaunch heißt das praktisch: Zugriff nur nach Bedarf, Verschlüsselung bei der Übertragung, getestete Backups.
Alte Seite, Weiterleitungen und Altlasten: Was nach dem Umzug stehen bleibt
Ändern sich Adressen, werden alte URLs per 301-Weiterleitung (dauerhafte Umleitung) auf die neuen Seiten geführt. Das ist vor allem für die Auffindbarkeit wichtig, hat aber auch eine Sicherheitsseite. Weiterleitungsziele sollten nur auf die eigene Domain zeigen. Wird das Ziel aus einem Parameter der Adresse gelesen, entsteht eine offene Weiterleitung, die sich für Phishing missbrauchen lässt. Das ist Fachwissen aus der Webentwicklung und sollte in der Abnahme getestet werden.
Zu den Altlasten zählen alte Domains und Subdomains, ausgemusterte Test-Uploads, Entwickler-Dateien wie phpinfo-Seiten und Backups. Nach einem Hosterwechsel bleiben außerdem DNS-Einträge bestehen, die auf nicht mehr genutzte Server zeigen. Solche verwaisten Einträge können Dritte unter Umständen übernehmen. Auch dazu gibt der Beitrag zu vergessenen Subdomains einen Überblick.
Zuletzt sind alte Zugangsdaten zu sperren: Zugänge des Altsystems, FTP-Konten, Datenbanknutzer und Schlüssel der früheren Agentur. Die alte Installation wird erst abgeschaltet, wenn die Weiterleitungen getestet sind und ein Backup existiert. Danach sollte sie nicht weiterlaufen, denn ein ungepflegtes Altsystem ist das schwächste Glied.
Wer prüft was: Verantwortung zwischen Auftraggeber, Agentur und Hoster
Viele Probleme entstehen nicht aus Unwissen, sondern aus unklarer Zuständigkeit. Die folgende Tabelle ordnet die Prüfpunkte den Beteiligten zu. Es handelt sich um eine redaktionelle Einschätzung und keine Norm. Verträge können die Aufteilung ändern.
Ein Relaunch ist der seltene Moment, in dem alles auf einmal verändert werden darf. Genau deshalb sollte auch alles auf einmal geprüft werden.
| Prüfpunkt | Phase | Auftraggeber | Agentur | Hoster |
|---|---|---|---|---|
| PHP-Version und Updates | Planung, danach | Verantwortet, lässt dokumentieren | Prüft Kompatibilität | Stellt Version bereit, patcht Server |
| Zugangsschutz Staging | Staging | Nimmt ab | Richtet ein | Unterstützt |
| Verträge zur Auftragsverarbeitung | Planung | Schließt ab | Liefert eigene Unterlagen | Liefert eigene Unterlagen |
| Datenschutzerklärung und Banner | Go-live | Verantwortet | Meldet geladene Dienste | Nicht beteiligt |
| Backup und Wiederherstellung | Go-live, danach | Lässt Test nachweisen | Prüft Seitenstand | Sichert Server, stellt wieder her |
| Weiterleitungen, Abschaltung Altsystem | Go-live, danach | Gibt frei | Setzt um | Schaltet DNS und Server ab |
| Abnahmeprotokoll | Go-live | Unterschreibt, archiviert | Erstellt | Liefert Nachweise |
Wichtig ist das Abnahmeprotokoll. Es hält fest, wer was geprüft hat und mit welchem Ergebnis. Bei Streit um Zuständigkeiten oder bei einem Vorfall liefert es den Nachweis. Betreiber, die nach der NIS2-Richtlinie in den Anwendungsbereich fallen könnten, finden eine Einordnung im Beitrag zu NIS2 für Website-Betreiber im Mittelstand.
Abnahme vor dem Go-live und Kontrolle danach: Die Relaunch-Checkliste für Sicherheit
Die Website-Relaunch Checkliste fasst die vorherigen Abschnitte in zehn Punkten zusammen. Jeder Punkt wird mit Datum und Verantwortlichem im Abnahmeprotokoll vermerkt.
- PHP-Version und Patchstand dokumentieren, Support-Ende der Version notieren.
- HTTPS, Zertifikat und Weiterleitung von HTTP auf HTTPS prüfen.
- Staging-Zugangsschutz entfernen oder Staging abschalten, noindex-Einstellung der Live-Seite prüfen.
- Backups testen und nicht öffentlich ablegen.
- Admin-Zugänge, Konten und Standard-Logins prüfen, Konten der Agentur sperren.
- Geladene Dienste gegen die Datenschutzerklärung und das Banner abgleichen.
- Formulare testen: Hinweistext, verschlüsselte Übertragung, Empfänger.
- Alte Seite, Test-Uploads und verwaiste DNS-Einträge abschalten.
- Außensicht prüfen.
- Abnahme dokumentieren und einen Wiederholungstermin setzen.
Die Kontrolle endet nicht mit dem Start. In den ersten Tagen lohnt ein Blick in die Fehlerprotokolle, auf Weiterleitungen, auf die Erreichbarkeit der Formulare und auf unerwartete Dienste in der Netzwerkansicht des Browsers. Wiederholungstermine, etwa nach einem Quartal oder nach größeren Updates, halten den Stand aktuell.
Nach dem Go-live gegenprüfen
Der kostenlose Check zeigt von außen, welche Dienste die neue Website lädt und wo Datenschutz und Technik nicht zusammenpassen.
Fazit: Drei Dinge vor dem nächsten Relaunch
Drei Maßnahmen bringen den größten Nutzen. Erstens gehören Sicherheit und Datenschutz ins Lastenheft und nicht erst in die Abnahme. Zweitens werden Laufzeitumgebung und Update-Zuständigkeit schriftlich geklärt, denn die PHP-Lücken vom Oktober 2026 zeigen, dass Schwachstellen unterhalb des CMS entstehen. Drittens werden nach dem Go-live Außensicht und geladene Dienste erneut geprüft, weil sich der Stand von Technik und Datenschutzerklärung nach dem Start weiter ändert.
Ein Relaunch ohne böse Überraschungen ist damit vor allem eine Frage der Reihenfolge und der klaren Verantwortung. Wer Phasen, Zuständigkeiten und Belege festhält, kann den Neustart gelassen angehen.