{"id":5795,"date":"2026-10-30T17:01:08","date_gmt":"2026-10-30T16:01:08","guid":{"rendered":"https:\/\/wwwschutz.de\/blog\/?p=5795"},"modified":"2026-10-23T16:11:03","modified_gmt":"2026-10-23T14:11:03","slug":"relaunch-website-sicherheit-datenschutz","status":"publish","type":"post","link":"https:\/\/wwwschutz.de\/blog\/relaunch-website-sicherheit-datenschutz\/","title":{"rendered":"Relaunch ohne b\u00f6se \u00dcberraschungen: Was beim Website-Neustart in puncto Sicherheit und Datenschutz zu pr\u00fcfen ist"},"content":{"rendered":"\n

Ein Relaunch bringt neue Technik, neue Plugins und neue Einbettungen, und damit neue Risiken f\u00fcr Sicherheit und Datenschutz. Vor, w\u00e4hrend und nach dem Go-live gibt es einiges zu pr\u00fcfen, und auch die PHP-L\u00fccken vom Oktober 2026 geh\u00f6ren dazu.<\/em><\/p>\n\n\n\n

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\u00f6ren 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\u00e4ge und Zust\u00e4ndigkeiten \u00e4ndern sich gleichzeitig.<\/p>\n\n\n\n

Eine n\u00fcchterne Pr\u00fcfliste 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\u00f6nnen sich \u00e4ndern.<\/p>\n\n\n\n

Website-Relaunch Sicherheit: Warum der Neustart ein riskanter Moment ist<\/h2>\n\n\n\n

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 \u00dcberg\u00e4ngen von alt zu neu: Eine Testseite bleibt \u00f6ffentlich, eine Einstellung wird nicht \u00fcbernommen, ein alter Zugang bleibt aktiv.<\/p>\n\n\n\n

Hilfreich ist ein fester Rahmen. Sicherheit und Datenschutz geh\u00f6ren 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.<\/p>\n\n\n\n\n

\"Schema
Vier Phasen mit je einem Blick auf Sicherheit und Datenschutz.<\/figcaption><\/figure>\n\n\n\n\n

Die Phasen bauen aufeinander auf. Was in der Planung nicht gekl\u00e4rt wird, fehlt sp\u00e4ter bei der Abnahme. Und was nach dem Start nicht erneut gepr\u00fcft wird, veraltet still.<\/p>\n\n\n\n

Planung: Anforderungen, Zust\u00e4ndigkeiten und Vertr\u00e4ge kl\u00e4ren<\/h2>\n\n\n\n

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\u00fcmmere sich.<\/p>\n\n\n\n

F\u00fcr 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\u00fcfen, ob der Vertrag f\u00fcr den neuen Dienstleister vorliegt.<\/p>\n\n\n\n

Sinnvoll ist au\u00dferdem 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\u00fcr Formularfelder genauso wie f\u00fcr Tracking.<\/p>\n\n\n\n

Ein weiterer Punkt betrifft die Zug\u00e4nge. Die Agentur sollte mit eigenen, personengebundenen Konten arbeiten und nur die Rechte erhalten, die sie braucht. Gemeinsam genutzte Zugangsdaten sind ein h\u00e4ufiges Einfallstor, weil sie sp\u00e4ter niemand mehr zuordnen kann. Zum Projektende werden die Konten der Agentur gesperrt oder gel\u00f6scht. Das ist Teil des Vertrags und geh\u00f6rt in die Planung.<\/p>\n\n\n\n

Die Laufzeitumgebung: PHP-Version, Hosting und das Beispiel vom 21.10.2026<\/h2>\n\n\n\n

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\u00fcber aus, ob PHP auf dem Server gepatcht ist.<\/p>\n\n\n\n\n

\"Schichten
Ein CMS-Update erreicht nur eine von mehreren Schichten, PHP und Server brauchen eigene Updates.<\/figcaption><\/figure>\n\n\n\n\n

Das aktuelle Beispiel zeigt, warum diese Pr\u00fcfung zum Relaunch geh\u00f6rt. Am 21.10.2026 ver\u00f6ffentlichte das PHP-Team Sicherheitsupdates f\u00fcr zwei Schwachstellen, die als CVE-2026-109618<\/a> und CVE-2026-109619<\/a> gef\u00fchrt werden. Eine CVE-Nummer ist eine eindeutige Kennung f\u00fcr eine bekannte Schwachstelle. Beide Eintr\u00e4ge sind nach CVSS 4.0, einer Skala von 0 bis 10 f\u00fcr den Schweregrad, mit 9,2 als kritisch bewertet. Es geht um die Ausf\u00fchrung fremden Programmcodes aus der Ferne (Remote Code Execution, RCE) ohne Anmeldung. Laut Advisory ist die Angriffskomplexit\u00e4t hoch, und es m\u00fcssen bestimmte Voraussetzungen erf\u00fcllt sein.<\/p>\n\n\n\n

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\u00e4tigt diese Fixversionen in seiner Sicherheitsmeldung vom 21.10.2026<\/a> und nennt zus\u00e4tzlich Backports f\u00fcr 7.4, 8.0 und 8.1. Das Bundesamt f\u00fcr Sicherheit in der Informationstechnik (BSI) spricht in seinem Sicherheitshinweis vom 21.10.2026<\/a> von allen PHP-Versionen bis mindestens PHP 5 und stuft die Lage mit Kritikalit\u00e4t 3 (Orange) ein.<\/p>\n\n\n\n

Wichtig ist die Trennung von Belegtem und Unbelegtem. Laut BSI gibt es keine best\u00e4tigten Angriffe, aber unbest\u00e4tigte Berichte, und eine breite Ausnutzung nach der Ver\u00f6ffentlichung des Patches wird als wahrscheinlich eingesch\u00e4tzt. Eine belastbare Zahl verwundbarer Websites nennt weder das PHP-Team noch das BSI. Klar ist nur: PHP l\u00e4uft auf einem sehr gro\u00dfen Teil aller Websites (siehe Sicherheitsl\u00fccke PHP2Shell).<\/p>\n\n\n\n

F\u00fcr den Relaunch ergibt sich daraus eine Lehre ohne Panik. Die PHP-Version samt Patchstand wird dokumentiert, die Zust\u00e4ndigkeit f\u00fcr Updates der Laufzeitumgebung wird festgelegt, und es wird eine Reaktionszeit vereinbart. Dazu z\u00e4hlt auch das Support-Ende: PHP 8.2 erh\u00e4lt laut php.net bis zum 31.12.2026 Sicherheitsupdates. Ein Neuaufbau auf diesem Zweig ist damit schon bei der Planung ein Ablaufdatum.<\/p>\n\n\n

\n
\n

Reicht es beim Relaunch, das neue CMS und die Plugins zu aktualisieren, damit die Website sicher ist?<\/h4>\n
\n
Nein. CMS und Plugins laufen auf einer Laufzeitumgebung wie PHP, die eigene Sicherheitsupdates braucht. Die beiden kritischen PHP-L\u00fccken vom 21.10.2026 (CVE-2026-109618 und CVE-2026-109619) liegen in der Laufzeitumgebung selbst und sind laut PHP-Team nur mit einem Update auf eine gepatchte Version vollst\u00e4ndig behoben. Beim Relaunch geh\u00f6ren PHP-Version, Hosting-Updates und Zust\u00e4ndigkeiten deshalb ebenso zur Abnahme wie das CMS.<\/div>\n <\/div>\n <\/div>\n\n <\/div>\n \n\n\n\n

Ein externer Test von au\u00dfen kann PHP-Version und Serverkonfiguration nur begrenzt beurteilen. Die Security-Checks von wwwschutz.de<\/a> liefern eine technische Au\u00dfensicht, ersetzen aber nicht den Blick des Hosters auf den Server selbst.<\/p>\n\n\n\n

Staging-Umgebung im Relaunch: Zugangsschutz, keine Echtdaten, danach abschalten<\/h2>\n\n\n\n

Staging bezeichnet eine Testumgebung, in der die neue Website vor dem Start aufgebaut und gepr\u00fcft wird. Sie ist oft unter einer Subdomain erreichbar und enth\u00e4lt unfertige Inhalte, Testkonten und mitunter Kopien echter Daten. F\u00fcr diese Umgebung gilt eine feste Reihenfolge beim Schutz: Zuerst ein Zugangsschutz per Passwort (HTTP-Authentifizierung) oder IP-Beschr\u00e4nkung, dann die Anweisung \u201enoindex\u201c gegen die Aufnahme in Suchmaschinen. Eine robots.txt allein reicht nicht, denn laut Google Search Central<\/a> dient sie der Steuerung des Crawlings und h\u00e4lt Seiten nicht zuverl\u00e4ssig aus der Suche.<\/p>\n\n\n\n

Echtdaten geh\u00f6ren nicht auf Staging. Eine Kopie der Produktivdatenbank mit Kundendaten, Anfragen oder Newsletter-Adressen verlagert personenbezogene Daten in eine schw\u00e4cher gesch\u00fctzte Umgebung. Besser sind Testdaten oder eine bereinigte Kopie.<\/p>\n\n\n\n

Aus der Praxis ist ein h\u00e4ufiger Fehler bekannt: Die noindex-Einstellung der Testumgebung wird mit auf die Live-Seite \u00fcbernommen, und die neue Website verschwindet aus den Suchergebnissen. Das ist eine Erfahrung aus Relaunch-Projekten und keine Norm, sie l\u00e4sst sich aber leicht pr\u00fcfen. Nach dem Go-live wird die Staging-Umgebung abgeschaltet, einschlie\u00dflich des DNS-Eintrags. Wie vergessene Testumgebungen zu einem Risiko werden, beschreibt der Beitrag zu vergessenen Subdomains und Staging-Altlasten.<\/p>\n\n\n\n

Datenschutz im neuen Auftritt: Einwilligung, Drittdienste und Datenschutzerkl\u00e4rung<\/h2>\n\n\n\n

Neue Plugins, Schriften, Karten, Videos und Statistik-Tools ver\u00e4ndern, welche Daten die Seite an Dritte sendet. Die Datenschutzerkl\u00e4rung beschreibt dagegen den Zustand der alten Seite. Nach dem Neustart sollte sie deshalb mit den tats\u00e4chlich geladenen Diensten abgeglichen werden. Die Pflicht zur Information \u00fcber die Datenverarbeitung ergibt sich aus Artikel 13 DSGVO. Fehlt ein Dienst in der Erkl\u00e4rung oder steht ein l\u00e4ngst entfernter Dienst noch darin, stimmen Text und Technik nicht \u00fcberein. Die Datenschutzerkl\u00e4rung nach dem Relaunch zu aktualisieren geh\u00f6rt zu jeder Abnahme.<\/p>\n\n\n\n

Zur Einwilligung: Werden Informationen auf dem Endger\u00e4t gespeichert oder ausgelesen, ist nach \u00a7 25 TDDDG<\/a> grunds\u00e4tzlich eine Einwilligung n\u00f6tig, sofern keine Ausnahme greift. Beim Wechsel von Theme oder Consent-Tool gehen Einstellungen des alten Cookie-Banners erfahrungsgem\u00e4\u00df leicht verloren, oder das Banner blockiert die neuen Dienste nicht mehr. Das ist Praxiswissen und kein Beleg f\u00fcr eine bestimmte Software. Gepr\u00fcft wird daher im Browser: Was wird vor der Entscheidung geladen, und was passiert nach einer Ablehnung?<\/p>\n\n\n\n

Auch das Impressum wandert mit. Die Pflichtangaben nach \u00a7 5 DDG<\/a> sind zu \u00fcbernehmen und auf Aktualit\u00e4t zu pr\u00fcfen, etwa bei ge\u00e4nderter Anschrift oder Rechtsform.<\/p>\n\n\n\n

Formulare, Konten und Daten: Was bei der Migration mitwandert<\/h2>\n\n\n\n

Bei der Migration stellt sich die Frage, welche Daten \u00fcberhaupt in das neue System geh\u00f6ren. Alte Formularanfragen, Newsletter-Listen, Benutzerkonten, Kommentare und Protokolldateien enthalten h\u00e4ufig personenbezogen<\/strong>e Daten. Was nicht mehr gebraucht wird oder dessen Aufbewahrungsfrist abgelaufen ist, wird nicht migriert, sondern gel\u00f6scht. Das folgt dem Grundsatz der Datenminimierung und spart zugleich Angriffsfl\u00e4che<\/a>.<\/p>\n\n\n\n

Werden Benutzerkonten \u00fcbernommen, ist das Passwort-Verfahren zu pr\u00fcfen. Passw\u00f6rter d\u00fcrfen nur als Hash gespeichert sein, und das neue System muss das alte Hash-Verfahren lesen oder die Nutzer zum Zur\u00fccksetzen auffordern. Zugriffsrechte werden neu vergeben, nicht einfach kopiert. Standardkonten wie \u201eadmin\u201c und Test-Logins der Entwicklung werden entfernt.<\/p>\n\n\n\n

Sicherungen und Exporte geh\u00f6ren nicht in \u00f6ffentlich erreichbare Verzeichnisse. Ein Datenbank-Dump im Webroot ist ein klassischer Fund bei Angriffen von au\u00dfen. Die Pflicht, ein dem Risiko angemessenes Schutzniveau zu gew\u00e4hrleisten, regelt Artikel 32 DSGVO. F\u00fcr den Relaunch hei\u00dft das praktisch: Zugriff nur nach Bedarf, Verschl\u00fcsselung bei der \u00dcbertragung, getestete Backups.<\/p>\n\n\n\n

Alte Seite, Weiterleitungen und Altlasten: Was nach dem Umzug stehen bleibt<\/h2>\n\n\n\n

\u00c4ndern sich Adressen, werden alte URLs per 301-Weiterleitung (dauerhafte Umleitung) auf die neuen Seiten gef\u00fchrt. Das ist vor allem f\u00fcr 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\u00fcr Phishing missbrauchen l\u00e4sst. Das ist Fachwissen aus der Webentwicklung und sollte in der Abnahme getestet werden.<\/p>\n\n\n\n

Zu den Altlasten z\u00e4hlen alte Domains und Subdomains, ausgemusterte Test-Uploads, Entwickler-Dateien wie phpinfo-Seiten und Backups. Nach einem Hosterwechsel bleiben au\u00dferdem DNS-Eintr\u00e4ge bestehen, die auf nicht mehr genutzte Server zeigen. Solche verwaisten Eintr\u00e4ge k\u00f6nnen Dritte unter Umst\u00e4nden \u00fcbernehmen. Auch dazu gibt der Beitrag zu vergessenen Subdomains einen \u00dcberblick.<\/p>\n\n\n\n

Zuletzt sind alte Zugangsdaten zu sperren: Zug\u00e4nge des Altsystems, FTP-Konten, Datenbanknutzer und Schl\u00fcssel der fr\u00fcheren 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\u00e4chste Glied.<\/p>\n\n\n\n

Wer pr\u00fcft was: Verantwortung zwischen Auftraggeber, Agentur und Hoster<\/h2>\n\n\n\n

Viele Probleme entstehen nicht aus Unwissen, sondern aus unklarer Zust\u00e4ndigkeit. Die folgende Tabelle ordnet die Pr\u00fcfpunkte den Beteiligten zu. Es handelt sich um eine redaktionelle Einsch\u00e4tzung und keine Norm. Vertr\u00e4ge k\u00f6nnen die Aufteilung \u00e4ndern.<\/p>\n\n\n\n

Ein Relaunch ist der seltene Moment, in dem alles auf einmal ver\u00e4ndert werden darf. Genau deshalb sollte auch alles auf einmal gepr\u00fcft werden.<\/p><\/blockquote><\/figure>\n\n\n\n

Pr\u00fcfpunkt<\/th>Phase<\/th>Auftraggeber<\/th>Agentur<\/th>Hoster<\/th><\/tr><\/thead>
PHP-Version und Updates<\/td>Planung, danach<\/td>Verantwortet, l\u00e4sst dokumentieren<\/td>Pr\u00fcft Kompatibilit\u00e4t<\/td>Stellt Version bereit, patcht Server<\/td><\/tr>
Zugangsschutz Staging<\/td>Staging<\/td>Nimmt ab<\/td>Richtet ein<\/td>Unterst\u00fctzt<\/td><\/tr>
Vertr\u00e4ge zur Auftragsverarbeitung<\/td>Planung<\/td>Schlie\u00dft ab<\/td>Liefert eigene Unterlagen<\/td>Liefert eigene Unterlagen<\/td><\/tr>
Datenschutzerkl\u00e4rung und Banner<\/td>Go-live<\/td>Verantwortet<\/td>Meldet geladene Dienste<\/td>Nicht beteiligt<\/td><\/tr>
Backup und Wiederherstellung<\/td>Go-live, danach<\/td>L\u00e4sst Test nachweisen<\/td>Pr\u00fcft Seitenstand<\/td>Sichert Server, stellt wieder her<\/td><\/tr>
Weiterleitungen, Abschaltung Altsystem<\/td>Go-live, danach<\/td>Gibt frei<\/td>Setzt um<\/td>Schaltet DNS und Server ab<\/td><\/tr>
Abnahmeprotokoll<\/td>Go-live<\/td>Unterschreibt, archiviert<\/td>Erstellt<\/td>Liefert Nachweise<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Wichtig ist das Abnahmeprotokoll. Es h\u00e4lt fest, wer was gepr\u00fcft hat und mit welchem Ergebnis. Bei Streit um Zust\u00e4ndigkeiten oder bei einem Vorfall liefert es den Nachweis. Betreiber, die nach der NIS2-Richtlinie in den Anwendungsbereich fallen k\u00f6nnten, finden eine Einordnung im Beitrag zu NIS2 f\u00fcr Website-Betreiber im Mittelstand.<\/p>\n\n\n\n

Abnahme vor dem Go-live und Kontrolle danach: Die Relaunch-Checkliste f\u00fcr Sicherheit<\/h2>\n\n\n\n

Die Website-Relaunch Checkliste fasst die vorherigen Abschnitte in zehn Punkten zusammen. Jeder Punkt wird mit Datum und Verantwortlichem im Abnahmeprotokoll vermerkt.<\/p>\n\n\n\n

    \n
  1. PHP-Version und Patchstand dokumentieren, Support-Ende der Version notieren.<\/li>\n\n\n\n
  2. HTTPS, Zertifikat und Weiterleitung von HTTP auf HTTPS pr\u00fcfen.<\/li>\n\n\n\n
  3. Staging-Zugangsschutz entfernen oder Staging abschalten, noindex-Einstellung der Live-Seite pr\u00fcfen.<\/li>\n\n\n\n
  4. Backups testen und nicht \u00f6ffentlich ablegen.<\/li>\n\n\n\n
  5. Admin-Zug\u00e4nge, Konten und Standard-Logins pr\u00fcfen, Konten der Agentur sperren.<\/li>\n\n\n\n
  6. Geladene Dienste gegen die Datenschutzerkl\u00e4rung und das Banner abgleichen.<\/li>\n\n\n\n
  7. Formulare testen: Hinweistext, verschl\u00fcsselte \u00dcbertragung, Empf\u00e4nger.<\/li>\n\n\n\n
  8. Alte Seite, Test-Uploads und verwaiste DNS-Eintr\u00e4ge abschalten.<\/li>\n\n\n\n
  9. Au\u00dfensicht pr\u00fcfen.<\/li>\n\n\n\n
  10. Abnahme dokumentieren und einen Wiederholungstermin setzen.<\/li>\n<\/ol>\n\n\n\n

    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\u00f6\u00dferen Updates, halten den Stand aktuell.<\/p>\n\n\n\n

    Nach dem Go-live gegenpr\u00fcfen<\/p>

    Der kostenlose Check zeigt von au\u00dfen, welche Dienste die neue Website l\u00e4dt und wo Datenschutz und Technik nicht zusammenpassen.<\/p>

    Zum DSGVO Website Check<\/a><\/p><\/div>\n\n\n\n

    Fazit: Drei Dinge vor dem n\u00e4chsten Relaunch<\/h2>\n\n\n\n

    Drei Ma\u00dfnahmen bringen den gr\u00f6\u00dften Nutzen. Erstens geh\u00f6ren Sicherheit und Datenschutz ins Lastenheft und nicht erst in die Abnahme. Zweitens werden Laufzeitumgebung und Update-Zust\u00e4ndigkeit schriftlich gekl\u00e4rt, denn die PHP-L\u00fccken vom Oktober 2026 zeigen, dass Schwachstellen unterhalb des CMS entstehen. Drittens werden nach dem Go-live Au\u00dfensicht und geladene Dienste erneut gepr\u00fcft, weil sich der Stand von Technik und Datenschutzerkl\u00e4rung nach dem Start weiter \u00e4ndert.<\/p>\n\n\n\n

    Ein Relaunch ohne b\u00f6se \u00dcberraschungen ist damit vor allem eine Frage der Reihenfolge und der klaren Verantwortung. Wer Phasen, Zust\u00e4ndigkeiten und Belege festh\u00e4lt, kann den Neustart gelassen angehen.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Ein Relaunch bringt neue Technik und neue Risiken. Was vor, w\u00e4hrend und nach dem Go-live bei Sicherheit und Datenschutz zu pr\u00fcfen ist, inklusive PHP-L\u00fccken vom Oktober 2026.<\/p>\n","protected":false},"author":4,"featured_media":5792,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[7,90],"tags":[105,123,124,116,97],"class_list":["post-5795","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenschutz","category-security","tag-checkliste","tag-php","tag-relaunch","tag-staging","tag-website-sicherheit","entry"],"blocks":"\n

    Ein Relaunch bringt neue Technik, neue Plugins und neue Einbettungen, und damit neue Risiken f\u00fcr Sicherheit und Datenschutz. Vor, w\u00e4hrend und nach dem Go-live gibt es einiges zu pr\u00fcfen, und auch die PHP-L\u00fccken vom Oktober 2026 geh\u00f6ren dazu.<\/em><\/p>\n\n\n\n

    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\u00f6ren 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\u00e4ge und Zust\u00e4ndigkeiten \u00e4ndern sich gleichzeitig.<\/p>\n\n\n\n

    Eine n\u00fcchterne Pr\u00fcfliste 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\u00f6nnen sich \u00e4ndern.<\/p>\n\n\n\n

    Website-Relaunch Sicherheit: Warum der Neustart ein riskanter Moment ist<\/h2>\n\n\n\n

    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 \u00dcberg\u00e4ngen von alt zu neu: Eine Testseite bleibt \u00f6ffentlich, eine Einstellung wird nicht \u00fcbernommen, ein alter Zugang bleibt aktiv.<\/p>\n\n\n\n

    Hilfreich ist ein fester Rahmen. Sicherheit und Datenschutz geh\u00f6ren 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.<\/p>\n\n\n\n\n

    \"Schema
    Vier Phasen mit je einem Blick auf Sicherheit und Datenschutz.<\/figcaption><\/figure>\n\n\n\n\n

    Die Phasen bauen aufeinander auf. Was in der Planung nicht gekl\u00e4rt wird, fehlt sp\u00e4ter bei der Abnahme. Und was nach dem Start nicht erneut gepr\u00fcft wird, veraltet still.<\/p>\n\n\n\n

    Planung: Anforderungen, Zust\u00e4ndigkeiten und Vertr\u00e4ge kl\u00e4ren<\/h2>\n\n\n\n

    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\u00fcmmere sich.<\/p>\n\n\n\n

    F\u00fcr 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\u00fcfen, ob der Vertrag f\u00fcr den neuen Dienstleister vorliegt.<\/p>\n\n\n\n

    Sinnvoll ist au\u00dferdem 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\u00fcr Formularfelder genauso wie f\u00fcr Tracking.<\/p>\n\n\n\n

    Ein weiterer Punkt betrifft die Zug\u00e4nge. Die Agentur sollte mit eigenen, personengebundenen Konten arbeiten und nur die Rechte erhalten, die sie braucht. Gemeinsam genutzte Zugangsdaten sind ein h\u00e4ufiges Einfallstor, weil sie sp\u00e4ter niemand mehr zuordnen kann. Zum Projektende werden die Konten der Agentur gesperrt oder gel\u00f6scht. Das ist Teil des Vertrags und geh\u00f6rt in die Planung.<\/p>\n\n\n\n

    Die Laufzeitumgebung: PHP-Version, Hosting und das Beispiel vom 21.10.2026<\/h2>\n\n\n\n

    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\u00fcber aus, ob PHP auf dem Server gepatcht ist.<\/p>\n\n\n\n\n

    \"Schichten
    Ein CMS-Update erreicht nur eine von mehreren Schichten, PHP und Server brauchen eigene Updates.<\/figcaption><\/figure>\n\n\n\n\n

    Das aktuelle Beispiel zeigt, warum diese Pr\u00fcfung zum Relaunch geh\u00f6rt. Am 21.10.2026 ver\u00f6ffentlichte das PHP-Team Sicherheitsupdates f\u00fcr zwei Schwachstellen, die als CVE-2026-109618<\/a> und CVE-2026-109619<\/a> gef\u00fchrt werden. Eine CVE-Nummer ist eine eindeutige Kennung f\u00fcr eine bekannte Schwachstelle. Beide Eintr\u00e4ge sind nach CVSS 4.0, einer Skala von 0 bis 10 f\u00fcr den Schweregrad, mit 9,2 als kritisch bewertet. Es geht um die Ausf\u00fchrung fremden Programmcodes aus der Ferne (Remote Code Execution, RCE) ohne Anmeldung. Laut Advisory ist die Angriffskomplexit\u00e4t hoch, und es m\u00fcssen bestimmte Voraussetzungen erf\u00fcllt sein.<\/p>\n\n\n\n

    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\u00e4tigt diese Fixversionen in seiner Sicherheitsmeldung vom 21.10.2026<\/a> und nennt zus\u00e4tzlich Backports f\u00fcr 7.4, 8.0 und 8.1. Das Bundesamt f\u00fcr Sicherheit in der Informationstechnik (BSI) spricht in seinem Sicherheitshinweis vom 21.10.2026<\/a> von allen PHP-Versionen bis mindestens PHP 5 und stuft die Lage mit Kritikalit\u00e4t 3 (Orange) ein.<\/p>\n\n\n\n

    Wichtig ist die Trennung von Belegtem und Unbelegtem. Laut BSI gibt es keine best\u00e4tigten Angriffe, aber unbest\u00e4tigte Berichte, und eine breite Ausnutzung nach der Ver\u00f6ffentlichung des Patches wird als wahrscheinlich eingesch\u00e4tzt. Eine belastbare Zahl verwundbarer Websites nennt weder das PHP-Team noch das BSI. Klar ist nur: PHP l\u00e4uft auf einem sehr gro\u00dfen Teil aller Websites (siehe Sicherheitsl\u00fccke PHP2Shell).<\/p>\n\n\n\n

    F\u00fcr den Relaunch ergibt sich daraus eine Lehre ohne Panik. Die PHP-Version samt Patchstand wird dokumentiert, die Zust\u00e4ndigkeit f\u00fcr Updates der Laufzeitumgebung wird festgelegt, und es wird eine Reaktionszeit vereinbart. Dazu z\u00e4hlt auch das Support-Ende: PHP 8.2 erh\u00e4lt laut php.net bis zum 31.12.2026 Sicherheitsupdates. Ein Neuaufbau auf diesem Zweig ist damit schon bei der Planung ein Ablaufdatum.<\/p>\n\n\n\n[faq]Reicht es beim Relaunch, das neue CMS und die Plugins zu aktualisieren, damit die Website sicher ist?|=|Nein. CMS und Plugins laufen auf einer Laufzeitumgebung wie PHP, die eigene Sicherheitsupdates braucht. Die beiden kritischen PHP-L\u00fccken vom 21.10.2026 (CVE-2026-109618 und CVE-2026-109619) liegen in der Laufzeitumgebung selbst und sind laut PHP-Team nur mit einem Update auf eine gepatchte Version vollst\u00e4ndig behoben. Beim Relaunch geh\u00f6ren PHP-Version, Hosting-Updates und Zust\u00e4ndigkeiten deshalb ebenso zur Abnahme wie das CMS.[\/faq]\n\n\n\n

    Ein externer Test von au\u00dfen kann PHP-Version und Serverkonfiguration nur begrenzt beurteilen. Die Security-Checks von wwwschutz.de<\/a> liefern eine technische Au\u00dfensicht, ersetzen aber nicht den Blick des Hosters auf den Server selbst.<\/p>\n\n\n\n

    Staging-Umgebung im Relaunch: Zugangsschutz, keine Echtdaten, danach abschalten<\/h2>\n\n\n\n

    Staging bezeichnet eine Testumgebung, in der die neue Website vor dem Start aufgebaut und gepr\u00fcft wird. Sie ist oft unter einer Subdomain erreichbar und enth\u00e4lt unfertige Inhalte, Testkonten und mitunter Kopien echter Daten. F\u00fcr diese Umgebung gilt eine feste Reihenfolge beim Schutz: Zuerst ein Zugangsschutz per Passwort (HTTP-Authentifizierung) oder IP-Beschr\u00e4nkung, dann die Anweisung \u201enoindex\u201c gegen die Aufnahme in Suchmaschinen. Eine robots.txt allein reicht nicht, denn laut Google Search Central<\/a> dient sie der Steuerung des Crawlings und h\u00e4lt Seiten nicht zuverl\u00e4ssig aus der Suche.<\/p>\n\n\n\n

    Echtdaten geh\u00f6ren nicht auf Staging. Eine Kopie der Produktivdatenbank mit Kundendaten, Anfragen oder Newsletter-Adressen verlagert personenbezogene Daten in eine schw\u00e4cher gesch\u00fctzte Umgebung. Besser sind Testdaten oder eine bereinigte Kopie.<\/p>\n\n\n\n

    Aus der Praxis ist ein h\u00e4ufiger Fehler bekannt: Die noindex-Einstellung der Testumgebung wird mit auf die Live-Seite \u00fcbernommen, und die neue Website verschwindet aus den Suchergebnissen. Das ist eine Erfahrung aus Relaunch-Projekten und keine Norm, sie l\u00e4sst sich aber leicht pr\u00fcfen. Nach dem Go-live wird die Staging-Umgebung abgeschaltet, einschlie\u00dflich des DNS-Eintrags. Wie vergessene Testumgebungen zu einem Risiko werden, beschreibt der Beitrag zu vergessenen Subdomains und Staging-Altlasten.<\/p>\n\n\n\n

    Datenschutz im neuen Auftritt: Einwilligung, Drittdienste und Datenschutzerkl\u00e4rung<\/h2>\n\n\n\n

    Neue Plugins, Schriften, Karten, Videos und Statistik-Tools ver\u00e4ndern, welche Daten die Seite an Dritte sendet. Die Datenschutzerkl\u00e4rung beschreibt dagegen den Zustand der alten Seite. Nach dem Neustart sollte sie deshalb mit den tats\u00e4chlich geladenen Diensten abgeglichen werden. Die Pflicht zur Information \u00fcber die Datenverarbeitung ergibt sich aus Artikel 13 DSGVO. Fehlt ein Dienst in der Erkl\u00e4rung oder steht ein l\u00e4ngst entfernter Dienst noch darin, stimmen Text und Technik nicht \u00fcberein. Die Datenschutzerkl\u00e4rung nach dem Relaunch zu aktualisieren geh\u00f6rt zu jeder Abnahme.<\/p>\n\n\n\n

    Zur Einwilligung: Werden Informationen auf dem Endger\u00e4t gespeichert oder ausgelesen, ist nach \u00a7 25 TDDDG<\/a> grunds\u00e4tzlich eine Einwilligung n\u00f6tig, sofern keine Ausnahme greift. Beim Wechsel von Theme oder Consent-Tool gehen Einstellungen des alten Cookie-Banners erfahrungsgem\u00e4\u00df leicht verloren, oder das Banner blockiert die neuen Dienste nicht mehr. Das ist Praxiswissen und kein Beleg f\u00fcr eine bestimmte Software. Gepr\u00fcft wird daher im Browser: Was wird vor der Entscheidung geladen, und was passiert nach einer Ablehnung?<\/p>\n\n\n\n

    Auch das Impressum wandert mit. Die Pflichtangaben nach \u00a7 5 DDG<\/a> sind zu \u00fcbernehmen und auf Aktualit\u00e4t zu pr\u00fcfen, etwa bei ge\u00e4nderter Anschrift oder Rechtsform.<\/p>\n\n\n\n

    Formulare, Konten und Daten: Was bei der Migration mitwandert<\/h2>\n\n\n\n

    Bei der Migration stellt sich die Frage, welche Daten \u00fcberhaupt in das neue System geh\u00f6ren. Alte Formularanfragen, Newsletter-Listen, Benutzerkonten, Kommentare und Protokolldateien enthalten h\u00e4ufig personenbezogen<\/strong>e Daten. Was nicht mehr gebraucht wird oder dessen Aufbewahrungsfrist abgelaufen ist, wird nicht migriert, sondern gel\u00f6scht. Das folgt dem Grundsatz der Datenminimierung und spart zugleich Angriffsfl\u00e4che<\/a>.<\/p>\n\n\n\n

    Werden Benutzerkonten \u00fcbernommen, ist das Passwort-Verfahren zu pr\u00fcfen. Passw\u00f6rter d\u00fcrfen nur als Hash gespeichert sein, und das neue System muss das alte Hash-Verfahren lesen oder die Nutzer zum Zur\u00fccksetzen auffordern. Zugriffsrechte werden neu vergeben, nicht einfach kopiert. Standardkonten wie \u201eadmin\u201c und Test-Logins der Entwicklung werden entfernt.<\/p>\n\n\n\n

    Sicherungen und Exporte geh\u00f6ren nicht in \u00f6ffentlich erreichbare Verzeichnisse. Ein Datenbank-Dump im Webroot ist ein klassischer Fund bei Angriffen von au\u00dfen. Die Pflicht, ein dem Risiko angemessenes Schutzniveau zu gew\u00e4hrleisten, regelt Artikel 32 DSGVO. F\u00fcr den Relaunch hei\u00dft das praktisch: Zugriff nur nach Bedarf, Verschl\u00fcsselung bei der \u00dcbertragung, getestete Backups.<\/p>\n\n\n\n

    Alte Seite, Weiterleitungen und Altlasten: Was nach dem Umzug stehen bleibt<\/h2>\n\n\n\n

    \u00c4ndern sich Adressen, werden alte URLs per 301-Weiterleitung (dauerhafte Umleitung) auf die neuen Seiten gef\u00fchrt. Das ist vor allem f\u00fcr 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\u00fcr Phishing missbrauchen l\u00e4sst. Das ist Fachwissen aus der Webentwicklung und sollte in der Abnahme getestet werden.<\/p>\n\n\n\n

    Zu den Altlasten z\u00e4hlen alte Domains und Subdomains, ausgemusterte Test-Uploads, Entwickler-Dateien wie phpinfo-Seiten und Backups. Nach einem Hosterwechsel bleiben au\u00dferdem DNS-Eintr\u00e4ge bestehen, die auf nicht mehr genutzte Server zeigen. Solche verwaisten Eintr\u00e4ge k\u00f6nnen Dritte unter Umst\u00e4nden \u00fcbernehmen. Auch dazu gibt der Beitrag zu vergessenen Subdomains einen \u00dcberblick.<\/p>\n\n\n\n

    Zuletzt sind alte Zugangsdaten zu sperren: Zug\u00e4nge des Altsystems, FTP-Konten, Datenbanknutzer und Schl\u00fcssel der fr\u00fcheren 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\u00e4chste Glied.<\/p>\n\n\n\n

    Wer pr\u00fcft was: Verantwortung zwischen Auftraggeber, Agentur und Hoster<\/h2>\n\n\n\n

    Viele Probleme entstehen nicht aus Unwissen, sondern aus unklarer Zust\u00e4ndigkeit. Die folgende Tabelle ordnet die Pr\u00fcfpunkte den Beteiligten zu. Es handelt sich um eine redaktionelle Einsch\u00e4tzung und keine Norm. Vertr\u00e4ge k\u00f6nnen die Aufteilung \u00e4ndern.<\/p>\n\n\n\n

    Ein Relaunch ist der seltene Moment, in dem alles auf einmal ver\u00e4ndert werden darf. Genau deshalb sollte auch alles auf einmal gepr\u00fcft werden.<\/p><\/blockquote><\/figure>\n\n\n\n

    Pr\u00fcfpunkt<\/th>Phase<\/th>Auftraggeber<\/th>Agentur<\/th>Hoster<\/th><\/tr><\/thead>
    PHP-Version und Updates<\/td>Planung, danach<\/td>Verantwortet, l\u00e4sst dokumentieren<\/td>Pr\u00fcft Kompatibilit\u00e4t<\/td>Stellt Version bereit, patcht Server<\/td><\/tr>
    Zugangsschutz Staging<\/td>Staging<\/td>Nimmt ab<\/td>Richtet ein<\/td>Unterst\u00fctzt<\/td><\/tr>
    Vertr\u00e4ge zur Auftragsverarbeitung<\/td>Planung<\/td>Schlie\u00dft ab<\/td>Liefert eigene Unterlagen<\/td>Liefert eigene Unterlagen<\/td><\/tr>
    Datenschutzerkl\u00e4rung und Banner<\/td>Go-live<\/td>Verantwortet<\/td>Meldet geladene Dienste<\/td>Nicht beteiligt<\/td><\/tr>
    Backup und Wiederherstellung<\/td>Go-live, danach<\/td>L\u00e4sst Test nachweisen<\/td>Pr\u00fcft Seitenstand<\/td>Sichert Server, stellt wieder her<\/td><\/tr>
    Weiterleitungen, Abschaltung Altsystem<\/td>Go-live, danach<\/td>Gibt frei<\/td>Setzt um<\/td>Schaltet DNS und Server ab<\/td><\/tr>
    Abnahmeprotokoll<\/td>Go-live<\/td>Unterschreibt, archiviert<\/td>Erstellt<\/td>Liefert Nachweise<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Wichtig ist das Abnahmeprotokoll. Es h\u00e4lt fest, wer was gepr\u00fcft hat und mit welchem Ergebnis. Bei Streit um Zust\u00e4ndigkeiten oder bei einem Vorfall liefert es den Nachweis. Betreiber, die nach der NIS2-Richtlinie in den Anwendungsbereich fallen k\u00f6nnten, finden eine Einordnung im Beitrag zu NIS2 f\u00fcr Website-Betreiber im Mittelstand.<\/p>\n\n\n\n

    Abnahme vor dem Go-live und Kontrolle danach: Die Relaunch-Checkliste f\u00fcr Sicherheit<\/h2>\n\n\n\n

    Die Website-Relaunch Checkliste fasst die vorherigen Abschnitte in zehn Punkten zusammen. Jeder Punkt wird mit Datum und Verantwortlichem im Abnahmeprotokoll vermerkt.<\/p>\n\n\n\n

      \n
    1. PHP-Version und Patchstand dokumentieren, Support-Ende der Version notieren.<\/li>\n\n\n\n
    2. HTTPS, Zertifikat und Weiterleitung von HTTP auf HTTPS pr\u00fcfen.<\/li>\n\n\n\n
    3. Staging-Zugangsschutz entfernen oder Staging abschalten, noindex-Einstellung der Live-Seite pr\u00fcfen.<\/li>\n\n\n\n
    4. Backups testen und nicht \u00f6ffentlich ablegen.<\/li>\n\n\n\n
    5. Admin-Zug\u00e4nge, Konten und Standard-Logins pr\u00fcfen, Konten der Agentur sperren.<\/li>\n\n\n\n
    6. Geladene Dienste gegen die Datenschutzerkl\u00e4rung und das Banner abgleichen.<\/li>\n\n\n\n
    7. Formulare testen: Hinweistext, verschl\u00fcsselte \u00dcbertragung, Empf\u00e4nger.<\/li>\n\n\n\n
    8. Alte Seite, Test-Uploads und verwaiste DNS-Eintr\u00e4ge abschalten.<\/li>\n\n\n\n
    9. Au\u00dfensicht pr\u00fcfen.<\/li>\n\n\n\n
    10. Abnahme dokumentieren und einen Wiederholungstermin setzen.<\/li>\n<\/ol>\n\n\n\n

      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\u00f6\u00dferen Updates, halten den Stand aktuell.<\/p>\n\n\n\n

      Nach dem Go-live gegenpr\u00fcfen<\/p>

      Der kostenlose Check zeigt von au\u00dfen, welche Dienste die neue Website l\u00e4dt und wo Datenschutz und Technik nicht zusammenpassen.<\/p>

      Zum DSGVO Website Check<\/a><\/p><\/div>\n\n\n\n

      Fazit: Drei Dinge vor dem n\u00e4chsten Relaunch<\/h2>\n\n\n\n

      Drei Ma\u00dfnahmen bringen den gr\u00f6\u00dften Nutzen. Erstens geh\u00f6ren Sicherheit und Datenschutz ins Lastenheft und nicht erst in die Abnahme. Zweitens werden Laufzeitumgebung und Update-Zust\u00e4ndigkeit schriftlich gekl\u00e4rt, denn die PHP-L\u00fccken vom Oktober 2026 zeigen, dass Schwachstellen unterhalb des CMS entstehen. Drittens werden nach dem Go-live Au\u00dfensicht und geladene Dienste erneut gepr\u00fcft, weil sich der Stand von Technik und Datenschutzerkl\u00e4rung nach dem Start weiter \u00e4ndert.<\/p>\n\n\n\n

      Ein Relaunch ohne b\u00f6se \u00dcberraschungen ist damit vor allem eine Frage der Reihenfolge und der klaren Verantwortung. Wer Phasen, Zust\u00e4ndigkeiten und Belege festh\u00e4lt, kann den Neustart gelassen angehen.<\/p>\n","_links":{"self":[{"href":"https:\/\/wwwschutz.de\/blog\/wp-json\/wp\/v2\/posts\/5795","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wwwschutz.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wwwschutz.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wwwschutz.de\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/wwwschutz.de\/blog\/wp-json\/wp\/v2\/comments?post=5795"}],"version-history":[{"count":1,"href":"https:\/\/wwwschutz.de\/blog\/wp-json\/wp\/v2\/posts\/5795\/revisions"}],"predecessor-version":[{"id":5802,"href":"https:\/\/wwwschutz.de\/blog\/wp-json\/wp\/v2\/posts\/5795\/revisions\/5802"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/wwwschutz.de\/blog\/wp-json\/wp\/v2\/media\/5792"}],"wp:attachment":[{"href":"https:\/\/wwwschutz.de\/blog\/wp-json\/wp\/v2\/media?parent=5795"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wwwschutz.de\/blog\/wp-json\/wp\/v2\/categories?post=5795"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wwwschutz.de\/blog\/wp-json\/wp\/v2\/tags?post=5795"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}