Wem gehören Domain und Website-Zugänge? Übergabe und Anbieterwechsel verständlich erklärt

Beginne mit einer Liste statt mit Passwörtern. Notiere zu jedem Dienst den Anbieter, den geschäftlichen Zweck, die hinterlegte Vertrags- oder Inhaberrolle, die Abrechnung, verantwortliche Personen und den Wiederherstellungsweg. So wird sichtbar, ob die Website nur technisch betreut wird oder ob zentrale Konten ausschließlich auf eine fremde Person laufen.

Domain und Hosting werden oft gemeinsam verkauft, bleiben aber unterschiedliche Leistungen. Die Domain ist die Adresse. DNS-Einträge verbinden sie unter anderem mit Website und E-Mail. Das Hosting liefert die Website aus. Ein Umzug der Domain verschiebt deshalb weder automatisch die Website-Dateien noch Postfächer oder Datenbanken.

Weitere Dienste können für Formularversand, Terminbuchung, Karten, Analyse, Schriften, Bilder oder Zahlungen zuständig sein. Auch Search Console und Unternehmensprofile sind keine Bestandteile des Hostingkontos. Sie benötigen eine eigene Rollen- und Übergabeprüfung.

Bei einer .de-Domain kommt der Domainvertrag laut DENIC unmittelbar zwischen DENIC und dem Domaininhaber zustande, auch wenn ein Provider die Registrierung vermittelt. Prüfe deshalb, ob dein Unternehmen beziehungsweise bei einem Einzelunternehmen die richtige Person als Domaininhaber geführt wird und ob Kontakt- sowie Rechnungsdaten aktuell sind. Für andere Domainendungen gelten die Regeln der jeweiligen Registrierungsstelle und des Registrars.

Das Providerkonto sollte über eine erreichbare geschäftliche Adresse wiederherstellbar sein. Es muss klar sein, wer Verlängerungen bezahlt und welche weiteren Leistungen im selben Paket liegen. Wird ein Vertrag beendet, darf niemand versehentlich Domain, Postfächer und Website gemeinsam kündigen, obwohl nur das Hosting wechseln sollte.

Für den Wechsel einer .de-Domain beschreibt DENIC das AuthInfo-Verfahren: Der Domaininhaber lässt beim bisherigen Provider ein zeitlich begrenztes Providerwechsel-Passwort erzeugen und gibt es dem neuen Provider. Diese AuthInfo wird erst für einen konkreten Wechsel benötigt. Sie ist kein dauerhaftes Kennwort für eine Übergabemappe und sollte nur geschützt an die zuständige Stelle weitergegeben werden.

Wenn ein Dienst mehrere Nutzer und Rollen unterstützt, erhält jede verantwortliche Person einen eigenen Zugang. Das Unternehmen behält mindestens eine belastbare Inhaber- oder Administratorrolle; der Dienstleister bekommt die für seine Aufgabe angemessene Berechtigung. So lassen sich Zugriffe später einzeln entziehen, ohne ein gemeinsam genutztes Passwort an vielen Stellen zu ändern.

Aktiviere Zwei-Faktor-Authentisierung für Konten mit weitreichenden Rechten. Das BSI empfiehlt 2FA, sobald ein Dienst sie anbietet, und weist darauf hin, für den Verlust des zweiten Faktors vorzusorgen. Halte deshalb dokumentiert fest, wo Wiederherstellungscodes geschützt verwahrt werden und welche weitere berechtigte Person im Notfall handeln kann.

Passwörter gehören nicht in ein frei versendetes Briefing oder in eine unverschlüsselte Übergabe-PDF. Nutze Einladungen und Rollen, wenn möglich. Wo ein Kennwort tatsächlich übergeben werden muss, gehört es in einen geeigneten Passwortmanager oder einen gesonderten sicheren Übertragungsweg und sollte anschließend geändert werden.

Zur technischen Übergabe können je nach System Quellcode, Datenbankexport, hochgeladene Medien, Konfiguration, Weiterleitungen und eine Liste externer Dienste gehören. Welche Bestandteile benötigt werden, hängt von der Architektur ab. Bei einem Baukasten kann beispielsweise kein frei betreibbarer Quellcode exportierbar sein; bei einer individuellen Anwendung reicht der Quellcode ohne Infrastruktur und Daten ebenfalls nicht für einen Wiederanlauf.

