Der SEOdiot

Heute statt des üblichen Wochenrückblicks aus aktuellem Anlass mal ein hoffentlich für den einen oder anderen doch ganz hilfreicher SEO-Basics-Artikel: wie ziehe ich meine Website auf einen neuen Server um, so dass es möglichst keine Auswirkungen auf meine Platzierungen hat?

Eigentlich ist die Antwort banal simpel: gestalte den Umzug genau so, wie Du ihn auch im Sinne der Besucher machen würdest. Denn dann wirst Du wohl früher oder später auf die Frage stoßen, wie Du verhinderst, dass ein Teil der Besucher wegen der Verzögerung in der Aktualisierung der DNS-Information auf den alten Server zugreift, wohingegen der andere Teil schon auf den neuen zugreift. Denn wenn das mit einem Shop passiert, also dass ein Teil der Besucher noch auf Server 1, der Rest aber schon auf Server 2 bestellt – viel Spaß damit, die alten Bestellungen von Server 1 irgendwie von Hand in Server 2 reinzuquetschen!

HTTP – IPs statt sprechende Namen

Da sich ja nicht nur Profis diesen RSS-Feed gekrallt haben, hole ich sicherheitshalber etwas weiter als für manchen vielleicht nötig aus, aber um dieses Problem aus dem vorigen Absatz zu verstehen, muss man sich zuallererst einmal grundsätzlich wieder in Erinnerung rufen, dass der Browser ja nicht mit "www.seodiot.de" spricht, wenn er von dort eine Seite holen will. Stattdessen arbeitet er wie alle Tools des Internet mit IP-Adressen, verbirgt das aber schön vor uns dummen Benutzern. Und das "Übersetzungsprogramm", welche IP hinter welcher sprechenden Adresse wie eben www.seodiot.de steht, das ist das DNS (Domain Name System).

Wenn ich also "www.seodiot.de" in meine Adresszeile des Firefox eintippe und die Eingabetaste drücke, schickt der Browser eine Anfrage der Art "hallo DNS-System, gib mir doch bitte mal die IP-Adresse der Maschine, die für www.seodiot.de zuständig ist" raus und bekommt als Antwort "85.214.118.117". Also baut der Browser im Anschluss eine HTTP-Verbindung zur IP-Adresse 85.214.118.117 (noch genauer: zu Port 80 dieser Adresse) auf und schickt dorthin dann die Anfrage "hallo Maschine, gib mir bitte mal die Seite /index.html für den Host www.seodiot.de". Ab da ist es dann Sache des Webservers, mit dieser Anfrage was anzufangen und die richtige Datei auszuliefern etcetera…

DNS – Dut Net Sofort…

Die Details, wie DNS genau funktioniert, sind nun allerdings etwas komplizierter zu erklären. In meiner Zeit als Tech-Support für TCP/IP-Stacks musste ich sowas mehrmals im Monat predigen, aber das ist über 10 Jahre her, weshalb man mir verzeihe, dass ich das jetzt einfach überspringe und sage: wann immer etwas an einem DNS-Eintrag geändert wird, dauert es trotz aller Verbesserungen der Technik und Übertragungsgeschwindigkeiten auch heute noch bis zu drei, manchmal sogar vier Tage, bis die neue Information wirklich weltweit von jedem Computer gefunden wird. Bis dahin arbeitet dieser mit der alten Info.

Wenn nun also ein Serverwechsel stattfindet und der DNS auf eine neue IP-Adresse umgebogen wird, steht diese neue Information für eine gewisse Zeit noch nicht allen Maschinen im Internet zur Verfügung. Und deswegen kann es eben passieren, dass ein Besucher in Stadt X bereits die neue Info hat und deswegen den neuen Webserver besucht, wohingegen ein Besucher in Stadt Y noch die alte Info bekommt und deswegen noch auf dem alten Server landet.

Parallele Systeme

Und aus diesem Grund ist es zwar nicht nur, aber vor allem bei Shops wichtig, dass beide Systeme – alt und neu – für eine gewisse Zeit 100%ig synchron laufen. Und dass Bestellungen, die auf dem alten Server getätigt werden, auch auf dem neuen Server bekannt sind.

