Am 5. und 6. April 2011 findet auch dieses Jahr wieder die SMX München statt. Natürlich ist auch Google dabei und wir haben eine ganze Reihe von Referenten am Start:

• Maile Ohye, Developer Programs Tech Lead in Mountain View, hält am Dienstag eine Keynote unter dem Titel "Das Aktuellste zur Google Suche". Schon vorher kann man sie bei "Das neue Suchuniversum: Google, Microsoft, Facebook, Apple & Co" hören.
• Uli Lutz aus dem Search Quality Team, spricht am selben Tag in einem Panel zu "SEO & User Generated Content".
• Johannes Müller, Webmaster Trends Analyst, wird genauso wie Maile zweimal ans Sprecherpult gebeten: dienstags zu "Search Engine Friendly Design" und mittwochs unter dem Titel "Technisches SEO: HTML5".
• Mark McCann, AdWords Product Specialist Ads Quality & Formats, beschäftigt schließlich am Mittwoch mit der neuen Generation der Suchanzeigen.

Ich werde ebenfalls anwesend sein. Falls ihr auch auf der SMX München seid, heißen wir euch in unseren Sessions willkommen und freuen uns auf viele Unterhaltungen zwischen den Panels!

Blogpost von Jörg Pacher, Search Quality Analyst

Heute erklärt Matt Cutts, ob und wie Google Signale von Twitter oder Facebook für die Rankings auswertet, und verweist dabei auf den ausführlichen Artikel "What Social Signals Do Google & Bing Really Count?" von Danny Sullivan von Search Engine Land.



Okay. Willkommen bei einer neuen Webmaster-Fragerunde. Es kamen fast 500 Fragen, sodass wir nicht alle beantworten können. Einige davon sind aber sehr interessant. Fangen wir mit der beliebtesten an. Sie kommt von Web SEO Analytics und lautet: "Hallo Matt! Neulich war in einem Artikel von Danny Sullivan zu lesen, dass Google Twitter und Facebook als Ranking-Signal verwendet. Stimmt das? Kannst du das näher erläutern?"

Ja, das ist richtig. Wir verwenden Links und Rankings von Twitter und Facebook in unseren Rankings für die Websuche. Darüber hinaus beachten wir aber auch den Ruf eines Autors auf Twitter oder Facebook. Das will ich näher erläutern.

Im Mai 2010 habe ich in einem Video gesagt, dass wir solche Signale nicht verwenden. Damals war das auch der Fall. Nun, im Dezember 2010, verwenden wir diese Signale doch. Ausführliche Infos zu diesem Thema lest ihr im Artikel von Danny Sullivan. Den Link findet ihr in der Beschreibung des Videos.

Hierzu noch folgende Anmerkungen: Das Search Quality Team besteht aus verschiedenen Gruppen und Büros. Die Teams, darunter das ursprüngliche Blogsearch-Team, Leute, die an der Echtzeitsuche arbeiten, nutzen diese Signale. Die Signale werden in erster Linie für die Echtzeitsuche verwendet, wo einzelne Tweets oder Links auf der Seite angezeigt werden. Wir untersuchen gerade, ob es sinnvoll wäre, die Signale auf breiterer Ebene in den Rankings der Websuche einzusetzen.

Dabei gibt es einiges zu beachten. Wenn wir eine Seite nicht crawlen, sie also nicht sehen können, können wir ihr keinen PageRank zuweisen und sie nicht richtig zählen. Nur abrufbare Daten können verwendet werden. Ist eine Seite vom Crawling ausgeschlossen oder kann anders nicht abgerufen werden, können wir sie nicht in unseren Rankings verwenden. Wir machen das momentan relativ zaghaft. Sollte sich die Methode als nützlich und robust erweisen, werden wir sie künftig verstärkt einsetzen.

Eine kleine Warnung noch: Geht jetzt nicht hin und betreibt Follower-Tausch, um Tausende von Mitlesern wie früher unzählige Links zu erhalten. Der PageRank hängt nicht nur von der Anzahl der Links ab, sondern auch von deren Qualität. Überlegt, welche Follower für Qualität stehen, Nutzer, hinter denen nicht nur Bots oder Softwareprogramme stehen. Auf dieses Signal achten wir nun genauer. Man sieht dies am meisten in der der Echtzeitsuche. Aber auch bei der Websuche wird es auf breiterer Ebene beachtet.

