Seit es Suchmaschinen wie Google, Yahoo und seit einiger Zeit auch Bing gibt, ist um den Mythos Pagerank in den vergangenen Jahren eine ganze Industrie gewachsen. So möchte natürlich jeder in den SERP’s ganz oben in den Top 10 stehen.

Ein weiterer Indikator ist der sogenannte Pagerank, auch genannt PR. Je höher der Pagerank (Pagerank-Skala 1-10) einer Seite ist, desto gewichtiger ist diese Seite für die Suchmaschine Google. Der Pagerank setzt sich u.  a. aus dem Pagerank anderer Seiten zusammen, die auf diese Seite zurück verlinken. Bekomme ich also einen Backlink von eine PR 5 Seite mit dem Atribut “follow” auf meine Seite, so wird meine Seite durch diesen Backlink aus Google-Sicht aufgewertet und könnte somit in den SERP’s weiter vorn gefunden werden. Soweit denke ich für viele nichts neues. Es gibt hierzu noch weitere Faktoren, so können Unterseiten einer Startseite einen anderen PR also Pagerank aufweisen, als die eigentliche Startseite. Dazu aber in einem evtl. weiteren Post später mal mehr.

In den vergangenen Perioden hat sich hinsichtlich Pagerank so einiges bei Google getan. Es scheint, dass der PR einer Seite nicht mehr allein der Gewichtungsfaktor einer Seite zu sein scheint. Ich habe in den vergangenen Wochen am eigenen Leib erfahren müssen, dass verschiedene Seiten trotz PR 3 und PR 4 in den SERP’s (Suchergebnissen) abgefallen sind.

Vielmehr schein es seit neuestem wichtig zu sein, dass eine Seite von einem Crawler schnell gescannt werden kann, dass der Content individuell ist und das die Seite weitgehend valide ist. Es sollten per W3C Validator nicht mehr wie 10 Fehler (…eigentlich schon 10 Fehler zu viel!) vorhanden sein, gleichwohl das früher auch schon so war. Optimal wären natürlich null Fehler. Bedeutet, je valider der Code ist, je schneller die Ladezeit einer Seite und um so schneller können die Crawler einer Suchmaschine Content scannen. Hierzu (Ladezeiten einer Seite) gibt es mehrere Möglichkeiten. Javascript komprimieren, aus dem Header bedingt entfernen und in den Footer verbannen, CSS komprimieren, bei statischem Content ein vernünftiges Cashing und noch einiges mehr. Weiterhin sollte auf das Umfeld einer Website geachtet werden. Sprich, bekomme ich Backlinks von Seiten, die u. a. guten Content liefern und bei Google beispielsweise nicht auf der Abschussliste stehen.

Fazit

Mein Erfahrungswert: wenn mir jemand erzählt, hey guggst Du, hier meine Seite hat beispielsweise einen PR 4, den werde ich belächeln. Denn PR  allein ist nicht mehr nur relevant für ein gutes Ranking in den SERP’s, eher ist es ein wenig Mythos und/oder eine Schwanzverlängerung.

Abschließend

Es gibt natürlich noch viele weitere Faktoren, die zu beachten sind, um in den Suchergebnissen einer Suchmaschine weit nach vorn zu kommen. Man findet im WWW genügend brauchbares und unbrauchbares Zeugs! Ich musste das aber mal loswerden, weil mir diese Aussage Pagerank oft genug vorgehalten wird. So…!

Seit kurzem ist nun das iPad von Apple raus und schon gehen die ersten Diskussionen los. Apple wird mit dem iPad und weiteren Apple-Produkten in Zukunft kein Adobe Flash mehr unterstützen. Könnte mir aber auch vorstellen, dass Steve Jobs sich da vielleicht etwas zu weit aus dem Fenster lehnt.

Das würde auch bedeuten, dass Adobe so einiges in Sachen Flash-CS4 Entwicklungen einstampfen muss. Mir persönlich ist es relativ egal. Wenn Flash nicht mehr die Zukunft sein sollte, dann lass ich eben die relevanten Applikationen im zukünftig kommenden HTML5 abbilden. Ein geniales Beispiel für die Unterstützung von Audio- und Video liefert hierfür die Seite Daylimotion. Zwar wird der neue offene Standard noch nicht von allen Browser zu 100% unterstützt, denke aber , dass es nicht mehr lange dauern wird.

Ein weiterer Vorsatz, den ich mir für 2010 vorgenommen habe ist der, dass von ich von Haus aus bei einer Entwicklung in Sachen HTML und CSS keine Rücksicht mehr auf den Browser IE6 nehmen werde. Es sei denn, ein zahlender Kunde möchte den IE6 berücksichtigt haben. Meine VM , die bisher für IE6-Tests ihren Dienst verrichtet hat, habe ich schon mal ganz provokativ gelöscht – Basta!

