Ich bin die Tage auf eine ganz interessante Taktik für Google Maps gestoßen. Wenn man bei Google nach einer Firma sucht, dann werden mir nicht die üblichen zehn lokalen Ergebnisse angezeigt (die gäb’s beim folgenden Beispiel auch nicht), sondern eben nur die Daten dieser Firma:

Da Google aber gar nicht so genau weiß, was nun ein “legaler” Firmenname ist, haben einige ihr lokales Listing auf Suchbegriffe abgestimmt und ihren Firmennamen so gewählt, dass dieser den Zielsuchbegriffen entspricht. Beispiel:

Für “osteopathie hannover” funktioniert das hervorragend, obwohl es durchaus noch andere zur Suchanfrage passende Unternehmen gibt. Für Berlin klappt das leider nicht – wohl, weil es einfach zuviele Unternehmen sind:

Man beachte: Auch hier gibt es Listings, bei denen der Firmenname den Suchbegriffen entspricht.

Meiner Meinung nach müsste Google hier auf jeden Fall nachbessern. Es müsste eine Art “Report Abuse”-Feature geben, das ich nutzen kann, wenn jemand nicht seinen echten Firmennamen eingibt oder andere Tricks nutzt.

Übrigens scheint Google auch manchmal Unternehmen anzuzeigen, bei denen nicht der Firmenname den Suchbegriffen entspricht. Beispiel aus Haltern (meiner Heimatstadt):

Es gibt auch hier noch zig andere Hotels in Haltern, aber Google entscheidet sich lieber dafür, eins herauszusuchen (zumindest meiner Meinung nach das beste). Gut für das eine Hotel, schlecht für die anderen

Das Programm für die SES Berlin steht jetzt auch fest:

Programm 24. November
Programm 25. November

Freue mich natürlich auf das Networking. Zwischendurch halte ich einen Vortrag (“Duplicate Content & Multiple Site Issues”) und moderiere ein Panel (“Besonderheiten des SEO & PPC in Deutschland”). Könnte ein toller Event werden… (Berlin, Berlin, wir fahren nach Berlin…)

Kurze Randnotiz: In den Google Webmaster Tools gibt es einen neuen Menüpunkt namens “Google Labs”. Dort stehen jetzt zwei Funktionen zur Verfügung:

Abruf wie beim Googlebot:
Nach Eingabe einer URL zeigt Google den HTTP-Verkehr (nur Response, nicht Request) und den HTML-Code der abgerufenen Seite an. Mir erscheint das erstmal recht sinnfrei – zumindest ich kann erstmal nicht erkennen, wofür man das sinnvoll nutzen kann (außer um zu prüfen, ob man fürs Cloaking die richtige IP erwischt hat).

Malware-Details:
Wenn eine Website als schadhaft eingestuft wird (Google SafeBrowsing), kann man hier Details abrufen, auf welchen Seiten Google denn welche schlimmen Sachen gefunden hat. Interessant, aber mangels Probekandidat konnte ich dieses Feature leider nicht testen. (Screenshots gibt’s aber z.B. hier)

Google testet derzeit in San Francisco und San Diego ein neues Angebot: Lokale Werbungen können über das Local Business Center (also ohne Umweg über AdWords) gebucht werden. Der Preis hängt von den Kategorien und der Stadt ab – ist aber fix und damit nicht von der Anzahl der Klicks abhängig.

Mehr Infos darüber findet man bei Google unter dem Stichwort Google Local Listing Ads oder im folgenden YouTube-Video:

Insgesamt ist das natürlich eine spannende Entwicklung, die sich vor allem an Unternehmen richtet, die Interesse an einer “Set it and forget it”-Lösung haben. Bis das nach Deutschland kommt, wird’s wohl noch ein bisschen dauern – falls der Test sich überhaupt als fruchtbar herausstellt.

Ich persönlich glaube, dass das ein gutes Angebot ist, das den Bedürfnissen vieler lokaler Unternehmen stark entgegen kommt.

Gestern haben wir endlich Richtfest gefeiert. Der Rohbau vom Blooplex ist damit fertig. Am Donnerstag morgen haben wir auch schon Steckdosen, Schalter und Sanitärkrams eingezeichnet, so dass es in den nächsten Tagen fleißig weiter gehen kann.

In jedem Fall hat’s mich sehr gefreut, dass viele Freunde, Bekannte und Nachbarn zum Richfest gekommen sind. Hier noch ein paar Fotos:

Felix (einer meiner drei Jungs) hat extra ein Schild gemalt…

Doris schenkt reichlich aus.

Mein jämmerlicher Versuch, einen meterlangen Nagel in 287234 Versuchen ins Gebälk zu kloppen.

Jan (einer meiner drei Jungs) managed die Bar. Hat er super gemacht…

Andreas (Mitgründer aus Kalifornien) darf ebenso wenig fehlen wie Richard von CREATEOCEANS (der unser suchradar layouted).

