Webmaster-Zentrale Blog
Offizielle Informationen zum Crawling und zur Indexierung von Webseiten und News für Webmaster
Von großen und kleinen Suchexperimenten
Donnerstag, 28. August 2008
In meinem
letzten Post
bin ich auf die Elemente eingegangen, aus denen sich euer Google-Sucherlebnis zusammensetzt, sowie auf die Grundlagen, die unsere Suche so gut funktionieren lassen. Scheinbar simple Features wie die Rechtschreibprüfung oder das zweizeilige Snippet, das jedes Suchergebnis beschreibt, basieren auf komplexen Algorithmen. Was wirklich funktioniert, erkennen wir in unseren Experimenten - winzigen Testläufen für eine kleine Anzahl von Usern, die uns dabei helfen, herauszufinden, welche Features Sinn machen - und welche eben nicht.
Diese Form des Experimentierens hat sich als äußerst hilfreich erwiesen und wir setzen sie im großen Rahmen ein, um potentielle Änderungen in der Suche auszutesten. Zwischen 50 und 200 Experimente laufen ständig auf Google-Sites auf der ganzen Welt. Ich gehe zuerst einmal auf experimentelle Änderungen ein, die so klein sind, dass man sie kaum wahrnehmen kann, selbst wenn man sie gerade vor Augen hat, und schließe mit einigen jener Experimente, die kaum zu übersehen sind. Eine Menge Leute haben es sich zur Aufgabe gemacht, jede Veränderung auf Google-Seiten mitzukriegen. Gelegentlich bilden sie sich dabei Sachen nur ein, aber sie bemerken auf jeden Fall eine Menge unserer offensichtlichen Experimente. Kleinere Änderungen werden im Gegensatz dazu beinahe immer übersehen.
Was zum Beispiel ist der Unterschied zwischen den beiden unten abgebildeten Seiten?
Variante 1:
Variante 2:
Ich bin ziemlich sicher, dass ich keinen Unterschied bemerken würde, wären die Bilder nicht direkt gegenüber gestellt. Ihr seid dazu aber offensichtlich in der Lage! Zumindest nebeneinander kann man den Unterschied erkennen. Solltet ihr es nicht sehen: der weiße Abstand um den ersten Treffer wurde verändert. Das betont ihn in Bild 2 ein wenig. Dieses visuelle Hervorheben vermittelt die Tatsache, dass unseren Rankingsignalen nach, das erste Resultat deutlich passender ist als Treffer Nummer 2. Dies hat den Vorteil, dem User zu helfen, sich aufs erste Suchergebnis zu konzentrieren. Falls man aber an einem anderen der Treffer interessiert sein sollte, kann es das Überfliegen der Seite erschweren. Ein Experiment hilft uns festzustellen, welcher Effekt stärker ist und ob eine Änderung euch dabei helfen würde, schneller zum Ergebnis zu kommen.
Eine andere Änderung, die beinahe genauso winzig ist, findet sich hier:
Hier entsteht so ein großer Unterschied im Userverhalten, dass wir sehr schnell feststellen konnten, welche Variante besser funktioniert: der Unterschied besteht in der Darstellung der Plus-Box vor dem "stock quote"-Link. Natürlich ist es nicht leicht zum Schluss zu kommen, dass eine Option "besser" ist, und man könnte bei einer Einschätzung Fehler begehen. Bedeutet eine stärkere Nutzung der Plus-Box "besser"? Was, wenn der User gute Resultate verpasst, weil er von der betonten Plus-Box abgelenkt wird? Schaut euch doch einfach die Google-Resultate an, um zu sehen, was sich am Ende durchgesetzt hat! Wenn wir unseren Job richtig machen, wird das Resultat für euch brauchbarer sein, auch wenn ihr es kaum bemerkt. Die Welt wird zu einem besseren Ort, erfüllt von fröhlichem Vogelgezwitscher. Okay, vielleicht ist das ein wenig übertrieben - aber zumindest habt ihr die beste Plus-Box, die wir euch liefern können. :)
Aber nicht alle unserer Experimente sind solche verrückten Sehtests. Worum es mir bei diesen beiden Beispielen hauptsächlich ging, war darzustellen, dass wir beinahe alles ausprobieren - sogar Details, von denen man glauben könnte, sie seien so winzig, dass sie uns egal sein können (und dass sie sowieso keinen Unterschied machen). Tatsache ist aber: winzige Änderungen machen einen Unterschied, und sie sind uns nicht egal.
Eine andere Form von Experimenten hat mit Änderungen zu tun, die nicht rein optischer Natur sind, sondern sich mit Modifikationen der zu Grunde liegenden Präsentationsalgorithmen befassen. Jener Algorithmus z. B., der für Titel und Snippets der Ergebnisseite verantwortlich ist, hebt seit einiger Zeit den Suchbegriff und auch einige Synonyme dazu hervor . Für die Suche
[hp printer drivers]
gibt es so auch Ergebnisse, die das Wort "driver" beinhalten und entsprechend hervorheben...
Diese Form des "stemmings", wie wir es nennen, ist deshalb nützlich, weil sie euch normalerweise dabei unterstützt, jene Ergebnisse, die mit dem Suchbegriff übereinstimmen, herauszufiltern - aber nicht in jedem Fall. Hier helfen uns die Experimente bestimmte Annahmen in Bezug auf Änderungen dieser Algorithmen zu verifizieren (oder unter Umständen als falsch auszuweisen).
Es gibt noch eine weitere Art von Experimenten, die kaum übersehen werden: jene, die ziemlich offensichtliche Features einführen. Auch in diesen Fällen bleibt das Ziel des Experiments dasselbe: fügen wir etwas hinzu, das den Leuten wirklich hilft, oder lenken wir nur vom Wesentlichen ab? Google liegt keine Gebrauchsanweisung bei. (Zugegebenermaßen gibt es zwar einige gut geschrieben Hilfe-Seiten, aber wir sind ziemlich sicher, ihr macht euch nicht die Mühe, sie zu lesen!) Folglich müssen sich Features selbst erklären, ohne die Unterstützung umständlicher Erläuterungen. Teilziel der Experimente ist es, zu verstehen, wie ein Feature benutzt wird - und das kann anders geschehen, als wir es uns vorgestellt haben.
Hier gibt es ein Beispiel für ein Experiment, dass euch die Suchergebnisse kommentieren läßt, in dem ihr sie am Bildschirm umordnet:
Im Moment kann ich noch nicht sagen, was wir davon halten sollen; wir sind einfach neugierig mitzukriegen, wie es verwendet wird.
Das waren einige Beispiele für die unterschiedlichen Arten von Experimenten, die zum Einsatz kommen, wenn wir alles Mögliche - von kaum wahrnehmbar bis nicht zu übersehen - testen. Wenn ihr das nächste Mal Google benutzt und ihr den Eindruck habt, irgendwas wäre anders - vielleicht ist es ja tatsächlich so. Und vielleicht nur für euch!
Search experiments, large and small (English version)
Post von Ben Gomes, Distinguished Engineer (Übersetzung von Jörg, Search Quality)
Die Bedeutung von User-Feedback, Teil 2 (und weitere "häufige Fragen"!)
Mittwoch, 27. August 2008
In einem kürzlich veröffentlichten
Post
von mir ging es darum, wie Userreports über
Webspam
und
bezahlte Links
dabei helfen, Googles Suchergebnisse für Millionen von Usern zu verbessern. In Anknüpfung daran möchte ich nun einen der wichtigsten Teile der Google Webmaster-Zentrale hervorheben: unser
Diskussionsforum für Webmaster
. Mit über 35.000 Mitgliedern in unserem englischen Forum, sowie zusätzlichen Foren in
15 weiteren Sprachen
, ist das Forum der Ort, an dem eure Fragen zum Thema Crawling, Indexierung oder zu den Webmaster-Tools beantwortet werden. Wir sind auch sehr dankbar für die fabelhafte Gruppe von äußerst aktiven und hilfsbereiten Usern, die ihre Zeit und Energie investieren, um aus der Diskussionsgruppe für Webmaster ein lohnenswertes Forum zu machen. Falls angebracht, springen auch ich oder andere Googler ein, um Klarheit in Diskussionen zu bringen oder am Dialog teilzunehmen. Eine Anmerkung dazu: wir bemühen uns sehr, alle Posts im Forum zu lesen, und auch wenn wir nicht auf alle antworten, so haben euer Feedback und eure Verbesserungsvorschläge erheblichen Einfluss darauf, an welchen Features wir arbeiten. Hier sind einige Beispiele:
Sitemap-Details
Eine Sitemap in den Webmaster-Tools einzureichen ist eine Möglichkeit um Google wissen zu lassen, welche Seiten auf eurer Site existieren.
Usern ist schnell aufgefallen
, dass sie trotz der Tatsache, dass sie eine Sitemap für alle Seiten eingereicht hatten, nur eine Auswahl an indexierten URLs über die Suchanfrage mit dem Operator site: fanden. Daraufhin hat das Webmaster-Tools-Team eine Sitemap-Details-Seite eingerichtet, um euch besser darüber zu informieren, wie eure Sitemap bearbeitet wurde. Falls ihr euer Wissen über die Sitemap-Details-Seite auffrischen wollte, dann könnt ihr
Jonathan's Blogpost
lesen.
Kontextuelle Hilfe
Eine Anfrage, die wir recht früh zu den Webmaster Tools erhalten haben, war die nach einer besseren Dokumentation zu den angezeigten Daten. Da wir
einige Fragen
über Meta-Beschreibung und Titel-Tag-Probleme bei der Benutzung unseres Content-Analyse-Tools erhalten haben, haben wir unsere
Dokumentation
auf der Seite verbessert und dort auch einen direkten Link zu dem Artikel in der Hilfe für Webmaster gesetzt. Ebenso haben wir festgestellt, dass
User
mehr Klarheit
über die Unterscheidung zwischen den "häufigsten Suchanfragen für jede Suche" und den "häufigsten Suchanfragen für jeden Klick" benötigten, sowie darüber, wie sie diese Daten verwenden können. Wir haben dazu einen Abschnitt hinter dem Link "Wie verwende ich diese Daten?" hinzugefügt, sowie kontextuelle Hilfeinformationen in den Webmaster-Tools eingefügt, um zu erklären, was ein Feature bedeutet und wo ihr mehr Informationen darüber erhalten könnt.
Blogposts
Das Diskussionsforum für Webmaster ist auch eine Möglichkeit für uns, ständig über die aktuellen, größeren Fragen der Webmaster informiert zu sein und einige dieser Fragen in unserem Blog aufzugreifen. Ob es nun darum geht, wie man einen
Antrag auf erneute Überprüfung
in den Webmaster-Tools einreicht, mit
Duplicate Content umgeht
, mit einer
Site umzieht
, oder um das
Design für Accessibility
- wir sind immer offen für weitere eurer Anregungen aus dem Forum. Was mich daran erinnert...
Es ist wieder Zeit für weitere "häufige Fragen"!
Im letzten Jahr haben wir hart daran gearbeitet, um innerhalb von zwei Wochen fünf größere Fragen aus dem Webmasterbereich zu beantworten. Diese
"heissen Themen"
waren sehr beliebt und deckten die folgenden Bereiche ab:
Susan hat ein
paar Methoden erläutert, wie ihr sicherstellen könnt, dass eure Site von Google indexiert wird
.
John hat
einige Fragen zum Thema Spam-Bericht und Antrag auf erneute Überprüfung beanwortet
.
John schrieb auch einen
Blogpost, der eine gute Quelle zum Thema Meta-Tags darstellt
.
Wysz
verschaffte mehr Klarheit über verborgenen Text
.
Matt
besprach ausführlicher den richtigen Gebrauch des Nofollow-Tags
.
Da diese Initiative sehr gut angekommen ist, freue ich mich euch mitteilen zu können, dass wir sie wiederholen werden. Geht einfach zu
diesem Thread
in unserem englischen Forum und stellt dort eure Fragen rund um das Thema Webmaster. Bis gleich!
The Impact of User Feedback, Part 2 (and more Popular Picks!) (English version)
Post von Reid Yokoyama, Search Quality (Übersetzung von Claudia, Search Quality)
Silbermedaille für Search Quality
Montag, 25. August 2008
Vielleicht habt ihr euch schon einmal gefragt: Wenn schon sowohl Tennis als auch Tischtennis Teil der Olympischen Spiele sind, weshalb gilt dann nicht auch Tischfußball neben Fußball als olympische Disziplin? Auch wenn dies nicht der Fall ist, hatten wir dennoch Grund
Nathan Johns
und
Jan Backes
zu feiern: die beiden Mitglieder unseres Search-Quality-Teams haben nämlich die Silbermedaille im Tischkickern vom
search engine foosball smackdown
auf der SES San Jose nach Hause gebracht.
Der "Smackdown" ist zwar mit der Olympiade nicht ganz zu vergleichen - jedoch war die Konzentration so hoch, dass man eine Nadel hätte fallen hören können!
Die Goldmedaille (bzw. der Pokal) ging an die
Suchmaschine ein paar Häuser weiter
. :)
Yahoo!s
Gewinner des ersten Platzes Daniel Wong and Jake Rosenberg.
Einfach nur um sicher zu stellen, dass die beiden auch tatsächlich Yahoo!-Mitarbeiter waren, stellte ich die Daniel und Jake die Frage: "Wie könnt ihr verhindern, dass eine Datei gecrawlt wird?" Ihre korrekte Antwort lautete: "
Robots.txt
".
Der Goldpokal war wohlverdient.
Post von Maile Ohye, Developer Programs Tech Lead (Übersetzung von Claudia, Search Quality)
Hey Google, auf meiner Website gibt es keine Badware mehr
Freitag, 22. August 2008
Dieser Post richtet sich an alle, die eine
E-Mail erhalten
oder von Google über
Badware
benachrichtigt wurden, während des Durchsuchens der eigenen Website in Firefox vor
Badware gewarnt
wurden oder als
Malware gekennzeichnete Suchergebnisse
auf der eigenen Website gefunden haben. Wie ihr wisst, werden diese Warnungen von automatisierten Scanning-Systemen erstellt, die wir eingerichtet haben um die Qualität unserer Suchergebnisse sicherzustellen, in dem wir unsere
User schützen
. Was auch immer der Fall ist, wenn ihr mit Badware zu tun habt, haben wir hier einige Empfehlungen, die euch weiterhelfen können.
1. Solltet ihr Badware gefunden haben, bedeutet das normalerweise, dass euer Webserver, eure Website oder eine Datenbank, die von eurer Website verwendet wird, beeinträchtigt wurde. Wir haben einen hilfreichen Post zu diesem Thema verfasst, in dem erklärt wird,
was ihr machen könnt, wenn ihr gehackt wurdet
. Seit vorsichtig, wenn ihr eure Website nach Malware durchsucht um zu vermeiden, dass euer Computer Malware-Angriffen ausgesetzt ist.
2. Wenn alles wieder sauber ist, könnt ihr der Anleitung in unserem Post über
Malware Überprüfung mittels Webmaster-Tools
folgen. Beachtet bitte, dass der Screenshot im vorigen Post überholt ist. Das neue Malware Review Formular findet ihr auf der Übersicht-Seite in den Webmaster-Tools:
Andere Programme, wie zum Beispiel Firefox, verwenden ebenfalls unsere Badware-Daten, erkennen jedoch Änderungen möglicherweise nicht sofort, weil sie Daten im Cache behalten. Das bedeutet, obwohl das Badware-Label in der Suche entfernt wurde, kann es einige Zeit dauern bis das in diesen Programmen ebenfalls sichtbar wird.
3. Wenn ihr der Ansicht seid, dass euer Ranking durch Malware beeinflusst wurde, wie zum Beispiel durch beeinträchtigten Content der unseren Richtlinien für Webmaster widerspricht (z. B. gehackte Seiten mit versteckten Links zu Pharmaseiten), dann solltet ihr einen
Antrag auf erneute Überprüfung
ausfüllen. Zur Verdeutlichung: Anträge auf erneute Überprüfung werden üblicherweise verwendet, wenn ihr Probleme feststellt, die aus der Verletzung unserer Richtlinien für Webmaster stammen und haben nichts mit Malware-Anfragen zu tun.
Solltet ihr weitere Fragen haben, steht euch unsere
Hilfe für Webmaster
zur Verfügung oder ihr postet im
Diskussionsforum
mit der URL eurer Website. Wir hoffen ihr findet diese aktualisierte Funktionalität in den
Webmaster-Tools
hilfreich um Malware zu finden und alle mit Malware verbundenen Probleme zu lösen.
Hey Google, I no longer have badware (English version)
Post von Evan Tang, Search Quality Team (Übersetzung von Michael, Search Quality)
Macht eure 404-Seiten noch nützlicher
Donnerstag, 21. August 2008
Die Besucher eurer Site können aus zahlreichen Gründen bei euch auf eine
404-"NotFound"
-Seite stoßen:
Eine falsch geschriebene URL oder ein Fehler beim Kopieren und Einfügen der URL
Fehlerhafte oder abgeschnittene Links auf Webseiten oder in E-Mails
Verschobener oder gelöschter Content
Wenn eure User die 404-Seite sehen, werden sie evtl. versuchen die URL zu korrigieren, den Zurück-Button zu klicken oder sogar auf eine andere Site zu navigieren. Wie in einem
früheren Post
der
"404-Woche auf unserem Blog für Webmaster"
bereits angedeutet, gibt es verschiedene Möglichkeiten, euren Besuchern aus dieser Sackgasse herauszuhelfen. Da wir versuchen, die 404-Seiten nützlicher zu machen, haben wir jetzt eine neue Rubrik in den
Webmaster-Tools
hinzugefügt: "404-Seiten verbessern". Falls ihr eine
benutzerdefinierte 404-Seite
eingerichtet habt, könnt ihr nun ein Widget in eure 404-Seite einbauen. Damit können eure Besucher besser finden wonach sie eigentlich gesucht haben, indem Vorschläge basierend auf der fehlerhaften URL gemacht werden.
Beispiel: Jamie bekommt den folgenden Link in einer E-Mail zugeschickt:
www.example.com/activities/adventurecruise.html
. Aufgrund einer fehlerhaften Formatierung im E-Mail-Programm, wird die URL abgeschnitten und sieht nun so aus:
www.example.com/activities/adventur
. Bei diesem Link wird daher eine 404-Seite angezeigt. Mit unserem zusätzlichen 404-Widget hingegen, könnte das Folgende angezeigt werden:
Zusätzlich zu dem Korrekturvorschlag für die URL, kann das 404-Widget (falls verfügbar) auch folgendes anzeigen:
einen Link zum übergeordneten Verzeichnis
einen Link zu eurer Sitemap-Seite
Vorschläge für Suchanfragen mittels Site-Suche und eine Suchbox
Wie könnt ihr das Widget hinzufügen? Besucht einfach die Rubrik "404-Seiten verbessern" in den Webmaster-Tools - dort könnt ihr einen JavaScript-Codeschnipsel erstellen lassen, welchen ihr kopieren und auf eurer benutzerdefinierten 404-Seite einfügen könnt. Wie immer, solltet ihr daran denken, einen
richtigen 404-Statuscode zurückzugeben
.
Könnt ihr das Aussehen des Widgets verändern? Als Ausgangspunkt belassen wir das HTML ohne CSS-Layout, ihr könnt jedoch den CSS-Block, den wir bereitstellen, entsprechend anpassen. Weitere Informationen dazu könnt ihr in unserem
Leitfaden zum Ändern der Darstellung des benutzerdefinierten 404-Widgets
finden.
Das 404-Widget ist derzeit noch experimentell, d. h. es kann vorkommen, dass wir für eure Site noch keine passenden Korrekturvorschläge anbieten können - aber wir arbeiten daran, diese Funktionalität zu verbessern. In der Zwischenzeit könnt ihr eure Meinung zu diesem Feature als Kommentar posten oder auch in unserem
Forum für Webmaster
vorbeischauen. Danke, dass ihr uns dabei behilflich seid, das Internet ein klein wenig freundlicher zu machen!
Make your 404 pages more useful (English version)
Post von Sahala Swenson, Webmaster Tools Team (Übersetzung von Sven, Search Quality)
Noch mehr zum 404
Montag, 18. August 2008
Jetzt, wo wir uns
von soft 404s verabschiedet haben
, werden wir uns in diesem Post in unserer
404-Woche
euren häufigsten Fragen zu 404s widmen.
Wie behandelt ihr den Statuscode 410 "Gelöscht"?
Genauso wie einen 404.
Indexiert ihr Content von Seiten mit einer 404-Statusmeldung oder folgt ihr Links auf solchen Seiten?
Wir versuchen, so viel wie möglich über eure Site und deren Content zu verstehen. Auch wenn wir unseren Usern in den Suchergebnissen keine 404-Seiten zeigen möchten, kann es sein, dass wir den Content oder die Links einer 404-Seite dazu nutzen, eure Site besser zu verstehen.
Wenn ihr eure Links gecrawlt und euren Content indexiert haben möchtet, solltet ihr daran denken, dass dies wesentlich besser funktioniert, wenn ihr dies mittels gewöhnlicher Seiten macht, die keinen 404-Statuscode zurückgeben.
Wie verhält es sich mit 404s die einen Meta-Refresh mit 10-sekündiger Verzögerung anwenden?
Diese Methode wird gegenwärtig z. B. von Yahoo! auf deren 404s angewandt. Sie
geben einen 404 zurück
, aber der Content des 404 beinhaltet außerdem:
<meta http-equiv="refresh" content="10;url=http://www.yahoo.com/?xxx">
Unserer Meinung nach, ist diese Technik vollkommen in Ordnung, da unnötige Verwirrung dadurch minimiert wird, dass User 10 Sekunden Zeit haben, eine neue Auswahl zu treffen - erst nach den 10 Sekunden wird die Homepage aufgerufen, falls es zwischenzeitlich keinen Userinput gab.
Soll ich 404s, die durch Schreibfehler zustande kommen, per 301 zur richtigen URL weiterleiten?
Die Weiterleitung von 404-Seiten ist dann sinnvoll, wenn es euren Usern hilft (d. h. nicht verwirrend wirkt wie soft 404s). Falls ihr z. B. feststellt, dass bei den
Crawling-Fehlern
in den Webmaster-Tools 404-Meldungen für falsch geschriebene Versionen eurer URL auftauchen, könnt ihr bedenkenlos eine 301-Weiterleitung zur richtigen Version eurer URL einsetzen.
Wenn wir z. B. diese 404-Meldung in den Crawling-Fehlern sehen würden:
http://www.google.de/webmsters
<-- Schreibfehler von "webmasters",
dann könnten wir zunächst prüfen, ob der Schreibfehler auf unserer Site existiert und ihn ggf. beheben. Außerdem können wir eine 301-Weiterleitung zur richtigen Version einrichten (weil der Link mit dem Schreibfehler noch auf anderen Seiten im Web vorhanden sein könnte):
http://www.google.de/webmasters
Habt ihr ein paar Beispiele für gelungene 404-Seiten?
Klar, haben wir! Wir haben hier mal eine Liste unserer beliebtesten 404-Seiten zusammengestellt. Falls ihr weitere Fragen zu 404s habt, lasst es uns wissen - und danke, dass ihr unsere 404-Woche verfolgt habt!
http://www.metrokitchen.com/nice-404-page
"Falls ihr ein Produkt sucht, welches aber nicht mehr auf Lager ist (wie es bei mir der Fall war), hilft diese Seite dabei, Alternativen zu finden."
-
Riona
http://www.comedycentral.com/another-404
"Die Roboter-Affen sind schuld!"
-
Reid
http://www.splicemusic.com/and-another
"Mit solch einer Seite könnt ihr die Verweildauer auf eurer Site deutlich steigern."
-
Susan
http://www.treachery.net/wow-more-404s
"Nicht sehr beruhigend aber dafür eindeutig."
-
Jonathan
http://www.apple.com/iPhone4g
"Gute Usability."
http://thcnet.net/lost-in-a-forest
"Immerhin gibt es einen Briefkasten..."
-
JohnMu
http://lookitsme.co.uk/404
"Sehr niedlich :)"
-
Jessica
http://www.orangecoat.com/a-404-page.html
"Ich sage nur: Flussdiagramm"
-
Sahala
http://icanhascheezburger.com/iz-404-page
-
Adam
Post von Maile Ohye, Developer Programs Tech Lead (Übersetzung von Sven, Search Quality)
Bye, bye, soft 404!
Donnerstag, 14. August 2008
Es gibt zwei Arten von
404-Statuscodes
("Datei nicht gefunden") im Web: "hard 404s" und "soft 404s". Wir raten euch davon ab, die sogenannten "soft 404s" zu benutzen, weil sie auf User und Suchmaschinen verwirrend wirken können. Anstatt mit dem 404-Statuscode für eine nicht existierende URL antworten Websites, die "soft 404s" einsetzen, mit einem 200-Statuscode. Dessen Content ist oft die Homepage oder eine Seite mit einer Fehlermeldung.
Wie sieht eine "soft 404" für den User aus? Im Bild präsentieren wir euch ein Soft-404-Modell: diese Website antwortet mit einem 200-Statuscode und führt im Fall von URLs, die nicht existieren, zur Homepage der Website.
Wie hier dargestellt, sind 404s oft nicht nur verwirrend für User, sondern auch Suchmaschinen könnten viel Zeit damit verschwenden, nicht vorhandene Inhalte oder Kopien der immerselben URL zu crawlen und zu indexieren. Dies kann negative Auswirkungen darauf haben, wie vollständig eure Site gecrawlt wird, weil der Googlebot Zeit auf nicht wirklich vorhandenen Seiten verbringt, während eure wirklich bedeutenden URLs eventuell nicht sofort entdeckt und unter Umständen seltener indexiert werden.
Und was benutze ich dann anstatt der "soft 404"?
Es macht weitaus mehr Sinn, einen tatsächlichen 404-Statuscode abzuschicken und dem User klar zu vermitteln, dass die gewünschte Datei nicht gefunden werden konnte.
Gebt einen 404-Statuscode aus!
Gebt euren Usern eine klare Antwort!
Kann euer Webserver mit einem 404 antworten und dem User trotzdem eine hilfreiche "Not found"-Message anzeigen?
Aber sicher! Infos dazu gibt es im weiteren Verlauf der 404-Serie!
Farewell to soft 404s (English version)
Post von Maile Ohye, Developer Programs Tech Lead (Übersetzung von Jörg, Search Quality)
404-Woche auf unserem Blog für Webmaster
Mittwoch, 13. August 2008
Diese Woche werden wir einige Blogposts veröffentlichen, um euch Hilfestellung rund um den 404-Statuscode zu geben.
HTTP-Statuscodes
sind numerische Statusangaben (wie z. B. 200 für "OK" oder 301 für "Dauerhaft verschoben"), die ein Webserver als Antwort auf die Anforderung einer URL liefert. Der 404-Statuscode sollte zurückgegeben werden, wenn eine Datei nicht gefunden wurde.
Wann immer ein User eine Anfrage an eure Website richtet, versucht euer Webserver, die entsprechende Datei für die angeforderte URL zu finden. Wenn diese Datei existiert, wird der Webserver in der Regel einen 200-Statuscode zusammen mit einer Nachricht (meist der Content einer Seite, z. B. das HTML) liefern.
Und was ist jetzt ein 404-Statuscode? Angenommen, im oben gezeigten Link "Besucht Google-Apps" ist der Link fehlerhaft, weil beim Erstellen der Seite ein Schreibfehler gemacht wurde. Wenn nun ein User auf den "Besucht Google-Apps"-Link klickt, kann die entsprechende Webseite/Datei nicht vom Webserver gefunden werden. Der Webserver sollte in diesem Fall einen 404-Statuscode zurückgeben, was bedeutet, dass die entsprechende Datei nicht gefunden wurde.
OK - Jetzt wisst ihr schon mal über die Grundlagen des 404 Bescheid. In den folgenden Posts geben wir euch weitere Informationen, wie ihr den 404-Statuscode sinnvoll für eure User und die Suchmaschinen einsetzen könnt.
It's 404 week at Webmaster Central (English Version)
Post von Maile Ohye, Developer Programs Tech Lead (Übersetzung von Sven, Search Quality)
Google Developer Day in München
Montag, 11. August 2008
Am 23. September ist es wieder soweit: Der Google Developer Day heißt euch in München willkommen!
Aufgrund der großen Resonanz im Vorjahr haben wir die Teilnehmerzahl verdoppelt - 500 Entwickler aus Deutschland können sich dieses Jahr zu den über 50 Produkten und Tools für Entwickler informieren. Einen ganzen Tag lang bieten wir Diskussionen, Keynotes und Programmier-Workshops rund um das Thema Web-Development.
Inhaltlich wird es in den Sessions schwerpunktmäßig um die verschiedenen APIs und Open-Source-Tools gehen, die wir rund um unsere Produkte anbieten:
Vereinfachung der Web-Entwicklung mittels unserer AppEngine, dem Google Web Toolkit und den Produkt-APIs
Verbesserung der Nutzererfahrung mittels Google Gears
Weiterentwicklung des Social Web mit Hilfe der Google-Produkte OpenSocial und FriendConnect
Darüberhinaus geht es auch um die Entwicklung von Android-Applikationen sowie Geo/Map-Anwendungen.
Google-Ingenieure und Produktspezialisten werden eine Reihe von Themen präsentieren und stehen euch für Fragen zur Verfügung. In einem Forum für lokale Entwickler könnt ihr euch mit Google-Experten und untereinander austauschen.
Eine detaillierte Agenda und das Anmeldeformular könnt ihr auf der offiziellen Seite des Developer Day finden:
www.google.de/developerday2008
Wir freuen uns auf euren Besuch!
Post von Sven Naumann, Search Quality Team
Wie ihr eine mehrsprachige Site aufbaut
Donnerstag, 7. August 2008
Habt ihr schon einmal probiert, eine oder mehrere Sites zu erstellen und diese in mehreren Sprachen zur Verfügung zu stellen? Angenommen, ihr wollt eine Site über Rucksacktourismus in Europa aufbauen und euren Content deutsch-, englisch- und spanischsprechenden Usern zur Verfügung stellen. Dabei ist es wichtig, sich im Vorfeld Gedanken über den Seitenaufbau, die geografische und sprachliche Ausrichtung eurer Site, sowie die Organisation eures Contents zu machen.
Seitenaufbau
Als erstes solltet ihr euch überlegen, ob es sinnvoll ist, länderspezifische Top-Level-Domains für alle Länder zu erwerben, in denen ihr den Content eurer Site anbieten wollt. In unserem Beispiel könnten die Domains dann so lauten: ichlieberucksackreisen.de, ilovebackpacking.co.uk und irdemochilero.es. Diese Option, auch bekannt als geografische Ausrichtung, ist vorteilhaft, wenn ihr euch entscheidet, euren Content auf die Länder auszurichten, mit denen die Top-Level-Domains assoziiert werden. Ein wenig später werden wir darauf eingehen, wie sich die geografische Ausrichtung von der sprachlichen unterscheidet. Angenommen, euer Content liegt in Deutsch vor und ist vor allem für User aus Deutschland relevant und weniger für deutschsprachige User aus der Schweiz oder Österreich. In diesem Fall ist es sinnvoll, eine de-Domain zu registrieren. Deutsche User werden eure Site als lokale Website erkennen, der sie mitunter mehr Vertrauen entgegen bringen. Andererseits kann es sehr teuer sein, länderspezifische Top-Level-Domains zu erwerben, ganz zu schweigen von dem Aufwand, mehrere TLDs zu verwalten und zu aktualisieren. Wenn eure Mittel und eure Zeit begrenzt sind, könnt ihr den Kauf einer generischen Domain in Betracht ziehen, auf der die verschiedenen Spachvarianten eurer Website zur Verfügung gestellt werden. Für diesen Fall empfehlen wir eine der zwei folgenden Optionen:
Legt den Content für die verschiedenen Sprachen in entsprechend getrennten Subdomains ab. Für unsere oben erwähnten Sprachen ergäbe das folgende Subdomains:
de.example.com, en.example.com, es.example.com.
Legt den Content für die einzelnen Sprachen in verschiedenen Unterverzeichnissen ab. Mit dieser Variante ist die Aktualisierung und Verwaltung eurer Website leichter zu bewerkstelligen. In unserem Beispiel würde das so aussehen:
example.com/de/,
example.com/en/
,
example.com/es/
.
Matt Cutts hat einen informativen Post über
Unterverzeichnisse und Subdomains
geschrieben, der euch die Wahl einer dieser Optionen erleichtern kann.
Geografische Ausrichtung versus sprachliche Ausrichtung
Wie weiter oben schon erwähnt, könnt ihr euren Content einer Zielgruppe in einer bestimmten Region der Welt zugänglich machen. Besonders hilfreich dafür ist das
Tool zur geografischen Ausrichtung in den Webmaster-Tools
. Es ermöglicht euch, verschiedene geografische Ausrichtungen für verschiedene Unterverzeichnisse oder Subdomains von generischen Top-Level-Domains zu wählen, z.B. /de/ für Deutschland.
Wenn ihr alle User auf der ganzen Welt erreichen wollt, die eine bestimmte Sprache sprechen, solltet ihr euch nicht auf eine bestimmte Region beschränken. Diese Option wird sprachliche Ausrichtung genannt und kann nicht mit dem Tool zur geografischen Ausrichtung vollzogen werden.
Organisation des Contents
Der gleiche Content in verschiedenen Sprachen wird nicht als Duplicate Content wahrgenommen. Aber achtet darauf, dass ihr der Website eine gute Organisation zugrunde legt. Wenn ihr einem der oben aufgeführten Vorschläge zum Seitenaufbau folgt, dann sollte nichts mehr schief gehen. Auf jeden Fall solltet ihr es vermeiden, verschiedene Sprachen auf einer Seite zu vermischen, da es sowohl die User als auch den Googlebot verwirren könnte. Am besten ist es, den Content und die Navigation auf einer Seite in derselben Sprache zu halten.
Um herauszufinden, wie viele eurer Seiten als zu einer bestimmten Sprache zugehörig erkannt wurden, solltet ihr eine sprachspezifische Site-Suche durchführen. Wenn ihr beispielsweise eine Suche nach google.com
mit dem Operator site:
durchführt, so könnt ihr unterhalb der Suchbox die Option festlegen, so dass euch nur Resulte angezeigt werden, die auf Deutsch vorliegen.
Wenn ihr mehr Fragen zu diesem Thema habt, dann postet doch in unserem
Forum für Webmaster
.
Post von Charlene Perez and Juliane Stiller, Search Quality Team
Aufbruch in die Unendlichkeit? Nein, danke!
Mittwoch, 6. August 2008
Wenn der Googlebot durchs Web gleitet, begegnet er oft einem Phänomen, das wir "endlose Weiten" nennen. Dabei handelt es sich um eine sehr große Anzahl von Links, die in den meisten Fällen sehr wenig oder gar keinen neuen Content zum Indexieren bieten. Falls das auf eurer Site der Fall sein sollte, könnte das Crawlen dieser URLs unnötige Bandbreite beanspruchen und dazu führen, dass der Googlebot nicht in der Lage ist, den tatsächlichen Content der Site komplett zu erfassen.
Vor kurzem haben wir damit begonnen, Webmaster zu benachrichtigen, wenn wir dieses Problem auf ihren Websites feststellen. Wie die meisten unserer Benachrichtigungen könnt ihr die entsprechenden Informationen im Nachrichten-Center der
Webmaster-Tools
finden. Wahrscheinlich wollt ihr so schnell wie möglich erfahren, ob der Googlebot dieses - oder ein anderes - Problem beim Crawlen eurer Websites hat. Deshalb überprüft eure Site doch einfach in den Webmaster-Tools und schaut ab und an mal im Nachrichten-Center vorbei.
Endlose Weiten in Beispielen
Das klassische Beispiel für endlose Weiten ist ein Kalender mit einem Link für "Nächsten Monat". Es könnte möglich sein, diesem Link für alle Ewigkeit ins Endlose zu folgen! Das ist natürlich nicht das, was ihr euch vom Googlebot wünscht. Der Googlebot ist intelligent genug, einige dieser Szenarien selbstständig zu durchschauen, aber es gibt jede Menge Varianten, endlose Weiten zu erzeugen, und wir können vielleicht nicht alle davon aufspüren.
Eine anderes Szenario tritt häufig bei Websites auf, die in der Lage sind, eine Anzahl von Suchergebnissen auf unterschiedlichste Art und Weise zu filtern. Ein Webshop kann beispielsweise die Option bieten, Kleidungsstücke nach Kategorie, Preis, Farbe, Marke, Gestaltung, etc. zu sortieren. Die Anzahl der möglichen Kombinationen wächst dabei unter Umständen exponential. So können tausende von URLs entstehen, die alle das gleiche Produkt anzeigen. Höchstwahrscheinlich ist das für eure User von Vorteil, aber dem Googlebot hilft es kaum. Der möchte doch bloß alles finden - und zwar genau einmal!
Probleme mit endlosen Weiten in den Griff bekommen
Dieser
Artikel in der Hilfe für Webmaster
beschreibt weitere Umstände, unter denen endlose Weiten entstehen können und enthält Empfehlungen, wie man das Problem umschiffen kann. Eine Lösung bestünde darin, ganze Kategorien von dynamisch erzeugten Links durch die robots.txt-Datei zu blockieren.
Die Hilfe für Webmaster enthält viele Informationen dazu, wie man robots.txt einsetzen kann.
Überprüft in diesem Fall aber auch, ob der Googlebot noch in der Lage ist,
euren gesamten Content auf anderem Wege aufzufinden. Ein anderer Lösungsansatz bestünde darin, die problematischen Links mit dem "nofollow"-Linkattribut zu versehen. Für
mehr Infos zu "nofollow"-Links werft
doch ebenfalls einen Blick in unsere Hilfe für Webmaster!
To infinity and beyond? No! (English version)
Post von Torry Hoffman, Webmaster Tools Team (Übersetzung von Jörg, Search Quality)
Search Quality – Fortsetzung
Montag, 4. August 2008
Vor einigen Wochen stellte
Udi Manber die Search Quality Gruppe vor
, und die
vorigen
Posts
in dieser Reihe handelten von Ranking. Das Ranking von Webdokumenten ist der Kern dessen, warum die Google-Suche so gut funktioniert, aber das Sucherlebnis besteht aus noch viel mehr. In diesem Post werde ich die Grundsätze beschreiben, die unsere Arbeit am Sucherlebnis als Ganzes leiten, und darüber sprechen, wie wir diese Grundsätze auf Schlüsselaspekte der Suche anwenden. Ich werde auch darauf eingehen, wie wir durch gründliches Testen sicherstellen, dass wir die richtigen Schritte unternehmen. Der nächste Post dieser Reihe wird einige der Tests beleuchten, die wir momentan durchführen.
Eine kurze Vorstellung zu meiner Person: Ich bin Ben Gomes und ich arbeite seit 1999 bei Google, überwiegend im Bereich Search Quality. Ich hatte das Glück, zu den meisten Teilen der Suchmaschine beitragen zu können, vom Crawlen des Webs hin zu Ranking. Momentan bin ich der verantwortliche Ingenieur für die Benutzeroberfläche und die Features der Suche.
Wenn ich zu Freunden sage, dass ich an Googles Benutzeroberfläche für die Suche arbeite, ist eine typische Reaktion: "Was machst du denn da? Die sieht doch immer gleich aus." Dann schauen sie mich misstrauisch an und meinen, ich solle nicht an etwas herumpfuschen, was gut funktioniert. Google sei genau richtig, so wie es ist -- eine schlichte, schnelle Webseite. "Das ist toll, aber das kann doch nicht so schwer sein?"
Um diese Frage zu beantworten, möchte ich bei unserem wichtigsten Ziel für die Websuche beginnen: wir wollen, dass ihr so schnell wie möglich zu den gesuchten Webseiten gelangt. Die Suche ist dabei nicht das Ziel, sondern vielmehr der Weg dorthin. Dies scheint offensichtlich, doch es unterscheidet eine Suchmaschine radikal von den meisten anderen Sites im Web, die ihren Erfolg daran messen, wie lange die User bleiben. Wir messen den Erfolg unserer Websuche teilweise daran, wie schnell ihr wieder geht (zufrieden, wie wir hoffen!). Wir wenden die folgenden Grundsätze an, damit ihr so schnell wie möglich zu den gesuchten Informationen gelangt:
Eine schlanke Seite.
Eine schlanke Seite kann schneller heruntergeladen und üblicherweise schneller von eurem Browser dargestellt werden. Dies führt zu einer minimalistischen Design-Ästhetik; zusätzlicher Schnickschnack auf der Benutzeroberfläche verlangsamt die Seite, ohne einen großen Nutzen für euch darzustellen.
Komplexe Algorithmen, einfache Darstellung.
Viele Features der Suche erfordern einiges an algorithmischer Komplexität und eine riesige Menge an Datenanalysen, damit sie gut funktionieren. Der Trick ist es, diese Komplexität hinter einer einfachen und intuitiven Benutzeroberfläche zu verbergen. Rechtschreibkorrektur, Snippets, Sitelinks und die Einblendung von verwandten Suchbegiffen sind Beispiele von Features, die komplizierte Algorithmen erfordern, welche wir konstant verbessern. Aus Sicht des Users wird die Suche, auf fast unsichtbare Art und Weise, einfach besser.
Features, die global funktionieren
. Features müssen so konzipiert sein, dass die Algorithmen und die Darstellung für alle Sprachen und alle Länder adaptiert werden können. Nehmt beispielsweise das Problem der Rechtschreibkorrektur in Chinesisch, wo Suchanfragen oft nicht in einzelne Wörter aufgeteilt sind, oder Hebräisch und Arabisch, wo der Text von rechts nach links geschrieben wird (interessanterweise wird dies als ein Beispiel für den First-Mover-Nachteil angesehen – wenn man etwas in Stein meißelt, ist es einfacher, den Hammer in der rechten Hand zu halten!).
Daten als Grundlage für Entscheidungen – testen, testen, testen.
Wir versuchen zu verifizieren, dass wir das Richtige tun, indem wir Tests durchführen. Ein Design, das vielversprechend aussieht, kann im Test letztendlich schlecht abschneiden.
Diese Grundsätze können zwiespältig sein. Wenn wir euch beispielsweise für jedes Suchergebnis mehr Text (oder Bilder) anzeigen, dann kann euch das vielleicht dabei helfen, das beste Ergebnis auszuwählen. Eine Ergebnisseite, die zu viele Informationen enthält, braucht jedoch länger beim Herunterladen und bei der visuellen Verarbeitung. Alle Informationen, die wir zur Ergebnisseite hinzufügen, müssen also gründlich bedacht werden, um sicherzustellen, dass der Nutzen für den User die Kosten überwiegt, diese zusätzlichen Informationen zu verarbeiten. Dies trifft auf alle Bereiche des Sucherlebnisses zu, vom Eintippen einer Suchanfrage bis zum Überfliegen und Durchforsten der Ergebnisse.
Die Suche beginnt mit der Eingabe einer Suchanfrage. Ein typischer Grund zur Frustration ist es, wenn man sich über die richtige Schreibweise eines Wortes nicht sicher ist! Die Rechtschreibkorrektur -- scheinbar ein einfaches und offensichtliches Feature -- verbirgt viele technische Herausforderungen. Zum Beispiel würde kein gewöhnliches englisches Wörterbuch je die richtige Schreibweise von Britney Spears enthalten (Britney Spears ist, wahrscheinlich ganz ohne ihr Wissen, zum Paradebeispiel für
dieses Feature
geworden). Wir analysieren die Milliarden Seiten im Web sowie unsere Logdaten von Suchanfragen in großem Maße, um festzustellen, was die "echten Worte" im Web und was wahrscheinlich Schreibfehler sind. Das System, das euch die Rechtschreibkorrektur liefert, muss im Bruchteil einer Sekunde eine riesige Anzahl an möglichen Worten, die ihr
vielleicht
meint (erheblich mehr, als jemals in einem manuell zusammengestellten Wörterbuch verzeichnet wurde), in Betracht ziehen und bestimmen, ob es eine wahrscheinlichere Suchanfrage gibt, die ihr eigentlich eingeben wolltet. Wenn wir uns sicher sind, dass ihr eigentlich vorhattet, etwas anderes einzutippen, dann erlauben wir uns eine seltene Freiheit bei der Ausgabe der Ergebnisse: wir versuchen euch davon abzulenken, auf das erste Ergebnis zu schauen. Die Rechtschreibkorrektur ist in eurem Blickfeld, in einem nicht zu übersehenden leuchtenden Rot. Wir achten außerdem darauf, dass
nichts anderes auf der Seite rot ist
, es sei denn, es wäre so wichtig wie die Rechtschreibung! (Bis jetzt ist dem nicht so.) Die Algorithmen für die Rechtschreibkorrektur werden ständig besser. Sie funktionieren jetzt für eine große Anzahl an Sprachen und können noch besser entdecken, wann ihr einen Rechtschreibfehler macht. Es ist uns so wichtig, die korrekte Schreibweise der Suchanfrage zu finden, dass wir es in Betracht ziehen, euch die Ergebnisse für die korrigierte Suchanfrage in der Mitte der Seite anzuzeigen (nur für den Fall, dass ihr unseren leuchtend roten Text oben und unten auf der Seite übersehen habt!).
Nach der richtigen Formulierung der Suchanfrage ist der nächste Schritt die Auswahl einer Seite von der Ergebnisliste. Für jedes Ergebnis zeigen wir den Titel und die URL an, sowie ein kurzes zweizeiliges Snippet. Seiten, die keinen richtigen Titel haben, werden von Usern oft ignoriert. Als eine der größeren Veränderungen der letzten Zeit extrahieren wir jetzt Titel für Seiten, die keinen HTML-Titel spezifizieren, bei denen jedoch ein Titel auf der Seite klar vorhanden ist. Um diesen vom Autor der Seite beabsichtigten Titel zu "sehen", analysieren wir das HTML der Seite. Dies macht es viel wahrscheinlicher, dass ihr eine Seite nicht wegen eines fehlenden guten Titels ignoriert. Unter dem Titel erscheint das Snippet, und eine entscheidende frühe Innovation lag darin, was Google als Snippet anzeigte. Zu dieser Zeit lieferten Suchmaschinen die ersten zwei Zeilen einer Webseite als Snippet; Google jedoch zeigte euch Ausschnitte, in denen eure Suchbegriffe tatsächlich vorkamen (Experten für Information Retrieval nennen das "Keywords-in-Context"). Keywords-in-Context anzuzeigen ist visuell einfach und von den simpleren Snippets so gut wie nicht zu unterscheiden, es ist jedoch eine sehr viel wertvollere Hilfe bei der Entscheidung, welche Seite ihr besuchen wollt. Diese Einfachheit trügt, denn dahinter steckt Komplexität: für solch ein Snippet müssen wir den tatsächlichen Text aller Ergebnisse durchgehen, um die relevantesten Ausschnitte zu finden (in denen die Suchbegriffe enthalten sind), anstatt euch einfach nur die ersten paar Zeilen zu liefern.
Mit der Zeit haben wir unsere Snippets mit Hilfe von Algorithmen, die die Relevanz von Teilen einer Seite bestimmen, verbessert. Die Änderungen sind subtil -- wir heben Synonyme für eure Suchbegriffe in den Ergebnissen hervor -- oder offensichtlicher. Hier ist ein Beispiel-Screenshot, in dem nach "arod" gesucht wurde. Wie ihr sehen könnt, sind die Wörter Alex und Rodriguez im Snippet des Suchergebnisses fett gedruckt. Dies beruht auf unserer Analyse, dass aus plausiblen Gründen wahrscheinlich der Baseballspieler Alex Rodriguez gemeint wurde:
Ein offensichtlicheres Beispiel unserer jüngsten Änderungen ist die Anzeige des Datums für Seiten, auf denen Verfasserangaben vorhanden sind. Diese Angaben gibt es in ganz unterschiedlichen Formaten. Wir extrahieren die Datumsangaben und stellen sie einheitlich dar, so dass ihr sie leicht überfliegen könnt:
Für die Navigationssuche, eine der üblichsten Arten von Suchanfragen, bei der ihr den Namen einer euch bekannten Website eingebt, haben wir Shortcuts eingeführt (wir nennen sie "Sitelinks"). Über diese Sitelinks könnt ihr zu den wichtigsten Teilen der Site gelangen. Sie sind ein Beispiel für die oben erwähnten Grundsätze; sie sind eine einfache Ergänzung zum Topresultat, durch die ein wenig zusätzlicher Text zur Ergebnisseite hinzugefügt wird.
Die Homepage von Hewlett-Packard hat beispielsweise fast 60 Links in einer Navigationsstruktur auf zwei Ebenen. Durch die Kombination von verschiedenen Signalen wählen unsere Algorithmen aus diesen Links diejenigen aus, bei denen es unserer Meinung nach am wahrscheinlichsten ist, dass ihr sie besuchen wollt.
Was, wenn ihr unter den Topresultaten nicht gefunden habt, wonach ihr sucht? In diesem Fall solltet ihr wahrscheinlich eine andere Suchanfrage ausprobieren. Wir helfen euch dabei, indem wir unten auf der Ergebnisseite eine Auswahl an verwandten Suchbegriffen anzeigen -- auch wenn diese Auswahl euch vielleicht nicht die Suchanfrage liefert, die ihr braucht, so bietet sie dennoch Tipps für verschiedene (und vielleicht erfolgreichere) Alternativen zur Verfeinerung eurer Suchanfrage. Da diese Vorschläge unten auf der Seite platziert sind, stören sie nicht, sind jedoch hilfreich zur Stelle, wenn der Rest der Suchergebnisse den Usern keine zufriedenstellenden Informationen liefern konnte.
Ich habe einige der wichtigsten Aspekte zum Thema Sucherlebnis beschrieben und bin auch darauf eingegangen, was wir mit der Zeit verändert haben -- einiges subtil und anderes, was mehr ins Auge springt. Woher wissen wir dabei, ob wir erfolgreich sind und keinen Mist gebaut haben? Wir führen fortwährende Bewertungen dieser Änderungen durch, indem wir sie mit euch teilen! Wir launchen anstehende Änderungen für einen kleinen Bruchteil unserer User und analysieren dann, ob sie das Sucherlebnis eher zu verbessern oder zu trüben scheinen. Wir verwenden viele Kriterien, um festzulegen, ob wir erfolgreich waren oder versagt haben. Der Bewertungsvorgang für diese Verbesserungen ist eine Wissenschaft für sich, mit vielen möglichen Fallstricken. Durch unsere experimentelle Methodik können wir eine Reihe von Möglichkeiten erforschen und dann das launchen, was am besten funktioniert. Für jedes neue Feature, das wir einführen, haben wir häufig eine Menge an Features getestet, die nie verwirklicht wurden.
Also, um zur anfänglichen Frage zurückzukommen: Wir verändern Googles Ergebnisseite tatsächlich ständig, und das seit Langem. Und nein, wir pfuschen nicht an Dingen herum, die gut funktionieren. Das würdet ihr nicht zulassen.
Im nächsten Post dieser Reihe werde ich ein paar Tests vorstellen, an denen wir gerade arbeiten, und darüber sprechen, was wir daraus lernen wollen.
Search quality, continued (English version)
Post von Ben Gomes, Distinguished Engineer (Übersetzung von Johanna, 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