Website-Hosting-Migration SEO

TL;DR — Ein Hosting-Migrationsprozess verschiebt die Infrastruktur hinter Ihrer Website, während Besucher weiterhin dieselben URLs verwenden. Bauen und testen Sie den neuen Host zuerst, senken Sie die DNS-Time-to-Live (TTL) vor dem Start, lassen Sie den alten Host während des Wechsels weiterlaufen und vergleichen Sie, was beide Systeme zurückgeben. Beobachten Sie DNS, Zertifikate, Statuscodes, Inhalte, Geschwindigkeit und Crawler-Zugriff. Fahren Sie den alten Host erst herunter, wenn seine Logs zeigen, dass der Traffic null erreicht hat.

Was ist ein Hosting-Migrationsprozess?

Ein Hosting-Migrationsprozess ändert, wo oder wie eine Website bereitgestellt wird, ohne die URLs zu ändern, die Benutzer sehen. Der Wechsel zu einem anderen Hosting-Unternehmen ist ein Beispiel. Das Hinzufügen oder Ersetzen eines Content Delivery Network (CDN), das Ändern eines Ursprungsservers oder der Wechsel des DNS-Anbieters können Teil desselben Projekts sein.

Die URL bleibt gleich – das ist die entscheidende Bedingung. https://example.com/page/ muss vor und nach dem Umzug https://example.com/page/ bleiben.

Google behandelt dies als Site-Umzug ohne URL-Änderungen. Wenn sich Domain, Protokoll, Hostname oder Pfad ändern, verwenden Sie stattdessen den vollständigen Site-Migrationsprozess. Möglicherweise führen Sie zwei Migrationen gleichzeitig durch.

Warum kann ein Umzug mit gleicher URL SEO beeinflussen?

Ein Hosting-Migrationsprozess kann alles hinter einer stabilen Adresse verändern. Suchmaschinen können auf einen anderen Antwortcode, einen langsameren Server, ein abgelaufenes Zertifikat, eine Firewall-Herausforderung, eine veraltete gecachte Seite, ein defektes Bild, einen fehlenden Header oder eine gerenderte Seite stoßen.

Der sicherste Umzug bewahrt die beobachtbare Antwort, während die Infrastruktur ersetzt wird. Benutzer und Crawler sollten vom neuen System dieselbe erfolgreiche Seite erhalten, die sie vom alten erhalten haben.

Was sind die grundlegenden Schritte?

1. Kopieren oder verbinden Sie die Website mit der neuen Infrastruktur.
2. Testen Sie den neuen Ursprung und das CDN, ohne das öffentliche DNS zu ändern.
3. Senken Sie die DNS-TTL im Voraus, damit die eventuelle Änderung schneller propagiert.
4. Bestätigen Sie Zertifikate, Caching, Sicherheitsregeln und Crawler-Zugriff.
5. Ändern Sie DNS, um Traffic an die neue Infrastruktur zu senden.
6. Halten Sie beide Umgebungen online, während DNS-Caches ablaufen.
7. Überwachen Sie Logs, Fehler, Geschwindigkeit, Crawling und Suchleistung.
8. Fahren Sie den alten Host erst herunter, wenn seine Logs keinen verbleibenden Traffic zeigen.

Google empfiehlt dieselbe Sequenz aus Vorbereiten, Wechseln, Überwachen und Herunterfahren in seiner Dokumentation zum Hosting-Wechsel.

Was bewirkt die DNS-TTL?

Die DNS-TTL steuert, wie lange ein Resolver eine DNS-Antwort zwischenspeichern darf. Eine niedrigere TTL vor dem Umzug lässt geänderte Einträge früher aus Caches ablaufen. Sie bewirkt nicht, dass jeder Resolver sofort wechselt, und sie zum Start zu senken, ist für Caches, die den alten Wert halten, zu spät.

Google schlägt vor, die TTL auf einen konservativen niedrigen Wert zu senken, z. B. auf einige Stunden, mindestens eine Woche vor dem Umzug. Behandeln Sie das als Beispiel, nicht als universelle Zahl; Ihr DNS-Anbieter und Ihre betrieblichen Anforderungen bestimmen den genauen Wert.

Benötigen Sie Weiterleitungen?

Ein echter Hosting-Migrationsprozess benötigt keine SEO-Weiterleitungen, da sich die öffentlichen URLs nicht ändern. Das Hinzufügen pauschaler Weiterleitungen während eines reinen Host-Wechsels schafft neue Fehlermodi, ohne das Infrastrukturproblem zu lösen.

Bestehende Weiterleitungen müssen sich weiterhin genau so verhalten wie zuvor. Testen Sie diese auf dem neuen Stack, einschließlich alter Legacy-Regeln, die möglicherweise im aktuellen Webserver, CMS, Load Balancer oder CDN leben.

