Field Note: Was eine gute Übergabe enthält

Eine Website ist nach dem Go-live nicht einfach „fertig“. Sie wird betrieben, aktualisiert, überwacht und im Störungsfall wiederhergestellt. Genau deshalb ist eine Übergabe keine Dateiablage und kein Abschlussmeeting, sondern die kontrollierte Verlagerung von Verantwortung: Die übernehmende Organisation muss das System verstehen, bedienen und ohne die bisherige Agentur sicher verändern können. Diese Website Übergabe Checkliste macht daraus einen prüfbaren Ablauf – für Websites ebenso wie für gekoppelte Formulare, CRM-Schnittstellen, Hosting- und Analyse-Setups.

Die Suchintention hinter einer Übergabe ist praktisch: Was muss konkret vorliegen, damit ein Team handlungsfähig wird? Die kurze Antwort lautet: vollständige Eigentümerschaft, dokumentierte Zugänge, ein nachvollziehbarer Betriebsweg und eine formale Abnahme. Nicht jede Anwendung braucht dieselbe Tiefe. Aber jede produktive Website braucht einen klaren Weg von der URL über den Code und die Infrastruktur bis zur verantwortlichen Person.

Übergabe beginnt mit Eigentum, nicht mit Passwörtern

Der häufigste Fehler liegt im Begriff „Zugang“. Ein Passwort für das CMS genügt nicht, wenn Domain, DNS-Zone, Cloud-Konto, Git-Organisation oder Analyse-Property einer externen Person gehören. Dann besitzt die Organisation zwar Inhalte, kann aber weder einen Ausfall selbst beheben noch einen Dienstleister wechseln. Deshalb trennt eine belastbare Übergabe drei Ebenen: rechtliche und administrative Inhaberschaft, rollenbasierte Berechtigungen und technische Geheimnisse.

Zuerst wird festgehalten, wer Eigentümer jedes zentralen Kontos ist. Dazu zählen Registrar, DNS-Provider, Hosting oder Cloud, E-Mail-Versand, CDN, CMS, Quellcode-Organisation, Monitoring, Cookie-Management, Webanalyse und gegebenenfalls Zahlungs- oder Formularanbieter. Der neue Eigentümer meldet sich während der Übergabe mit einem eigenen Konto an. Erst dann ist der Zugang nachweisbar. Persönliche Agentur-Accounts sind durch Unternehmens-Accounts zu ersetzen; geteilte Logins sind kein Ersatz für Rollen und ein zweiter Faktor gehört zu jedem privilegierten Konto.

Bei Code ist der Unterschied zwischen Zugriff und Kontrolle besonders sichtbar. Ein Repository-Transfer auf GitHub überträgt Inhalte, Issues, Pull Requests, Releases, Projekte und Einstellungen an den neuen Eigentümer. Webhooks, Secrets und Deploy Keys bleiben dabei grundsätzlich verknüpft – sie müssen daher nicht nur „mitübernommen“, sondern gezielt geprüft, rotiert und auf ihre weitere Berechtigung bewertet werden. GitHub leitet Links zur bisherigen Repository-Adresse weiter, empfiehlt aber, bestehende lokale Klone auf die neue Origin-URL umzustellen. 1 Für die operative Übergabe folgt daraus: Repository-Transfer, Rechteprüfung und Deployment-Test gehören in eine gemeinsame Abnahmesequenz.

Die Übergabeakte: ein System, das sich wiederfinden lässt

Eine gute Dokumentation ist keine lange Erzählung über den Projektverlauf. Sie beantwortet unter Zeitdruck vier Fragen: Was läuft? Wo läuft es? Wer entscheidet? Wie wird es sicher geändert oder wiederhergestellt? Als Format genügt ein versioniertes Übergabedokument im Repository oder Wissenssystem, ergänzt um einen Passwortmanager für Geheimnisse. Passwörter, API-Schlüssel und private Schlüssel gehören nicht in ein PDF, ein Ticket oder ein unverschlüsseltes Wiki.

Das Kernstück ist ein Inventar. Es ordnet jedem Baustein Zweck, Eigentümer, Zugriffsweg und Abhängigkeiten zu. Eine URL allein ist kein Inventar: Auch Subdomains, Redirect-Regeln, Cronjobs, Queues, Serverless-Funktionen, Transaktionsmails, Datenbanken und externe APIs müssen sichtbar werden. Für den Betrieb hilft es, das Inventar nach Wirkung zu priorisieren: Was verhindert Umsatz, Lead-Erfassung, Veröffentlichung oder Sicherheit, wenn es ausfällt?