Wie man das nun am einfachsten erreicht? Ganz simpel: man bereitet den neuen Server so weit vor, versetzt den alten Server kurz in einen Wartungsmodus (damit keine neuen Bestellungen reinlaufen), kopiert schnell die Daten der alten Datenbank in die neue – und jetzt kommt der Trick: konfiguriert das alte System so, dass es auf die Datenbank auf dem neuen Server zugreift! Danach kann man den Wartungsmodus wieder beenden, kurz testen, ob alles so funktioniert, wie es soll – und dann erst sollte man den DNS verbiegen und erst nach etwa einer Woche den alten Server wirklich richtig abschalten.

Auf diese Weise ist es also während dieser DNS-Übergangsphase egal, ob ich nun auf den alten oder neuen Server zugreife – ich arbeite immer mit der Datenbank auf dem neuen Server. Les voila…

Mit dieser Vorgehensweise habe ich in meinem Leben über 10 mehr oder weniger kritische Websites umgezogen, wovon zwei sogar wirkliche High-Traffic-Shops waren, d.h. die Downtime musste minimalst sein. Und es gab niemals auch nur den kleinsten Fehler und die Downtime war maximal drei Minuten, da so ein SQL-Dump ja bei den dicken Verbindungen, die Server in den Rechenzentren üblicherweise untereinander haben, selbst bei großen Datenbanken flott von A nach B kopiert ist. Und notfalls kann man die zu übertragende Datei vorher sogar noch komprimieren. Bei meinen zwei wirklich kritischen Umzügen hatte ich vorab einfach ein entsprechendes Skript entwickelt und mehrmals getestet, so dass ich außer dem Aufruf des Skripts nicht mal mehr was selbst tippseln musste, was wiederum einiges an Zeit sparte…

Was kann passieren, wenn…?

Geht man anders vor, also kopiert man zum Beispiel einfach die Daten rüber, verbiegt den DNS und legt dann gleich den Schalter des alten Servers um – nun, da kann viel passieren. Als erstes werden es die Besucher merken. Oder zumindest ein Teil. Nämlich der Teil, der noch nicht die neuen DNS-Informationen hat. Die stehen dann nämlich vor einer Fehlermeldung des Webservers oder des Browsers.

Viel wichtiger ist aber, dass ja Google ebenfalls auf den DNS angewiesen ist. Wenn Dein alter Webserver also schon nichts mehr für die umgezogene Website ausliefert und der Googlebot kommt aber nochmal vorbei – tja, dann läuft er eben auf einen 404, 403 oder sonstwas. Und schon kann das natürlich entsprechende Auswirkungen auf Deine Platzierungen haben.

Andere Vorgehensweisen

Gibt es Alternativen zu dieser Vorgehensweise? Also sicher gibt es den einen oder anderen Sonderfall, abhängig von konkreten Umständen einer Website oder Server-Landschaft oder dergleichen. Aber prinzipiell wird es wohl immer darauf hinauslaufen: Server2 fertig machen, Server1 auf die Datenbank von Server2 umbiegen, DNS umbiegen, eine Woche warten, dann Server1 abschalten…

Oder habt Ihr andere Prozesse beim Serverumzug?

Das könnte Dich auch interessieren:

1. Der SEOdiot – jetzt mit MEHR POWER! Das würde zumindest Tim Taylor sagen. Diese Website wird jetzt nämlich von einem satten QuadCore-Prozessor angetrieben. Dieser werkelt in einem...
2. Google und Parameter-URLs – Resignation vor der Wirklichkeit Danke, Google. Als ich heute morgen die Twittersphere überflog, sprangen mir dutzende Meldungen entgegen, dass Du jetzt die Möglichkeit bietest,...
3. Endlich: Ladezeit einer Seite jetzt ein Ranking-Kriterium Diese Neuigkeit verbreitet sich ja gerade mit rasanter Geschwindigkeit durch alle einschlägigen SEO-Blogs: Google hat die Ladezeit einer Seite in...
4. Der SEOdiotische Wochenrückblick – KW 41/2009 Sodala. Der Umzug des Firmenbüros ist zwar mit den üblichen, kleinen Murphys, aber immerhin ohne größere Verluste vonstatten gegangen. Und...