SEO Book » Javascript

Die SEO-Woche: senile Bettflucht, maritime Untiefen und ein langweiliger Linkbait

Eric Kubitz — Fri, 04 Nov 2011 08:01:53 +0000

Was bin ich vorhin erschrocken! Freitag isses und ich habe noch nicht einmal über den Wochenrückblick nachgedacht. Zum Glück leide ich unter seniler Bettflucht und war früh genug am Schreibtisch, um zu einer noch halbwegs verlinkungsfreundlichen Zeit meinen Google Reader leer und diesen Beitrag voll zu räumen.

Google liefert uns – so jedenfalls Amit Singhal, “Google Fellow” – nun noch frischere und aktuellere Ergebnisse. Jedenfalls immer dann, wenn man sie möchte. Also, besser gesagt, wenn Google davon ausgeht, das “man” sie möchte. Mhhh. Also das ist toll – lässt mich aber wieder über meine informationelle Selbstbestimmung nachdenken. Als älterer Mensch trauere ich immer noch solch überkommenen Konzepten wie “Wahlfreiheit” und so nach…
Goolge liefert uns – so jedenfalls Pawel Aleskander Fedorynski und Maile Ohye – nun noch mehr Javascript- und AJAX-Inhalte. Jedenfalls dann, wenn sie richtig dargestellt werden. Also das ist toll. Punkt.
Heise hat hat dazu auch eine Meinung und betont, dass Google “SEO-Experten” trotzdem abrät, relevante Inhalte hinter erforderlichen Nutzeraktionen zu verstecken.”)
Schön, wenn man sich verlassen kann. Zum Beispiel darauf, dass es massenhaft ReCaps vom SEO Day in Köln gibt. Noch schöner, wenn einer diese dann am Ende zusammenfasst. Danke Marcus Tandler!
Ihr müsst sie euch nicht durchlesen, die Grafik mit dem SEO-Periodensystem von Searchengineland. Ist m.E. nicht besonders inhaltsschwer. Aber schaut euch an, wie großartig die US-Kollegen das auf ihrer Seite dargestellt und zur Einbindung angegeboten haben. Ich finde zwar, hübsche Grafiken sind eine der etwas lahmereren Formen eines Linkbaits. Aber keine Frage: wenn das so gemacht wird, lohnt es sich. Schaut euch mal an, wie viele Shares und Tweets es dafür gab – von Backlinks gar nicht zu reden.
Dr. Pete schreibt uns auf SEOmoz, was die Gründe sein können, warum toller Inhalt nicht funktioniert.
So ‘ne Mail habe ich noch nicht bekommen – das heißt dann wohl, dass keiner meiner Beiträge kopiert… Und zwar berichtet Markus Hövener davon, dass Google bei Duplicate Content nun auch Mails verschickt bzw. verschicken will. Hier der Googler-Beitrag dazu.
Und wie findet Google die “kanonische Quelle” also Duplicate Content? Das beantwortet uns Mister-30-Tage Mann Matt Cutts. Video unten, am besten hier anschauen, ist gut für meine durchschnittliche Verweildauer. Ach was, vergesst das
Zurück zu Markus, dem Internet-Kapitän. Der navigiert uns auf dem großen Ozean der Linkerei in den etwas unsicheren Hafen der Google Webmaster Tools. Dazu lotet er die Untiefen mit eigenen Tests aus – und wird uns darüber auf der SEOkomm in Salzburg informieren.
Lang und ausführlich: Im SEO-Handbuch lesen wir, wie man Microdaten gemäß schema.org vernünftig auszeichnet. Lohnt sich. Echt!
100 kostenlose SEO-Tools! Da zucken jetzt gleich die professionellen Anbieter. Aber das ist gar nicht nötig. Denn dofollow.de zählt vor allem kleine Tools wie “Zeichenzähler”, “HTML-Cleaner” und “Onine-Ping-Service” dazu. Und davon kann man nie genug haben… Was mich aber schon interessieren würde, warum Abakus dort mit rechtlichen Schritten gedroht hat. Wer ist hierbei der Schuft?
Einer noch - zum Thema “Lebensglück”: Am Wochenende werde ich mir den Artikel auf imgriff.com durchlesen, in dem die Vorteile stehen, sich auf eine Sache zu konzentrieren.