Bereich	Bei der Übergabe nachweisbar machen	Abnahmekriterium
Domain & DNS	Registrar, Inhaber, Nameserver, Zonenexport, DNSSEC-Status, Ablauf- und Verlängerungsprozess	Kundenteam kann Zone lesen und eine Teständerung im Vier-Augen-Prinzip freigeben
Hosting & Deployment	Provider, Regionen, Projekt/Account, Build- und Releaseweg, Umgebungen, Rollback	Staging- und Produktionsrelease erfolgen mit dokumentierter Rolle
Code & Konfiguration	Repository, Standardbranch, Branch-Schutz, CI/CD, Konfigurationsvariablen, Lizenzhinweise	Neuer Owner verwaltet Rechte; Build ist reproduzierbar
Daten & Integrationen	Datenbanken, Backups, Formulare, APIs, Webhooks, Mail- und Consent-Anbieter	Datenfluss, Verantwortliche und Wiederanlauf sind dokumentiert
Betrieb & Sicherheit	Monitoring, Alarmziele, Logzugang, Incident-Weg, Patch-Verantwortung	Ein Testalarm erreicht die zuständige Person
SEO & Messung	Search Console, Sitemap, robots.txt, Canonicals, Analytics, Consent-Konfiguration	Properties liegen beim Kunden; Ausgangswerte sind festgehalten

Das Inventar bleibt bewusst knapp, aber es braucht Verweise auf die tatsächlichen Orte: URL des Verwaltungsbereichs, Name der Organisation, Projekt-ID, Runbook-Pfad und verantwortliche Rolle. Für den Aufbau eines dauerhaften Betriebsdokuments kann ein Systemcheck für WordPress ein sinnvoller nächster Schritt sein. Bei DNS sollte die Übergabe mit einer klaren Betriebsverantwortung verbunden werden; die Grundlogik dazu beschreibt der Beitrag WordPress als Betriebssystem.

Betriebsfähigkeit beweisen statt nur bestätigen

Dokumente zeigen Absicht; Übungen zeigen Fähigkeit. Die Abnahme sollte deshalb mit kurzen, risikoarmen Tests arbeiten. Der neue Betreiber führt einen Login aus, löst einen Staging-Deploy aus, prüft einen Alarmkanal und findet den letzten Backup-Nachweis. Ein Rollback muss nicht zwingend in Produktion stattfinden. Er sollte aber für Staging oder eine kontrollierte Testversion einmal durchgespielt werden. Entscheidend ist, dass der Ablauf unabhängig von Erinnerungen einzelner Personen funktioniert.

Auch der Content-Betrieb braucht einen eigenen Test. Das Redaktionsteam legt einen Entwurf an, lässt ihn prüfen, veröffentlicht ihn und korrigiert eine bestehende Seite. Dabei werden Rollen, Freigaben, Bildrechte, Redirect-Anforderungen und die Grenzen des CMS sichtbar. Wer komplexere Inhaltsstrukturen betreibt, sollte ergänzend das Content-Modell dokumentieren, statt Wissen über Felder und Komponenten nur mündlich weiterzugeben.

Bei Sicherheitskontakten gehört die Zuständigkeit nach außen. RFC 9116 verlangt für Webdienste die Datei unter /.well-known/security.txt; sie muss über HTTPS mit text/plain; charset=utf-8 abrufbar sein. Die Felder Contact und Expires sind verpflichtend, und das Ablaufdatum sollte nicht länger als ein Jahr in der Zukunft liegen. 2 Das ist kein Ersatz für ein Incident-Runbook. Es verhindert aber, dass Sicherheitsfunde in einem nicht mehr betreuten Postfach oder bei einem ehemaligen Dienstleister landen.

# https://www.example.de/.well-known/security.txt
Contact: mailto:security@example.de
Policy: https://www.example.de/sicherheit
Preferred-Languages: de, en
Expires: 2027-01-29T00:00:00Z

Das Beispiel ist absichtlich minimal. Vor der Veröffentlichung muss die Mailbox erreichbar sein, die Policy zum tatsächlichen Umgang mit Meldungen passen und das Ablaufdatum als wiederkehrende Aufgabe im Betrieb stehen.

SEO und Redirects sind Teil der Betriebsübergabe

SEO wird bei Relaunches oft als einmalige Optimierungsleistung behandelt. Operativ ist es jedoch ein Bestand an URLs, Regeln, Messpunkten und Verantwortlichkeiten. Wer eine Domain, eine Informationsarchitektur oder ein CMS übergibt, übergibt damit auch die Pflicht, alte Adressen korrekt zu behandeln. Google empfiehlt vor einem Umzug eine Zuordnung alter zu neuen URLs, serverseitige permanente Redirects, aktuelle interne Links, Canonicals und Sitemaps sowie das Monitoring von alter und neuer Property in Search Console. 3

