Posts Tagged ‘deutsch’

Zwischenzertifikat für’s Zwischenzertifikat

Auf die hier angesprochenen Probleme mit dem 1&1 SSL-Zertifikat, die sich durch die nicht angekündigte Umstellung auf eine Lösung mit Zwischenzertifikat ergeben, ist man mittlerweile auch bei Geotrust aufmerksam geworden.

Und man löst das ganze über eine weiteres Zwischenzertifikat. Das heißt, man hat jetzt zum gleichen Preis wie vorher kein Rootzertifikat mehr und auch kein Zertifikat, dessen Stammzertifikat ein Root-Zertifikat ist (was sich mit dem ‘falschen’ Zwischenzertifikat von Geotrust ja mit einem gewissen Bastelaufwand bewerkstelligen ließ), sondern einen bis in die vierte Ebene verschachtelten Zertifikatsbaum.

Als die Welt noch in Ordnung war: Zertifikat ohne Zwischenzertifikat


Funktionierende Selbstbaulösung mit einem Zwischenzertifikat


Das neueste aus dem Hause Geotrust: Zwei Zwischenzertifikate

Nur damit wir uns nicht falsch verstehen: Dadurch wird nichts unsicherer. Und zumindest als 1&1-Kunde hat man bislang für das Zertifikat ja auch nichts bezahlt, aber es bleibt trotzdem ein fader Beigeschmack bei dem Ganzen.

Der schleichende Niedergang…

…des 1&1-SSL-Zertifikats.

1&1 bietet seit Jahren zu seinen Server-Produkten ein SSL-Zertifikat kostenlos mit an.

Dabei handelte es sich die letzten Jahre, und ich habe seit mindestens fünf ein solches im Einsatz, um ein vollwertiges Zertifikat, d.h., es war als Rootzertifikat ausgestellt und ist somit ohne irgendwelche Zwischenzertifikate nutzbar. Da ist es dann auch nicht weiter wild, dass man es jedes Jahr erneuern muss. Das Zertifikat wird über Plesk verwaltet, bislang reichte es einfach aus, das neue per Copy&Paste in der Zertifikatsverwaltung einzupflegen und den Apache neu zu starten.

Seit diesem Jahr geht das nicht mehr. Denn seit diesem Jahr stellt Geotrust, die der eigentliche Leistungserbringer sind, das Zertifikat mit Zwischenzertifikat aus und als Nutzer erfährt man davon erst, wenn man das Zertifikat eingefügt hat und die Seite aufruft, um zu prüfen, ob alles in Ordnung ist. Denn dann wird man von einem hübschen Zertifikatsfehler begrüßt, der je nach Browser mehr oder weniger furchteinflößend daherkommt.

Eine kurze Information seitens 1&1, dass sich am Zertifikat und seiner Installation etwas geändert hat, wäre als wirklich nicht zu viel verlangt. Denn die Installation ist, anders als es die Anleitung bei Geotrust vermuten lässt, nicht ganz so einfach. Geht man nämlich gemäß Anleitung vor und lädt die Zertifikate getrennt hoch quittiert Plesk das mit einer Meldung, dass das Zwischenzertifikat nicht zum eigentlichen Zertifikat passen würde. Abhilfe schaffte im konkreten Fall bei Plesk 8, beide Zertifikate in der eigentlich nur für das Zertifikat vorgesehenen Box gleichzeitig hochzuladen – BEGIN/END-Zeilen dabei nicht vergessen. Ob es sich dabei um einen Fehler in der Anleitung von Geotrust handelt oder es an der zugegebenermaßen antiquierten Plesk-8-Version liegt, darüber kann man nur spekulieren.

Der 1&1-Support konnte im Übrigen nicht wirklich weiterhelfen. Aber das ist eine andere Geschichte…

Google vs. Phark: Das Problem ist text-indent

Es geht um eine Startseite und die Startseite rankt nicht. Nicht mal für den Brandnamen. Gerade mal für die URL. Oder anders ausgedrückt: Im Index ist sie drin. Zahlreiche SEOs haben sich die Seite angesehen, ein bisschen im Nebel gestochert und das ein oder andere Bröckchen zu Tage gefördert. Insgesamt war nichts verwertbares dabei. Das bisherige Highlight kam dann aber gestern:

Das Problem ist text-indent