Heute bin ich nach längerer Zeit mal wieder an die Elbe zum fotografieren losgefahren. Eines vorweg, es war a**** kalt! Nicht das mein Nikon Equipment schlappgemacht hat, nein eher der Typ hinter der Kamera. Trotz Handschuhe und Wellensteyn-Jacke war es nach ca. 30 Minuten einfach zu kalt, zumindest an den Beinen und an den Fingerkuppen.

Deshalb meine Empfehlung: Ab -6.0°C sollte eine lange Unterhose (Liebestöter ), spezielle Fotohandschuhe und Mütze vorhanden sein. Wenn dann noch ein kalter Wind geht, sollte man am besten gleich zu Hause bleiben. Es war mir eine Lehre.

Generell ist hierzu eines zu sagen, ruhig bleiben und zu erst analysieren. Die gestrige DoS Attacke kam, wenn man den IP- Adressen Glauben schenken darf, aus dem asiatischen Raum, eine derzeit typische IP-Range für solche Späßchen.

Für solche Denial of Service Attacken gibt es, um die Kuh kurzfristig vom Eis zu bekommen, eine quick and dirty Lösung. In einigen Fällen kann man via “tracert” Befehl die IP-Adressen zurückverfolgen und notieren. Danach schnappt man sich die .htaccess aus dem relevanten Verzeichnis, auf welches der Angriff erfolgt ist und sperrt die notierten IP-Adressen einfach aus. Ich nehme deshalb die .htaccess, weil sie recht wirkungsvoll ist und dazu auch relativ schnell durchzuführen ist.

Das könnte dann so aussehen:

order allow,deny
deny from xxx.xxx.xxx.xxx
deny from xxx.xxx.xxx.xxx
allow from all

Die “xxx.xxx.xxx.xxx” stehen hierbei für die IP-Adressen, die geblockt werden sollen.

Vorsicht ist geboten

Bevor man die quick and dirty Lösung anwendet, sollte noch überprüft werden, ob nicht eine der IP-Adressen evtl. ein Google-Bot sein könnte, den würde ich nicht aussperren.

Nachteil

Der Nachteil an dieser Lösung liegt natürlich klar auf der Hand. Bei sehr vielen IP-Adressen ist sehr viel Schreibarbeit angesagt. Ein weiterer Nachteil bei dieser Abwehrmethode gegen eine DoS-Attacke sind evtl. vom Angreifern und “Scripter-Schweinen” gefälschte IP-Adressen im Kopf der IP-Pakete. Wenn Ihr diese dann in Eure .htaccess eintragt, nützt es reichlich wenig, weil es nicht die echte IP-Adresse ist.

Fazit

Diese Lösung ist kein “Allerheilmittel” und wirklich nur eine Notlösung zur schnellen Reaktion. Für eine mittelfristige Vorsorge sollte grundsätzlich ein Gespräch mit dem Provider durchgeführt werden. Wer einen eigenen Root-Server besitzt, der sollte schon ein wenig Grundwissen mitbringen, um solchen DoS Angriffen entgegenwirken zu können.

Für mich ein Fall von typischer Datenvorratsspeicherung. ELENA oder auch “Elektronischer Entgelt-nachweis” läuft aktuell jetzt im Januar 2010 an und Erfasst bundesweit alle Arbeitnehmerdaten. Die erfassten Daten beinhalten unter anderem Informationen wie Krankheitstage, Streiktage Abmahnungen und noch vieles mehr!

Dieses Szenario liebe Frau Merkel, ist für mich ein Eingriff in die Intim- und Privatsphäre und das geht ja mal garnicht! Auch wenn die Daten verschlüsselt an einen Zentralrechner übergeben werden und nur mit einem zweiten Key angefordert und wieder entschlüsselt werden können, so liegen u. a. Daten und Informationen über meine Person für Behörden mehr oder weniger frei verfügbar zum Abruf bereit. Was für eine Scheiße nimmt sich unsere Bundesregierung eigentlich noch alles heraus, sorry aber dass regt mich mal so richtig auf.

Die Zielsetzung dieses Verfahrens ist für mich in vielen Abschnitten nicht nachvollziebar. Innovation im Bürokratieabbau und Kostenentlastung der Unternehmen wird als Argumentation vorgeschoben. Ich kann nur lachen. Was kostet denn den Steuerzahler ein Aufbau so einer  IT-Infrastrucktur und so eines Storagesystems. Von den monatlichen Betriebskosten so eines Rechenzentrums mal ganz zu schweigen.

ELENA ist für mich ein weiterer Grund mich noch intensiver mit dem Auswanderungsgedanken zu beschäftigen, armes Deutschland!