Veröffentlicht von Daniela Loesser, Search Quality Team

Unser Ziel ist ganz einfach: Wir möchten unseren Nutzern in möglichst kurzer Zeit die relevantesten Ergebnisse anzeigen. Und da ständig neue Inhalte – gute ebenso wie schlechte – ins Web gestellt werden, müssen unsere Algorithmen fortlaufend aktualisiert werden.

Viele der Updates, die wir vornehmen, sind so fein und subtil, dass sie meist gar nicht wahrgenommen werden. Vor einiger Zeit haben wir aber eine ziemlich bedeutende Algorithmusverbesserung für unser Ranking eingeführt: eine Veränderung, die sich auf 11,8 Prozent unserer Suchanfragen spürbar auswirkt und über die wir euch gezielt informieren möchten. Ziel dieses Updates ist es, die Rankings für Websites von geringer Qualität zu reduzieren, d. h. für Websites, die einen geringen Mehrwert für Nutzer darstellen, die Inhalte von anderen Websites kopieren oder die einfach nicht hilfreich sind. Gleichzeitig erhalten Websites von hoher Qualität bessere Rankings, also Websites mit Originalinhalten und Informationen wie Forschungsergebnisse, detaillierte Berichte, sorgfältige Analysen usw.

Eine wichtige Verbesserung wirkt sich natürlich auf das Ranking vieler Websites aus. Einige Websites steigen zwangsläufig auf und andere ab. Google baut auf die qualitativ hochwertigen Inhalte guter Websites aus aller Welt und fühlt sich für die Erhaltung eines gesunden Web-Ökosystems verantwortlich. Aus diesem Grund müssen Websites von hoher Qualität belohnt werden – und genau dies geschieht mit dieser Änderung.

Dieses Update ist keine Reaktion auf Feedback, das wir zu der letzte Monat veröffentlichten Google Chrome-Erweiterung "Personal Blocklist" erhalten haben. Allerdings haben wir die gesammelten Blocklist-Daten mit den von unserem Algorithmus gefundenen Websites verglichen und zu unserer Freude festgestellt, dass die Vorlieben unserer Erweiterungsnutzer gut vertreten sind. Mit dieser Algorithmusänderung werden 84 Prozent von mehreren Dutzend der am häufigsten von der Google Chrome-Erweiterung blockierten Domains angegangen. Dies ist ein ganz eigenständiger Beweis für die Nutzervorteile.

Wir sind sehr stolz auf diese neue Rankingverbesserung, denn wir glauben, dass dies ein großer Schritt in die richtige Richtung ist, nämlich, die Qualität der Ergebnisse für unsere Nutzer zu verbessern. Wir beschäftigen uns bereits seit über einem Jahr mit diesem Thema. Diese spezielle Veränderung haben wir in den vergangenen Monaten entwickelt. Und wir arbeiten noch an vielen weiteren Updates, die die Qualität der Seiten in unseren Ergebnissen erheblich verbessern werden.

Dieses Update wurde zunächst nur in den USA eingeführt, soll jedoch nach und nach auch in anderen Ländern verfügbar gemacht werden. Wir halten euch über die Einführung dieser und anderer Veränderungen auf dem Laufenden. Sendet uns auch weiterhin Feedback zur Qualität unserer Ergebnisse. Dies hilft uns sehr bei der Verbesserung der Google-Suche.

Finding more high-quality sites in search (English version)

Blogpost von Amit Singhal, Google Fellow, und Matt Cutts, Principal Engineer (Veröffentlichung von Jörg Pacher, Search Quality Team)

Manche Webmaster sind besorgt, vielleicht auf ewig von einer Google-Penalty betroffen zu sein. Matt Cutts geht deshalb im heutigen Video auf den Unterschied zwischen Algorithmen und manueller Arbeit ein und erklärt, wann und wie Penaltys aufgehoben werden.