Wann ist der Umzug abgeschlossen?

Der Hosting-Umzug ist abgeschlossen, wenn die neue Infrastruktur die beabsichtigten Antworten konsistent liefert und die alte Infrastruktur keinen echten Benutzer- oder Crawler-Traffic mehr erhält. Google empfiehlt ausdrücklich, die Logs des alten Anbieters zu prüfen und ihn erst herunterzufahren, wenn der Traffic null erreicht hat.

TL;DR — Behandeln Sie eine Migration von Hosting, CDN oder DNS bei gleicher URL als Projekt zur Antwortparität und Verkehrslenkung. Erfassen Sie alle Hostnamen und Abhängigkeiten, senken Sie die DNS-TTL vor dem Start, konfigurieren Sie den neuen Ursprung und Edge, validieren Sie Zertifikate und Sicherheitskontrollen, testen Sie realistische Crawler- und Nutzerlast und vergleichen Sie rohe sowie gerenderte Antworten. Führen Sie alte und neue Infrastruktur parallel durch die DNS-Verbreitung. Überwachen Sie beide Log-Streams, DNS-Antworten, Fehler, Latenz, Cache-Verhalten, Crawl-Aktivität und Search Console. Führen Sie den Rollback durch, indem Sie nur bei einem vorab vereinbarten Infrastrukturfehler die vorherige Weiterleitung wiederherstellen.

Entscheiden Sie, ob dies wirklich eine Migration mit gleicher URL ist

Eine Hosting-Migration mit gleicher URL ändert die Infrastruktur, ohne die exakte öffentliche URL-Zeichenfolge zu ändern. Schema, Hostname, Port, Pfad, Query-Behandlung und Verhalten des abschließenden Schrägstrichs bleiben stabil.

Klassifizieren Sie das Projekt, bevor Sie es planen:

Lassen Sie nicht zu, dass ein Projektmanager eine URL-Änderung als „nur Hosting“ bezeichnet. Der Bereitstellungsplan muss jeden Migrationstyp enthalten, der tatsächlich ausgeliefert wird.

Erstellen Sie das Infrastruktur-Inventar

Das Infrastruktur-Inventar verhindert, dass die stillen Abhängigkeiten zu Überraschungen am Starttag werden. Erfassen Sie:

• alle öffentlichen Hostnamen, einschließlich Assets, Bilder, APIs, internationale Hosts und Legacy-Aliase;
• A-, AAAA-, CNAME-, NS-, SOA-, CAA-, MX-, TXT- und relevante SRV-Einträge;
• Zertifikatsaussteller, Validierungsmethoden, Subject Alternative Names und Ablauf;
• Ursprungsadressen, Ports, Health Checks, Load Balancer und Failover-Verhalten;
• CDN-Cache-Schlüssel, Cache-Regeln, Weiterleitungen, Transformationen, Worker und Purge-Methoden;
• WAF-, Bot-, Rate-Limit-, Geo-, Authentifizierungs- und IP-Allow/Deny-Regeln;
• Antwort-Header, Komprimierung, Cookie-Verhalten und Sicherheits-Header;
• Log-Ziele, Aufbewahrung, Sampling, Felder und Zeitzonen;
• Verifizierungsmethoden für Search Console und Analytics;
• Drittanbieter-Callbacks, Webhooks, Zahlungsabläufe, Feeds und allowlistete IPs.

Die DNS-Überprüfung muss Nicht-Web-Einträge umfassen. Das Unterbrechen von MX-, SPF-, DKIM-, DMARC- oder Diensteinträgen ändert möglicherweise nicht direkt die Rankings, kann aber das Geschäft schädigen, das Sie schützen wollten.

Legen Sie eine Antwortparitäts-Baseline fest

Antwortparität bedeutet, die alten und neuen Systeme für dieselbe angeforderte URL zu vergleichen, nicht nur zu prüfen, dass beide 200 zurückgeben.

Erfassen Sie einen repräsentativen Satz über Vorlagen und Verhaltensweisen hinweg:

• Status und Weiterleitungskette;
• endgültige URL und Protokollaushandlung;
• Titel, Canonical, Robots-Anweisungen, hreflang und strukturierte Daten;
• rohes HTML und browser-gerenderten Hauptinhalt;
• Content-Type, Cache-Control, Vary, Komprimierung und Sicherheits-Header;
• Bilder, Schriftarten, JavaScript, CSS, PDFs und Medien-Assets;
• Cookies und angemeldete oder personalisierte Varianten;
• mobiles und Desktop-Verhalten;
• Latenz, Zeit bis zum ersten Byte und Fehlerrate.

