Agenturwechsel ohne Kontrollverlust: Wem gehört Ihre Website wirklich?

Die Website läuft, Rechnungen werden bezahlt und die Agentur reagiert auf Änderungen. Das wirkt wie Kontrolle – bis die Zusammenarbeit endet.

Dann zeigt sich plötzlich, dass der Domain-Registrar nur einem ehemaligen Freelancer bekannt ist, DNS in einem privaten Account liegt, das Hosting auf die Kreditkarte der Agentur läuft oder der Quellcode in einem Repository steckt, das niemand im Unternehmen administrieren kann. Google Search Console enthält noch alte bestätigte Inhaber und der Consent-Manager wurde über ein fremdes Konto lizenziert.

Die Website ist weiterhin online. Trotzdem ist das Unternehmen operativ abhängig.

Ein guter Website-Handover besteht deshalb nicht aus einer ZIP-Datei und einer Passwortliste. Er beantwortet eine wichtigere Frage: Kann das Unternehmen die Website weiter betreiben, bezahlen, absichern, wiederherstellen und an einen neuen Dienstleister übergeben, ohne die bisherige Agentur zu benötigen?

1. Besitz ist mehr als ein CMS-Login

Moderne Websites verteilen Kontrolle auf viele Systeme: Domain-Registrar, DNS, Hosting oder Cloud, CDN, Quellcode, CI/CD, CMS, Datenbank, Backups, E-Mail-Versand, Analytics, Tag Manager, Consent-Plattform, Search Console, Monitoring und Drittanbieter-APIs.

Ein Unternehmen kann im CMS Administrator sein und trotzdem keine echte technische Handlungsfähigkeit besitzen. Wenn nur die Agentur DNS ändern, ein Deployment auslösen oder die Domain verlängern kann, bleibt ein Single Point of Failure bestehen.

Das Ziel eines Handovers ist deshalb keine maximale Anzahl von Admin-Rechten. Das Ziel ist eine klare Ownership Map: Welches System ist kritisch, welchem Unternehmen gehört der Account organisatorisch, wer darf ihn nutzen und wie wird der Zugang wiederhergestellt?

2. Domain und Registrar zuerst prüfen

ICANN verweist Domaininhaber für operative Verwaltung wie Verlängerung, Kontaktdaten und Nameserver an den jeweiligen Registrar. Genau deshalb sollte der Registrar niemals ein unbekannter Teil der Infrastruktur sein.

Für jede geschäftskritische Domain sollten Sie beantworten können:

• Bei welchem Registrar ist sie registriert?
• Welches unternehmenskontrollierte Konto hat Zugriff?
• Welche Adresse dient zur Account-Wiederherstellung?
• Wer erhält Ablauf- und Verlängerungshinweise?
• Ist die Zahlungsart gültig?
• Ist MFA aktiviert, sofern verfügbar?
• Wer darf Transfers oder Nameserver-Änderungen auslösen?

Ein Warnsignal ist eine Domain, die ausschließlich im privaten Account einer einzelnen Person liegt. Das kann jahrelang problemlos funktionieren – bis diese Person nicht mehr erreichbar ist. Die Domain sollte organisatorisch am Unternehmen hängen, nicht an der aktuellen Dienstleisterbeziehung.

3. DNS vollständig inventarisieren

DNS bestimmt nicht nur, wohin www.example.de zeigt. In der Zone liegen häufig auch Einträge für E-Mail, SPF, DKIM, DMARC, Domain-Verifikationen, API-Subdomains, CDN-Ziele und Search-Console-Verifikation.

Wer beim Agenturwechsel eine DNS-Zone neu aufsetzt, ohne die bestehenden Records zu verstehen, kann deshalb neben der Website auch E-Mail oder andere Dienste beschädigen.

Vor der Übergabe sollte ein Export oder dokumentierter Snapshot der Zone existieren. Zu jedem wichtigen Record gehört idealerweise nicht nur sein Wert, sondern auch die Antwort auf die Frage: Welcher Dienst benötigt diesen Eintrag?

4. Hosting-Zugang ist nicht automatisch Deployment-Fähigkeit

Viele Websites werden nicht mehr per FTP auf einen einzelnen Server kopiert. Releases können von GitHub Actions, GitLab CI, Vercel, Netlify, Container-Registries oder eigenen Pipelines abhängen.

Darum sollten zwei Fähigkeiten getrennt geprüft werden:

Betrieb: Kann das Unternehmen Hosting, Abrechnung, Logs, Domains und Konfiguration verwalten?