Äh, wo waren wir noch? Ach ja, SEO. Also – jetzt also Matt Cutts:

Die SEO-Woche: senile Bettflucht, maritime Untiefen und ein langweiliger Linkbait ist erschienen im Seo Book der CONTENTmanufaktur.

Need for Speed: Webseiten beschleunigen (Worskhop auf der SEO Campixx)

Eric Kubitz — Mon, 14 Mar 2011 13:42:27 +0000

Nicht nur für SEOs: Beschleunigung von Webseiten

Und hier mein Recap des nach meinem Gefühl besten Workshops, den ich auf der SEO Campixx besucht habe. Markus Ostertag von moviemaze.de hat das Thema “Need for Speed” zusammen gefasst. Das Feine daran: Es war wirklich ein Workshop – denn im Saal “Brandenburg” waren eine Menge kompetenter Kollegen, die sich rege beteiligten…

Hierzu eine persönliche Bemerkung: Markus war im vergangenen Jahr auf einem Performance-Workshop, den er nicht so klasse fand und hat deshalb die Möglichkeit geschnappt, es besser zu machen. Großartig! Dies auch als Hinweis an die Kollegen, die uns nach der Rückkehr in München am Flughafen sagten, dass ja nicht so viel Neues auf der SEO Campixx erzählt wurde. Erstens: Das sehe ich völlig anders. Die Campixx war super, vielen Dank an Marco und Team. Und zweitens: Dann macht es halt besser…

Noch ein kurzer Sitestep: Ist die Performance – also die Geschwindigkeit einer Webseite – denn überhaupt ein SEO-Thema? Wenn man Google glaubt, auf jeden Fall. Denn Matt Cutts hat ja im vergangenen Jahr darauf hingewiesen, dass die Performance ein Ranking-Faktor ist. Viele Kollegen auf der SEO-Campix sind allerdings gar nicht dieser Meinung und wir sehen tatsächlich reichlich lahme Sites, die trotzdem super ranken. Also was jetzt?

Es gibt sicherlich mindestens drei Gründe, die für eine schnelle Site sprechen: Erstens ermöglicht eine hohe Crawlinggeschwindigkeit, dass ggf. mehr Seiten in den Index wandern. Zweitens werden viele User bei Ladezeiten von mehreren Sekunden sicher entnervt auf die Suchergebnisse zurück-klicken – und das wirkt sich via Bouncerate negativ aufs Ranking aus. Und schließlich ist eine schnelle Seite immer gut für mehr Klicks und bessere Conversions. Das ist streng genommen kein SEO-Thema. Aber irgendwie schon.

Die Optimierung der Performance einer Site lässt sich unter drei Überschriften vornehmen:

Size does matter!
Optimize connections
Caching

Also zur Sache: Size does matter!

Hier die drei zusammen gefassten Tipps von Markus, vermischelt und erweitert mit den Erfahrungen anderen Teilnehmer und mir:

Bilder sollten auf die notwendige Größe reduziert werden. Es muss nicht immer ein JPEG mit 100% Qualität und ein PNG24 sein. 70 % JPEG und PNG 8 reichen meist. Aber das sollte dann wohl von Bild zu Bild entschieden werden. Also sollte ausprobiert werden, ob es hierfür einen vernünftigen Workflow geben kann…
Wer auf dem Server die gzip-Komprimierung nicht einschaltet, ist selber schuld. Diese kann 60 % der übertragenen Daten reduzieren. Natürlich abgesehen von den eh schon komprimierten Bildern.
Mit “Minify” werden Leerzeilen, Leerzeichen und Kommentare aus dem Code heraus gepuhlt. Dafür gibt es fertige Scripte wie z.B. Google ModSpeed. Aber Obacht: Das sollte nur mit Vorsicht getan werden. Denn das Weglassen der falschen Zeilenschaltungen oder Leerzeichen kann ein Script schließlich töten (Leerzeilen und Kommentare können natürlich immer raus). Außerdem ist der Code ohne diesen “Ballast” schwerer zu lesen. Deshalb sollte mindestens im CMS immer die “normale” Version gehalten werden und erst beim Publizieren eine Minify-Version auf die Webserver gespielt werden. So kann man immer wieder zurück auf die Original-Version.

Next: Schauen wir auf die Connections