Sorry, nein. Das Problem ist nicht text-indent!

Aber machen wir mal einen kleinen Ausflug in die Vergangenheit. Damals, als das Netz noch jung war und die Suchmaschinen dumm konnte man sie problemlos übertölpeln (was nicht heißt, dass das heute nicht mehr möglich wäre). Weißer Text auf weißem Grund, sieht die Suchmaschine ja nicht, wenn sie sich nur den Quelltext ansieht. Entsprechend ist das schnell auf der Liste spammiger Techniken gelandet, hat Einzug gefunden in die Google Richtlinien und in den Spambericht.

Zurück in die Gegenwart. Das Netz steht nicht still, immer wieder gilt es, Probleme zu lösen, die sich auch und vor allem um das Thema Schriften drehen. @font-face steckt noch in den Kinderschuhen. Auf frænkisch.de nutze ich es für Überschriften, damit auch dem kompletten Fließtext eine Schriftart abseits der Masse zu geben wie es Gerrit van Aaken auf praegnanz.de macht ist dabei schon die Ausnahme von der Ausnahme. Und nicht immer ist @font-face die Lösung, weil es beispielsweise die Lizenz der gewünschten Schriftart nicht hergibt.

Schon lange üblich ist hingegen, dass man die gewünschte Schrift einfach als Bild platziert. Eine Methode, die Google auch heute noch propagiert. Will man aber Markup und Darstellung konsequent trennen, auch im Zuge von Zugänglichkeit und Barrierearmut, ist es wünschenswert, dass sich im Quelltext eben keine Bilder finden, die aus rein visuellen Gründen dort platziert sind. Vielmehr sollte Struktur und Semantik des Dokuments erhalten bleiben, ohne auf die Vorteile, die Bilder im Hinblick auf ausgefallene Schriften bieten, verzichten zu müssen.
Wegen der Einfachheit in der Implementierung beliebt ist hier vor allem die sog. Phark-Methode. Und diese bedient sich eben text-indent mit einem hohen negativen margin, um den eigentlichen Text aus dem sichtbaren Bereich zu schieben. Empfohlen wird die Methode im übrigen unter anderem von Jens Meiert, seines Zeichens Webmaster. Bei Google.

Jetzt kann man natürlich orakeln, warum Google nach wie vor ein Vorgehen vorschlägt, dass seit mehreren Jahren technisch überholt ist. Vermutlich, weil sie nicht in der Lage sind, bei text-indent zuverlässig zu erkennen, ob es sich wirklich nur um eine optische Geschichte handelt oder der mit Keywords vollgestopfte <h1>-Tag aus dem Blickfeld des Betrachters, aber nicht des Googlebots, eliminiert werden soll.

Denn damit Google erkennen kann, dass Text mittels CSS (und vielleicht Javascript, welches diverse Elemente noch nachträglich modifiziert) ausgeblendet wird, müsste es weit mehr tun als nur Quelltexte indizieren. Es müsste prinzipiell die Seite komplett parsen, um dann erkennen zu können, ob bestimmter Text noch sichtbar ist oder nicht. Und ob der Text, der auf dem Bild steht, nicht vielleicht doch identisch ist mit dem im <h2>-Tag. Selbst bei der Rechenleistung, die Google zur Verfügung steht, eine unrealistische Annahme. Auch liest Google bei einem Besuch weder die CSS- noch die Javascript-Dateien. Und selbst wenn könnte man ihm die über die robots.txt, an die Google sich ja nach eigener Aussage hält, vorenthalten.

Die fragliche Seite hat im CSS 24 mal text-indent mit hohem negativen margin. 24 mal, um mittels Phark-Methode eine Überschrift oder einen Navigationspunkt durch ein Bild zu ersetzen. Sicherlich kann man das etwas eindampfen. Aber sollte das wirklich das Problem sein, dann wirft es neue Fragen auf:
Warum trifft es nur die Startseite, aber keine Unterseiten, obwohl beide das gleiche CSS verwenden?
Warum rankt die englische Startseite prima, die deutsche aber gar nicht, obwohl beide das gleiche CSS verwenden?

Wer sich auch mal an der Beantwortung dieser Fragen versuchen will, ein paar Invite-Codes hab ich noch. E-Mail genügt.

Der SEO CAMPIXX’ zweiter Streich