Release: Kann ein neuer technischer Ansprechpartner aus dem Quellcode reproduzierbar eine neue Version bauen und ausrollen?

Ein guter Dry Run ist erstaunlich simpel: Eine fachkundige Person erhält die Handover-Dokumentation, ändert einen ungefährlichen Text in einer Testumgebung und folgt dem vorgesehenen Release-Prozess. Wenn dafür zwingend der Laptop des bisherigen Entwicklers benötigt wird, fehlt Betriebswissen.

5. Quellcode und Repository gehören in die Besitzprüfung

Der Produktionsserver sollte nicht die letzte existierende Kopie des Projekts sein. Zur Übergabe gehören das vollständige Repository, relevante Historie und Branches, Build-Konfiguration, Deployment-Konfiguration, dokumentierte Abhängigkeiten und gegebenenfalls Infrastructure-as-Code.

GitHub dokumentiert abgestufte Repository-Rollen, damit Menschen nur die Rechte erhalten, die zu ihrer Aufgabe passen. Für Organisationen empfiehlt GitHub außerdem mehr als einen Owner, damit Projekte nicht unzugänglich werden, wenn die einzige besitzende Person ausfällt.

Das ergibt ein sinnvolles Prinzip für Website-Betrieb: Kritische technische Assets sollten nicht an einem einzigen persönlichen Account hängen. Gleichzeitig braucht nicht jeder Admin-Rechte.

Prüfen Sie außerdem Deploy Keys, Service Accounts, Apps und externe Collaborators. Ein entfernter Agenturmitarbeiter ist nicht automatisch aus allen technischen Zugriffspfaden verschwunden.

6. CMS-Konten statt geteilter Admin-Passwörter

WordPress definiert offiziell Rollen und Capabilities vom Subscriber bis zum Administrator beziehungsweise Super Admin. Ein professioneller Betrieb nutzt diese Trennung statt eines seit Jahren gemeinsam verwendeten admin-Logins.

Benannte Konten machen sichtbar, wer noch Zugriff hat und welche Rechte tatsächlich benötigt werden. Nach einem Agenturwechsel lassen sich alte Accounts gezielt entfernen, ohne interne Nutzer auszusperren.

Zusätzlich sollten Lizenzen geprüft werden. Premium-Plugins, Themes oder Page Builder können technisch funktionieren, aber an ein Agenturkonto gekoppelt sein. "Die Lizenz ist heute aktiv" ist nicht dasselbe wie "das Unternehmen kann sie nächstes Jahr selbst verlängern".

7. Search Console: Nutzer entfernen reicht nicht immer

Google Search Console unterscheidet bestätigte und delegierte Inhaber. Bestätigte Inhaber weisen ihre Kontrolle über technische Tokens nach, zum Beispiel DNS-Records, HTML-Dateien oder Tags.

Für einen Handover ist ein Detail besonders wichtig: Google dokumentiert, dass ein entfernter bestätigter Inhaber sich erneut bestätigen kann, solange sein altes Verifikationstoken weiterhin vorhanden ist.

Prüfen Sie deshalb nicht nur die sichtbare Nutzerliste, sondern auch:

• Welche bestätigten Inhaber existieren?
• Welche Verifikationsmethode nutzt jeder davon?
• Welche nicht mehr benötigten Tokens liegen noch in DNS, HTML oder Konfiguration?
• Gibt es mindestens einen bestätigten Inhaber unter direkter Kontrolle des Unternehmens?

Das ist eine nützliche allgemeine Lektion: Zugriff entfernen und einen Besitznachweis widerrufen sind nicht immer dieselbe Aktion.

8. Analytics, Consent und Drittanbieter nicht vergessen

Nach dem Hosting fallen oft die Systeme auf, die im Tagesgeschäft unsichtbar waren: Analytics-Property, Tag-Manager-Container, Consent-Management, Werbepixel, Karten, Chat, Bewertungswidgets, E-Mail-Versand oder externe APIs.

Für jeden Dienst sollten vier Dinge dokumentiert sein: Eigentümer, Abrechnung, Zweck und technische Einbindung. Das reduziert Lock-in und erleichtert spätere Datenschutz-, Tracking- und Wartungsprüfungen, weil nachvollziehbar ist, welcher Dienst überhaupt warum auf der Website existiert.

9. Secrets sicher übergeben – nicht per Passwortdokument

Ein Handover braucht Zugriff, aber keine ungeschützte Sammlung sämtlicher Passwörter. Sinnvoller ist es, kritische Konten auf unternehmenskontrollierte Adressen zu übertragen, persönliche Agenturkonten durch benannte Zugänge zu ersetzen und Secrets über geeignete Passwort- oder Secret-Management-Systeme weiterzugeben.