Die heutige Frage stammt von Walter Chavez. Walter fragt: "Hallo Matt. Gibt es bei Google so etwas wie eine permanente Penalty? Oder werden Penaltys für Websites in jedem Fall aufgehoben, wenn die erforderlichen Korrekturen entsprechend den Google-Richtlinien vorgenommen wurden?"

Eine sehr gute Frage. Um sie zu beantworten, muss ich ein bisschen weiter ausholen und über Algorithmen und manuelle Vorgehensweisen sprechen. Wir wissen bereits, dass das Webspam-Team von Google bereit ist, manuelle Maßnahmen zu ergreifen. Das ist etwa der Fall, wenn wir einen Spam-Bericht erhalten, Pornografie auf nicht-porn Seiten, all so etwas. Aber wir benutzen all diese Daten auch, um unsere Algorithmen zuverbessern. Unsere Engineers schreiben Classifier für Spam-Inhalte, überflüssige Keywords, Cloaking und irreführende JavaScript-Weiterleitungen. All diese Dinge.

Nehmen wir nun also an, eure Website sei von einem Algorithmus betroffen. Dabei spielt es keine Rolle, was genau Ursache einer Meldung oder Auslöser dafür war, dass wir überflüssige Keywords oder etwas in der Art erkannt haben. Wenn ihr eure Website nun ändert, sollte, nachdem wir die Site erneut gecrawlt und indexiert haben und unsere Algorithmen genügend Zeit hatten, sie erneut zu verarbeiten, eure Website wieder in den Ergebnissen erscheinen bzw. sich im Ranking verbessern können. Bei manueller Vorgehensweise hingegen versuchen wir, soweit ich weiß, in der Mehrzahl der Fälle eine zeitliche Beschränkung festzulegen. Wenn wir also verborgenen Text finden, legen wir eine Penalty für verborgenen Text fest. Das können dann vielleicht 30 Tage sein. Nach deren Ablauf läuft alles wieder normal. Dann gibt es natürlich die schwereren Fälle. Cloaking etwa oder richtig böse Sachen. Hier dauert die Penalty zwar länger, läuft aber auch irgendwann ab.

Wir versuchen also, so vorzugehen, dass, wenn ihr eure Website verbessert, nachdem sie von einem Algorithmus betroffen wurde oder ihr etwas an eurer Website geändert habt, die Penalty irgendwann abläuft. Natürlich könnt ihr jederzeit einen Antrag auf erneute Überprüfung stellen. Wenn eine Penalty nach manueller Prüfung verhängt wurde, untersuchen wir den Vorfall. Und wenn wir zu dem Ergebnis kommen, dass sich die Website im Rahmen unserer Richtlinien bewegt, heben wir die Penalty auf. Eure Website ist dann sofort wieder zu sehen und ihr braucht euch keine Gedanken mehr um diese Penalty zu machen.

An dieser Stelle möchte ich erwähnen, dass, wenn ihr einen Antrag auf erneute Überprüfung stellt, wir zumindest zurzeit prüfen, ob eine Penalty manuell vergeben wurde. Dies kann etwa dann vorkommen, wenn jemand eine Verletzung unserer Richtlinien bemängelt hat. Dies wird also von uns überprüft. Wurde jedoch eine Site nur von unseren Algorithmen betroffen, jedoch nicht manuell eine Verletzung unserer Richtlinien festgestellt, könnt ihr in einem solchen Fall gegen das Ergebnis des Algorithmus keinen Widerspruch einlegen. Der Algorithmus wird schließlich weiterhin ausgeführt. Ihr müsstet also erst einmal eure Website ändern, damit sie von den Algorithmen nicht mehr als Spam erkannt wird. Das müsst ihr auf jeden Fall beachten, bevor ihr einen Antrag auf erneute Überprüfung stellt. Unser gegenwärtiger Ansatz sieht also so aus, dass wir nur manuell verhängte Penaltys überprüfen.

Veröffentlicht von Daniela Loesser, Search Quality Team