Verwenden Sie den Staging vs. Production SEO Diff für gepaarte Seitenprüfungen. Ein vollständiger Crawler und eine skriptgesteuerte Anfragesuite sollten das größere Inventar abdecken.

Bereiten Sie den neuen Ursprung vor

Die Vorbereitung des Ursprungs beginnt mit der Parität von Inhalten und Konfiguration. Kopieren Sie aktuelle Inhalte, Vorlagen, Medien, Robots-Regeln, Weiterleitungen, Fehlerbehandlung und Verifikationsdateien. Friere oder synchronisiere Schreibvorgänge ein, damit die neue Datenbank nicht mit veralteten Daten startet.

Testen Sie den Ursprung direkt über einen kontrollierten Hostnamen, einen lokalen Hosts-Datei-Override oder einen anbieter-spezifischen Vorschau-Mechanismus. Der Test muss den Produktions-Host-Header bewahren, da virtuelle Hosts, Anwendungs-Routing, Zertifikate, Kanonische URLs und absolute Links oft davon abhängen.

Der neue Ursprung muss auch die Last nach dem Wechsel bewältigen. Wärmen Sie die Anwendung und die Datenbank auf, bestätigen Sie Verbindungspools und Autoscaling, und testen Sie die Last bei ungecachten Anfragen. CDN-Cache-Misses können den Datenverkehr unmittelbar nach dem Start am Ursprung konzentrieren.

Konfigurieren Sie das CDN als separates System

Die CDN-Migration ändert mehr als nur die Geografie. Vergleichen Sie das alte und das neue Edge-Verhalten explizit:

• Cache-Key-Zusammensetzung, einschließlich Query-Strings, Cookies, Headern und Gerätevarianten;
• cachebare Statuscodes und Dateitypen;
• Browser-TTL, Edge-TTL, Stale-Serving, Revalidierung und Origin-Shielding;
• Weiterleitungen, Rewrites, Header-Transformationen und Edge-Funktionen;
• Cache-Bypass-Regeln für Konten, Warenkörbe, Suche und personalisierte Seiten;
• Komprimierung und Bildoptimierung;
• Purge-Umfang und -Ausbreitung;
• WAF, Bot-Management, Rate-Limiting und Ursprungsschutz.

Die aktuelle Dokumentation von Cloudflare weist beispielsweise darauf hin, dass das Standard-Caching die Cache-Control-Header des Ursprungs respektieren kann, aber durch Edge-Regeln überschrieben werden kann. Es bietet auch gezielte oder vollständige Purges, um frische Ursprungsabrufe zu erzwingen. Das genaue Verhalten ist anbieter-spezifisch, daher sollten Sie die Konfiguration exportieren und vergleichen, anstatt anzunehmen, dass äquivalente Bezeichnungen äquivalente Ergebnisse bedeuten. Siehe Cloudflares Cache-Dokumentation.

Behandeln Sie Cache-Parität als Inhalts-Parität

Die Cache-Konfiguration kann die falsche Seite korrekt und schnell ausliefern. Testen Sie anonyme, authentifizierte, lokalisierte, mobile und Query-String-Varianten. Ein Cache-Key, der ein bedeutendes Cookie oder einen Header auslässt, kann personalisierte Inhalte leaken. Ein Cache-Key, der jeden Tracking-Parameter enthält, kann den Cache fragmentieren und den Ursprung überlasten.

Purgen oder Vorwärmen Sie kritische Assets und Seiten gemäß dem Launch-Plan. Purgen Sie nicht blind alles während des Spitzenverkehrs, es sei denn, der Ursprung wurde auf den resultierenden Miss-Sturm getestet.

Validieren Sie TLS vom Nutzer bis zum Edge und vom Edge bis zum Ursprung

Die TLS-Validierung hat zwei Beine, wenn ein CDN HTTPS terminiert: Browser zu CDN und CDN zu Ursprung. Bestätigen Sie die Hostname-Abdeckung, vollständige Zertifikatsketten, moderne Protokollunterstützung, Erneuerung und strenge Ursprungsvalidierung.

Nur für den Ursprungsserver vorgesehene Zertifikate sind möglicherweise nicht öffentlich vertrauenswürdig. Cloudflare warnt, dass seine Zertifikate der Ursprungszertifizierungsstelle Browser-Vertrauensfehler verursachen können, wenn das Proxying deaktiviert oder pausiert ist. Das ist beim Rollback wichtig: Ein reiner DNS-Fallback zu einem Ursprung mit ausschließlich am Edge geltendem Vertrauensmodell kann für Nutzer fehlschlagen. Siehe Cloudflares Anleitung zur Ursprungszertifizierungsstelle.

Testen Sie jeden öffentlichen Hostnamen, einschließlich Wildcard-Annahmen und selten genutzter Asset- oder regionaler Hosts. Ein gültiges Apex-Zertifikat beweist nicht, dass jeder Subdomain abgedeckt ist.