CISA empfiehlt MFA als zusätzliche Schutzschicht für Online-Konten. Priorität verdienen insbesondere Registrar, Hosting, Repository und zentrale E-Mail-Konten. Recovery-Adressen und Recovery-Codes gehören ebenfalls in die Prüfung.

Nicht mehr benötigte API-Schlüssel, Deploy Keys und Service Accounts sollten nach der Übergabe rotiert oder widerrufen werden – aber erst, nachdem der neue Betriebsweg nachweislich funktioniert.

10. Abrechnung, Backups und Restore sind Teil der Technik

Ein erstaunlich wirksamer Abschaltknopf ist eine alte Kreditkarte. Domain, Hosting, CDN, Premium-Plugins, E-Mail-Versand, Consent-Tool oder Monitoring können an Zahlungswegen hängen, die niemand im Unternehmen kennt.

Dokumentieren Sie daher Vertragspartner, Zahlungsweg, Verlängerung und Verantwortliche. Ebenso wichtig: Wo liegen Backups, wer kontrolliert das Konto und wie wird ein Restore gestartet?

Wenn nur die bisherige Agentur weiß, wie eine Sicherung zurückgespielt wird, ist das Backup technisch vorhanden, aber die Wiederherstellung nicht vollständig übergeben.

Zwölf Red Flags für einen fragilen Handover

1. Die Domain liegt im privaten Account eines Dienstleisters.
2. Niemand im Unternehmen kennt den Registrar.
3. Die Recovery-Adresse eines kritischen Accounts gehört der Agentur.
4. Nur eine Person besitzt das Code-Repository.
5. Es gibt keinen reproduzierbaren Deployment-Prozess.
6. Produktions-Secrets liegen nur lokal auf einem Entwicklergerät.
7. Das CMS nutzt einen gemeinsam geteilten Admin-Login.
8. Ehemalige Mitarbeiter oder Dienstleister besitzen noch Admin-Rechte.
9. Search Console enthält unbekannte oder alte bestätigte Inhaber.
10. Lizenzen lassen sich nur über das Konto der alten Agentur verlängern.
11. Backups existieren, aber niemand außerhalb der Agentur kennt den Restore.
12. Es gibt keine aktuelle Liste aller technisch angebundenen Dienste.

Keiner dieser Punkte beweist schlechte Agenturarbeit. Viele solcher Abhängigkeiten wachsen organisch über Jahre. Riskant werden sie, wenn sie unbekannt bleiben.

Der bessere Handover-Test: ein kontrollierter Dry Run

Vor dem Ende der Zusammenarbeit sollten Unternehmen und neuer technischer Ansprechpartner praktisch prüfen: Registrar öffnen, DNS exportieren, Hosting und Abrechnung aufrufen, Repository klonen, Projekt anhand der Dokumentation bauen, einen ungefährlichen Test-Deploy durchführen, CMS-Rollen prüfen, Search-Console-Owner und Tokens kontrollieren, Analytics und Consent-Zugänge verifizieren sowie Backup- und Restore-Ablauf nachvollziehen.

Erst wenn dieser Weg funktioniert, werden alte externe Zugänge reduziert. So werden fehlende Informationen sichtbar, solange die bisherige Agentur noch helfen kann.

Was Website-Pflichtencheck bei einem Handover prüfen würde

Ein Website-Handover-Check kann unter anderem Registrar und Recovery-Pfade, DNS und Nameserver, Hosting- und CDN-Eigentümer, Repository-Rollen, Build- und Deployment-Dokumentation, CMS-Konten, Search-Console-Inhaber und Verifikationstokens, Analytics- und Consent-Zugänge, Backup- und Restore-Verantwortung, externe API-Konten, Lizenzen, Zahlungsabhängigkeiten und alte Dienstleisterzugänge prüfen.

Das Ergebnis sollte keine Passwortliste sein, sondern eine Ownership Map mit Prioritäten: Was ist kritisch, wer kontrolliert es, wer kann es wiederherstellen und was passiert, wenn der heutige Ansprechpartner morgen nicht mehr verfügbar ist?

Eine gute Agentur macht sich nicht dadurch wertvoll, dass nur sie die Website bedienen kann. Sie schafft Wert, indem sie einen Betrieb hinterlässt, der nachvollziehbar, wartbar und sauber übergabefähig ist.

Wenn Ihre Website nur funktioniert, solange dieselbe Person erreichbar ist, besitzen Sie zwar eine Website – aber noch keinen belastbaren Website-Betrieb.