Wir haben bemerkt, dass immer mehr Fragen von Webmastern sich darauf beziehen, wie man eine Website optimal für Mobiltelefone strukturieren kann und wie Websites am besten mit dem Googlebot-Mobile interagieren können. In diesem Beitrag erläutern wir die aktuelle Situation und geben euch Empfehlungen, die ihr jetzt implementieren könnt.

Hintergrund

Beginnen wir mit einer einfachen Frage: Was meinen wir mit "Mobiltelefon", wenn wir über mobiltaugliche Websites reden?

Eine gute Antwort auf diese Frage wäre, an die Webbrowser-Funktionen des Mobiltelefons zu denken, insbesondere im Vergleich zu den Funktionen von modernen Desktop-Browsern. Der Einfachheit halber können wir Mobiltelefone in verschiedene Kategorien unterteilen:

1. Traditionelle Mobiltelefone: Telefone mit Browsern, die keine normalen Desktop-Webseiten rendern können. Dies sind Browser für cHTML (iMode), WML, WAP usw.
2. Smartphones: Telefone mit Browsern, die normale Desktopseiten rendern können, zumindest bis zu einem gewissen Punkt. Diese Kategorie enthält viele verschiedene Geräte wie das Windows Phone 7, Blackberry-Geräte, iPhones und Android-Telefone sowie Tablet-PCs und eBook-Reader.

Wir können diese Kategorie weiter nach Unterstützung von HTML5 unterteilen:

• Geräte mit Browsern, die HTML5 nicht unterstützen
• Geräte mit Browsern, die HTML5 unterstützen

Einst waren Mobiltelefone über Browser mit eingeschränkten Rendering-Funktionen mit dem Internet verbunden. Dies ändert sich jedoch mit dem schnellen Aufstieg der Smartphones, deren Browser jenen am Desktop nicht mehr nachstehen. Daher solltet ihr beachten, dass die Unterscheidung hier auf der aktuellen Situation basiert und sich in Zukunft ändern kann.

Der Googlebot und mobile Inhalte

Google hat zwei relevante Crawler zu diesem Thema: den Googlebot und den Googlebot-Mobile. Der Googlebot crawlt Webseiten von Desktop-Browsern sowie den dort eingebetteten Inhalt. Der Googlebot-Mobile wiederum crawlt mobile Inhalte. Die Fragen, die immer häufiger gestellt werden, können folgendermaßen zusammengefasst werden:

Welche Art von Inhalt sollte ich dem Googlebot-Mobile im Hinblick auf die Funktionen von mobilen Webbrowsern zur Verfügung stellen?

Die Antwort liegt in dem User-Agent, der den Googlebot-Mobile beim Crawlen unterstützt. Es gibt verschiedene Zeichenfolgen für den User-Agent, die der Googlebot-Mobile verwendet. Alle haben folgendes Format:

[Phone name(s)] (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)

Um zu entscheiden, welche Inhalte bereitgestellt werden sollen, überlegt, welche Inhalte auf eurer Website am besten für die Telefone in der Zeichenfolge des User-Agent geeignet sind. Eine vollständige Liste der User-Agents für den Googlebot-Mobile findet ihr hier.

Beachtet bitte, dass der Googlebot-Mobile derzeit keine Crawling-Vorgänge mithilfe einer User-Agent-Zeichenfolge für Smartphones durchführt. Daher stellt ein richtig konfiguriertes Inhaltsbereitstellungssystem derzeit Googlebot-Mobile-Inhalte nur für die oben genannten traditionellen Telefone zur Verfügung, da dies heutzutage von den verwendeten User-Agent-Zeichenfolgen so vorgegeben wird. Dies könnte sich künftig ändern, sodass wir dann eine neue User-Agent-Zeichenfolge für den Googlebot-Mobile hätten.

Derzeit erwarten wir, dass Smartphones Inhalte für Desktop-Computer anzeigen können, sodass momentan kein wirklicher Bedarf für Webmaster besteht, spezifische Inhalte für Mobiltelefone zu erstellen. Bei machen Websites kann es jedoch weiterhin sinnvoll sein, den Inhalt für Smartphones anders zu formatieren. Diese Entscheidung solltet ihr dahingehend treffen, wie ihr euren Nutzern die Inhalte am besten bereitstellen könnt.