Senken Sie die DNS-TTL vor dem Wechsel

Die TTL-Planung beginnt vor dem Cutover. Google empfiehlt, die relevante TTL mindestens eine Woche vor dem Wechsel auf einen konservativen niedrigen Wert, z. B. einige Stunden, zu senken. Ein DNS-Anbieter kann andere Mindestwerte vorschreiben; proxierte Einträge können auch feste Werte haben.

Cloudflares TTL-Dokumentation erklärt den grundlegenden Kompromiss: Längere Werte erhöhen die Cache-Wiederverwendung, während kürzere Werte es ermöglichen, dass Änderungen an Einträgen schneller wirksam werden. Notieren Sie die ursprüngliche TTL und planen Sie deren Wiederherstellung erst, nachdem die neue Infrastruktur stabil ist.

DNS-Änderungen können über verteilte Systeme hinweg nicht atomar sein. Ändern Sie während des Umstiegs so wenig wie möglich, verifizieren Sie Antworten von mehreren öffentlichen Resolvern und halten Sie das alte Ziel verfügbar, solange gecachte Antworten gültig bleiben.

Crawler-Zugriff und Sicherheitskontrollen verifizieren

Sicherheitsparität ist nicht Regelanzahl-Parität. Eine von einem anderen Anbieter kopierte WAF kann Crawler herausfordern oder blockieren, Query-Parameter entfernen, Antworten umschreiben oder hochvolumiges Crawling unterschiedlich stark ratenbegrenzen.

Der Hosting-Leitfaden von Google besagt, dass Firewalls und Denial-of-Service-Schutz Googlebot nicht von DNS- oder Hosting-Servern blockieren dürfen. Verifizieren Sie Googlebot mit den dokumentierten Verifizierungsmethoden von Google, nicht nur mit einem User-Agent-String.

Testen Sie sowohl normales Crawler-Verhalten als auch legitime Bursts. Vermeiden Sie breite Allowlists, die den Schutz für gefälschte User-Agents deaktivieren. Bewahren Sie Sicherheitslogs auf, damit blockierte Anfragen von Ursprungsfehlern unterschieden werden können.

Den parallelen Betrieb planen

Paralleler Betrieb bedeutet, dass sowohl die alte als auch die neue Infrastruktur während der Verbreitung korrekte Produktionsantworten liefern können. Die alte Umgebung muss weiterhin Inhalts- oder Datenänderungen erhalten, welche die Website betreffen. Andernfalls können Benutzer, die über gecachte DNS-Antworten geroutet werden, veraltete Bestände, unterbrochene Sitzungen oder veraltete Seiten sehen.

Wählen Sie eine Synchronisierungsstrategie:

• eine gemeinsame Lese-/Schreib-Datenbank für beide Stacks;
• replizierte Daten mit verstandenem Lag und Konfliktrichtlinie;
• ein kontrollierter Inhalts-Freeze während des Umstiegs;
• unidirektionale Ereignisreplikation für Bestellungen, Formulare oder Benutzerschreibvorgänge.

Sitzungszustand, Uploads, Cache-Invalidierungen und Hintergrundjobs benötigen dieselbe Entscheidung. „Beide Server sind an“ ist kein Plan für parallelen Betrieb, wenn ihre Zustände divergieren.

Den Umstieg durchführen

Der Hosting-Umstieg sollte bewusst langweilig sein:

1. Stoppen Sie unabhängige Deployments und bestätigen Sie das Änderungsfenster.
2. Führen Sie die finalen Paritäts-, Zertifikats-, Kapazitäts- und Backup-Prüfungen durch.
3. Entfernen Sie temporäre Crawl- oder Zugriffsblockaden vom neuen Produktionspfad.
4. Ändern Sie nur die geplanten DNS- oder CDN-Routing-Einträge.
5. Bestätigen Sie erwartete Antworten von mehreren Resolvern.
6. Fordern Sie geschützte Seiten über die öffentliche Route als Benutzer und Crawler an.
7. Bestätigen Sie, dass Logs von Edge, neuem Ursprung und altem Ursprung eintreffen.
8. Beobachten Sie Fehler, Latenz, Cache-Misses, Ursprungslast und Konversionen.

Verwenden Sie das Change-of-Address-Tool von Google nicht für einen reinen Hosting-Wechsel. Keine öffentliche URL hat sich geändert, daher gibt es keine Adressänderung zu melden.

Die Beweise überwachen, die den Wechsel belegen

Infrastrukturüberwachung sollte alten und neuen Verkehr trennen. Verwenden Sie einen Deployment-Marker und vergleichen Sie dieselbe Wochenzeit-Baseline, wo Saisonalität relevant ist.

