Webmaster-Zentrale Blog
Offizielle Informationen zum Crawling und zur Indexierung von Webseiten und News für Webmaster
Wie ihr Kommentar-Spam loswerdet
Montag, 29. September 2008
Vielleicht habt ihr gerade zum ersten Mal ein Forum in eure Site eingebaut oder die Kommentarfunktion eures Blogs aktiviert. Ihr gebt euch Mühe, ein oder zwei Posts zu schreiben, klickt auf "Senden" und freut euch mit angehaltenem Atem auf die ersten Kommentare.
Diese lassen dann auch nicht lange auf sich warten. Vielleicht bekommt ihr eine nette Nachricht eines Blogger-Kollegen, ein wichtiges Update eines Mitglieds eurer MMORPG-Gilde oder eine Erinnerung von Tante Millie an das Abendessen am Donnerstag. Aber dann kommt vielleicht etwas anderes - etwas... beunruhigendes. Werbung für Angebote, die zu gut klingen, um wahr zu sein, ein bizarrer Schwall unzusammenhängender Worte und eindeutige Bilder, die Tante Millie besser nicht sehen sollte. Alles Zeichen dafür, dass ihr von einer Lawine nervenden
Kommentar-Spams
überrollt wurdet.
Kommentar-Spam ist in jeder Beziehung schlecht: Für euch, weil es euch zusätzliche Arbeit beschert. Für eure User, die eigentlich nützliche Informationen auf eurer Site finden wollen anstatt seltsamer Links und unzusammenhängendem Content. Schließlich schadet es auch dem Web insgesamt, da durch den Kommentar-Spam viele Leute davon abgehalten werden, ihre Site für user-generierten Content zu öffnen oder sich selbst an den Unterhaltungen in bereits bestehenden Foren zu beteiligen.
Was könnt ihr als Webmaster also dagegen tun?
Die folgende Liste sollte euch schon mal weiterhelfen (Hinweis: Die Liste soll nur als Ausgangspunkt dienen und erhebt keinen Anspruch auf Vollständigkeit). Es gibt so viele verschiedene Blog-, Forum- und Message-Board-Systeme, dass wir unmöglich für alle Systeme detaillierte Anweisungen geben können - wir haben die einzelnen Punkte deshalb so formuliert, dass die Konzepte auf die meisten Systeme zutreffen sollten.
Stellt sicher, dass die Kommentare von Menschenhand verfasst sind
Nutzt ein
CAPTCHA
. Bei CAPTCHAs werden User dazu aufgefordert, eine leicht verschleierte Zeichenfolge zu entziffern und das Resultat in ein Textfeld einzugeben, um damit zu demonstrieren, dass es sich um echte Menschen handelt und nicht um ein automatisiertes Skript. Falls euer Blog- oder Forum-System standardmäßig keine CAPTCHAS anbietet, könnt ihr ggf. ein entsprechendes Plug-in verwenden, wie z. B.
Recaptcha
, ein Projekt, das auch beim Digitalisierern alter Bücher eingesetzt wird. CAPTCHAs sind kein Allheilmittel, aber sie machen den Spammern das Leben bereits ein klein wenig schwerer.
Hier könnt ihr mehr über die verschiedenen Arten von CAPTCHAs erfahren
, bedenkt dabei aber, dass bereits ein simples CAPTCHA bereits recht effektiv sein kann.
Blockiert verdächtige Verhaltensweisen. Bei vielen Foren könnt ihr ein Zeitlimit setzen (für wiederholte Postings des gleichen Nutzers) und es gibt zahlreiche Plug-ins, die vor exzessivem Traffic von identischen IPs schützen und zahlreiche andere Verhaltensweisen, die charakteristisch für automatisierte Skripte sind, erkennen helfen.
Verwendet eine automatische Filterung
Eindeutig unerwünschte Kommentare könnt ihr häufig blockieren, indem ihr bestimmte Worte einer sogenannten "Blacklist" hinzufügt. Da viele Spammer häufig einzelne Worte in ihren Kommentaren verschleiern, ist diese Filterung nicht immer eine zuverlässige Lösung - sie kann jedoch bei plumpen Spamversuchen recht nützlich sein.
Verwendet die bereits eingebauten Anti-Spam-Funktionen eures Systems oder setzt entsprechende Plug-ins ein. Spammer verwenden in der Regel automatisierte Tools beim Angriff auf eure Site - warum also nicht auch automatisierte Tools zur eigenen Verteidigung nutzen? Umfangreiche Lösungen wie z. B.
Akismet, das Plug-ins für viele Blogs und Forum-Systeme anbietet
, oder z. B. die zu Akismet kompatible Open-Source-Lösung
TypePad AntiSpam
sind leicht zu installieren und nehmen euch dann die meiste Arbeit ab.
Probiert, falls vorhanden, Bayessche Filter-Funktionen aus. Dabei müsst ihr euer System "trainieren", den Spam zu erkennen, was einen gewissen Aufwand bedeutet.
Diese Technik hat sich aber vor allem beim E-Mail-Spam als sehr erfolgreich erwiesen
.
Seid bei euren Voreinstellungen etwas strenger
Setzt Links, denen ihr nicht vertraut, auf
"nofollow"
. Viele Systeme bieten eine Einstellmöglichkeit, um das rel="nofollow"-Attribut bei Kommentar-Links zu setzen, oder machen dies bereits standardmäßig. Dies kann bereits vor einigen Arten von Spam schützen, sollte jedoch nicht eure einzige Maßnahme bleiben.
Denkt darüber nach, für das Posten von Kommentaren die Erstellung eines Nutzer-Kontos auf eurer Site vorauszusetzen. Dies erfordert zwar zusätzliche Schritte von euren Besuchern und könnte vor allem Gelegenheitsbesucher davon abhalten, Kommentare zu hinterlassen. Gleichzeitig wird so aber auch das Signal-Rausch-Verhältnis erhöht. ;)
Ändert eure Einstellungen dahingehend, dass Kommentare erst von euch "freigeschaltet" werden müssen, bevor sie auf der Site erscheinen. Dies eignet sich besonders dann, wenn ihr einen hohen Standard bei den Kommentaren gewährleisten wollt, nicht allzu viele Kommentare erwartet oder nur eine kleine private Site betreibt. Ihr könnt beispielsweise Angestellten/Kollegen oder vertrauten Nutzern erlauben, die eigenen Posts freizuschalten und den Arbeitsaufwand auf diese Weise etwas aufteilen.
Bestimmte Arten von Kommentaren könnt ihr ggf. ganz deaktivieren. Beispielsweise könnte es sinnvoll sein, die Kommentarfunktion für sehr alte Posts zu deaktivieren, falls es unwahrscheinlich ist, dass dort noch organische Kommentare erscheinen werden. Bei Blogs bietet es sich häufig an, die Trackbacks oder Pingbacks zu deaktivieren - dies sind zwar coole Features, bilden jedoch gleichzeitig ein Einfallstor für automatisch generierten Spam.
Haltet eure Site auf dem neusten Stand
Nehmt euch die Zeit, um eure Software auf dem neusten Stand zu halten und haltet besonders nach wichtigen Sicherheits-Updates Ausschau. Spammer machen sich gern Sicherheitslücken in älteren Versionen von Blogs, Message-Boards und anderen CMS zu nutze. Zusätzliche hilfreiche Maßnahmen könnt ihr auch unserer
Sicherheits-Checkliste für Webmaster
entnehmen.
Es ist an euch, zwischen den angesprochenen Möglichkeiten die richtige Balance zu finden, je nachdem, welche Blog- oder Message-Board-Software ihr verwendet, wer eure hauptsächlichen Nutzer sind und je nach eurem persönlichen Grad an Erfahrung im Umgang mit Kommentar-Spam. Es stellt ein großes Risiko dar, gänzlich unvorbereitet eine Site für Kommentare zu öffnen - egal ob es sich nur um einen kleinen privaten Blog oder um eine Site mit tausenden von Usern handelt. Sollte euer Forum aber dennoch einmal durch tausende von Spam-Posts überflutet worden sein und gar nicht mehr in der Google-Suche auftauchen, dann solltet ihr zunächst den ganzen Schrott entfernen und einige der hier beschriebenen Maßnahmen treffen, um in Zukunft dagegen gewappnet zu sein. Anschließend könnt ihr ggf. einen
Antrag auf erneute Überprüfung
einreichen.
Aus Erfahrung als
langjähriger Blogger und Web-Developer
kann ich euch sagen, dass sich dieser kleine Aufwand im Vorfeld auf jeden Fall bezahlt macht und euch im Nachhinein eine Menge Arbeit erspart. Ich bin neu im Webmaster Central Team und komme ursprünglich aus Cleveland. Ich finde es spannend, Webmaster-Kollegen zu helfen und bin sehr an Fragen der Usability und Search Quality interessiert (worüber ich auch
ein wenig akademische Forschung
betrieben habe). Wir freuen uns auf eure Tipps zur Vermeidung von Forum- und Kommentar-Spam - hinterlasst doch einfach einen Kommentar. ;) Wie immer könnt ihr natürlich auch wieder eure Fragen in unserem
Forum für Webmaster
diskutieren.
Keeping comment spam off your site and away from users (English version)
Post von Jason Morrison, Search Quality Team (Übersetzung von Sven, Search Quality)
Alles über dynamische URLs
Montag, 22. September 2008
Durch zahlreiche Gespräche mit Webmastern haben wir festgestellt, dass es viele weit verbreitete Annahmen gibt, die vielleicht in der Vergangenheit zutreffend waren, jedoch heute nicht mehr unbedingt aktuell sind. Genau das ist uns aufgefallen als wir uns neulich mit ein paar Freunden über die Struktur von URLs unterhalten haben. Eine unserer Freundinnen war sehr abgeneigt gegen die Verwendung von dynamischen URLs, da sie der Meinung war "Suchmaschinen können damit gar nichts anfangen!". Ein anderer Bekannter wiederum wandte ein, dass dynamische URLs überhaupt kein Problem darstellten und dass diese Schwierigkeiten längst der Vergangenheit angehörten. Jemand sagte in diesem Zusammenhang sogar, dass er die ganze Aufregung um statische URLs im Vergleich zu dynamischen URLs nicht nachvollziehen könne. Für uns war dieses Gespräch der Moment, uns weitergehend mit diesem Thema zu beschäftigen, um Klarheit zu schaffen über statische und dynamische URLs.
Lasst uns kurz erklären, worum es eigentlich geht:
Was ist eine statische URL?
Eine statische URL ist eine URL, die sich nicht verändert - typischerweise enthält diese URL keine URL-Parameter. So eine URL kann etwa so aussehen: http://www.example.com/archive/january.htm. Ihr könnt nach weiteren URLs dieser Art suchen, in dem ihr
filetype:htm
in die Google-Suche eingebt. Die Pflege solcher URLs kann sehr zeitaufwändig sein, besonders, wenn die Menge an Informationen schnell wächst, da jede einzelne Seite direkt im Quellcode verändert werden muss. Dies ist ein Grund, warum Webmaster, die große, sich häufig ändernde Sites besitzen wie Online-Shops, Foren, Blogs oder Content-Management-Systeme, eher dynamische URLs verwenden.
Was ist eine dynamische URL?
Wenn der Content einer Site in einer Datenbank gespeichert ist und nur auf Anfrage auf diesen zugegriffen wird, dann werden dynamische URLs eingesetzt. In diesem Fall ist die Site ein Template, in welches sich ständig ändernder Content eingefügt wird. Normalerweise sieht eine dynamische URL so aus: http://code.google.com/p/google-checkout-php-sample-code/issues/detail?id=31. Man kann dynamische URLs sehr leicht daran erkennen, dass sie Sonderzeichen wie diese enthalten: ? = &. Dynamische URLs haben den Nachteil, dass verschiedene URLs ein und denselben Content haben können. Dies kann dazu führen, dass mehrere User auf unterschiedliche dynamische URLs mit verschiedenen Parametern linken, die eigentlich denselben Content haben. Das könnte beispielsweise ein Beweggrund für Webmaster sein, die URLs in statisch aussehende URLs umzuformen.
Sollte ich meine dynamischen URLs in statisch aussehende URLs umwandeln?
Wir haben im Folgenden ein paar Punkte zusammengetragen, die ihr beachten solltet, wenn ihr dynamische URLs benutzt.
Es ist ziemlich schwer, eine dynamische URL in richtiger Weise in eine statisch aussehende URL umzuwandeln und diese dann zu pflegen.
Es ist viel besser, wenn ihr uns die ursprüngliche dynamische URL anbietet und es uns überlasst, problematische Parameter aufzuspüren und zu umgehen.
Wenn ihr eure URL umschreiben wollt, so könnt ihr unnötige Parameter entfernen, solltet aber die dynamisch aussehende URL beibehalten.
Wenn ihr eine statische URL anstelle einer dynamischen URL anbieten wollt, solltet ihr eine statische Kopie des dazugehörigen Contents erstellen.
Was versteht der Googlebot besser, eine statische oder eine dynamische URL?
Wir haben viele Webmaster getroffen, die wie unsere Freunde annehmen, dass statische oder statisch aussehende URLs einen Vorteil für Indexierung und Ranking mit sich bringen würden. Dies liegt hauptsächlich an dem Vorurteil, dass Suchmaschinen Probleme damit haben, URLs zu analysieren und zu crawlen, die Session-IDs und Source Tracking verwenden. Tatsächlich haben wir bei Google Fortschritte in beiden Bereichen erzielt. Auch wenn statische URLs noch immer einen kleinen Vorteil in Hinblick auf die Click-Through-Rate (CTR) bieten, da User diese statischen URLs viel einfacher lesen und interpretieren können, so bedeutet die Entscheidung, eine datenbankgestützte Website und somit dynamische URLs zu erstellen, keinen Nachteil in Bezug auf Indexierung und Ranking. Ihr solltet dynamische URLs, wenn möglich, dem Erstellen einer statisch aussehenden URL vorziehen.
Lasst uns nun mit einigen weit verbreiteten Behauptungen in Bezug auf dynamische URLs aufräumen.
Mythos: "Dynamische URLs können nicht gecrawlt werden."
Fakt:
Wir können dynamische URLs crawlen und die verschiedenen Parameter interpretieren. Wir könnten Probleme beim Crawling und Ranking eurer Site haben, wenn ihr versuchen solltet, eure URLs statisch erscheinen zu lassen und derweil Parameter versteckt, die dem Googlebot eventuell wertvolle Informationen geliefert hätten.
Eine unserer Empfehlungen ist es, die Umwandlung von URLs, damit sie statisch aussehen, zu vermeiden.
Es ist natürlich immer angebracht, bei statischem Content auch statische URLs zu verwenden, aber in Fällen, in denen ihr dynamischen Content anbietet, solltet ihr uns die Möglichkeit geben, eure URL-Struktur zu analysieren anstatt die URL statisch aussehen zu lassen und Informationen durch versteckte Parameter zu beseitigen.
Mythos: "Dynamische URLs sind in Ordnung, so lange sie weniger als drei Parameter besitzen."
Fakt:
Es gibt keine Begrenzung der Anzahl an Parametern, die man benutzen sollte, aber
eine gute Daumenregel ist es, die URLs so kurz wie möglich zu halten
(das trifft auf alle URLs zu, ob sie nun statisch oder dynamisch sind). Wenn ihr in der Lage seid, Parameter zu entfernen, die für den Googlebot nicht so wichtig sind, könnt ihr euren Usern eine leicht verständliche dynamische URL anbieten. Falls ihr nicht wissen solltet, welche Parameter entfernt werden können, so empfehlen wir euch, uns alle Parameter in eurer dynamischen URL anzubieten, damit unser System selbst die unwichtigen Parameter herausfiltern kann. Wenn Parameter versteckt sind, so können wir die URLs nicht richtig analysieren oder Parameter nicht als solche erkennen, was zum Verlust wichtiger Informationen führen kann.
Nun wollen wir noch ein paar Fragen beantworten, die ihr vielleicht an dieser Stelle haben könntet.
Bedeutet das, ich sollte es vermeiden, URLs umzuformatieren?
Das empfehlen wir, es sei denn, eure Umformatierung beschränkt sich darauf, unwichtige Parameter zu entfernen oder sie beinhaltet die sorgfältige Beseitigung aller Parameter, die Probleme verursachen können. Solltet ihr dynamische URLs umwandeln, damit sie statisch aussehen, so kann es sein, dass wir nicht in der Lage sind, die Informationen in jedem Fall korrekt zu interpretieren. Wenn ihr einen statischen Ersatz für eure dynamische URL liefern wollt, solltet ihr es in Betracht ziehen, auch den zu Grunde liegenden Content zu verändern, in dem ihr eine statische Kopie erstellt. Ein Beispiel wäre es, Dateien für alle Pfade zu erstellen und an einer Stelle eurer Site zugänglich zu machen. Solltet ihr jedoch eher URLs umwandeln (anstatt eine Kopie des Contents zu erstellen), um eine statisch aussehende URL aus einer dynamischen zu erzeugen, könnte das mehr nachteilig als gut sein. Ihr könnt uns immer eure eigentliche dynamische URL anbieten und wir filtern automatisch die Parameter heraus, die unwichtig sind.
Könnte ich ein Beispiel sehen?
Wenn ihr eine dynamische URL habt, die in einem Standardformat wie diesem vorliegt: foo?key1=value&key2=value2, so empfehlen wir euch, die URL auch in diesem Format zu belassen. Wir werden dann die Parameter bestimmen, die getrost entfernt werden können. Ihr könnt natürlich auch die Parameter für uns entfernen. Seid dabei aber sehr sorgsam, so dass ihr nur Parameter löscht, die keine Rolle spielen, wie zum Beispiel Session-IDs. Hier ist eine dynamische URL mit ein paar Parametern:
www.example.com/article/bin/answer.foo?language=en&answer=3&sid=98971298178906&query=URL.
language=en
- gibt die Sprache des Artikels an
answer=3
- der Artikel hat die Nummer 3
sid=98971298178906
- die Session-ID hat die Nummer 98971298178906
query=URL
- die Suchanfrage, mit der der Artikel gefunden wurde [URL]
Nicht alle der dargestellten Parameter bieten dem Googlebot zusätzliche Informationen. Wenn ihr die URL umformatiert, so dass sie folgendermaßen aussieht:
www.example.com/article/bin/answer.foo?language=en&answer=3
würde es wahrscheinlich keine Probleme bereiten, da alle unwichtigen Parameter entfernt wurden und die URL für den Googlebot interpretierbar bleibt.
Im Folgenden sind einige Beispiele statisch aussehender URLs aufgelistet, die womöglich mehr Probleme beim Crawling hervorrufen können als eine dynamische URL, die nicht umgewandelt wurde.
www.example.com/article/bin/answer.foo/en/3/98971298178906/URL
www.example.com/article/bin/answer.foo/language=en/answer=3/sid=98971298178906/query=URL
www.example.com/article/bin/answer.foo/language/en/answer/3/sid/98971298178906/query/URL
www.example.com/article/bin/answer.foo/en,3,98971298178906,URL
Wenn ihr dynamische URLs umwandelt und sie so aussehen lasst wie in den eben gezeigten Beispielen, könnte dies zu Problemen beim Crawling führen, da wir denselben Content unnützerweise über mehrere URLs crawlen, die alle verschiedene Werte für
sid
(Session-ID) und
query
haben. Die dargestellten URL-Formate erschweren es uns zu verstehen, dass
URL
und
98971298178906
überhaupt nichts mit dem eigentlichen Content, der über diese URL ausgegeben wird, zu tun haben. Hier noch ein weiteres Beispiel einer Umformatierung, bei der alle irrelevanten Parameter entfernt wurden:
www.example.com/article/bin/answer.foo/en/3
Obwohl wir diese Form der Umwandlung richtig interpretieren können, würden wir euch trotzdem davon abraten, sie zu benutzen, da sie sehr schwer zu pflegen ist und jedesmal aktualisiert werden muss, sobald ein neuer Parameter zur eigentlichen dynamischen URL hinzugefügt wird. Wenn diese URLs nicht gepflegt werden, hättet ihr wieder eine statisch aussehende URL, die Parameter versteckt. Die einfachste Lösung ist daher oft, die dynamischen URLs so zu belassen wie sie sind. Ihr könnt irrelevante Parameter entfernen, aber lasst die URL dynamisch, wie in dem Beispiel weiter oben gezeigt wurde:
www.example.com/article/bin/answer.foo?language=en&answer=3
Wir hoffen, dass dieser Artikel euch weitergeholfen hat, ein paar Dinge rund um dynamische URLs zu klären. Falls ihr weitere Fragen habt, dann schaut doch in unserer
Diskussionsgruppe
vorbei.
Post von Juliane Stiller and Kaspar Szymanski, Search Quality Team
Webmaster-Tools - ganz einfach
Donnerstag, 18. September 2008
Wir arbeiten immer daran, das Leben für Webmaster ein bisschen einfacher zu machen. Zu vielen Initiativen, die wir um die Webmaster-Tools herum gestartet haben, bekamen wir sehr gutes Feedback von euch. Da aber der Aufbau und die Pflege einer Website eine komplexe Angelegenheit ist, gibt es zu den Webmaster-Tools einige Fragen, die häufig in unseren Foren für Webmaster gestellt wurden. Daraufhin haben wir uns überlegt, wie wir diese Fragen am besten beantworten können.
Ihr findet es vielleicht genauso wie ich viel einfacher etwas zu lernen, wenn ihr vorher jemand anderem dabei zugeschaut habt. Mit dieser Überlegung werden wir in den nächsten Monaten eine Folge von sechs Video-Anleitungen posten. Diese Videos zeigen euch nicht nur ersten Schritte in den Webmaster-Tools, sondern auch wie ihr die bereitgestellten Informationen in den Tools auswerten könnt, um Veränderungen an eurer Site vorzunehmen und so eure Präsenz im Google-Index zu verbessern.
Unser erstes Video verschafft euch eine Überblick über die Informationen, die ihr bereitgestellt bekommt, wenn ihr eure Site in den Webmaster-Tools verifiziert habt. Wir stellen auch die unterschiedlichen Methoden vor, wie ihr eure Site verifizieren könnt.
Viel Spaß dabei:
Und hier noch eine Vorschau auf die gesamte Serie der Video-Anleitungen:
Video 1: Erste Schritte, Anmelden, Vorteile eure Site zu verifizieren
Video 2: Präferenzen für Crawling und Indexierung einstellen
Video 3: Erstellen und Einreichen von Sitemaps
Video 4: Entfernen eures Inhalts aus dem Index
Video 5: Die Bereiche Diagnose, Statistiken und Links
Video 6: Wie ihr mit Google kommunizieren könnt
Webmaster Tools made easier in French, Italian, German and Spanish (English version)
Post von Rebecca Steelman, Search Quality (Übersetzung von Juliane, Search Quality)
Search-Evaluierung in Google
Dienstag, 16. September 2008
Diese Reihe
von Posts hat Googles Search Quality-Aktivitiäten auf Gebieten wie Ranking und Search-UI beschrieben. In diesem Post werde ich mich mit dem Thema Search-Evaluierung befassen. Einfach gesagt ist Search-Evaluierung der Prozess, um sowohl die Qualität unserer Suchergebnisse zu bestimmen als auch die Qualität der Erfahrung unserer User mit der Suche.
Ich möchte mich kurz vorstellen. Ich bin Scott Huffman und als Engineering Director für Search-Evaluierung verantwortlich, indem ich mit einem talentierten Team aus Statistikern und Softwareingenieuren zusammenarbeite. Ich bin seit 2005 in diesem Bereich tätig, und ich habe bereits die letzten 14 Jahre im weiteren Sinne an Search gearbeitet.
Wenn ich Leute interviewe, die daran interessiert sind, dem Search-Evaluierungs-Team beizutreten, dann verwende ich oft folgendes Szenario, um zu beschreiben, was wir tun: Stell dir vor, ein Google Ranking-Ingenieur stürmt in dein Büro und behauptet "Ich habe eine tolle Idee um unsere Suchergebnisse zu verbessern! - Immer wenn der Titel einer Seite mit dem Buchstaben T beginnt, dann schieben wir dieses Ergebnis um drei Plätze nach oben." Der Ingenieur zieht verschiedene Suchanfragen aus der Tasche, bei denen - mag man es nun glauben oder nicht - die besagte Idee das Suchergebnis tatsächlich immens verbessern würde.
Nun, wir beide mögen vielleicht denken, dass dieser Hack mit dem Buchstaben T eine ziemlich alberne Idee ist - aber wie können wir tatsächlich sicher sein? In der Search-Evaluierung dreht es sich permanent darum, Antworten auf solche Fragen zu finden. Dieser Hack wurde zwar nie tatsächlich vorgeschlagen, jedoch sind wir ständig damit beschäftigt, alle Optionen auszuwerten, wie beispielsweise:
- Verbesserungsvorschläge zur Segmentierung von chinesischen Suchanfragen
- neue Ansätze um Spam zu bekämpfen
- Techniken um die Art und Weise zu verbessern, wie wir zusammengesetzte schwedische Wörter handhaben.
- Änderungen der Art und Weise wie wir Links und Linktext behandeln
- alles Mögliche andere
Wie Udi bereits in seinem
ersten Post
über Search Quality erwähnt hat, haben wir im Jahr 2007 über 450 Verbesserungen an der Google-Suche durchgeführt, und jede einzelne von ihnen ging durch einen komplexen Evaluierungsprozess.
Es ist nicht verwunderlich, dass wir Search-Evaluierung sehr ernst nehmen. Präzise Evaluierung versetzt unser Team in die Lage, zu wissen "welcher Weg nach oben führt". Einer unserer Grundsätze in Search Quality ist es, unsere Entscheidungen stark auf Daten zu gründen. Wir wollen uns nicht auf vereinzelte Beispiele verlassen, die für ein Produkt wie die Suche oft in die Irre leiten können - immerhin wirken sich dort Entscheidungen täglich auf hunderte Millionen von Suchanfragen aus. Durch äußerst sorgfältige und statistisch aussagekräftige Evaluierung erhalten wir die Daten, die wir brauchen, um tatsächliche Verbesserungen im Bereich der Suche zu erzielen.
Suche zu evaluieren ist aus verschiedenen Gründen schwierig:
Erstens müssen wir verstehen, was User tatsächlich wollen, wenn sie eine Suchanfrage eingeben - diese "Intention" der Suchanfrage festzustellen kann sehr schwierig sein. Für Navigationssuchanfragen wie [ebay] oder [orbitz] können wir mit einiger Sicherheit wissen, dass User zu der jeweiligen Site gelangen möchten. Aber wie steht es mit [Olympiade]? Will der User Nachrichten, eine Medaillenübersicht der kürzlich stattgefundenen Spiele in Peking, die Homepage des IOCs, geschichtliche Information über die Spiele oder ... ? Dies ist genau dieselbe Frage, die sich natürlich unsere Ranking- und UI-Teams stellen. Evaluierung ist die andere Seite dieser Medaille.
Zweitens ist es nie eine schwarz-wei
ß
e Angelegenheit, die Qualität von Suchmaschinen zu vergleichen - ob es nun darum geht, Google gegen unsere Konkurrenz abzugleichen, Google gegen Google vor einem Monat oder Google gegen Google inklusive des "Buchstabe T"-Hacks. Es ist schlicht unmöglich, eine Änderung vorzunehmen, die sich in allen Situationen 100% positiv auswirkt; mit jeder algorithmischen Änderung, die wir an der Suche vornehmen, werden sich viele Suchergebnisse verbessern, andere werden jedoch schlechter werden.
Drittens gibt es verschiedene Dimensionen von "guten" Resultaten. Traditionell hat Search-Evaluierung einen Fokus auf die
Relevanz
der Ergebnisse, und natürlich ist das auch unsere höchste Priorität. Der heutige Suchmaschinen-User erwartet jedoch mehr als nur Relevanz. Sind die Ergebnisse aktuell und zeitgemäß? Stammen sie von Quellen mit Autorität? Sind sie umfassend? Sind sie frei von Spam? Enthalten ihre Titel und Snippets genügend Beschreibungen? Beinhalten sie zusätzliche UI-Elemente, die User für ihre Suchanfrage hilfreich finden könnten, wie etwa Karten, Bilder, Vorschläge für die Suchanfrage etc.? Mit unserer Evaluierung versuchen wir jeden dieser Bereiche so gut wie möglich abzudecken.
Viertens verlangt die Evaluierung von Googles Suchqualität einen extrem breiten Ansatz. Wir decken über hundert Sprachgebiete(Land/Sprach-Paare) mit eingehender Evaluierung ab. Über den Fokus auf diese Sprachgebiete hinaus unterstützen wir Search Quality-Teams in ihrer Arbeit an vielen verschiedenen Arten von Suchanfragen und Features. Beispielsweise messen wir explizit die Qualität von Googles Buchstabiervorschlägen, Ergebnisse der universellen Suche, Bilder- und Video-Suchanfragen, Vorschläge von verwandten Suchanfragen, Oneboxes für Aktien und vieles, vieles mehr.
Um diese Fragen zu lösen, verwenden wir eine Reihe von Evaluierungsmethoden und Datenquellen:
Menschliche Evaluierer. Google setzt Evaluierer in vielen Ländern und Sprachen ein - sie sind bestens vorbereitet und haben die Aufgabe, die Qualität von Suchergebnissen auf verschiedene Weisen zu beurteilen. Manchmal zeigen wir den Evaluierern eine ganze Reihe von Ergebnissen nacheinander, manchmal auch gleichzeitig mit Alternativen. In anderen Fällen zeigen wir ihnen ein einzelnes Ergebnis für eine Suchanfrage und lassen sie dessen Qualität anhand verschiedener Kriterien bestimmen.
Live-Traffic-Experimente. Wir setzen auch Experimente ein, in denen bei Bruchteilen von Suchanfragen Ergebnisse von alternativen Herangehensweisen in der Suche angezeigt werden. Ben Gomes hat in seinem vorherigen Post darüber gesprochen, wie wir von diesen
Experimenten um UI-Elemente der Suche zu testen
Gebrauch machen. Durch diese Experimente, sind wir in der Lages zu sehen, wie User wirklich auf alternative Ergebnisse reagieren (durch Klicks etc.).
Es ist klar, dass wir nie in der Lage sein werden, alle Suchanfragen zu überprüfen, die Google in der Zukunft erhalten wird. Tatsächlich erhält Google jeden Tag viele Millionen Suchanfragen, die wir vorher noch nie gesehen haben und auch nie wieder sehen werden. Daher stellen wir anhand von repräsentativen Samples der laufenden Suchanfragen statistische Rechnungen an. Der "Buchstabe T"-Hack verbessert wohl einige wenige Suchanfragen, aber ich bin mir sicher, dass er, an einer Auswahl von repräsentativen Suchanfragen getestet, sehr schlecht abschneiden würde.
Eine der Schlüsselqualifikationen unseres Evaluierungsteams ist experimentelles Design. Für jeden Verbesserungsvorschlag der Suche erstellen wir einen Experiment-Plan, der es uns erlaubt, die Hauptaspekte der Änderung festzustellen. Wir verwenden häufig eine Kombination von sowohl menschlicher Evaluierung als auch Live-Traffic-Evaluierung. Stellt euch beispielsweise einen Verbesserungsvorschlag für Googles "verwandte Suchvorgänge"-Feature vor, um dessen Verbreitung auf mehrere Sprachgebiete auszuweiten. Unser Experiment-Plan könnte Life-Traffic-Evaluierung beinhalten, bei der wir Usern die neuen Vorschläge der verwandten Suchvorgänge zeigen, die Click-through-Rate für jedes Sprachgebiet messen und die Ergebnisse auf die Position der einzelnen Vorschläge für verwandten Suchvorgänge herunterbrechen. Ebenso könnten wir menschliche Evaluierung miteinbeziehen, indem wir für ein repräsentatives Sample an Suchanfragen an jedem Ort von den Evaluierern eine Beurteilung der Angemessenheit, Nützlichkeit und Relevanz jedes einzelnen Vorschlages der verwandten Suchvorgänge erfragen. Indem wir beide Arten der Evaluierung berücksichtigen können wir die gesamte Auswirkung auf User (über das Live-Traffic-Experiment) beurteilen und detailliert die Qualität jedes Vorschlages an jedem Ort anhand vieler Kriterien messen (durch das menschliche Evaluierungsexperiment).
Eine geeignete Auswahl an Suchanfragen für die Evaluierung auszuwählen, kann viel Raffinesse erforden. Wenn wir einen Verbesserungsvorschlag der Suche auswerten, dann untersuchen wir nicht nur, ob das Ergebnis bestimmter Suchanfragen tatsächlich durch den Vorschlag verändert würde, sondern auch wie hoch die Auswirkungen sind, den diese Änderung auf unsere User haben würde. So hat beispielsweise eine Suchanfrage, bei der sich die ersten drei Ergebnisse ändern, wahrscheinlich grössere Auswirkungen als eine, bei der lediglich die Ergebnisse der neunten und zehnten Position vertauscht werden. In Amit Singhals
vorherigem Post
zum Thema Ranking hat er Synonyme besprochen. Wir haben kürzlich einen Vorschlag für ein Update untersucht, welches Synonyme in manchen Fällen verstärken soll. In einem flachen (von geringer Auswirkung) Sample betroffener Suchanfragen wirkte sich die Änderung recht positiv aus. Als wir jedoch ein Sample überprüften, in welchem sich die Änderung stark niederschlug, stellten wir fest, dass der Eingriff viel zu weit ging. So wurden beispielweise im Chinesischen "klein" (小) und "groß" (大) als Synonym gewertet... keine gute Idee!
Wir nehmen Search-Evaluierung sehr ernst, weil wir euch in jedem Fall eine Sucherfahrung von größtmöglicher Qualität bieten wollen. Anstatt einfach zu raten, was eventuell sinnvoll sein könnte, verwenden wir einen sorgfältigen, datenbasierten Ansatz um sicherzustellen, dass unsere "tollen Ideen" auch tatsächlich toll für euch sind. Vor diesem Hintergrund hatte der Hack mit dem "Buchstaben T" daher nie eine Chance.
Search evaluation at Google (English Version)
Post von Scott Huffman, Engineering Director (Übersetzung von Claudia, Search Quality)
Die "Duplicate Content-Penalty" - entmystifiziert!
Freitag, 12. September 2008
Duplicate Content. Ein andauerndes Thema.
Wir
schreiben
ständig
darüber
, und
User
fragen
ständig
danach
. Vor allem höre ich noch immer, dass viele Webmasters besorgt darüber sind ob ihre Site möglicherweise die "Duplicate Content-Penalty" hat.
Lasst uns also eines ein für alle Mal klarstellen: Es gibt keine "Duplicate Content-Penalty".
Zumindest nicht in der Art und Weise, wie es die meisten User beschreiben, wenn sie darüber sprechen.
Es gibt einige Penalties, die mit dem Konzept zusammenhängen, dass eine Site den gleichen Content hat wie eine andere Site. Wenn ihr beispielsweise Content von anderen Sites unerlaubt übernehmt und diesen wieder veröffentlicht, oder falls ihr Content wiederveröffentlicht ohne Mehrwert hinzuzufügen. Diese Techniken sind in folgendem Auszug aus unseren
Richtlinien für Webmaster
klar (und als nicht empfehlenswert) beschrieben:
Erstellen Sie keine doppelten Seiten, Sub-Domains oder Domains, die im Grunde
denselben Inhalt
haben.
Vermeiden Sie [...] die Verwendung anderer vorgefertigter Techniken wie z. B. Partnerprogrammen
ohne oder mit nur geringem eigenem Inhalt.
Falls Sie mit Ihrer Website an einem
Partnerprogramm
teilnehmen, prüfen Sie, ob Ihre Website einen wirklichen Wertgewinn darstellt. Stellen Sie speziellen und relevanten Content bereit, der Nutzer zum Besuch Ihrer Website veranlasst.
Die meisten Webmaster, die sich über Duplicate Content sorgen, reden jedoch nicht von Scraping oder Domainfarms; sie beziehen sich eher auf mehrfache URLs auf derselben Domain, die denselben Content aufweisen, wie beispielsweise
www.example.com/skates/black/riedell/
und
www.example.com/riedell/skates/black/
. Diese Art von Duplicate Content kann möglicherweise Einfluss darauf haben, wie eure Site in den Suchergebnissen erscheint - sie verursacht jedoch keine Penalties. Ein Auszug aus unseren Richtlinien für Webmaster zum Thema
Duplizierter Content
:
Duplizierter Content auf einer Website ist kein Grund für Maßnahmen gegen diese Website, außer es scheint, dass mit diesem duplizierten Content Nutzer getäuscht bzw. Suchmaschinenergebnisse manipuliert werden sollen. Falls Ihre Website duplizierten Content enthält und Sie nicht den oben beschriebenen Tipps folgen, tun wir unser Bestes, eine Version des Contents in unseren Suchergebnissen anzuzeigen.
Diese Art von Duplizierung ohne bösen Hintergedanken ist recht häufig, insbesondere da viele CMS damit oft nicht gut umgehen können. Wenn Leute also sagen, dass diese Art von Duplicate Content einen Einfluss auf ihre Site haben kann, dann nicht etwa deshalb, weil gezielte Maßnahmen dagegen ergriffen werden, sondern schlicht aufgrund der Tatsache, dass Websites und Suchmaschinen in einer bestimmten Art und Weise funktionieren.
Die meisten Suchmaschinen streben ein gewisses Maß an Vielfalt an; sie möchten euch zehn verschiedene Ergebnisse auf einer Ergebnisseite zeigen anstelle von zehn verschiedenen URLs, die alle denselben Content haben. Aus diesem Grund versucht Google Duplikate herauszufiltern, damit Usern so wenig wie möglich redundante Ergebnisse angezeigt werden. Mehr dazu könnt ihr in
diesem Blogpost
erfahren, der u. a. sagt:
Wenn wir feststellen, dass Duplicate Content vorliegt, der beispielsweise durch Variationen von URL-Parametern hervorgerufen wird, dann fassen wir diese duplizierten URLs zu einer Gruppe zusammen.
Wir wählen dann jene URL aus, die als am besten geeignet erscheint, die jeweilige Gruppe in den Suchergebnissen zu vertreten.
Schließlich werden bestimmte Eigenschaften der URLs aus der Gruppe, wie z. B. die Link-Popularität, vereinigt und auf die im vorigen Schritt ermittelte URL übertragen.
Mögliche Konsequenzen für euch als Webmaster sind:
Bezüglich Schritt 2: Googles Auffassung davon, was die "am besten geeignetste" URL ist, stimmt eventuell nicht mit eurer Auffassung überein. Wenn ihr mehr Kontrolle darüber haben möchtet, ob www.example.com/skates/black/riedell/ oder www.example.com/riedell/skates/black/ in unseren Suchergebnissen angezeigt wird, dann lohnt es sich für euch darüber nachzudenken, wie ihr diese Duplizierung vermindern könnt. Ein Weg uns wissen zu lassen, welche URL ihr bevorzugt, besteht darin, diese in eurer
Sitemap
anzugeben.
Bezüglich Schritt 3: Wenn wir nicht in der Lage sind, alle Duplikate einer bestimmten Seite zu identifizieren, dann können wir diese nicht entsprechend zusammenfassen. Dies könnte die St
ä
rke der einzelnen Rankingsignale dieses Contents mindern, da sie über verschiedene URLs aufgeteilt sind.
In den meisten Fällen handhabt Google diese Art von Duplizierung sehr gut. Es lohnt sich für euch jedoch auch auf Duplicate Content zu achten, der eventuell über verschiedene Domains verteilt ist. Insbesondere wenn ihr euch dafür entscheidet, eine Site zu erstellen, die in erster Linie auf Contentduplizierung basiert, dann solltet ihr dies überdenken, falls euer Geschäftsmodell auf Suchtraffic abzielt. Wir hören beispielsweise mitunter von Amazon.com-Affiliates, die es schwer haben für ihren Amazon-Content zu ranken. Will Google sie dafür bestrafen, dass sie versuchen
Everyone Poops
zu verkaufen? Nein - nur, weshalb sollten sie besser ranken als Amazon selbst, wenn sie genau die gleichen Einträge bieten? Amazon besitzt eine sehr große Autorität als Onlinebusiness (die sehr wahrscheinlich wesentlich größer ist, als die einer typischen Amazonaffiliate-Site) - üblicherweise werden User der Google-Suche daher wohl die Originalinformationen auf Amazon bevorzugen, zumindest solange die Affiliate-Site nicht einen erheblichen
Mehrwert
bietet.
Es lohnt sich nicht zuletzt auch, die Auswirkungen zu beachten, die Duplizierung auf die Bandbreite eurer Site haben kann. Duplicate Content kann zu ineffizientem Crawling führen: Wenn Googlebot zehn URLs auf eurer Site entdeckt, dann muss er jede dieser URLs crawlen, um herauszufinden, ob sie denselben Content beinhalten (und sie entsprechend, wie oben beschrieben, zusammenzufassen). Je mehr Zeit und Ressourcen Googlebot darauf verwenden muss um duplizierten Content auf mehrfachen URLs zu crawlen, desto weniger Zeit hat er, den Rest eures Contents zu erfassen.
Zusammenfassend: Duplicate Content kann eure Site auf verschiedene Arten beeinflussen; solange ihr jedoch nicht absichtlich Duplizierungen erzeugt, ist es unwahrscheinlich, dass eventuelle unerwünschte Auswirkungen aufgrund einer Penalty entstehen. Dies bedeutet, dass:
ihr keinen Antrag auf erneute
Überprüfung einreichen m
ü
sst, wenn ihr unbeabsichtigte Duplikate entfernt habt.
ihr, falls ihr Webmaster im Anfangsstadium seid,
wohl nicht zu viel Energie darauf verwenden m
ü
sst,
ü
ber
Duplicate Content besorgt zu sein, da die meisten Suchmaschinen damit umgehen k
ö
nnen.
ihr anderen Webmastern helfen könnt, indem ihr den Mythos der Duplicate Content-Penalties nicht weiter verbreitet! Ihr habt alle Mittel zur Hand, um gegen Duplicate Content vorzugehen. Hier sind einige
gute
Hinweise
um
anzufangen
.
Demystifying the "duplicate content penalty" (English version)
Post von Susan Moskwa, Webmaster Trends Analyst (Übersetzung von Claudia, Search Quality)
Macht eure Website kompatibel für alle Browser!
Montag, 8. September 2008
Seit seinem Erscheinen ist
Google Chrome
für viele Websurfer ein schneller,
aufregender neuer Browser
. Ein guter Zeitpunkt, um euch als Webmaster daran zu erinnern, dass Browser-Kompatibilität eine hohe Priorität hat, egal mit welchem Browser die User eure Website besuchen – Firefox, Internet Explorer, Google Chrome, Safari etc. Wenn eure Site schlecht dargestellt wird oder in vielen Browsern schwierig zu verwenden ist, riskiert ihr, das Interesse eurer Besucher zu verlieren, und, falls ihr eine kommerzielle Website betreibt, vielleicht potenzielle Kunden. Hier ist eine kurze Liste mit den wichtigsten Grundlagen für eine browser-kompatible Website:
Schritt 1: Browser-Kompatibilität durch gute Accessibilty erreichen
Dieselben Techniken, die dafür sorgen, dass eure Website zugänglich für Suchmaschinen ist, z. B. statisches HTML im Gegensatz zu aufwendigen Funktionalitäten wie AJAX, fördern meistens auch die Kompatibilität eurer Website mit verschiedenen Browsern und zahlreichen Browser-Versionen. Einfacheres HTML ist häufig eher cross-browser-kompatibel als die neueste Technik.
Schritt 2: Zieht es in Betracht, euren Code zu validieren
Wenn euer Code
valide
ist, habt ihr einen möglichen störenden Faktor für die Browser-Kompatibilität beseitigt.
Mit validiertem Code
braucht ihr euch nicht mehr auf die Art der Fehlerbehandlung der verschiedenen Browser zu verlassen, und es ist einfacher, weitere potenzielle Fehler zu beheben.
Schritt 3: Überprüft, ob eure Website nutzbar ist (und nicht nur vernünftig dargestellt wird)
Es ist wichtig, dass eure Website gut angezeigt wird, doch genauso wichtig ist es, sicherzustellen, dass die User die Funktionen eurer Website in ihrem Browser auch nutzen können. Anstatt einfach nur einen Ausschnitt eurer Website anzusehen, wäre es besser, wenn ihr euch außerdem durch eure Website in verschiedenen Browsern navigiert oder Artikel zu eurem Einkaufswagen hinzuzufügt etc. Es ist möglich, dass die klickbare Fläche eines verlinkten Bildes oder eines Buttons von Browser zu Browser variiert. Falls ihr darüber hinaus etwa JavaScript für Komponenten wie den Einkaufswagen einsetzt, kann es sein, dass dies in einem Browser funktioniert, in einem anderen jedoch nicht.
Schritt 4: Fehler ausbügeln
Dieser Schritt erfordert etwas Herumprobieren, allerdings gibt es verschiedene gute Websites, die euch dabei helfen, die Anzahl der Versuche zu reduzieren, während ihr eure Website cross-browser-kompatibel macht.
Doctype
ist eine Open Source-Referenz mit Testfällen für Cross-Browser-Kompatibilität sowie mit Tipps und Tricks für CSS.
Fragt ihr euch beispielsweise, wie ihr den Offset für ein Element eurer Website finden könnt? Funktioniert euer Code problemlos in Internet Explorer, aber nicht in Firefox und Safari? Es hat sich gezeigt, dass gewisse Browser ein bisschen sensibel reagieren, wenn es darum geht, den Offset zu finden –
zum Glück stellen die Helfer des Doctype-Projektes Code zur Verfügung
, um dies zu vermeiden.
Schritt 5: Was sind eure Tipps und Quellen zur Browser-Kompatibilität?
Wir fänden es super, von euch zu hören, welche Schritte ihr unternehmt, um sicherzustellen, dass eure Seite für die meisten Besucher funktioniert. Wir haben einen
tiefergehenden Artikel in der Hilfe für Webmaster
geschrieben, der sich mit Themen wie Zeichenkodierung auseinandersetzt. Falls ihr zusätzliche Tipps zu Browser-Kompatibilität habt, teilt sie uns gerne mit! Und falls ihr Fragen habt, speziell die Suche betreffend, wendet euch einfach an uns!
Workin' it on all browsers (English version)
Post von Maile Ohye, Developer Programs Tech Lead (Übersetzung von Anna-Julia Danisch, Search Quality)
Labels
#NoHacked
2
2017
1
Accessibility
13
AJAX
1
AMP
7
Android
2
api
1
App-Indexierung
3
Best Practices
99
Bildersuche
2
captcha
1
Chrome
4
Code
12
Crawling
1
Crawling und Indexierung
126
Diskussionsforum
15
Duplicate Content
17
Dynamic Rendering
1
Einsteiger
8
Event
1
events
1
Feedback
1
Geo-Targeting
11
Google Analytics
6
Google Dance
1
Google News
1
Google Places
4
Google-Assistant
1
Google-Suche
59
Google+
9
Hacking
16
Hangouts
1
https
3
JavaScript
3
Kanonische URL
1
Kommentare
1
Konferenz
19
Lighthouse
3
Links
18
Malware
17
Mobile
38
Mobile-first indexing
1
Nachrichten-Center
16
Optimisation
3
PageSpeed Insights
2
Penalties
1
Performance
3
Ranking
1
reCaptcha v3
1
Rendering
2
Rich Snippets
18
Richtlinien für Webmaster
36
robots.txt
7
Safe Browsing
5
Search Console
19
Search Results
1
Security
4
Seitenzugriff
1
SEO
4
Sicherheit
38
Site Clinic
5
Sitemaps
30
Spam Report
9
SSL
1
Structured Data
8
Tools und Gadgets
17
Verschlüsselung
1
Video
132
Webmaster blog
1
Webmaster Community
1
Webmaster-Academy
1
Webmaster-Tools
154
webspam
3
Archiv
2020
Nov.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
2019
Dez.
Nov.
Okt.
Sept.
Juni
Mai
Feb.
Jan.
2018
Dez.
Nov.
Okt.
Sept.
Juli
Juni
Mai
Apr.
Feb.
Jan.
2017
Dez.
Nov.
Juni
Apr.
März
Jan.
2016
Nov.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Jan.
2015
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Mai
Apr.
März
Feb.
Jan.
2014
Nov.
Okt.
Sept.
Aug.
Juni
Mai
Apr.
März
Feb.
Jan.
2013
Dez.
Nov.
Okt.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2012
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2011
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2010
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2009
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2008
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2007
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feed
Forum für Webmaster
Webmaster-Sprechstunden
Webmaster-Tools-Hilfe
Developers-Site für Webmaster