Browser bauen jeweils nur eine bestimmte Zahl von Connections gleichzeitig zu einem Host auf (IE7 2, IE8, ff3 15, Chrome 6, Safari 8.) Idealerweise werden bei einer hohen Bandbreite des Users aber so viele Daten wie möglich gleichzeitig geladen. So kann es eine kluge Lösung sein, die Dateien über mehrere Hosts zu laden. z.B. manche Bilder nicht über www.domain.de sondern auf www2.domain.de. Noch besser ist, dies auf einer ganz eigenen Domain zu machen, die keine Cookies wirft, deshalb ist www.domain2.de aus Performance-Gründen noch besser. Obacht aber für Bilder-SEOs: Ein Teilnehmer hatte dieses Problem schon mit Martin Mißfeld diskutiert und sie haben sich darauf geeinigt, dass große Bilder (die ranken sollen) auf die eigene Domain gepackt werden – und alles andere auf eine andere, cookieless Domain. So schön können Workshops das Wissen vieler verdichten!
Und doch rudern wir wieder ein bisschen zurück: Da der Verbindungsaufbau zu jedem Host wegen des DNS Lookup auch wieder Zeit kostet, sollte man die Parallelisieren auch etwas begrenzen. Hier ist das Bauchgefühl eines erfahrenen Webmasters gefragt. Markus meint, dass 10 unterschiedliche Domains sicherlich zu viel, und 3-5 wohl eine gute Zahl sind.
Das Javascript muss seriell abgearbeitet werden. Eine Aussage, die meine technische Kompentenz übersteigt, aber dazu führt, dass das Auslagern auf andere Hosts keinen Vorteil bringt. Deshalb: Packt möglichst viel davon in eine einzige Javascriptdatei. Das lässt sich nicht immer machen – aber es ist die richtige Zielvorstellung.
Für bestimmte Javascript-Dateien – die sehr häufig auch von anderen Seiten verwendet werden - können die Dateien z.B auch über Google Code geladen werden. Das spart eigene Bandbreite und außerdem liegen sie dann möglicherweise auch schon im Cache vieler User. Achtung: Das funktioniert lt. eines Teilnehmer mit manchen AdServern nicht. Dann muss doch wieder selbst gehostet werden.
Höchste Prio: Da das CSS für das Rendering der Seite notwendig ist, sollte es möglichst optimal, gerne auch komprimiert aber natürlich auch in einer Datei vom Server in den Browser geschoben werden. Noch ein Tipp hierzu: Manche Seiten haben gigantische CSS-Files, die für alle Unterseiten (von Home bis hin zur Gallerie) alles detailliert definieren – egal, ob es grad gebraucht wird oder nicht. Da macht es Sinn, nur jeweils das auzuliefern, was gerade gebraucht wird. Also keine Homepage-Formatierungen auf der Galerie und anders herum. Das gilt übrigens auch für die Javascript-Dateien…
Wer mit HTTP1.1. unterwegs ist, schicke bitte immer “KeepAlive” mit (was wohl die Grundeinstellung ist). Es gibt wohl keinen Grund das auszuschalten… (äh, gibt es hier Widerspruch?)

Finaly: Caching!

Wie lange sollte man die Daten im Cache halten? Auch hier muss jeder seine passende Balance finden. Zwei Gedanken dazu:

Wer hier viele Monate oder Jahre einstellt, muss wissen, dass die User dann die Datei auch ewig so sehen. Zum Beispiel ein neues Logo muss dann mit einem neuen Dateinamen eingebaut werden.
Außerdem sollte das natürlich auch rechtlich beurteilt werden. Hat man einen abmahnfähigen Artikel publiziert und ändert diesen nach dem bösen Schreiben eines Anwalts, wird dieser die Seite (bzw. z.B. das Bild darauf) erst dann neu sehen, wenn der Cache abgelaufen ist. In der Zwischenzeit wird der Abmahnanwalt begeistert Screeshots schießen…

Also Obacht – aber ansonsten möglichst lange Cache-Zeiten. Gell?

Tools: Und womit mache ich das?

Übersicht bei webpagetest.org