Wenn man am Vortag die Ehre hatte, den Chauffeur zu spielen, ist es relativ einfach, am nächsten Tag fit und ausgeschlafen auf der Matte zu stehen. OK, Pingdom hat mich gegen zwei mal geweckt, aber sonst war die Nacht ruhig, bis im Hotel die große Unruhe ausbrach, was aufgrund der Hellhörigkeit des Hauses auch an mir nicht spurlos vorbeiging. Ich will aber nicht schon wieder nörgeln, man sagt mir eh nach, ich wäre viel zu negativ.

Erste Session des Tages: Thomas Zeithaml zu interner Verlinkung. Ein abendfüllendes Thema. Locker-knackig in 50 Minuten untergebracht. Und was ich allein in dieser kurzen Zeit an Problemen und Problemchen ausgemacht habe – da kommt Arbeit auf mich zu.

Bei Sasa Ebach ging es im Anschluß darum, ein fiktivies Projekt mit 1 Milliarde Euro (das ist so eine Zahl mit neun Nullen hintendran) in einem stark umkämpften Bereich, im konkreten Fall Auto, nach oben zu bringen. Ebach ging es dabei primär um den Linkaufbau und um die Mittel und Wege, Links organisch zu bekommen. Nichts, was ich machen möchte, aber auch nichts, was augenscheinlich unmöglich ist. Selbst in hart umkämpften Umfeldern nicht.

Nach der Mittagspause war ich dann im proppenvollen Raum bei SEO technisch mit Markus Orlinski. Der Vortrag ist mittlerweile online. Im Großen und Ganzen war es ein Rundumschlag über die ganzen Themen, denen man unter technischen Gesichtspunkten Aufmerksamkeit schenken muss: Crawlability, Performance, Internationalisierung. Markus schien mir etwas aufgeregt, ansonsten habe ich aus dem Vortrag viel hilfreiches mitgenommen – vor allem im Hinblick auf internationale Projekte. Wenn’s auch jetzt nicht unbedingt japanische sind.

Ein anderer Marcus war dahingegen cool wie immer. Marcus Tandler, besser bekannt als Mediadonis, zog mal wieder eine perfekte Show ab. Ich schau ihm wirklich gerne zu. Er ist ein großartiger Entertainer. Und er hat ein Branding für seine Person, da könnte sich manche Firma eine dicke Scheibe abschneiden. Genug geschleimt. Ist ehrlich gemeint. Und außerdem war Blog-/Twitter-/Fotografierverbot.

Das letzte Panel haben wir sausen lassen. Eine gute Entscheidung. Denn schon als wir losgefahren sind ist in Berlin noch einmal der Winter ausgebrochen. Und das muss ziemlich heftig gewesen sein:

Chaos am Flughafen Tegel – zwar mittlerweile im Flieger, aber laut Pilot geht’s erst in 2 Stunden los… Das is ma doof.. #DoofesSchneechaos

Marcus Tandler um 18:37

Ja, ich hoff jetzt auch mal auf bessere Verhältnisse, wage mich jetzt mal aus dem Autbahn-Restaurant wieder auf die A10 #campixx #Seocampixx

SeoSocke um 19:35

Ich hoffe ihr seit mittlerweile alle gut zu Hause angekommen.

Pro’s und Con’s

T-Shirts

Super Idee. Man muss nicht zwanghaft versuchen, einen Blick auf den Teilnehmerausweis zu erhaschen, um zu wissen, wer der (respektive die, Frauenquote war relativ hoch) andere ist. Den Namen auf der Brust vorne nochmal zu wiederholen wäre dabei aber auch hilfreich. Bei der Anmeldung hätte aber klar sein sollen, was da als ‘Name’ aufgedruckt wird. Dann hätte ich nämlich sicher nicht ‘matt’ angegeben, sondern msslovi0. Und es sollten wirklich alle das T-Shirt anziehen. Sonst bringt das irgendwie nichts.

Essen

Schnell auf Kritik reagiert, Hut ab. Und das, obwohl ich sie in meiner bekannt überheblichen Art und Weise geäußert habe. Vielleicht war ich aber auch gar nicht der Auslöser. Es würde mir aber auch nichts ausmachen, wenn man mich weiterhin in dem Glauben lässt, es gewesen zu sein. Das Abendessen am Grillhähnchenstand war super. Genau das richtige. Schnell was auf die Hand, schnell satt. Zum Mittagessen eher ausgefallenere Sachen der griechischen und italienischen Küche zu kredenzen fand ich dann doch etwas übertrieben. Da hätten es ein paar Schnitzel oder Steaks auch getan.