Also, dann hoffe ich mal, dass der nächste Blog-Beitrag etwas mit Einzug zu tun hat. Angepeilt ist der erste Januar. Mal schauen…

Der neue Comic ist jetzt auch da… viel Spaß damit

Google möchte AJAX suchmaschinenkompatibel machen und hat auf der SMX East einen Vorschlag veröffentlicht, wie das funktionieren könnte. Mehr dazu steht außerdem im Google Webmaster Central Blog.

Hintergrund

Mit AJAX kann eine bereits geladene Seite nochmal Inhalte vom Webserver nachladen. Das ist oftmals sehr praktisch, da man sich so das komplett neue Laden von Seiten ersparen kann. Suchmaschinen analysieren jedoch den Quellcode einer Seite und sehen die nachträglich geladenen Inhalte daher nicht.

Beispielsweise könnte man auf einer Seite einen Artikel anteasern und sobald jemand auf “mehr” klickt, wird der Rest des Artikels per AJAX nachgeladen. Suchmaschinen bleibt der Rest des Artikels dann verborgen. Zwar werden Google & Co. immer besser darin, JavaScript zu verstehen und könnten theoretisch auch den Klick auf “mehr” mit AJAX ausführen, um an dem vollständigen Artikel zu gelangen. Der Aufwand wäre jedoch vergleichsweise hoch. Zum einen müssten Suchmaschinen den JavaScript-Code samt AJAX nicht nur verstehen, sondern auch tatächlich ausführen, um Inhalte nachzuladen. Zum anderen sind längst nicht alle AJAX-Seiten so einfach gehalten wie im Beispiel. So kann man z.B. auch ganze Web-Anwendungen mit JavaScript und AJAX bauen. Jedes Mal, wenn sich etwas auf dem Bildschirm ändert, würde ein Suchmaschinen-Crawler das als neuen Zustand erfassen müssen.

Allerdings gibt es noch ein viel grundsätzlicheres Problem: Unabhängig vom Zustand, in dem sich eine Seite gerade befindet, ist die URL immer die gleiche. Suchmaschinen könnten aus ihren Suchergebnissen also gar nicht auf einen bestimmten Zustand verlinken.

Lösen können Suchmaschinen dieses Problem nicht im Alleingang. Sie können dem Browser eines Nutzers eben keine Information wie “geh auf diese URL und klick auf mehr” mitgeben.

Googles Vorschlag

Der Vorschlag von Google zielt darauf ab, bestimmte JavaScript-Zustände einer Seite für Suchmaschinen erfassbar zu machen. Außerdem soll es möglich werden, direkt auf diese Zustände zu verlinken.

Um spezielle AJAX/JavaScript-Zustände in einer URL zu kennzeichnen, sollen URL-Fragmente modifiziert werden. Ein Ausrufezeichen soll Googles Vorschlag zufolge verwendet werden, um einen Zustand im URL-Fragment zu kennzeichnen. Eine vollstände URL könnte dann z.B. so aussehen: http://www.internetkapitaene.de/index.php?id=1#!nameDesZustands
Der Aufruf einer solchen URL soll immer zum gleichen Inhalt führen, so dass Suchmaschinen direkt darauf verlinken können. Umgekehrt müssen auch alle Zustände, auf die Suchmaschinen verlinken sollen, derart aufrufbar sein. Ein Zustand “Schriftfarbe auf rosa geändert” müsste man also nicht weiter kennzeichnen, ein “ganzen Artikel anzeigen” dagegen schon.

Damit Suchmaschinen diese Zustände erfassen können, sollen Webserver in die Lage versetzt werden, diese gleich fertig auszuliefern. Google schlägt vor, dass sie dafür einen so genannten “headless Browser” verwenden. Headless Browser sind Browser ohne grafische Benutzeroberfläche. Diese sollen die Seite ganz normal abrufen, das enthaltene JavaScript samt AJAX ausführen, um die Seite in den gewünschten Zustand zu versetzen. Dann soll ein HTML-Snapshot der fertigen Seite im Zielzustand gemacht werden, den der Webserver an den Crawler ausliefert.

Zwei Probleme treten dabei auf, für die Google auch gleich eine Lösung parat hat. Denn der Webserver kann weder ohne Weiteres erkennen, dass gerade eine Suchmaschine anfragt, noch kann er mit URL-Fragmenten umgehen. Deshalb möchte Google den Zustand als ganz normalen Query-Parameter an die URL anhängen und schlägt als Parameter “_escaped_fragment_” vor. Obige URL sähe dann so aus: http://www.internetkapitaene.de/index.php?id=1&_escaped_fragment_=nameDesZustands
Diese URL würde der Webserver dann annehmen, intern wieder in http://www.internetkapitaene.de/index.php?id=1#!nameDesZustands umwandeln und an den headless Browser schicken. Der liefert seinen HTML-Snapshot beim Webserver ab, welcher diesen gleich an den Crawler weiterreicht. Die folgende Grafik verdeutlich das auch nochmal (Quelle).

Einschätzung

