Ein WordPress-Umzug überträgt eine funktionierende Website in eine neue Umgebung. Dazu gehören Dateien, Datenbank, Adressen und betriebliche Abhängigkeiten. Die Domain kann dabei gleich bleiben oder wechseln. Ein guter Ablauf sorgt dafür, dass der neue Stand vor der Umschaltung geprüft wird, zwischenzeitliche Änderungen nicht verloren gehen und ein brauchbarer Rückweg vorhanden ist. Dieser Leitfaden beschreibt eine kontrollierte Migration mit verständlichen Entscheidungen. Für Shops, Mitgliederplattformen und stark veränderliche Websites sind zusätzliche Abstimmungen nötig, weil ihre Daten während des Umzugs weiter wachsen.
Den tatsächlichen Umfang erfassen
Erstelle zunächst eine Bestandsliste. Notiere die öffentliche Hauptadresse, das WordPress-Verzeichnis, die zugehörige Datenbank, aktive Themes und Plugins sowie verwendete PHP-Versionen. Erfasse zusätzlich geplante Aufgaben, externe Dienste und besondere Serverregeln. Wenn mehrere Domains im alten Hostingkonto liegen, muss eindeutig sein, welche Dateien und Daten zur umzuziehenden Website gehören. Eine Verzeichnisbezeichnung allein ist dafür nicht immer ausreichend. Prüfe Zuordnung und tatsächliche Funktion anhand des bestehenden Systems.
Diese Freigabepunkte geben dem Umzug seine Reihenfolge. Die Zielprüfung erfolgt vor der Umschaltung; für die letzte Datenübernahme wird ein eindeutiger Schlussstand vereinbart.
Die Tabelle lässt sich seitlich verschieben.
| Phase | Konkrete Aktion | Erst weiter, wenn … |
|---|---|---|
| Ausgangsstand | Dateien und Datenbank als zusammengehörigen Sicherungssatz erfassen. | Zeitpunkt, Umfang und Zugriff auf die Sicherung nachvollziehbar sind. |
| Zielprüfung | Die geschützte Kopie anhand der wichtigen Seiten und Funktionen testen. | Die vereinbarten Testfälle bestehen oder Abweichungen ausdrücklich geklärt sind. |
| Letzte Datenübernahme | Redaktionspause oder den benötigten Umgang mit laufenden Schreibzugriffen festlegen. | Neue Inhalte, Bestellungen und Benutzer einem eindeutigen maßgeblichen Stand zugeordnet sind. |
| Web-DNS umschalten | Nur die vorgesehenen Webeinträge ändern und alte Werte dokumentieren. | Zieladresse und Rückweg feststehen; vorhandener Mailbetrieb berücksichtigt ist. |
| Öffentlich nachprüfen | Lokale Testzuordnungen entfernen und die normale öffentliche Adresse prüfen. | Hauptadresse, HTTPS, wichtige Funktionen und Hintergrundaufgaben korrekt arbeiten. |
- Bestand erfassen
- Ausgangsstand sichern
- Zielkopie herstellen
- Funktionen prüfen
- Daten abschließen
- DNS umschalten
Unterscheide Webhosting, Domainverwaltung und E-Mail. Die Website kann auf einen anderen Server ziehen, während Registrierung und Mailbetrieb unverändert bleiben. Ein Nameserverwechsel ist dafür nicht automatisch nötig. Notiere bestehende DNS-Einträge und die Verantwortlichen für sie. Wenn das Projekt keine Mailmigration umfasst, werden die entsprechenden Einträge und Postfächer als getrennte bestehende Dienste behandelt. Diese Abgrenzung schützt vor einem Umzug, der nebenbei funktionierende Kommunikation unterbricht.
Erfasse außerdem geschäftliche Funktionen. Werden Bestellungen, Kommentare oder neue Benutzer gespeichert? Gibt es ein Buchungssystem? Ruft eine Schnittstelle Daten von außen ab? Solche Vorgänge entscheiden darüber, wie die letzte Synchronisierung vorbereitet wird. Bei einer reinen Informationswebsite kann eine kurze Redaktionspause genügen. Bei einem Shop braucht es eine genaue Abstimmung der Schreibzugriffe und der Abschlussprüfung.
Zielumgebung prüfen und getrennt anlegen
Kontrolliere, ob Domain oder Abonnement auf dem neuen Server schon vorhanden sind. Eine bestehende Installation darf nicht ohne Bestandsprüfung überschrieben werden. Lege für die Migration eine eindeutig zugeordnete Umgebung mit eigenem Verzeichnis und eigener Datenbank an. Prüfe Speicherbedarf einschließlich Testkopie und Sicherungen. Die Zielumgebung benötigt passende PHP- und Datenbankversionen sowie die Erweiterungen, die deine Anwendung tatsächlich verwendet.
Vergleiche nicht nur die Versionsnummern. Zeitlimits, Uploadgrenzen, PHP-Speicher und verfügbare Ausführungswege können sich unterscheiden. Ein großes Archiv lässt sich vielleicht nicht über eine gewöhnliche Browseroberfläche übertragen. Dann brauchst du einen passenden sicheren Datei- oder administrativen Übertragungsweg. Dokumentiere diese Entscheidungen vor dem Wartungsfenster. Während einer geplanten Umschaltung sollte niemand erst herausfinden müssen, wie ein Datenbankexport importiert werden kann.
Nutze die Hostingoberfläche zur Kontrolle der tatsächlichen Funktionen. Eine vorhandene Plesk-Oberfläche kann Dateiverwaltung, Datenbankverwaltung und WordPress-Werkzeuge bereitstellen; der genaue Umfang hängt vom Konto ab. Der Plesk-Ratgeber erklärt diese Verwaltungsbereiche. Allgemeine Produktbeschreibungen dienen zur Orientierung, ersetzen aber die konkrete Prüfung am Ziel nicht.
Umzugsweg passend zur Website auswählen
Es gibt unterschiedliche Wege: eine manuelle Übertragung, eine dafür geeignete Erweiterung oder einen vereinbarten Migrationsservice. Entscheidend ist, dass der Weg Dateien und Datenbank vollständig behandelt und mit der Größe des Projekts zurechtkommt. Ein Plugin kann viele Schritte vereinfachen, besitzt aber eigene Voraussetzungen und Grenzen. Prüfe benötigte Rechte, Archivgrößen und den Umgang mit Adressänderungen. Bewahre den alten Stand unabhängig vom verwendeten Werkzeug auf.
Eine manuelle Migration bietet Einblick in die einzelnen Bestandteile. Sie verlangt allerdings, dass die zuständige Person Datenbankexport, Import und Konfiguration sicher beherrscht. Ein Anbieterumzug kann diese Arbeit übernehmen, benötigt aber eine klare Leistungsbeschreibung. Frage nach den übertragenen Bestandteilen, dem Testzugang, der geplanten Umschaltung und der Nachkontrolle. Ein allgemein beworbener Umzugsservice bestätigt noch keinen bestimmten Termin und keinen vollständigen Umgang mit jeder Spezialanwendung.
Wähle einen Weg, dessen Ergebnis du nachvollziehen kannst. Die Meldung „Import erfolgreich“ ist ein Werkzeugstatus. Die echte Website muss danach trotzdem geprüft werden. Für einen komplizierten Shop kann fachkundige Begleitung wirtschaftlicher sein als ein improvisierter Ablauf mit unklaren Datenständen. Für einen kleinen Informationsauftritt reicht oft eine überschaubare Migration mit sorgfältigen Kontrollen.
Einen konsistenten Ausgangsstand sichern
Vor jeder Veränderung werden Dateien und Datenbank gesichert. Die offizielle WordPress-Dokumentation behandelt beide Bestandteile beim Serverwechsel. Zu den Dateien gehören insbesondere Uploads, Themes, Plugins und relevante Konfigurationen. Ein Export von Beiträgen allein ersetzt diese vollständige Sicherung nicht. Erfasst werden auch zusätzliche Dateien, die außerhalb des gewöhnlichen WordPress-Verzeichnisses liegen und für den Betrieb gebraucht werden.
Achte auf den zeitlichen Zusammenhang. Wenn du die Datenbank morgens exportierst und die Dateien abends kopierst, können zwischenzeitlich neue Uploads oder andere Änderungen entstehen. Bei wenig Aktivität lässt sich eine Redaktionspause vereinbaren. Bei dynamischen Projekten muss der Sicherungsprozess das Schreiben entsprechend kontrollieren. Beschrifte den Sicherungssatz mit Projekt, Datum, Zeitraum und technischem Stand. Kennwörter werden nicht in Dateinamen oder öffentlichen Protokollen gespeichert.
Dateien und Datenbank übertragen
Übertrage die gesicherten Dateien über einen sicheren geeigneten Weg. Erhalte relevante Verzeichnisstrukturen und kontrolliere, welche versteckten Konfigurationsdateien benötigt werden. Kopiere keine fremden Projekte oder unnötigen alten Archive in die neue Umgebung. Der Zielpfad soll eindeutig zur geplanten Domain gehören. Prüfe anschließend, ob der Webprozess die erforderlichen Dateien lesen und notwendige Uploads schreiben kann. Pauschal sehr offene Dateirechte sind dafür keine gute Lösung.
Importiere die Datenbank in eine neu angelegte, eindeutig zugeordnete Zieldatenbank. Prüfe nach dem Import Tabellenanzahl und erkennbare Inhalte. Wenn Name, Benutzer oder Kennwort der Datenbank neu sind, muss die WordPress-Konfiguration entsprechend angepasst werden. Diese Zugangswerte gehören in die dafür vorgesehene geschützte Konfigurationsdatei. Gib sie nicht in Screenshots, öffentlichen Projektberichten oder einem Websitepaket aus.
Kontrolliere die Dateibesitzverhältnisse und serverabhängige Einstellungen. Eine auf dem alten Host passende Regel kann auf dem neuen anders wirken. Individuelle Pfade und Aufgaben benötigen besondere Aufmerksamkeit. Aktiviere zunächst einen kontrollierten Betrieb, bei dem die Testkopie keine echten Benachrichtigungen oder Transaktionen auslöst. Erst dann beginnt die funktionale Prüfung der übertragenen Anwendung.
Gleiche Domain ohne öffentliche Umschaltung testen
Wenn die Domain gleich bleibt, musst du für den Vorabtest nicht zwangsläufig alle WordPress-Adressen ändern. Ein lokaler Auflösungsweg kann die Domain auf dem eigenen Rechner bereits dem neuen Server zuordnen, während die öffentliche DNS-Antwort noch zum alten zeigt.
Die genaue Umsetzung hängt vom Arbeitsplatz ab und sollte dokumentiert werden. Prüfe sorgfältig, welchen Server der Testbrowser tatsächlich erreicht, damit du nicht versehentlich weiterhin die alte Website abnimmst.
Dieser Testweg benötigt auch ein gültiges Zertifikat für die verwendete Adresse. Eine Browserwarnung sollte kein normaler Prüfzustand für den späteren Betrieb bleiben. Manche Hostingoberflächen bieten zusätzlich Vorschauadressen; deren Verhalten mit WordPress ist vorab zu prüfen. Wenn du eine temporäre Domain einsetzt, entstehen später Adressanpassungen. Entscheide bewusst, welcher Weg für das Projekt die wenigsten unnötigen Veränderungen verursacht.
Halte den Testzugang geschützt. Auch eine Kopie mit identischem Inhalt kann veraltete Angaben, persönliche Daten oder ungewollte externe Aktionen enthalten. Eine Suchmaschinenanweisung allein schützt den Zugriff nicht. Testpersonen erhalten einen klar benannten Zugang und einen festgelegten Prüfauftrag. Die alte Livewebsite bleibt bis zur abgestimmten Umschaltung die Quelle für tatsächliche Änderungen.
Bei Domainwechsel gespeicherte Adressen anpassen
Wechselt die Hauptadresse, müssen gespeicherte Verweise geprüft werden. Dazu zählen Websiteadresse, interne Links, Medienverweise und gegebenenfalls Einstellungen von Erweiterungen. Ein einfaches globales Ersetzen in einer SQL-Datei kann problematisch sein, weil WordPress und Plugins auch serialisierte Werte speichern können. Verwende einen geeigneten Weg, der diese Datenformen berücksichtigt. WP-CLI bietet dafür einen dokumentierten Search-Replace-Befehl mit einem Probelaufmodus.
- Adressen eindeutig zuordnen. Lege genau fest, welche alte Adresse durch welche neue ersetzt werden soll. Unterscheide HTTP, HTTPS und die Variante mit www.
- Die Änderung vorab prüfen. Ein Probelauf zeigt zunächst geplante Treffer, ohne den Datenbestand zu verändern.
- Sichern und kontrolliert ausführen. Anschließend wird eine Sicherung angelegt und die Änderung kontrolliert ausgeführt.
- Erzeugte Ressourcen kontrollieren. Prüfe auch Plugin-spezifische Caches und erzeugte Dateien. Ein scheinbar funktionierendes Frontend kann weiterhin einzelne alte Ressourcen laden.
Beim Domainwechsel brauchst du zusätzlich eine Weiterleitungsstrategie. Alte wichtige Adressen sollen auf die passende neue Seite führen. Eine pauschale Weiterleitung jeder Unterseite auf die neue Startseite hilft dem Leser häufig wenig. Prüfe besonders gut verlinkte Ratgeber, Leistungen und Medien. Der Domain- und HTTPS-Leitfaden erläutert, warum Pfad und Suchparameter im Umleitungsablauf bewusst behandelt werden müssen.
Zertifikate und Hauptadresse kontrollieren
Richte HTTPS vor dem öffentlichen Betrieb ein. Das Zertifikat muss alle angesprochenen Varianten abdecken, auch wenn eine davon anschließend weiterleitet. Bei einer Hauptadresse ohne www werden WordPress-Adressen, Canonical-Angaben und Sitemap entsprechend einheitlich gesetzt. Teste beide Schreibweisen und die unverschlüsselte Variante. Alle vorgesehenen Wege sollen nachvollziehbar an der richtigen HTTPS-Adresse enden, ohne unnötige Umleitungsketten.
Prüfe nicht nur die Startseite. Öffne eine tiefe Unterseite, eine Medienadresse und eine URL mit Suchparameter. Kontrolliere außerdem, ob eingebettete Ressourcen ebenfalls verschlüsselt geladen werden. Gemischte Inhalte können aus gespeicherten alten Adressen oder aus hart eingetragenen Themeverweisen entstehen. Bearbeite die Ursache, statt Warnungen lediglich zu verdecken. Cachebestände werden nach den Änderungen gezielt erneuert.
Dokumentiere Zertifikatserneuerung und zuständige Stelle. Ein korrekt ausgestelltes Zertifikat ist ein aktueller Zustand, die automatische Erneuerung eine weitere Betriebsaufgabe. Prüfe, ob benötigte Validierungswege im späteren Betrieb erreichbar bleiben. Wenn DNS für E-Mail unverändert bleiben soll, beschränkt sich die Webumschaltung auf die dafür vorgesehenen Einträge. Eine Domainweiterleitung rechtfertigt keine beliebige Änderung anderer Dienste.
Funktionen anhand echter Nutzungspfade prüfen
Lege einen Prüfplan mit wichtigen Seiten und Funktionen an. Dazu gehören Startseite, mehrere Inhaltsseiten, Bilder, Navigation, Suche und WordPress-Anmeldung. Prüfe eine redaktionelle Änderung in einer unkritischen Testseite und kontrolliere das Ergebnis. Teste mobile Darstellung und Tastaturbedienung. Individuelle Erweiterungen, Downloads oder geschützte Bereiche erhalten eigene Fälle. Ein Stichprobenplan ist nachvollziehbarer als die Aussage, die Website „sehe normal aus“.
Notiere Ergebnis, Datum und Testumgebung. Falls ein Fehler auftritt, ist zunächst zu klären, ob er schon vorher bestand oder durch die Migration entstanden ist. Vergleiche bei Bedarf Protokolle und Konfigurationen. Ändere während dieser Prüfung möglichst wenige voneinander unabhängige Faktoren. Ein gleichzeitiger Relaunch mit neuem Theme und mehreren Pluginwechseln erschwert die Zuordnung erheblich.
Geplante Aufgaben und externe Verbindungen nachziehen
WordPress-Aufgaben können über WP-Cron oder eine dafür eingerichtete Serveraufgabe ausgelöst werden. Prüfe, welcher Weg im Ausgangssystem verwendet wird. Eine beim alten Anbieter angelegte Aufgabe zieht nicht automatisch mit den Webdateien um.
Wenn die Website eigene Imports, Sicherungen oder Veröffentlichungen plant, kontrolliere deren Zuständigkeit und Zeitpunkt. Ein doppelt aktiver Job auf altem und neuem Host kann dieselbe externe Aktion mehrfach ausführen. Deshalb braucht die Umschaltung auch für diese Aufgaben einen eindeutigen Übergang.
Erfasse Verbindungen zu Zahlungsdiensten, Newsletterwerkzeugen oder anderen Systemen, sofern solche Funktionen vorhanden sind. Manche Dienste erwarten eine bestimmte Rückrufadresse oder erlaubte IP-Adresse. Eine neue Serverumgebung kann daher Anpassungen außerhalb von WordPress benötigen. Verändere solche Einstellungen gezielt und dokumentiere den Zeitpunkt. Nutze im Vorabtest vorgesehene Testkonten, damit keine echten Kundenbenachrichtigungen oder Datenabgleiche unbeabsichtigt ausgelöst werden. Zugangswerte bleiben in geschützter Ablage.
Kontrolliere nach dem Umzug einen tatsächlich fälligen Hintergrundvorgang. Eine sichtbare Liste geplanter Aufgaben beweist noch keine erfolgreiche Ausführung. Prüfe Protokoll, Ergebnis und gegebenenfalls Eingang beim externen Dienst. Falls eine Aufgabe ausfällt, dokumentiere die konkrete Fehlermeldung und die verwendete Umgebung. Das erleichtert dem Support die Unterscheidung zwischen fehlendem Auslöser, falschem Pfad und einem Anwendungsfehler.
Typische Abweichungen gezielt untersuchen
Zeigt die Zielwebsite eine Datenbankfehlermeldung, prüfst du zuerst Zuordnung, Zugang und Erreichbarkeit der vorgesehenen Datenbank. Eine weiße Seite oder ein Serverfehler verlangt einen Blick in passende Fehlerprotokolle und die PHP-Kompatibilität. Fehlen nur einzelne Bilder, können Uploadpfade, Berechtigungen oder gespeicherte alte Adressen die Ursache sein. Ändere nicht wahllos mehrere Einstellungen. Beschreibe das Symptom mit konkreter Adresse, Zeitpunkt und dem Unterschied zum Ausgangssystem.
Funktioniert die Startseite, aber eine Unterseite liefert einen Fehler, kontrolliere Adressstruktur und serverseitige Weiterleitungsregeln. Wenn Links weiterhin zum alten Host führen, prüfe gespeicherte URLs und erzeugte Cachedateien. Wird ein Fehler nur in einer angemeldeten Sitzung sichtbar, untersuche Benutzerzustand und Cacheverhalten getrennt. Ein einzelner erfolgreicher anonymer Seitenabruf deckt diese Unterschiede nicht ab. Halte deine Prüfungen so fest, dass eine zweite Person sie nachvollziehen kann.
Bei größeren Projekten können serverseitige Grenzen während Import oder Bildverarbeitung auffallen. Ein höheres Limit ist nur sinnvoll, wenn der Vorgang und die verfügbaren Ressourcen dazu passen. Prüfe zunächst, ob die Übertragung vollständig ist und ob das verwendete Werkzeug eine andere geeignete Methode unterstützt. Der Hosting-Leitfaden erklärt, warum Paketressourcen und einzelne Laufzeitgrenzen getrennt betrachtet werden müssen.
Abnahme und Kommunikation festlegen
Bestimme vor dem Umschalttermin, wer fachlich und wer technisch abnimmt. Die technische Person prüft Übertragung, HTTPS und Betrieb. Der Betreiber oder eine zuständige Redaktion bestätigt Inhalte, Preise, Ansprechpartner und wichtige Abläufe. Beide Perspektiven ergänzen sich. Ein Administrator kann nicht allein entscheiden, ob die Leistungsbeschreibung korrekt ist. Eine Redakteurin kann umgekehrt ein funktionierendes Zertifikat nicht aus dem Erscheinungsbild der Seite ableiten.
Nutze eine kurze Ergebnisliste mit bestandenen Prüfungen, offenen Punkten und deren Wirkung. Wenn eine unwichtige alte Grafik noch fehlt, kann das anders bewertet werden als ein defekter Bestellvorgang. Die Freigabe bezieht sich auf den geprüften Stand und ein bestimmtes Zeitfenster. Während der letzten Synchronisierung sollten Beteiligte wissen, wo Änderungen erlaubt sind. So werden keine Texte auf dem alten Host gespeichert, die beim Abschluss unbemerkt fehlen.
Die letzte Synchronisierung vorbereiten
Vereinbare ein Wartungsfenster und informiere die zuständigen Beteiligten über Ablauf und Einschränkungen. Das Fenster richtet sich nach tatsächlichem Umfang und Risiko; eine pauschale Minutenangabe wäre ohne Prüfung nicht belastbar. Erstelle unmittelbar vor den letzten Übertragungen einen aktuellen Sicherungssatz. Prüfe den Zielstand anschließend erneut anhand der wichtigsten Funktionen. Erst wenn die festgelegten Kriterien erfüllt sind, erfolgt die öffentliche Umschaltung.
Für stark dynamische Projekte kann eine fachlich geplante Synchronisierung notwendig sein. Die passende Methode hängt von der Anwendung und ihren Datenmodellen ab. Ein gewöhnliches Kopierwerkzeug ist keine automatische Lösung für konkurrierende Schreibzugriffe. Wenn das Projekt diesen Aufwand benötigt, sollte er ausdrücklich zum Migrationsauftrag gehören und mit den Verantwortlichen für die Anwendung abgestimmt werden.
DNS kontrolliert umschalten
Ändere nur die für den Webbetrieb benötigten Einträge. Prüfe vorher, ob sowohl IPv4 als auch IPv6 im Spiel sind und welche Antworten tatsächlich vorhanden sind. Ein unverändert alter IPv6-Eintrag kann dazu führen, dass ein Teil der Besucher weiterhin den alten Server erreicht. Dokumentiere den alten Wert, den neuen Wert und den Zeitpunkt der Änderung. Überprüfe anschließend die öffentliche Auflösung aus mehreren passenden Perspektiven.
DNS-Antworten werden zwischengespeichert. Eine Umschaltung erreicht daher nicht jeden Besucher im selben Augenblick. Eine vorherige Anpassung der Lebensdauer kann Teil des Plans sein, wirkt aber nicht rückwirkend auf bereits gespeicherte ältere Antworten. Halte den alten Server für einen abgestimmten Übergangszeitraum verfügbar. Prüfe, ob er noch neue Daten annimmt und wie diese gegebenenfalls behandelt werden müssen.
Nach der Umschaltung kontrollierst du die Website über die normale öffentliche Auflösung. Entferne lokale Testzuordnungen, damit der Prüfcomputer wieder denselben Weg wie gewöhnliche Besucher nutzt. Eine weiterhin aktive lokale Anpassung kann einen fehlgeschlagenen öffentlichen Wechsel verdecken. Kontrolliere Hauptadresse, HTTPS, wichtige Seiten und Protokolle erneut. Halte die Prüfung im Migrationsprotokoll fest.
Rückweg und Nachkontrolle bereithalten
Ein Rückweg braucht klare Voraussetzungen. Dokumentiere, wann zurückgeschaltet werden darf und wer entscheidet. Wenn auf dem neuen Server bereits neue Bestellungen entstanden sind, löst ein simples Zurückstellen der DNS-Antwort nicht das Datenproblem. Zuerst müssen die entstandenen Änderungen berücksichtigt werden. Ein brauchbarer Rückfallplan beschreibt deshalb sowohl die technische Adresse als auch die maßgeblichen Datenbestände und den Umgang mit zwischenzeitlichen Vorgängen.
Beobachte nach dem Wechsel Fehlermeldungen, Ressourcen und wichtige Geschäftsfunktionen. Prüfe auch Sicherungsjobs, geplante Aufgaben und Zertifikatserneuerung. Erneute Cachekontrollen helfen, veraltete Antworten zu erkennen. Der Performance-Ratgeber bietet einen Ablauf zur Einordnung langsamer Seiten. Eine Migration ist erst dann vollständig abgeschlossen, wenn der reguläre Betrieb auf dem neuen System nachweisbar funktioniert.
Bewahre den alten Sicherungsstand für eine angemessene dokumentierte Frist auf und kündige den früheren Dienst erst nach der Abnahme. Entferne danach unnötige Testzugänge und Kopien. Aktualisiere das Betriebsblatt mit Zielhost, Hauptadresse und Zuständigkeiten. Ein kontrollierter Umzug endet mit einer verständlichen Übergabe: Der Betreiber weiß, wo die Website läuft, wie sie gesichert wird und wie künftige Änderungen ohne erneutes Rätselraten durchgeführt werden.