Zwei Tipps für Web-Tools sind wepagetest.org und site-perf.com. Viel erreichen kann man bekanntlich auch mit Googles PageSpeed und Yahoos Yslow. Die meisten haben schon regelmäßig mit Webpagetest gearbeitet – und das kann ich auch allen stark empfehlen. Es gibt auch weitere Tools, die zu verwenden sind, aber die genannten beiden sind definitiv nicht nur ein guter Start sondern helfen viel weiter.

Und jetzt los!

Need for Speed: Webseiten beschleunigen (Worskhop auf der SEO Campixx) ist erschienen im Seo Book der CONTENTmanufaktur.

Google-Tool für Webmaster: Page Speed

Bookmarklet: ausgehende Links checken

Eric Kubitz — Fri, 16 Jan 2009 17:50:28 +0000

Verkauft da jemand Links? Welche Seite bekommt Linkjuice? Gibt es irgendwelche wilden Javskript-Links? Immer, wenn eine Webseite etwas zwielichtig aussieht, lohnt es sich mal die ausgehenden Links zu checken. Aber wer kann die schon alle so einfach sehen? Aber hier kommt ein Bookmarklet, mit dem das ganz fix geht.

Um es “anzuwenden” muss das Bookmarklet als Link in den Firefox-Bookmarks gespeichert werden und es wird angeklickt, wenn die Seite geöffnet ist, deren ausgehende Links abgefragt werden sollen.

Wie wird das Bookmarklet installiert?