Setzt sich Googles Vorschlag durch, so ließe sich damit ein grundlegendes Problem vieler Websites lösen, die auf AJAX setzen. Die Lösung verlangt jedoch viel Mitarbeit von den Website-Betreibern, was sicher die größte Hürde darstellen wird. Vermutlich wird Google hier noch kräftig nachlegen, um Webmastern die Umstellung zu erleichtern. Viel Mitarbeit wird auch von Webservern gefordert, auf denen die headless Browser den Crawlern ordentlich Arbeit abnehmen sollen. Dabei könnten headless Browser auch genausogut von Google eingesetzt werden. Mit dem Hinweis, dass man so mehr Kontrolle darüber behält, wie die Seite letztlich ausgeliefert wird, versucht Google, Webmastern diese Lösung schmackhaft zu machen.

Auf jeden Fall stellt sich für Webmaster die Frage, ob man nicht besser fährt, wenn man die Website optional auch ohne AJAX bedienbar macht. Denn so oder so steht zunächst einmal eine Menge Arbeit für den Webmaster an. Im Hinblick auf Barrierefreiheit ist eine Lösung ohne AJAX auf jeden Fall die bessere Lösung. Andererseits verspricht die Lösung mit Ausrufezeichen-URLs, dass Benutzer die aktuelle URL aus dem Browser kopieren und problemlos verlinken können. Weiterer Unterschied: Die Variante mit der optionalen Non-AJAX-Lösung funktioniert schon heute. Googles Vorschlag ließe sich ebenfalls heute schon umsetzen, allerdings ist Googles Crawler noch nicht so weit, dass man daraus schon einen Vorteil ziehen könnte.

Wow, nach langer Zeit endlich mal ein hilfreiches Video von Matt Cutts (nicht das übliche “Bau eine tolle Site & alles wird schon gut werden”).

Es geht darin um die Frage, warum man manchmal in Suchergebnissen “Uncrawled Results” sucht:

Die kurze Antwort:

Ein Eintrag in der robots.txt besagt nur, dass die Website nicht gecrawled werden darf. Es kann aber trotzdem sein, dass sie in den Suchergebnissen auftaucht, wenn Google glaubt, dass die Website trotzdem wichtig ist (weil sie z.B. gut verlinkt ist). Deswegen kann es schon mal passieren, dass es ein “Uncrawled Result” gibt.

Wer überhaupt nicht erscheinen möchte, muss die entsprechende Seite schon auf Noindex (im Robots-Meta-Tag) setzen. Dann ist die Seite auch komplett aus dem Index verschwunden.

Nichts weltbewegendes, aber trotzdem die 4:33 wert.

Google hat da schon lange nichts mehr mit gemacht, Bing auch nicht – nur Yahoo stand immer noch auf der Liste der Websites, die Meta Keywords unterstützen. Laut Yahoo (“Yahoo Search No Longer Uses Meta Keywords Tag“) sind aber auch diese Zeiten jetzt vorbei.

Mal schauen, ob sich das in Zukunft ändert. Grund dafür gäb’s eigentlich keinen.

Das Canonical-Tag funktioniert ja derzeit nur innerhalb einer Domain. Google hat jetzt aber angekündigt, dass sich das ab Jahresende ändern soll, so dass man dann das Tag auch über Domaingrenzen hinweg nutzen kann.

Prinzipiell ist das eine gute Idee, birgt aber auch einige Potenziale/Gefahren. Wenn man zwei Domains hat (www.meine-website.de und www.meine-website.com) könnte man dann diese beiden Websites über das Canonical-Tag vereinen. Das würde ich aber nicht empfehlen, weil es eine Google-spezifische Lösung wäre (Bing/Yahoo werden das wohl erstmal nicht mitmachen). Außerdem ist ein 301-Redirect per htaccess in drei Zeilen fertig. Der Aufwand für das Canonical-Tag wäre wohl wesentlich höher.

Ich frage mich aber schon, was passiert, wenn es zwei Domains gibt (A und B) und in beiden Websites wird jeweils das Canonical-Tag für A gesetzt. Dann müsste es ja eigentlich auch so sein, dass die Link Popularität von A und B zusammengezählt wird und nur noch A in den Suchergebnissen angezeigt wird. Da könnten sich ganz neue Modelle in Bezug auf Domains und Linkaufbau ergeben: Ich muss gar keine alte, gut verlinkte Domain mehr kaufen, um mit einem neuen Projekt schnell gute Rankings zu erzielen. Es würde reichen, wenn die alte Website B ein Canonical-Tag für meine Website A bekommt. Da könnte man ja ein tolles Rent-A-PageRank-Modell raus bauen.

Das ist natürlich erstmal alles hypothetisch, aber schon irgendwie interessant

Also: Schön, dass Google das Canonical-Tag domainübergreifend erweitert. Aber wirklich relevant ist das meiner Meinung nach nicht, weil man mit einer htaccess schneller, sicherer und suchmaschinenübergreifend zum Ziel kommt.