Beobachten Sie:

• DNS-Antworten und Resolver-Verbreitung;
• alte-Host- und neue-Host-Anfragen von Benutzern und verifizierten Crawlern;
• Statuscode-Verteilung an Edge und Ursprung;
• TLS-, Verbindungs-, Timeout- und Anwendungsfehler;
• Latenz-Perzentile und ungecachte Ursprungsantwortzeit;
• Cache-Trefferquote und Ursprungsanfragevolumen;
• Googlebot-Anfragen, Crawl Stats, Page Indexing und repräsentative URL Inspection;
• synthetische Checks über Regionen und Netzwerke hinweg;
• Analysen, Konversionen und kritische Geschäftstransaktionen.

Google sagt, dass ein vorübergehender Rückgang der Googlebot-Crawl-Rate unmittelbar nach einer Hosting-Änderung normal sein kann, gefolgt von einem Anstieg in den nächsten Tagen. Verankern Sie jede Entscheidung an Zugänglichkeits- und Fehlerbeweisen, nicht nur an diesem erwarteten Muster.

Rollback vor dem Start definieren

Rollback führt das Routing zurück in einen bekannten guten Infrastrukturzustand. Es ist kein vages Versprechen, „DNS zurückzuschalten“. Dokumentieren Sie:

• die genauen Einträge, Routen und Konfigurationen, die wiederherzustellen sind;
• wer die Umkehrung autorisieren und ausführen kann;
• wie geänderte Inhalte, Sitzungen, Formulare, Bestellungen und Uploads abgeglichen werden;
• ob die alten Zertifikate und Abhängigkeiten gültig bleiben;
• Cache-Purge-Schritte auf beiden Routen;
• die Fehlerschwellen, die ein Rollback auslösen;
• die maximale sichere Entscheidungszeit.

Rollback-Auslöser sollten beobachtbar sein: anhaltende Verfügbarkeitsausfälle, erhebliche Conversion-Einbußen, weit verbreitete falsche Inhalte, Zertifikatsfehler, Crawler-Blockaden oder ein Kapazitätskollaps, der nicht innerhalb des Zeitfensters behoben werden kann. Eine vorübergehende Schwankung der Crawl-Rate allein ist kein Rollback-Auslöser.

Alte Infrastruktur anhand von Logs ausmustern, nicht anhand eines Kalenders

Die Ausmusterung des alten Hosts erfolgt, nachdem Logs zeigen, dass Nutzer und Crawler ihn nicht mehr erreichen und alle abhängigen Dienste umgezogen sind. Google empfiehlt, den alten Host abzuschalten, nachdem sein Traffic null erreicht hat.

Konfigurationsexporte, Logs und Rollback-Artefakte gemäß den Geschäftsanforderungen aufbewahren. DNS-TTL nach erwiesener Stabilität auf den vorgesehenen Dauerwert zurücksetzen. Temporäre Firewall-Ausnahmen und doppelte geplante Jobs entfernen, damit die Migration kein dauerhaftes Wartungschaos hinterlässt.

KI-Zusammenfassung

• Ein Hosting-Migrationswechsel ändert Server, CDN, Origin oder DNS, während die öffentlichen URLs identisch bleiben.
• URL-Änderungen erfordern den umfassenderen Site-Move-Prozess. Ein reiner Host-Wechsel benötigt keine neue Redirect-Map oder Change-of-Address-Einreichung.
• DNS, TLS, Origin, CDN, WAF, Cache, Logs, Verifizierung, Assets und geschäftliche Abhängigkeiten vor dem Start inventarisieren.
• DNS-TTL vor dem Cutover senken, den alten Wert behalten und nach Stabilisierung des neuen Pfads wiederherstellen.
• Alte und neue Rohantworten, gerenderte Seiten, Header, Assets, Redirects, Statuscodes, Latenz und Geschäftsverhalten vergleichen.
• Browser-zu-Edge- und Edge-zu-Origin-TLS sowie Zertifikate auf jedem Rollback-Pfad validieren.
• Die Umgebungen parallel betreiben und Schreibvorgänge synchronisieren, bis gecachte DNS-Antworten keinen Traffic mehr an den alten Stack senden.
• Beide Log-Streams, DNS-Antworten, Fehler, Origin-Last, Cache-Verhalten, verifizierten Crawler-Zugriff, Search Console und Conversions überwachen.
• Den alten Host erst ausmustern, wenn seine Logs zeigen, dass der Traffic null erreicht hat.

Offizielle Dokumentation

Google