Socialising

Wenn du keinen kennst, dann kennst du nach der Veranstaltung nur wenige mehr. Der Netzwerkgedanke kommt meiner Meinung nach zu kurz. Wer sich eh kennt steht in Grüppchen zusammen und es ist schwer für den Außenstehenden, da ‘einzudringen’. Man will ja auch nicht den Elefanten im Porzellanladen spielen. Vielleicht sollte ich mit dem Rauchen anfangen. Für die scheint das leichter zu sein. Aber es ist nicht so, dass wir gar keine neuen Kontakte geknüpft hätten.

Technik

Das muss ich noch grad mal loswerden: Die (gefühlte) iPhone-Quote lag bei 90%. Ich bin mir noch nicht sicher, ob ich das toll finde oder ob es mir Angst macht. Da so ein Tag ziemlich akkumordend ist, wäre es gut, wenn man in den einzelnen Räumen leicht zugängliche Steckdosen hätte, quasi Ladestationen. Vielleicht könnte man sogar einen Hersteller wie Powermat dazu bringen, die Veranstaltung entsprechend auszurüsten.

Sessionbenennung

Wenn ich gewusst hätte, dass es bei „Pimp my Feed” um Google Base Tuning geht, dann wäre ich da wohl auch hin, anstatt mich in der xt:Commerce-Session zu langweilen. Das soll nämlich sehr interessant gewesen sein. Leider war da Blogverbot, somit ist auch im Nachhinein nichts darüber zu erfahren. Schade.

Veranstaltung allgemein

Insgesamt super. Also rundum. Perfekte Organisation von Marco Janck und seinem Team.
Ein Hotel im letzten Zipfel von Berlin, damit da auch keiner wegrennt. Macht halt auch das hinrennen etwas schwierig, aber man kann nicht alles haben.
Problematischer finde ich, dass die ganzen SEO-Veranstaltungen sehr auf Norddeutschland konzentriert scheinen, sei es die SEMSEO in Hannover oder die SEO CAMPIXX in Berlin. Irgendwer sollte mal im Rhein-Main-Gebiet die Initiative ergreifen.

Trotz oder gerade wegen aller Kleinigkeiten, und mehr ist das, was ich da oben zu kritisieren habe, nicht:

Schlussfazit

Rundum zufrieden.

SEO CAMPIXX 2K10, der erste Tag

Einmal rum um den Müggelsee erfreue ich mich nach einem harten ersten Tag auf der SEO CAMPIXX am mießen WLAN hier im Hotel in Friedrichshagen, während vor Ort sicherlich United Four gerade erst so richtig die Kuh fliegen lassen.

Die SEO CAMPIXX ist ja nach der SEMSEO letztes Jahr erst meine zweite Veranstaltung dieser Art. Immerhin kenne ich jetzt schon ein paar Gesichter. Nicht, dass wir uns gegenseitig Schwänke aus unserer Jugend erzählen würden, aber ich kann zumindest einen von 1000 Chinesen umgebenenen Thomas Promny ziemlich sicher erkennen.

Genial, wie ich nunmal bin, habe ich mich beim Blick in den Plan gleich mal vertan und wir sind heute erst zum Beginn der einzelnen Sessions eingelaufen. Den Vorspann kann man aber bei jog nachlesen.
Los ging’s also mit den Rankingfaktoren unter der Leitung von Stefan Fischerländer. Nichts essentiell wichtiges mitgenommen, aber ein unterhaltsamer Plausch anerkannter Größen des Business, den ich dann zur Halbzeit für das „Gruppengespräch SEO für XT Commerce” mit Rafael Prukop verlassen habe. Böser Fehler. Ich habe ja eigentlich gedacht, die Scorer-Fortbildung von vor ein paar Wochen lässt sich nicht mehr toppen, was Zeitverschwendung durch Arschlplattsitzen angeht, aber weit gefehlt. Angeblich betreut Prukop 160 Shops. Ich hab nur sechs. Aber wahrscheinlich auch das sechsfache Wissen um diesen Shop und dessen Schwachstellen. Deshalb ist das Gespräch auch ziemlich spontan in alles mögliche abgedriftet und wurde auch vom „Moderator” zu keinem Zeitpunkt auf die richtige Bahn zurückgebracht. Das einzige verwertbare aus dieser Session kam dann auch nicht von Prukop, sondern von Marco Verch von Trusted Shops im Zusammenhang mit Google Analytics.