URL-Struktur für mobile Inhalte

Andere Fragen beschäftigen sich mit den URLs, von denen mobile Inhalte bereitgestellt werden sollen. Lasst uns bei einigen Fällen mal ins Detail gehen.

Websites mit Inhalten exklusiv für Desktop-Computer

Die meisten Websites verfügen derzeit nur über eine Version ihres Inhalts, nämlich in HTML für Desktop-Webbrowser. Dies bedeutet, dass alle Browser über die gleiche URL auf den Inhalt zugreifen.

Diese Websites können möglicherweise ihre Inhalte nicht auf traditionellen Mobiltelefonen bereitstellen. Die Qualität der auf Smartphones angezeigten Inhalte hängt von dem verwendeten mobilen Browser ab. Möglicherweise ist die Qualität so gut wie die des Desktop-Browsers.

Wenn ihr nur Desktop-Inhalte für alle User-Agents bereitstellt, solltet ihr dies auch für den Googlebot-Mobile tun. Das heißt: Behandelt den Googlebot-Mobile genau so wie alle anderen oder unbekannten User-Agents. In diesen Fällen, kann Google eure Webseiten für ein besseres mobiles Erlebnis modifizieren.

Websites mit spezifischem mobilen Inhalt

Viele Websites verfügen über Inhalte, die speziell für Nutzer von Mobiltelefonen optimiert wurden. Der Inhalt könnte einfach für die üblicherweise kleineren mobilen Displays neu formatiert oder in einem anderen Format bereitgestellt worden sein (beispielsweise über WAP usw.).

Eine sehr häufig gestellte Frage lautet: Ist es wichtig, ob die verschiedenen Arten von Inhalt über die gleiche URL oder von verschiedenen URLs bereitgestellt werden? Beispielsweise lautet die URL, auf die Desktop-Browser zugreifen sollen, "www.example.com", und die URL für die verschiedenen Mobilgeräte lautet "m.example.com" oder "wap.example.com". Andere Websites stellen alle Arten von Inhalt nur über eine URL-Struktur wie "www.example.com" bereit.

Für den Googlebot und den Googlebot-Mobile ist es egal, wie die URL-Struktur aussieht, solange sie genau das zurückgibt, was der Nutzer auch sieht. Wenn ihr beispielsweise mobile Nutzer von "www.example.com" zu "m.example.com" weiterleitet, wird dies vom Googlebot-Mobile erkannt. Beide Websites werden gecrawlt und dem richtigen Index hinzugefügt. Verwendet in diesem Fall eine 301-Weiterleitung sowohl für Nutzer als auch den Googlebot-Mobile.

Wenn ihr alle Inhaltstypen von "www.example.com" aus bereitstellt, z.B. für Desktops oder Mobilgeräte optimierte Inhalte von der gleichen URL je nach User-Agent, können Googlebot und Googlebot-Mobile eure Website richtig crawlen. Dies wird von Google nicht als Cloaking betrachtet.

Ich möchte noch einmal betonen, dass ihr den User-Agent wie von euren Nutzern und dem Googlebot-Mobile vorgegeben richtig erkennen und beiden den gleichen Inhalt bereitstellen müsst - ungeachtet der URL-Struktur. Vergesst nicht, den Standardinhalt, also den Desktop-Inhalt, beizubehalten, für den Fall, dass ein unbekannter User-Agent diesen anfordert.

Mobile Sitemaps in Webmaster-Tools

Wir erhalten auch viele Fragen darüber, welche URLs für mobile Sitemaps verwendet werden sollen. Wie in unserer Hilfe für mobile Sitemaps erläutert, solltet ihr nur URLs für mobile Inhalte in mobile Sitemaps einfügen, auch wenn diese URLs zusätzlich Inhalte zurückgeben, die nicht für Mobilgeräte geeignet sind, wenn ein User-Agent darauf zugreift, der nicht nach mobilen Inhalten sucht.

Noch Fragen?