• Webhosting wechseln und SEO bewahren erklärt den Prozess mit identischen URLs: Vorbereitung, DNS-Wechsel, Überwachung und Abschaltung.
• Website-Umzüge mit URL-Änderungen gilt, wenn sich auch Schema, Hostname oder Pfad ändern.
• Googlebot verifizieren dokumentiert Reverse-/Forward-DNS und die Verifizierung über veröffentlichte IPs.
• Crawl Stats report hilft bei der Überwachung von Googlebot-Anfragen und Host-Verfügbarkeit.

Infrastruktur-Referenzen

• Cloudflare DNS TTL erklärt TTL- und Propagierungs-Kompromisse.
• Cloudflare cache dokumentiert Edge-Caching, Cache-Regeln und das Leeren des Caches.
• Cloudflare-Ursprungszertifizierungsstelle dokumentiert Edge-zu-Origin-Zertifikate und die Einschränkung der Browser-Vertrauenswürdigkeit.

Zitate aus der Quelle

• “This guide is only for migrations that don’t affect the user-visible URL.” (Übersetzung) „Dieser Leitfaden gilt nur für Migrationen, die sich nicht auf die für Benutzer sichtbare URL auswirken.“ Google Search Central. Zum Hosting-Leitfaden springen
• Paraphrase: Google empfiehlt, die DNS-TTL vor dem Umzug zu senken, sicherzustellen, dass Firewalls weiterhin verifizierten Googlebot-Traffic zulassen, einen vorübergehenden Rückgang der Crawl-Rate zu erwarten und den alten Host so lange verfügbar zu halten, bis sein Traffic beendet ist. TTL-Anleitung, Firewall-Anleitung, Crawl-Rate-Anleitung, und Abschaltungs-Anleitung.

Hosting-Migrations-Checkliste

Umfang und Ausgangsbasis

• Bestätigt, dass sich keine öffentliche URL ändern wird.
• Alle Web-, Asset-, API- und regionalen Hostnamen inventarisiert.
• DNS-, CDN-, WAF-, Cache-, Redirect-, TLS- und Origin-Konfigurationen exportiert.
• Repräsentative Roh- und gerenderte Antwort-Baselines gespeichert.
• Traffic-, Fehler-, Latenz-, Crawl-, Indexierungs- und Konversions-Baselines aufgezeichnet.

Neue Infrastruktur

• Aktuelle Inhalte, Medien, Redirects, Robots-Regeln und Verifizierungsdateien synchronisiert.
• Host-Header-Routing und jeden öffentlichen Hostnamen getestet.
• Browser-zu-Edge- und Edge-zu-Origin-Zertifikate validiert.
• Cache-Schlüssel, Umgehungen, TTLs, Cookies, Transformationen und Purge-Verhalten abgeglichen.
• WAF-, Bot-, Rate-Limit- und Origin-Zugriffsverhalten abgeglichen.
• Cache-Misses, Anwendungsabhängigkeiten und Datenbankkapazität unter Last getestet.
• Bestätigt, dass Edge-, Origin-, Anwendungs- und Sicherheitsprotokolle aufbewahrt und durchsuchbar sind.

DNS und Start

• Relevante TTLs vor dem Umzug gesenkt und ursprüngliche Werte aufgezeichnet.
• Nicht-Web-Einträge, DNSSEC, Verifizierung und Service-Abhängigkeiten beibehalten.
• Die genaue Routing-Änderung und Rollback-Befehle dokumentiert.
• Alte und neue Infrastruktur mit einem Datensynchronisationsplan am Leben gehalten.
• Jede temporäre Crawl- oder Zugriffsblockade im Produktionspfad entfernt.
• DNS-Antworten über mehrere unabhängige Resolver verifiziert.

Nach dem Start

• Status, Inhalt, Header, Rendering, Assets und Redirects in der Produktion verglichen.
• Bestätigt, dass Benutzer und verifizierte Crawler nicht herausgefordert oder blockiert werden.
• Alte/neue Protokolle, Fehler, Latenz, Cache-Misses, Origin-Last und Konversionen beobachtet.
• Crawl-Statistiken, Seitenindexierung und repräsentative URL-Inspektionsergebnisse geprüft.
• TTL erst nach erwiesener Stabilität wieder auf den Dauerzustand zurückgesetzt.
• Alten Host erst außer Betrieb genommen, nachdem sein Traffic null erreicht hat.

Das Fünf-Schichten-Paritäts-Framework

Das Migrationszustandsmodell

Vorbereitet bedeutet, dass der neue Stack Paritäts- und Lasttests besteht. Umschalten bedeutet, dass DNS-Antworten und Anfragen aufgeteilt sind. Stabilisieren bedeutet, dass der neue Stack fast allen Datenverkehr bedient, während der alte Stack verfügbar bleibt. Abgeschlossen bedeutet, dass der Datenverkehr zum alten Host auf null sinkt und alle Abhängigkeiten zurückgezogen oder übertragen sind.