Daneben stehen Nutzungsrechte. § 31 UrhG unterscheidet einfache und ausschließliche Nutzungsrechte und erlaubt räumliche, zeitliche oder inhaltliche Beschränkungen. Für dein Projekt sollte deshalb verständlich vereinbart sein, wie Design, Texte, Fotos, Schriften, Software und andere Bestandteile genutzt, verändert und durch Dritte weiterbetreut werden dürfen. Fremdlizenzen und Open-Source-Bestandteile können eigene Bedingungen behalten.

Verlange keine pauschale Zusage wie „alles gehört dir“, wenn unklar bleibt, was „alles“ meint. Besser ist eine Liste: Welche Arbeitsergebnisse werden bereitgestellt? Welche Nutzungen sind erlaubt? Welche Lizenzen laufen auf wessen Namen? Was kann bei einem Wechsel technisch übertragen werden, und welche Dienste müssen neu beauftragt werden? Bei rechtlicher Unsicherheit sollte der Vertrag fachkundig geprüft werden.

Die Übergabe sollte zu Projektgröße und Technik passen. Eine kleine statische Unternehmensseite braucht keine hundertseitige Betriebsdokumentation. Sie braucht aber eine verständliche Übersicht darüber, wo Domain und Website liegen, wie veröffentlicht wird, welche Dienste beteiligt sind und wer im Störungsfall zuständig ist.

Sicherungen sind nur dann belastbar, wenn Umfang, Zeitpunkt und Wiederherstellungsweg bekannt sind. Das BSI empfiehlt Unternehmen, Backups anzulegen und Funktion, Konsistenz sowie Aktualität regelmäßig zu testen. Vereinbare deshalb nicht bloß „Backup vorhanden“, sondern welche Daten gesichert werden, wie lange, durch wen und wie eine Wiederherstellung geprüft wird.

Dokumentiere außerdem den abgenommenen Funktionsumfang und bekannte offene Punkte. Das verhindert, dass ein späterer Betreuer zunächst erraten muss, ob eine Funktion bewusst fehlt, extern betrieben wird oder nicht mehr funktioniert. Sensible Schlüssel und Passwörter bleiben dabei außerhalb der allgemein lesbaren Dokumentation.

Ein Anbieterwechsel beginnt mit der Bestandsaufnahme: Welche Systeme liefern Website, E-Mail und andere geschäftliche Funktionen? Danach werden neue Verantwortlichkeiten und Zugänge vorbereitet, aktuelle Daten gesichert und der Migrationsweg getestet. Erst wenn Zielsystem und Rückfallplan feststehen, folgen DNS- oder Domainänderungen.

Plane für Website und E-Mail getrennte Prüfungen. Nach dem Wechsel müssen nicht nur Startseite und Logo erscheinen. Formulare, Weiterleitungen, Suchmaschinenbestätigung, Zertifikate, Postfächer und externe Schnittstellen brauchen eigene Tests. Vereinbare ein Zeitfenster, in dem der bisherige Stand noch verfügbar bleibt, soweit Vertrag und Technik das zulassen.

Nach erfolgreicher Abnahme werden nicht mehr benötigte Zugriffe entfernt. In der Google Search Console genügt es bei früheren bestätigten Inhabern nicht in jedem Fall, nur den Nutzer zu löschen: Google weist darauf hin, dass verbleibende Bestätigungstokens eine erneute Bestätigung ermöglichen können. Prüfe deshalb bei jedem Dienst dessen eigenes Rollen- und Wiederherstellungsmodell, bevor alte Konten geschlossen werden.

Du musst für ein Erstgespräch keine Zugangsdaten verschicken. Bringe die Webadresse, vorhandene Verträge und Rechnungen sowie eine Liste bekannter Anbieter mit. Wenn du nicht weißt, wer als Domaininhaber geführt wird oder wo die Website gehostet ist, ist genau das ein sinnvoller Ausgangspunkt für die Bestandsaufnahme.

Bitte den Anbieter, die Zielstruktur verständlich zu beschreiben: Welche Konten werden auf dein Unternehmen angelegt? Welche Rollen erhält der Dienstleister? Welche Daten und Dokumente werden nach Projektabschluss bereitgestellt? Was bleibt eine laufende Leistung? Und was passiert technisch sowie finanziell, wenn die Betreuung endet?

Bei Deichklar kann ein Website-Kurzcheck helfen, erkennbare Abhängigkeiten und den nächsten Prüfschritt einzuordnen. Eine solche Ersteinschätzung ersetzt weder eine vollständige technische Migration noch eine individuelle Rechtsprüfung. Sie soll sichtbar machen, welche Informationen vor einer belastbaren Entscheidung noch fehlen.