Diese Hinweise lassen sich direkt in die Übergabe übersetzen: Die URL-Mapping-Datei ist ein Übergabeartefakt; die Person mit Search-Console-Zugriff ist benannt; ein Ausgangsexport zu indexierten Seiten, Fehlern und wichtigen Suchanfragen liegt ab. Bei einer Domain- oder Subdomain-Änderung gehört der Change-of-Address-Schritt in den Ablauf. Für Pfadänderungen innerhalb derselben Domain ist er dagegen nicht vorgesehen. 3

Google rät, permanente Redirects möglichst mindestens ein Jahr zu behalten, und weist darauf hin, dass sich Rankings während der erneuten Verarbeitung der URLs vorübergehend verändern können. 3 Daraus folgt keine garantierte Sichtbarkeitsprognose. Es folgt aber eine klare Betriebsaufgabe: Redirects dürfen nicht kurz nach Projektende verschwinden, nur weil ein altes Hosting-Konto gekündigt wurde.

Ein direkter technischer Test ist besser als eine Sichtprüfung im Browser. Die folgende Prüfung erwartet in redirects.tsv je Zeile eine alte URL und ihr exaktes, absolutes Ziel, getrennt durch Tabulatoren. Sie akzeptiert nur direkte 301- oder 308-Antworten und meldet jede Abweichung als Fehler.

#!/usr/bin/env bash
set -euo pipefail

while IFS=$'\t' read -r old_url expected_url; do
  headers="$(curl -sSI --max-redirs 0 "$old_url")"
  status="$(printf '%s\n' "$headers" | awk 'NR == 1 {print $2}')"
  location="$(printf '%s\n' "$headers" | awk -F': ' 'tolower($1) == "location" {sub("\\r$", "", $2); print $2; exit}')"

  if { [ "$status" != "301" ] && [ "$status" != "308" ]; } || [ "$location" != "$expected_url" ]; then
    printf 'FEHLER: %s -> Status %s, Location %s\n' "$old_url" "$status" "$location" >&2
    exit 1
  fi
done < redirects.tsv

Das Skript prüft nur den ersten Hop. Es ersetzt weder einen vollständigen Crawl noch einen Test der Zielseite, verhindert aber einen verbreiteten Fehler: eine Redirect-Kette oder eine Weiterleitung auf die falsche, oft nur allgemein passende Seite.

Abnahme, Restpunkte und Grenzen

Eine Übergabe endet mit einem protokollierten Termin, nicht mit der letzten Rechnung. Dort werden Inventar, Zugriffe, Tests und offene Punkte gemeinsam durchgegangen. Jeder Restpunkt erhält einen Eigentümer, ein Ziel und ein Fälligkeitsdatum. Sinnvoll ist außerdem eine kurze Stabilisierung: Die bisherige Umsetzungspartnerin bleibt für klar definierte Rückfragen erreichbar, während Änderungen bereits über die neuen Betreiberkonten laufen. So wird echte Verantwortungsübernahme sichtbar, ohne eine verdeckte Dauerabhängigkeit zu erzeugen.

Die Abnahme sollte zwischen vollständig übergeben, betriebsfähig und noch offen unterscheiden. Ein fehlendes Archiv älterer Design-Dateien ist etwas anderes als ein nicht getestetes Produktionsbackup. Kritische Punkte dürfen nicht als bloße Notiz stehen bleiben: Ohne funktionierenden Domainzugang, Wiederherstellungsweg oder Ansprechpartner für Sicherheitsmeldungen ist die Übergabe noch nicht betriebsfähig. Weniger dringende Verbesserungen können in ein priorisiertes Backlog. Das Protokoll hält für jeden Test Datum, ausführende Rolle, Ergebnis und Link zum Nachweis fest. So lässt sich später nachvollziehen, was konkret abgenommen wurde – und was nicht.

Diese Checkliste ersetzt keine Rechtsberatung, keinen Auftragsverarbeitungsvertrag und kein organisationsspezifisches Notfallmanagement. Sie kann auch nicht aus einer unklaren Vertragslage nachträglich Eigentum machen. Bei regulierten Daten, komplexen Cloud-Landschaften oder kritischen Diensten müssen Datenschutz, Informationssicherheit, Beschaffung und Fachbetrieb zusätzliche Kriterien definieren. Der Maßstab bleibt dennoch einfach: Eine Übergabe ist gut, wenn das übernehmende Team die Website sicher betreiben, ändern, messen und im Fehlerfall wiederherstellen kann – ohne auf das Gedächtnis oder die Konten des bisherigen Dienstleisters angewiesen zu sein.

Weiterführende Quellen

Diese offiziellen Dokumentationen und Standards vertiefen die im Beitrag behandelten Entscheidungen.