In der Session von Andi Petzold zum Thema Rankingkriterium Onlinebewertung ging es primär um Hotelbewertungen. Naja, ist ja ein Feld, in dem ich auch mal gekämpft habe. Und es hat interessante Einblicke dahingehend eröffnet, was in den nächsten Jahren wohl noch auf andere Branchen zukommen wird.

Weiter ging’s mit Duplicate Content mit Johannes Marquart. Interessante Einblicke. So indiziert Google beispielsweise URLs mit dem GET-Parameter gclid (das kommt aus Googles Adwords-Programm) und erkennt das als internen DC, sprich Google entscheidet, welche der mehreren Seiten letztendlich angezeigt werden und welche nur über diesen ‘Ähnliche Seiten’-Link erreichbar sind. Ja ganz großes Kino. Die ach so hoch intelligente Suchmaschine ist zu blöd, ihren eigenen Dreck aus dem Index rauszuhalten (für Google Analytics Parameter gilt beispielsweise das selbe). Eigentlich müsste man nach Mountain View fahren und jemand fragen ob er noch alle auf der Rolle hat. Kostet aber mehr als ein paar Meta-Tags passend zu setzen, daher gleich mal aufgeräumt.

Letzer Punkt an diesem Tag: Florian Stelzner mit der Frage, ob Pagespeed ein Rankingkriterium ist. Insgesamt sehr unterhaltsam vorgetragen, im großen und ganzen für mich aber nichts neues dabei. Nur: 10 Minuten Cache-Zeit für HTML-Seiten halte ich bei dynamischen Seiten für unbrauchbar. Das darf gar nicht gecached werden, sonst sieht man beispielsweise Veränderungen im Warenkorb nicht. Das lausige WLAN hier zeigt mir außerdem, wie weit ich mit der Optimierung schon vorangeschritten bin.

Und nachdem so langsam das Brennen der einen Chili-Nuss, die ich gegessen habe, wieder nachlässt, kann getrost Tag zwei kommen (vielleicht erkenne ich jog ja dann, wenn er schon die Veranstaltungen mit mir teilt). Den Teilnehmern am Chilicontest gilt derweil mein ehrlicher Respekt – und mein Mitgefühl.

Jeder darf mal: .htaccess-Bullshit

Geschwindigkeit ist ja der neue Backlink und jeder meint, da seinen Senf dazugeben zu müssen. Und egal wie blödsinnig die Umsetzung ist, es wird sich immer wer finden, der’s geil findet.

Zwei Sachen dazu:
Das hat im .htaccess nichts verloren. Über Performance schreiben und dann das .htaccess-File zumüllen ist wie bei 280 auf der linken Spur über den hohen Benzinpreis jammern. Wer Zugriff auf seine Apache-Konfiguration hat sollte das dort unterbringen. Immer.
Hartkodierte Datumsangaben, die, vom heutigen Standpunkt aus, weit in der Zukunft liegen, sind eine ganz schlechte Idee. Ist ja nicht so, dass wir das nicht erst hatten. mod_expires bringt da ein viel einfacheres Mittel, um genau das Problem zu vermeiden.

Finger raus aus der Keksdose!

Eine sehr einfache Methode, Bandbreite zu sparen und Daten schneller auszuliefern ist, sie ohne Cookies zu senden.

Google sagt:

Serve static content from a cookieless domain

Liegen dynamische Daten und Bilder, Stylesheets und Javascript-Dateien auf der gleichen Domain sendet der Browser bei jeder Anfrage die Cookies, die er für diese Domain gespeichert hat, mit. Was absolut unnötig ist, denn die wichtigste Eigenschaft von statischem Content ist, dass er genau das ist: Statisch.

Also raus mit den Cookies. Einfachste Lösung: Eine Subdomain anlegen, z.B. static.domain.de, als ServerAlias in der Apache-Konfiguration hinzufügen und alle Bilder, Javascripts und Stylesheets über diese URL adressieren. Alternativ kann man es machen wie Google und das über eine eigene Domain steuern. Oder gleich über ein CDN. Dazu aber später mal mehr.

