Mit anderen Worten: Pubsubhubbub macht aus einem passiven Feed, der auf seinen Leser wartet, ein aktives Push-Medium und kann dafür sorgen, dass auch Google neu veröffentliche Seiten schneller in den Index aufnimmt.

Wir empfehlen ja, Twitter als Wecksignal für Google zu verwenden: Wenn wir einen Beitrag veröffentlichen und diesen über einen halbwegs relevanten Twitter-Account in die Welt tweeten, dann haben wir in der Regel wenige Sekunden später den Robot auf unserer Seite der sich den Beitrag anschaut und bei Interesse in den Index aufnimmt. Das funktioniert sehr schnell und stabil.

Und genau das will/soll Pubsubhubbub leisten: Wird der Feed eines Blogs, einer Newsseite oder einer anderen Site erweitert, stubst das Protokoll einen Hub an, der wiederum seinen Abonnenten Bescheid gibt, dass die Welt um einen Beitrag reicher ist.

Entstanden ist das (wohl) in einer Austastlücke bei Google und so liegt die Projektseite auch hier: http://code.google.com/p/pubsubhubbub/. Das freut uns SEOs natürlich. Denn selbst, wenn es unter “normalen” Usern noch Anwendungen dafür gibt (z.B. wäre ja jeder Feedreader ein Kandidat für eine Anbindung an einen Pubsubhubbub-Hub), sind zumindest die Google-Produkte schon ziemlich weit in der Fertigstellung: Google Reader, Buzz (was war das noch mal?), Blogger, Google Alerts, Fast Flip und Feedburner (fast) können mit dem Protokoll umgehen. Wir können also sicher sein, dass wir mit einer Erweiterung unseres Feeds, die Suchmaschine auch erreichen.

Wie die Integration von Pubsubhubbub funktioniert

Und das geht eigentlich recht einfach. Der Seitenbetreiber muss vor allem in seinen Feed einen oder mehrere “link rel=”hub” einbauen, was etwa so aussehen kann: ”

<atom:link rel="hub" href="http://pubsubhubbub.appspot.com"/>
<atom:link rel="hub" href="http://superfeedr.com/hubbub"/>

Und bei der Veröffentlichung wird dieser Hub angepingt – und zwar nicht nur als schüchternes “Ping” sondern gleich mit dem kompletten Inhalt. Der Hub kann nun seinerseits weitersagen, dass hier etwas neues aufgetaucht ist – etwa über eine AJAX-Funktion z.B. in webbasierten Feedreadern oder als Aufforderung an den Such-Robot mal auf der Seite vorbei zu schauen.

Und ganz praktisch?

• Für WordPress-Blogger gibt es ein Plugin. Sicherlich auch schon für andere CMS Systeme…
• Wer seinen Feed im Feedburner hat, kann diesen auch dafür aktivieren. Wie das geht, erklärt drweb.
• Und wer selber coden muss bzw. will, findet natürlich alles auf der Projektseite.

Dort finden sich auch die derzeit wenigen Hubs, die angepingt werden können. Im Grunde könnte ja jeder einen solchen Hub betreiben und das könnte zum Beispiel für Medienhäuser durchaus eine gute Idee sein, wenn man nicht jeden Ping annimmt sondern einen qualitativ hochwertigen News-Stream anbietet. Auch eine Erweiterung (z.B. Kategorisierung) der Pings wäre meiner Meinung nach eine gute Idee…

Aber das ist noch Zukunftsmusik. Momentan empfehlen wir, Pubsubhubbub für eine schnellere Indexierung bei Google einzusetzen und hoffen, dass dies auch gut funktioniert. Weitere nützliche Einsatzmöglichkeiten für SEO suchen wir allerdings erst noch

Echtzeitweb & SEO? Einstieg in Pubsubhubbub ist erschienen im Seo Book der CONTENTmanufaktur.

Related posts:

1. RSS-Feed zur Google-Optimierung?

• Das soll wohl nur für den englischsprachigen Raum gelten (siehe Bemerkung unten)…
• Laut Matt Cutts sollen sich dadurch nur ein Prozent der Suchergebnisse ändern.
• Johannes “Sistrix” Beus gibt ein paar Zahlen vor: Ein guter Wert für die Auslieferung des HTMLs sollte bei weniger als 500 Millisekunden liegen, die Auslieferung der gesamten Seite lt. den Google Webmaster Tools um die 1,5 Sekunden.

Hierzu nun zwei Bemerkungen von mir:

Erstens sind die Werte von Sistrix unerreichbare Traumzahlen für alle, die eine größere Seite mit einem Redaktionssystem betreiben, das eine Datenbank abrufen muss. Ich denke nicht dass diese Zahlen gelten, sondern dass Google sich auf einen realen Durchschnitt einlässt. Für das SEO-Book hier sagen mir die Google Webmaster Tools “Im Durchschnitt benötigen Seiten auf Ihrer Website 2,3 Sekunden zum Laden (aktualisiert am 08.04.2010). Dies ist schneller als 67 % der Websites.” Ich denke, in einem Mittelfeld zu liegen ist o.k.. Denn, merke: Um super zu ranken musst du einfach nur ein bisschen besser sein, als die Konkurrenz…