Bezeichnen Sie das Projekt nicht als abgeschlossen, wenn „DNS geändert“ erreicht ist. Das ist der Beginn der Umstellung, nicht das Ende der Migration.

Welcher Migrationsplan gilt?

Häufige Hosting-Migrationsfehler

Einige Regionen erreichen weiterhin den alten Host

Wahrscheinliche Ursache: zwischengespeicherte DNS-Antworten, Resolver-Verhalten oder Datensätze, die nicht konsistent geändert wurden. Behebung: Vergleichen Sie autoritative Antworten mit mehreren öffentlichen Resolvern, halten Sie den alten Host mit aktuellem Inhalt erreichbar und prüfen Sie TTLs, anstatt wiederholte Änderungen zu erzwingen.

Googlebot-Anfragen fallen nach dem Start

Wahrscheinliche Ursache: eine normale kurzfristige Anpassung der Crawl-Rate, eine Firewall-Herausforderung, DNS-Fehler, Latenz oder Serverfehler. Behebung: Prüfen Sie Crawl Stats und Zugriffsprotokolle verifizierter Bots. Der dokumentierte kurzfristige Rückgang bei Google ist kein Grund, echte Zugriffsfehler zu ignorieren.

Seiten sind schnell, zeigen aber veralteten Inhalt

Wahrscheinliche Ursache: ein Edge-TTL, Cache-Schlüssel, Fehler beim Leeren oder eine abweichende Datenquelle. Behebung: Prüfen Sie Age, Cache-Control, Vary und die Cache-Status-Header des Anbieters; testen Sie relevante Varianten; leeren Sie gezielt; verifizieren Sie dann Ursprung und Edge getrennt.

Die Website funktioniert über das CDN, schlägt aber fehl, wenn es umgangen wird

Wahrscheinliche Ursache: Vertrauen in das Ursprungszertifikat, Host-Header-Routing, Firewall-Allowlists oder eine fehlende direkte Ursprungsabhängigkeit. Behebung: Validieren Sie den vorgesehenen Edge-zu-Ursprung-Pfad und den dokumentierten Rollback-Pfad. Legen Sie keinen privaten Ursprung offen, nur um einen ungeplanten Bypass-Test zu bestehen.

Assets schlagen fehl, während HTML funktioniert

Wahrscheinliche Ursache: ausgelassene Asset-Hostnamen, CORS, Zertifikate, absolute URLs, Cache- Regeln, Hotlink-Schutz oder Ursprungsberechtigungen. Behebung: Crawlen und testen Sie das Asset-Inventar im Browser, einschließlich Schriftarten, Bilder, CSS, JavaScript, PDFs und Medien.

Ursprungslast steigt sofort an

Wahrscheinliche Ursache: kalte Caches, ein geänderter Cache-Schlüssel, umgangener Cache, fehlendes Shielding oder Bot-Datenverkehr, der den Ursprung direkt erreicht. Behebung: Stellen Sie die vorgesehenen Cache-Regeln wieder her, wärmen Sie hochwertige Objekte sorgfältig auf und erhöhen Sie die Kapazität. Führen Sie einen Rollback durch, wenn anhaltende Fehler den vereinbarten Schwellenwert überschreiten.

Tools für einen URL-gleichen Infrastrukturwechsel

• DNS-Checker vergleicht gängige Record-Typen über mehrere öffentliche Resolver. Verwenden Sie ihn während der Propagation, aber vergleichen Sie das Ergebnis auch mit der autoritativen Zone.
• HTTP-Header-Checker zeigt Header über Redirects hinweg, einschließlich CDN-Fingerprints, Komprimierung, Sicherheits- und Cache-Header.
• Staging-vs.-Produktion-SEO-Diff vergleicht gepaarte URLs hinsichtlich Status, Canonicals, Direktiven, ausgewählter Header, Schema und Inhalt.
• Bulk-HTTP-Statuscode-Checker prüft Status, Redirects, Ziel und Latenz über eine repräsentative URL-Menge.
• Google-Index-Checker prüft beobachtbare Crawl- und Indexierbarkeits-Blocker und verweist dann für Googles eigene Sicht auf die Search Console.
• Server- und Edge-Logs belegen, wohin der Traffic ging, welche Antwort er erhielt und wann die alte Infrastruktur tatsächlich ungenutzt ist.
• Synthetisches Monitoring testet die öffentliche Verfügbarkeit und kritische Transaktionen aus mehreren Netzwerken und Regionen.

Nachweisen, dass die Hosting-Migration funktioniert hat

DNS-Propagation und Drain-Test des alten Hosts