ga.js aktuell halten

Es gibt ja für jede Lösung ein Problem, so natürlich auch für mögliche Änderungen an ga.js, wenn man die Datei, um sie gzip-komprimiert auszuliefern, selber hosten will.

Ein bisschen Shell-Scripting sorgt dafür, dass die Datei von Google geladen und an die richtige Stelle kopiert wird:

#!/bin/sh
# TMP DIRECTORY
MYTMP=/tmp
# SAVE ga.js HERE
INSTALL_IN=/htdocs/domain.de/javascript/
# RESOURCE URL
GOOGLE_GA_URL=http://www.google-analytics.com/ga.js
# USER-AGENT
UA="Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3"
# CD TO TMP DIRECTORY
cd $MYTMP
# DOWNLOAD THE FILE
curl --header "Pragma:" -f -s -A "${UA}" -m 1800 --retry 15 --retry-delay 15 --max-redirs 8 -O $GOOGLE_GA_URL
# GIVE FILE CORRECT PERMISSIONS
chmod 644 $MYTMP/ga.js
# COPY FILE TO SITE DIRECTORY
cp -r $MYTMP/ga.js $INSTALL_IN
# RETURN TO OLDPWD
cd $OLDPWD
exit 0;

Als Cronjob ausgeführt wird damit ab sofort regelmäßig die aktuelle Version der ga.js von Google geholt.

Hält man sich darüber hinaus an die Empfehlung von Google und versieht seine statischen Dateien mit weit in der Zukunft liegenden Expire-Headern sollte man bei der Gelegenheit dann auch gleich sicherstellen, dass die Datei einen deutlich niedrigeren Expire-Header bekommt, sonst kann man sich die ganze Aktion auch gleich sparen:

<Files ga.js>
ExpiresByType application/javascript "access plus 1 week"
</Files>

Google vs. Google: ga.js gzip-komprimieren

Geschwindigkeit ist der neue heiße Scheiß. Google trommelt ganz vorne mit, klar, für die ist (Rechen-)zeit bares Geld. Das Firebug-Plugin Pagespeed gibt es schon länger, unter Let’s make the web faster hat der Suchmaschinenriese zahlreiche Informationen an zentraler Stelle gesammelt und seit kurzem hat auch eine Site Performance Auswertung Einzug in die Webmastertools gehalten.

Darin finden sich dann auch so interessante Sachen:
Google Site Performance bemängelt Google Analytics

Wirklich eine klasse Idee. Sollte Google vielleicht jemandem bei Google mal sagen.

Natürlich kann man die Datei auch selbst hosten.

Vorteile:

  • Man spart sich einen DNS-Lookup für www.google-analytics.com
  • Man kann die Datei komprimiert ausliefern
  • Eine Nichterreichbarkeit von www.google-analytics.com blockiert nicht den Ladevorgang

Auf der anderen Seite steht dem natürlich entgegen:

  • Der User hat, aufgrund der hohen Verbreitung von Google Analytics, die Datei möglicherweise schon im Cache
  • Ändert Google etwas an ga.js liefert man nach wie vor eine veraltete Datei aus.

Am Ende muss also jeder selbst entscheiden, ob sich für ihn das Einsparpotential durch die Komprimierung rechnet.

Umziehen Part 3: Mit mod_proxy von Server zu Server

In Teil 1 und 2 haben wir uns damit beschäftigt, wie man Browser und Suchmaschinen den Weg zu einer neuen Ressource weißt, wenn sich deren URL geändert hat. In diesem Teil geht es um den einfachen Umzug auf einen neuen Server.

Im Folgenden geht es ausschließlich um den Umzug eines Webauftritts von einem Server auf einen anderen. Prinzipiell ist das ganze auch bei Shared Hosting möglich, gewisse Dinge wie der Zugriff auf die hosts-Datei sind dabei aber unter Umständen nicht möglich. mod_proxy sollte installiert und aktiviert sein. Der Zugriff auf die DNS-Konfiguration ist Bedingung.