Ein guter Ansatzpunkt sind unsere Artikel in der Hilfe für mobile Websites sowie die relevanten Abschnitte in unserer SEO-Starter-Guide. Solltet ihr noch Fragen haben, freuen wir uns, wenn ihr im Webmaster-Forum vorbeischaut.

Making Websites Mobile Friendly (English version)

Post von Pierre Far, Webmaster Trends Analyst (Veröffentlichung von Jörg Pacher, Search Quality Team)

Bisher musste man sich bei der Erstellung einer Website oder Webanwendung weitgehend mit einigen wenigen "websicheren" Schriftarten wie Times und Arial begnügen. Wollte man eine andere Schriftart einbauen, musste man Adobe Flash verwenden oder Text in Bilder einbetten, wobei man wiederum eine Reihe Kompromisse in anderen Bereichen eingehen musste. So sind Bilder beispielsweise nicht semantisch und können nicht automatisch in andere Sprachen übersetzt werden. Zudem sind Bilddateien häufig sehr viel größer als Textdateien. Darüber hinaus kann Text in Bildern nicht in die Zwischenablage kopiert, nicht mit einer Bildschirmlese-Software gelesen und auch nicht reibungslos von Suchmaschinen indexiert werden.

Hier die gute Nachricht: Mit Google Web Fonts können jetzt Hunderte von websicheren Schriftarten auf Webseiten verwendet werden. Seit Mai vergangenen Jahres könnt ihr mit Google Web Fonts ganz einfach die Schriftart(en) auswählen, die ihr auf eurer Webseite, in eurem Blog oder in eurer Webanwendung verwenden möchtet, und das entsprechende HTML- und CSS-Snippet einbetten. Nach ca. 30 Sekunden habt ihr wunderschöne Schriftarten auf euren Seiten, die in den allermeisten modernen Webbrowsern korrekt angezeigt werden. Ihr müsst keine Bilder oder Flash mehr verwenden, um die Schriftart eurer Wahl einzubetten. 

Im Gegensatz zu Times und Arial, die auf Schriftarten verweisen, die auf dem lokalen Rechner installiert sind, werden Webschriftarten ähnlich wie ein Bild über eine Browseranfrage bereitgestellt. Auf diese Weise kann jede beliebige Webschriftart per Push auf den Computer eines Nutzers übertragen werden. Zur Freude der Nutzer verhalten sich diese Schriftarten genau wie jeder andere Text in Arial-Schriftart.

Beispiele für Webschriftarten von Google Web Fonts

Die Übernahme der Webschriftart-Technologie verläuft rasant. Google Web Fonts erhält täglich etwa 50 Millionen Anfragen[1] von ca. 800.000 individuellen Websites[2]. Der monatliche Zuwachs beträgt ungefähr 30 Prozent. Wir bei Google freuen uns über die neuen Möglichkeiten, die Webschriftarten für das Web bieten. Es ist viel angenehmer, Seiten mit schönen, interessanten und ausdrucksstarken Schriftarten im Web anzusehen.

Auf ein visuell ansprechendes Web!

Beyond Times and Arial - The New Web Safe Fonts (English version)

Post von David Wurtz, Product Manager, Google Web Fonts (Veröffentlichung von Jörg Pacher, Search Quality Team)

[1] Eine Anfrage ist eine einzelne Anforderung einer oder mehrerer Schriftarten beim Google Font-API.
[2] Eine individuelle Website wird als eindeutige Domain gezählt. "www"-Subdomains werden jedoch nicht gezählt. Beispiel: www.meinblog.com und meinblog.com würden als eine Domain zählen. peter.meinblog.com und sabine.meinblog.com würden hingegen als zwei Domains zählen.

Heute klärt Matt Cutts einige Missverständnisse, die bezüglich Google und SEO kursieren, und geht dabei auf Links und nofollow, Meta-Tags und das Google Webspam-Team näher ein.



Die heutige Frage kommt von Tom S. aus Seattle und lautet : "Nenne fünf Beispiele für falsche SEO-Informationen aus dem letzten Jahr, die aus seriösen Quellen stammen und dich an den Rand der Verzweiflung brachten. Du musst keine Namen nennen."