1. Möglichkeit: Erstelle ein neues Lesezeichen mit einem vernünftigen Namen (z.B. “Bookmarklet Ausgehende Links”) und kopiere den hier geschriebenen Code in das Feld für die URL:
javascript:(function(){as=document.getElementsByTagName("a");str="

";for(i=0;i"+as[i].href+"\n"}str+="

";with(window.open()){document.write(str);document.close();}})()

Obacht: Achte darauf, dass am Anfang und am Ende KEIN Leerzeichen mit hinein gerät.

2. Möglichkeit: Ziehe diesen hier folgenden Link in deine Seitenspalte oder sonstwo, wo die Lesezeichen organisiert sind:"+as[i].href+"\n"}str+="";with(window.open()){document.write(str);document.close();}})()">Bookmarklet Metatags.

Ja, das Ergebnis ist nicht schön – aber hilfreich…

Bookmarklet: ausgehende Links checken ist erschienen im Seo Book der CONTENTmanufaktur.

So klappt’s mit Google Images

Eric Kubitz — Wed, 22 Oct 2008 08:15:11 +0000

Die Bildersuche “Google Images” ist zwar in der Diskussion (ob es überhaupt erlaubt ist, Thumbnails von Bildern zu zeigen, was für ein Schwach…) – aber für manche Webseiten ein Quell steten Traffics. Hier meine Erkenntnisse, woran sich der Algorithmus der Bildersuche orientiert.

Ein kleines, nettes Beispiel vorab: Die Suche nach dem durchaus generischen Begriff “buddha” bringt das Bild eines Buddhas von meinem “Waldundwiesenblog” zu Tage – und zwar gerade auf Platz 7! Habt ihr eine Ahnung, wie irrelevant mein Blog im Allgemeinen und zum Thema “Buddha” im Speziellen ist? Ich hatte dieses Bild eher zufällig verwendet. Aber es trifft einfach eine Menge Kriterien…

Wir gehen hierbei immer davon aus, dass ein Keyword vorhanden ist, das etwa beschreibt, was auf dem Bild ist – und das auch die richtigen User anlockt. Denn das ist bei Google Images zwei mal zu bedenken: Was bringt mir der Traffic überhaupt? Sind das nur Bilderklauer, oder kann ich den Besuchern, die über die Bilder kommen, auch etwas anderes bieten?

1. Die technische Einbindung

Bildname: Dieser sollte unbedingt das Keyword enthalten. Gerne auch zusätzlich noch Ziffern oder andere Buchstaben.
Pfad: Dieser (also der Ordner, in dem das Bild liegt und evtl. Unterordner) können auch “speaking” sein.
Größenangaben: Zum Bild-HTML-Tag gehört “width” und “height”. Diese sollten gefüllt sein.
ALT-Tag: Dieser enthält möglichst auch das Keyword. Gerne auch noch weitere Begriffe.
Das Bildverzeichnis sollte nicht für Robots gesperrt sein.
In der Robots.txt sollte nicht verboten sein, Bilder zu crawlen.
Die Großversion des Bildes (falls im Text nur ein Thumbnail ist) sollte nicht nur über einen Javaskript-Link erreichbar sein.

2. Die Bilder

Einmaligkeit: Auch bei Bildern mag Google keinen Duplicate Content. Schon gar nicht auf der Seite – denn das sieht dann danach aus, dass es sich um das Headerbild oder ein Logo handelt. Also: Beste Chancen haben Bilder, die genau ein mal auf der Seite sind.
Bilder mehrfach verwenden ist allerdings sehr günstig. Indem ich unten das Buddhabild hier auch noch einfüge, unterstütze ich es.
Aktualität spielt eine untergeordnete Rolle. Es scheint sogar so zu sein, dass die Aktualisierung eines Bildes dieses aus dem Index kicken kann… Das konnte ich selber aber noch nicht verfolgen.
Bildergröße: Hier kann ich keinen echten Wert nennen. Aber große Bilder haben offenbar eine deutlich bessere Chance, in den Index zukommen. Standardformate (Querformat, Hochformat) mit Standardwerten (600×400 o.ä.) scheinen noch etwas besser zu laufen…
JPGs werden vom Robot wohl lieber gesehen als GIFs – und auch eher angezeigt. Aber das kann auch nur ein Zufall sein. Wie das mit PNGs aussieht, kann ich nicht sagen – dafür gibt es einfachzu wenige…
Das Motiv selber ist (noch) nicht wichtig. Google kann ja z.B. Gesichter (hängt mal den Parameter “&imgtype=face” an eine Images-Suche) und möglicherweise auch mittlerweile andere Motive (Häuser? Natur?) erkennen und es ist wohl absolut ein Ziel, zu einem Namen das passende Bild anzuzeigen. Aber ich denke, da haben wir noch etwas Zeit…
Das Bild sollte nicht verlinkt sein.

3. Das Drumrum

Text-Einbettung: Absolut entscheidend ist, dass das Bild von Text umflossen wird oder darüber und/oder darunter der Haupttext der Seite steht. Dabei ist es (siehe mein Beispiel) nicht so wichtig, ob der Text inhaltlich zum Bild passt. Hingegen ist viel Text (mehr als 150 Wörter) offenbar etwas günstiger…
Bilder von einer Seite mit hohem Pagerank scheinen diesen etwas zu “erben”, sie haben es leichter.
Ein einziges Bild im Contentbereich einer Seite ist besser als sehr, sehr viele Bilder auf einer Seite.

Also, fassen wir zusammen: Google mag große, dekorative Fotos die mitten in einem Text stehen und sauber ausgezeichnet wurden. Das ist doch sogar verständlich, oder? Und wer endlose Bildergalerien bastelt und diese in Images erwartet wird endtäuscht.

So klappt’s mit Google Images ist erschienen im Seo Book der CONTENTmanufaktur.

Kein Javaskript (jedenfalls nicht unüberlegt)

Eric Kubitz — Wed, 30 Jul 2008 14:26:00 +0000

Grundsätzlich kann der Google-Robot kein Javascript lesen. Zwar ändert sich das derzeit ein wenig, aber trotzdem sollten alle wesentlichen Inhalte ohne die Skriptsprache erreichbar sein. Just to be shure…
Doch keine vernünftige Seite funktioniert heute völlig ohne Javaskript. Deshalb sollte zumindest bei der Verlinkung, bei der Navigation und bei der Anzeige von Text auf Javaskript verzichtet werden. Und in jedem Fall sollte der Javaskript-Code nicht im Sourcecode stehen sondern in einer eigenen Datei in einem vor Google geschützten Verzeichnis. Denn dann wird der gesamte Code schlanker.

Selbstverständlich wird Javaskript hin und wieder dafür verwendet, böse Links oder Texte vor Suchmaschinen zu verstecken. Vorsicht: Das ist nur so lange eine gute Idee, so lange die Suchmaschinen kein Javaskript lesen können. Und in Zeiten, in denen sich dank AJAX komplette Webseiten mindestens aber interessante Funktionen und Inhalte auf Javaskript verlassen, kann dieser Zeitpunkt nicht mehr fern sein.

Kein Javaskript (jedenfalls nicht unüberlegt) ist erschienen im Seo Book der CONTENTmanufaktur.