Mit steigenden Zugriffszahlen wachsen auch die Anforderungen an die Hardware. Gerade wenn in Spitzenzeiten die Antwortzeiten in den Keller gehen ist es Zeit, sich Gedanken über einen Serverumzug zu machen. Oder dieser Schritt steht turnusmäßig sowieso an, weil die aktuelle Hardware veraltet ist. Doch wie die Besucher problemlos auf die neue Maschine migrieren, wie verhindern, dass Zugriffe auf die alte und die neue Maschine zeitgleich stattfinden? Schließlich ist das DNS-System zwar robust, aber mitunter nicht sonderlich schnell.

Wir möchten also unseren aktuellen Webauftritt unter www.domain.de, der auf dem Server mit der IP 8.8.4.4 liegt, auf einen neuen Server mit der IP 8.8.8.8 umziehen.

Der erste Schritt ist das ‘Anlegen’ einer Subdomain im lokalen hosts-File am Arbeitsrechner. Diese findet sich auf unixoiden Betriebssystemen in /etc/hosts, unter Windows in C:WINDOWSsystem32driversetchosts und kann mit jedem beliebigen Texteditor bearbeitet werden. Dort fügen wir einen neuen Eintrag hinzu:

8.8.8.8     new.domain.de

Dieses Vorgehen hat gegenüber einem richtigen DNS-Eintrag den Vorteil, dass new.domain.de nur vom Arbeitsrechner aus erreichbar ist und man so auf gesonderte Sicherungsmaßnahmen am neuen Server verzichten kann, wie sie sonst nötig wären, um eine vorzeitige Indizierung der Inhalte durch Google zu verhindern. Hat man keinen Zugriff auf die hosts-Datei am alten Server muss dieser Eintrag unbedingt über das DNS-System erfolgen und sollte mit entsprechendem Vorlauf (mind. 48 Stunden) gemacht werden!

Auf dem neuen Server richtet man nun new.domain.de ein und transferiert den aktuellen Webauftritt vollständig auf die neue Maschine, kopiert also sowohl Dateien als auch Datenbankinhalte auf den neuen Server und passt, sofern erforderlich, die Konfigurationsdateien an. Anschließend testet man alles auf Herz und Nieren.

Das Logfile zu Hilfe nehmend, um den idealen Transferzeitpunkt zu ermitteln, geht es dann an den eigentlichen Umzug. Zunächst muss verhindert werden, dass der alte Auftritt weiterhin genutzt werden kann. Die .htaccess auf dem alten Server wird daher durch die folgende ersetzt:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !.*storedown.*$
RewriteRule .* /storedown.php [L]

storedown.php sollte nicht nur kurz darüber informieren, dass hier gerade ein Umzug im Gange ist, sondern auch einen 503-Header senden, damit auch Google Bescheid weiß:

<?php
header("HTTP/1.1 503 Service Temporarily Unavailable");
header("Status: 503 Service Temporarily Unavailable");
header("Retry-After: 360");
header("Connection: Close");
?>
<!DOCTYPE HTML>
<html lang="en-US">
<head>
	<title>503 Service Temporarily Unavailable</title>
	<meta charset="UTF-8">
</head>
<body>
	<h1>Service Temporarily Unavailable</h1>
	<p>The server is temporarily unable due to maintenance downtime. Please try again later.</p>
</body>
</html>

Der Retry-After-Header sollte einen realistischen Wert in Sekunden enthalten, bis wann der Umzug abgeschlossen sein wird.

Ein letzter Sync zwischen altem und neuen Server stellt sicher, dass auf der neuen Maschine auch der letzte Stand verfügbar sein wird. Der neue Server wird jetzt auf die eigentliche Domain www.domain.de konfiguriert und /etc/hosts auf dem alten Server um folgenden Eintrag ergänzt:

8.8.8.8     www.domain.de

.
Jetzt nur noch die .htaccess auf dem alten Server ersetzen:

RewriteEngine On
RewriteRule ^(.*) http://www.domain.de/$1 [P]

Ohne Zugriff auf die hosts-Datei am alten Server muss mod_proxy angewiesen werden, auf die zuvor eingerichtete Subdomain new.domain.de zuzugreifen:

RewriteEngine On
RewriteRule ^(.*) http://new.domain.de/$1 [P]

Jetzt kann die DNS-Änderung für www.domain.de beantragt werden. Alle Anfragen, die bis dahin noch auf dem alten Server 8.8.4.4 eintreffen, werden mittels mod_proxy und Dank dem Eintrag in der hosts-Datei an den neuen Server weitergereicht – für den Besucher vollkommen transparent.