Okay. Mir fallen mindestens zwei Beispiele ein, denen ich noch weitere Trugschlüsse hinzufügen möchte. Am meisten kopfschütteln musste ich bei der Meinung, dass die Links automatisch zählen, wenn sich Kunden bei negativen Erfahrungen auf entsprechenden Websites beschweren. Diese Idee ist gefährlich: Je schlechter man seine Kunden behandelt, desto mehr Links erhält man und desto höher das Ranking bei Google. Das ist ganz eindeutig ein Trugschluss. Thor von getsatisfaction.com schrieb in einem Blog, dass diese Links ein "nofollow"-Attribut erhalten. Der "nofollow"-Mechanismus weist darauf hin, dass man diesen Link zu einem Drittanbieter nicht unbedingt befürwortet. Man kann damit also sagen: Auch wenn dies eine namhafte Website ist, vertrauen wir diesem "nofollow"-Link nicht unbedingt. Wir überspringen sie in unserem Link-Graph, damit sie keine Rolle beim Ranking spielt. Durch diesen Link fließt kein Ankertext. Daher hat keine der Beschwerde-Websites zu den Such-Rankings einer bestimmten Website beigetragen.

Ein weiterer Trugschluss ist, dass das Google-Webspam-Team dieses Jahr etwas nachlässiger sei. Nur weil manche SEOs nicht sehen, an was das Webspam-Team arbeitet, heißt das nicht, dass wir nicht aktiv sind. Eine der größten Herausforderungen im Jahr 2010 waren gehackte Websites. Es gibt viele Leute da draußen, die im Grunde illegale Aktivitäten tätigen. Manche versuchen, Websites zu hacken und eigene Links einzufügen, oder Malware, Viren und Trojaner zu verbreiten. Auf diese bösartigen Aktivitäten wollten wir uns konzentrieren und diese verhindern. Daran mussten viele Mitarbeiter mehrere Monate arbeiten und andere Veränderungen wurden nicht so richtig wahrgenommen. Solange wir gegen gehackte Spam-Websites vorgehen, sieht man vom normalen Kampf gegen Spam vielleicht nicht mehr viel. Die meisten Veränderungen wegen gehackter Websites sind mittlerweile eingeführt, sodass wir uns wieder dem normalen Web-Spam zuwenden können.

Ein weiterer Trugschluss ist, dass nur Links zählen. Manch einer denkt: "Ich brauche nur Links und sonst gar nichts." Guter Inhalt auf der Website spielt aber auch eine Rolle. Baut also nicht nur auf Links. Achtet auch auf die Architektur eurer Website, ihre Crawlbarkeit, wie gut durchsuchbar sie ist, ob ihr gute interne Links habt, ob die Begriffe auf eurer Seite stehen, nach denen die Nutzer wirklich suchen. All das ist wirklich wichtig.

Ein spezieller Trugschluss, auf den ich hinweisen will, ist, dass das Meta-Tag der Keywords im Such-Ranking von Google irgendeine Rolle spielen würde. Tut es einfach nicht. Wir verwenden das Meta-Keywords-Tag nicht.

Außerdem höre ich immer wieder, dass das Web-Spam-Team entweder nur mit Algorithmen oder nur manuell arbeitet. Wir behalten uns vor, Websites manuell zu entfernen, wenn wir Spam oder andere Probleme feststellen. Wir haben ein manuelles Team in vielen Sprachen auf der ganzen Welt. Wir sind stolz auf dieses Team, das tolle Arbeit leistet. Auch die anderen großen Suchmaschinen haben ein Team, das manuell nach Spam sucht. Die Teams entfernen nicht nur Spam, sondern geben auch Übungsdaten an Entwickler weiter, die an der Spam-Bekämpfung arbeiten. Es sind also nicht nur Entwickler und es sind nicht nur manuelle Prüfer, die sich mit Spam-Meldungen beschäftigen. Mit einer Kombination aus diesen beiden geht Google gegen Web-Spam vor.

Das waren also ein paar Dinge, die ich gerne richtigstellen wollte.

Veröffentlicht von Daniela Loesser, Search Quality Team