Und bin ich in diesem Punkt gar nicht bei Martin Mißfeld, der schreibt “Alles, was nicht reiner Text ist, wirkt sich in Zukunft negativ aus.” Bei allem Respekt, Martin, aber das ist  eindimensional. Ein Bild auf einer Seite ist ein positiver Rankingfaktor. Doch wenn ich es ätzend langsam ausliefere, wird davon wieder ein bisschen was abgezogen. Das ist auch für die User nur fair…

Zweitens ist das doch eh schon länger so. Unabhängig von einem aus irgendeinen Grund gerade jetzt veröffentlichten “Rankingfaktor” verschwenden langsame Seiten schon immer die ihnen zur Verfügung gestellte Crawlerzeit und werden deshalb mittelbar schlechter gewertet (weil weniger Seiten im Index aktuell gehalten werden können). Google hat doch nicht umsonst schon vor langer Zeit das Tool “Page Speed” gelauncht…

Meine Meinung: Dass Google schnelle Webseiten von uns verlangt, hat vor allem damit etwas zu tun, dass das die User auch wollen und damit der Robot möglichst viele eurer Unterseiten sehen kann. Und auch unabhängig vom Ranking werdet ihr schnell merken, dass sich bei einer Geschwindigkeitsverbesserung von einer Sekunde alle, alle, alle Werte verbessern: Visits, PIs und Conversion. Na klar: Zählt doch bitte jetzt mal im Kopf langsam auf vier. Wollt ihr so lange auf jede Unterseite warten?

Die von Google empfohlenen Tools (auch das nicht neu) sind:

• Page Speed, das Firefox/Firebug Addon von Google.
• YSlow, das Firefox/Firebug Addon von Yahoo.
• WebPagetest eine sehr eindrückliche Test-Webseite zum Thema.
• Und in Webmaster Tools gibt es in den Labs die “Site Performance”.

Nun auch “offziell”: Seitengeschwindigkeit ist Rankingfaktor ist erschienen im Seo Book der CONTENTmanufaktur.

Related posts:

1. Schon wieder: Google Webmastertools
2. Google-Tool für Webmaster: Page Speed
3. “Die häufigsten Suchanfragen” in den Google Webmaster Tools

Wir haben also den Ernstfall eines sehr üblichen Geschäftsmodells simuliert: Eine journalistische Special Interest Seite syndiziert (“verkauft”) Inhalte an ein größeres, allgemeines Portal.

Das Ergebnis ist klar: Das Canonical-Tag tut alles wie erwartet

Da sich Google ja wünscht, jeweils die relevanteste Seite anzuzeigen, können wir davon ausgehen, dass auch der Robot Interesse daran hat, den Urheber (also die Special Interest Seite) aufzunehmen und zwar nun ihn. Dafür soll das canonical-Tag eine Hilfe sein.

Und: Es ist eine Hilfe. Wir sehen bei ausnahmslos allen “syndizierten” Seiten, dass der Beitrag des Urhebers im Index bleibt – mit den gewohnten Schwankungen. Und der Beitrag des Portals ist in den ersten 100 Ergebnissen nicht zu finden.

Interessantes Detail: Die Seite mit dem Content des Portals ist zwar Index vorhanden (man kann sie über den Site-Befehl “site:domain.de keyword” finden) – aber nicht in den Suchergebnissen. Selbst bei der Suche nach ganzen Text-Schnipseln zeigt Google die Portal-Seite nicht an. Mit anderen Worten: Der Content-Nehmer bekommt die Seiten im Index “gutgeschrieben” und es ist damit zu rechnen, dass die internen Links darauf auch Pagerank und Trust weiter geben. Allerdings wird die Seite selbst nicht als relevantes Suchergebnis gewertet.

Fazit: Das Geschäftsmodell “Syndication” funktioniert – wenn (fast) alle mitmachen

Dieses Ergebnis ist die Bestätigung der Hoffnung, dass Verlage auch in SEO-Zeiten gefahrlos ihre Inhalte verkaufen können. Das funktioniert allerdings nur, wenn der Geschäftspartner (also das meist größere Portal) diese Inhalte nicht allein zum Zwecke der Google-Optimierung sondern für die User kauft – und dementsprechend den canonical-Tag einfügt.

Und wenn die anderen nicht mitmachen? Wenn sich also der Syndication-Kunde weigert, den canonical-Tag einzubauen bzw. richtig viel Geld dafür zahlt, wenn er ihn nicht einbauen muss? Nun, dafür haben wir eine weitere Theorie zur Rettung. Aber die müssen wir nun auch erstmal überprüfen…

Gefahrlos Inhalte syndizieren: Test zu “canonical”-Tag extern ist erschienen im Seo Book der CONTENTmanufaktur.

Related posts:

1. Übersicht: das Canonical-Tag von Google
2. YEPP! Google führt canonical-Tag “cross-domain” ein
3. SEO am Morgen: “Canonical-Tag domainübergreifend” oder “Die Rettung der Syndication?”