• Durchzuführender Test: Autoritative DNS plus mehrere öffentliche Resolver abfragen und dann das Anfragevolumen auf alter und neuer Infrastruktur grafisch darstellen.
• Erwartetes Ergebnis: Öffentliche Antworten konvergieren auf die vorgesehene Route, während der Traffic zum alten Host auf null sinkt.
• Fehlerinterpretation: Inkonsistente Records, gecachte Antworten oder nicht verfolgte Hostnamen leiten weiterhin Traffic woanders hin.
• Überwachungsfenster: Vom Cutover bis mindestens zur längsten zuvor relevanten TTL und bis die Logs des alten Hosts dauerhaft bei null bleiben.
• Rollback-Auslöser: Wesentliche Regionen können den neuen Dienst nicht auflösen oder erreichen, und das Problem kann nicht innerhalb des Wiederherstellungsfensters behoben werden.

Antwort-Paritätstest

• Durchzuführender Test: Vergleichen Sie die Baseline mit der Produktion mithilfe des Staging-vs.-Produktion- SEO-Diff, eines Crawlers und gerenderter Browsertests.
• Erwartetes Ergebnis: Beabsichtigter Status, Canonicals, Robots-Regeln, Inhalt, strukturierte Daten, interne Links, Assets und Header bleiben erhalten.
• Fehlerinterpretation: Die neue Origin-, Edge- oder Anwendungskonfiguration hat trotz stabiler URLs eine suchsichtbare Antwort verändert.
• Überwachungsfenster: Unmittelbar vor und nach dem Cutover, danach nach jedem Launch-Fix.
• Rollback-Auslöser: Ein seitenweiter Indexierbarkeits-, Canonical-, Inhalts- oder Asset-Fehler betrifft geschützte Vorlagen und kann nicht sicher per Hotfix behoben werden.

Crawler-Zugriffs- und Kapazitätstest

• Durchzuführender Test: Verifizierte Crawler-Logs, Search Console Crawl Stats, Origin-Latenz, Fehlerraten und ungecachte Lasttestergebnisse prüfen.
• Erwartetes Ergebnis: Verifizierte Crawler erhalten erfolgreiche Antworten ohne Herausforderungen, während die Origin innerhalb ihres etablierten Kapazitätsrahmens bleibt.
• Fehlerinterpretation: WAF, DNS, TLS, Rate Limiting oder Origin-Kapazität verhindern zuverlässiges Crawling.
• Überwachungsfenster: Kontinuierlich vom Launch bis zu den ersten Tagen der Crawl-Raten-Stabilisierung.
• Rollback-Auslöser: Anhaltende Crawler- und Benutzerfehler überschreiten die genehmigte Fehler- oder Verfügbarkeitsschwelle.

Cache-Sicherheitstest

• Durchzuführender Test: Anonyme, authentifizierte, lokalisierte, mobile und Query-Varianten anfordern, während Cache-Keys und Antwort-Header geprüft werden.
• Erwartetes Ergebnis: Öffentliche Inhalte werden wie vorgesehen gecacht; private oder personalisierte Antworten werden nicht geteilt; sinnvolle Varianten bleiben unterscheidbar.
• Fehlerinterpretation: Cache-Key- oder Bypass-Regeln können falsche Inhalte ausliefern oder die Origin überlasten.
• Überwachungsfenster: Vor dem Launch, unmittelbar nach dem Cutover und nach jeder Änderung von Cache-Regeln oder Purges.
• Rollback-Auslöser: Personalisierte Daten werden offengelegt, weit verbreitete veraltete Inhalte werden ausgeliefert, oder die Origin kann die Miss-Rate nicht verkraften.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Artikel

• A Website Migration Takes More Than a Checklist to Be Successful deckt den breiteren Migrationsprozess, Ausgangswerte, Staging und Überwachung ab.
• Redirects for SEO erklärt das veraltete Redirect-Verhalten, das einen Infrastrukturwechsel überstehen muss.

Verwandte Anleitungen auf dieser Website

• Site Migrations deckt die Migrationsklassifizierung und den universellen Prozess ab.
• Website Migration Checklist bietet die phasenbasierte Projekt-Checkliste.
• HTTP Status Codes erklärt die Antwortebene, die Sie beibehalten und überwachen sollten.

Aus der Branche

• Google: Hosting wechseln
• Google: Googlebot verifizieren
• Cloudflare: DNS TTL
• Cloudflare: Manage DNS records
• Cloudflare: Cache documentation
• Cloudflare: Ursprungszertifizierungsstelle
• Bing: IndexNow

Testen Sie sich: Website-Hosting-Migrations-SEO

Fünf Fragen zur Klassifizierung, zum Start und zur Validierung eines URL-gleichen Infrastrukturwechsels. Wählen Sie für jede eine Antwort aus und überprüfen Sie dann.

Änderungsprotokoll