Zugänge und Bestand prüfen
Das neue Team erfasst mit individuellem Lesezugriff Hosting, WordPress, Code, Plugins, Formulare, Analytics, Monitoring und frühere Störungen. Die Live-Site bleibt unverändert.
Tickets bleiben liegen, Zugänge sind unklar, niemand fühlt sich für die Live-Site zuständig. Wir klären Domain, Hosting und Admin-Zugang und betreiben die Website danach weiter.

Marketing wartet auf Textänderungen. Die bisherige Agentur antwortet langsam oder gar nicht. Domain, Hosting, WordPress-Admin und Backups liegen bei Personen, die das Unternehmen nicht mehr steuert.
Solange niemand die Live-Website verantwortet, bleibt jede Störung ein Streitfall. Formulare, Updates und Search Console hängen in der Luft.
Wir klären Zugänge und tragen danach die Verantwortung für Betrieb, Releases und Störungen.
Nach der Prüfung von Domain, Hosting, WordPress-Admin, Backups und Formularen liegt die Live-Site bei uns. Sie haben eine Ansprechperson für Störungen, Updates und Veröffentlichung.
Kleine Reparaturen und Wartung laufen auf der bestehenden Plattform. Einen Relaunch planen wir nur, wenn die Prüfung zeigt, dass Theme, Content-Modell oder Integrationen das Geschäft nicht mehr tragen. Ablauf: Website-Relaunch.
Bei einem Agenturwechsel wechselt die Betreuung. Ein Relaunch ändert Design, Struktur, Inhalte oder technische Grundlage. Die erste Entscheidung verlangt die zweite nicht.
Behalten Sie die aktuelle Website, wenn Marketing veröffentlichen kann, wichtige Formulare funktionieren und das Theme wartbar ist. Ein Relaunch kann sinnvoll sein, wenn normale Änderungen die Site beschädigen, wichtige Erweiterungen aufgegeben wurden oder die Inhaltsstruktur nicht mehr zum Unternehmen passt.
Lassen Sie Agenturwechsel, erste Reparaturen und einen möglichen Relaunch getrennt kalkulieren. So können Sie die kleinste sinnvolle Änderung beauftragen. Scope und SEO-Migration: Website-Relaunch.
| Status | Bedeutung | Nachweis | Entscheidung |
|---|---|---|---|
| Unternehmenskontrolliert und geprüft | Ein Unternehmenskonto kann Zugang wiederherstellen, verlängern, Rechte vergeben und die nötige Aufgabe ausführen. | Rolle, Wiederherstellung, MFA, Rechnung, Export und erfolgreicher Test | Abnehmen |
| Übertragbar | Der bisherige Inhaber oder Anbieter hat die Übertragung bestätigt. | Empfänger, Schritte, Frist, Kosten und Abschlussnachweis | Vor Ende der Kündigungsfrist einplanen |
| Vor dem Ende ersetzen | Konto oder Lizenz lassen sich nicht übertragen oder ein Unternehmenskonto ist sicherer. | Ersatzkonto, übertragene Einstellungen und erfolgreicher Test | Alten Dienst noch nicht kündigen |
| Fehlt oder ungeklärt | Inhaber, Wiederherstellung, Einstellung, Export oder Test fehlen. | Offene Frage und zuständige Person | Abnahme blockieren, wenn kritisch |
| Abhängigkeit | Vor Kündigung erfassen | Bei Änderung | Abnahmenachweis |
|---|---|---|---|
| Domain-Registrar | Inhaber, Anbieter, Verlängerung, Rechnung, Wiederherstellung, MFA | Beim .de-Providerwechsel Empfänger und Ablaufdatum der AuthInfo notieren | Unternehmen kann Domain verlängern und Zugang wiederherstellen |
| Verbindliches DNS | Anbieter, Nutzer, vollständiger Zonenexport, Nameserver | Zeitfenster, alte und neue Werte, Rückfallweg | Website und benötigte Einträge werden aufgelöst |
| Webhosting | Vertrag, Verwaltung, Datenbank, Dateien, Zugänge, Backups | Vor Umschaltung beim Ziel wiederherstellen und testen | Seiten, Formulare, Aufgaben, Protokolle und Rückfallweg funktionieren |
| E-Mail-Hosting | Postfächer, Weiterleitungen, Versanddienst, Supportkontakt | MX, SPF, DKIM und DMARC erhalten und prüfen | Senden, Empfangen und Formularzustellung funktionieren |
Das neue Team erfasst mit individuellem Lesezugriff Hosting, WordPress, Code, Plugins, Formulare, Analytics, Monitoring und frühere Störungen. Die Live-Site bleibt unverändert.
Ein aktuelles Backup wird in Staging eingespielt. Build, Deployment, Kompatibilität, Cronjobs, Formulare, Consent, Caching, Monitoring und Rollback werden geprüft.
Legen Sie fest, wer Störungen erhält und Änderungen veröffentlichen darf. Übergeben Sie Anleitungen, Anbieter, offene Fehler, Verlängerungen und bekannte Übergangslösungen.
Einen kleinen Fix über Testumgebung, Backup, Freigabe, Live-Website und Prüfung veröffentlichen. Verantwortung erst tragen, wenn Formulare, Alarme, Wiederherstellung, Verlängerungen, Rückfallweg und geänderte Anbieter funktionieren.
Halten Sie Domain, URLs, Canonicals, robots-Regeln, Sitemap, Inhalte, Redirects und Analytics während des Wechsels stabil. Erfassen Sie vor dem ersten Release Search-Console-Klicks und Indexierung, Top-Landingpages, Crawl-Fehler, Core Web Vitals und Conversion-Events.
Kombinieren Sie die Zugangsübergabe nicht mit einem ungeprüften Hosting-Umzug oder Plugin-Cleanup. Muss Hosting umziehen, behandeln Sie das als eigenes Release mit Quell- und Ziel-Baseline, Rollback, DNS-Plan und Post-Change-Verifikation. SEO-Migration gehört in den Website-Relaunch.
Schicken Sie uns den aktuellen Stand Ihrer Website. Wir antworten mit den Risiken, die wirklich zählen.
| Schritt | Vor der Umschaltung festhalten | Abnahme nach der Umschaltung |
|---|---|---|
| 1. DNS-TTL senken | Aktuelle TTL und Datum der Absenkung (oft 24 bis 48 Stunden vorher) | Propagationsfenster entspricht dem Plan; Rollback-IP ist bekannt |
| 2. Unabhängiges Backup | Datei- und Datenbankkopie außerhalb beider Hoster, mit Restore-Verantwortung | Wiederherstellung in einer Nicht-Produktionsumgebung gelingt |
| 3. Zielsystem aufbauen | Staging-URL, PHP- und WordPress-Versionen, SSL-Weg, Cron, Mailversand | Seiten, Formulare, Login, Medien und geplante Aufgaben funktionieren auf dem Ziel |
| 4. SEO-Signale stabil halten | URL-Inventar, Canonicals, robots, Sitemap, Search-Console-Baseline | Kein versehentliches noindex, kein doppelter Live-Host, Prioritäts-URLs lösen einmal auf |
| 5. DNS umschalten und prüfen | Zeitfenster, Eskalationskontakt, Aufbewahrungszeit des alten Hosters | HTTPS, Formulare, Analytics, Monitoring und Backups auf dem neuen Host bestätigt |
| 6. Alten Host später beenden | Mindest-Aufbewahrung (oft 7 bis 14 Tage) und wer kündigt | Kündigung erst nach Prüfung und datierter Abnahmenotiz |
| Bereich | Erforderliche Übergabe | Abnahme |
|---|---|---|
| Architektur | Hosting, Umgebungen, DNS, CDN, Datenbank, Storage | Diagramm entspricht Live-Konten |
| Release | Repository, Branches, Build, Deploy, Rollback | Kleine Änderung erreicht Staging |
| WordPress | Theme, Custom Plugins, Extension-Regel, Rollen | Kein unbekannter Production-Code |
| Betrieb | Backups, Monitoring, Incidents, Wartungsfenster | Restore und Alarm getestet |
| Marketing | Formulare, CRM, SMTP, Analytics, GTM, Consent | End-to-End-Test erreicht Owner |
| Search | Sitemaps, robots, Redirects, Canonicals, hreflang | Prioritätsseiten entsprechen Baseline |
| Verträge | Anbieter, Lizenzen, Verlängerungen, Support | Übertragung oder Ersatz dokumentiert |
| Bekannte Risiken | Fehler, Sicherheitsausnahmen, Übergangslösungen | Risiko, zuständige Person und Prüftermin erfasst |
Nicht durch den Wechsel allein. Risiko entsteht, wenn gleichzeitig Hosting, Redirects, Canonicals, robots-Regeln, Performance, Inhalte oder Analytics ohne kontrollierte Migration verändert werden. Den SEO-Migrationsablauf beschreibt Website-Relaunch.
DNS-TTL rechtzeitig senken, eine vollständige Kopie auf dem neuen Host aufbauen und testen, während der alte Host live bleibt, dann DNS in einem geplanten Fenster umschalten und den alten Host als Rollback behalten. Nutzen Sie die Hosting-Umschaltungstabelle auf dieser Seite. Der Plugin-Export ist ein Transfer-Schritt; die Abnahme folgt erst nach Restore-, Formular- und DNS-Prüfung.
Prüfen Sie den Vertrag und sichern Sie zuerst unternehmenseigene Zugänge und ein unabhängiges Backup. Folgen Sie dann dem vereinbarten Kündigungs- und Übergabeprozess. Das ist operative Vorbereitung, keine Rechtsberatung.
Dokumentieren Sie, was übertragbar ist und was ersetzt werden muss. Erstellen Sie Unternehmenskonten, reproduzieren Sie die Konfiguration in Staging und migrieren Sie Abhängigkeiten einzeln. Kündigen Sie den alten Dienst erst nach dem Test.
Nein. Eine wartbare Website kann weiterbetrieben und schrittweise verbessert werden. Ein Neubau ist erst sinnvoll, wenn Theme, Content-Modell, Workflow, Security oder Anforderungen wirtschaftlich nicht korrigierbar sind.
Erst wenn das neue Team Wiederherstellung und Rechte der Unternehmenskonten, Backup, Veröffentlichungsweg, Formulare und Alarme geprüft, offene Risiken dokumentiert und Vorfälle in der Verantwortung hat. Danach ehemalige Nutzer und Bestätigungsdateien entfernen sowie geteilte Zugangsdaten ändern.
DENIC erklärt die AuthInfo für einen .de-Providerwechsel und trennt Domainverwaltung von Webspace, E-Mail und Namensdiensten. Ein reiner Agenturwechsel löst keinen dieser Schritte aus.
WordPress dokumentiert Rollen und Rechte und empfiehlt Backups außerhalb des Hosts. Google trennt Search-Console-Inhaber und Nutzer sowie Analytics-Zugänge auf Konto- und Property-Ebene.
Some Tech Work kann eine bestehende WordPress-Plattform weiterbetreiben, ohne einen Relaunch als Standardantwort zu verkaufen. Wir inventarisieren Eigentum, stellen Staging wieder her und prüfen Releases, Formulare, Search-Signale, Backups und Monitoring.
Ist die Plattform nicht wirtschaftlich korrigierbar, trennen wir den Relaunch-Scope vom Agenturwechsel. Für Updates, Security, Monitoring und Incident Response vergleichen Sie die veröffentlichten WordPress-Wartungspakete. Technische Führung danach: Fractional CTO.
Verfasst von
Vineet Talwar
Co-Founder, Tech & Operations bei Some Tech Work. WordCamp-Speaker in Europa und Asien und Host des WP-Shoutout-Podcasts.
Sagen Sie uns, was nicht läuft
Wir lesen jedes Briefing und antworten innerhalb eines Werktags.
Lieber erst sprechen?oder Tech-Stack-Audit anfragen →oder direkt per E-Mail →
Unklar, wo Sie anfangen sollen? Schicken Sie die hängende Entscheidung, den Workflow oder die Seite. Wir sagen, ob ein Diagnosegespräch, ein Tech-Stack-Audit oder ein anderer erster Schritt passt.