Das Problem ist eigentlich der Scheduler

Jo Müller, der “europäische Matt Cutts”, zeigt auf seinen Präsentationen gerne den komplexen Weg, den eine Seite durch die Google-Server nehmen muss, um gecrawlt zu werden. Ganz am Anfang steht da der “Scheduler”, sozusagen der Vorarbeiter des Robots, der dessen Zeit einteilt. Vermutlich ist die Zeitmenge, die der Robot pro Webseite hat, abhängig von ihrer Autorität (und damit wieder von den Backlinks). Was er aber in dieser Zeit zu sehen bekommt, haben wir selber in der Hand. Und ist diese Zeit abgelaufen, wird der Robot zurück gepfiffen und muss woanders crawlen.

Zeitsparprogramm für den Robot

Ein wichtiges Ziel der Google-Optimierung ist also, dem Robot in möglichst kurzer Zeit möglichst viele relevante Seiten zu zeigen. Und da spielen eine Menge Faktoren eine Rolle:

• Alle Seiten sollten schnell ausgeliefert werden. Hierbei ist es nicht entscheidend, wie groß die Seiten sind – sondern wie schnell der Crawler sie sehen kann.
• Neue und veränderte Seiten müssen ihm zuerst “vorgelegt” werden,
• danach aber auch alle anderen wichtigen Seiten.
• Duplicate Content ist kein Grund für eine Penalty – sondern die Verschwendung von kostbarer Crawler-Zeit.
• Das gilt auch für unnötige Index- bzw. gefilterte Seiten.
• Und auf den eigentlichen Beitragsseiten sollte der Robot möglichst schnell und übersichtlich die zur Einordnung wichtigen Informationen erkennen können.

Das ist eigentlich schon alles

Viel Arbeit für die Crawlability…

Selbstverständlich ist das für Kunden mit mehreren Hundertausend Unterseiten und einem komplexen Content Management System eine gigantische Herausforderung. Das kostet Geld und Zeit. Aber, hey, es muss nun mal sein…

Ich kann und will in diesem Übersichts-Artikel nicht auf die Details eingehen, aber die drei wichtigsten Arbeitsbereiche möchte ich schon kurz darstellen:

1. “Seitengeschwindigkeit” heit auf Englisch “Page Speed” und ich kann jedem nur das gleichnamige Tool von Google sowie “ySlow” von Yahoo empfehlen. Wem das Installieren von Firefox-Erweiterungen zu kompliziert ist, dem empfehle ich “Pagetest” als Einstieg…
2. Duplicate Content & unnötige Index-Seiten findet man am besten mit dem viruosen Einsatz des “site”-Befehls (wobei ich diesen Artikel unbedingt  aktualisieren muss….). Ziel hier sollte es nicht sein, möglichst viele Seiten in den Index zu bekommen – sondern unique und relevante Seiten. Das macht man in der robots.txt, mit Meta-Angaben für den Robot (“noindex” bzw. “noindex,follow”) und/oder mit dem geschickten Einsatz der Google Webmaster Tools.
3. Die Seitenstruktur sollte die Relevanz abdecken. Wichtige und aktuelle Seiten sind möglichst “nahe” der Home – weniger wichtige Seiten aber trotzdem erreichbar. Und wer jetzt sagt, dass er dafür einfach eine Sitemap mit allen Unterseiten an Google liefert, dem empfehle ich, diesen Artikel noch mal oben zu beginnen…
4. Der Code ist nicht nur schlank sondern auch eindeutig. Wer viele Überschriften und kiloweise Text in die Randspalten packt, braucht sich nicht darüber zu wundern dass der Robot den Kontext für wichtiger hält als die eigentliche Information. Am besten präsentieren wir unsere Seiten ohne Javaskript, mit eindeutigen Hinweisen auf den “eigentlichen” Content und gut strukturiert. HTML 5 wird uns da möglicherweise in Zunft helfen.

Das soll es heute mal gewesen sein. Einen Credit will ich noch los werden: Solche Themen wie “Crawlability” sind für Konferenzen meist zu komplex und bringen  nicht so viel Credibility wie irgendwelche Pseudo-Blackhat-SEM-Themen. Deshalb habe ich mich sehr über den Einsatz von Alexander Holl und Boris Bergmann von 121Watt auf dem vergangenen Konferenz-Marathon gefreut!

Erweiterte Crawlability: Don’t waste robot-time! ist erschienen im Seo Book der CONTENTmanufaktur.

Related posts:

1. Nun auch “offziell”: Seitengeschwindigkeit ist Rankingfaktor
2. SEO am Morgen: Google pumpt Seiten
3. SEO am Morgen: Matt Cutts und eine geschärfte Auffassung zur robots.txt

Website-Geschwindigkeit IST ein Ranking-Faktor ist erschienen im Seo Book der CONTENTmanufaktur.

Related posts:

1. Nun auch “offziell”: Seitengeschwindigkeit ist Rankingfaktor
2. Google-Tool für Webmaster: Page Speed
3. Zusammenfassung der Ranking Faktoren