Interview mit Google Search Guru Amit Singhal

Grade ein Interview mit Google Search Guru Amit Singhal gelesen. Singhal leitet das Core Ranking Team innerhalb Googles Search Quality Group und sitzt beispielsweise jeden Donnerstag mit Matt Cutts, Head des Anti-Web Spam Teams, im Meeting, um den Launch der wöchentlichen Änderungen am Algorithmus zu besprechen. Um und bei 6.000 sollen das allein im letzten Jahr gewesen sein, zum Testen reicht dabei „Much less than 1% of our traffic“ – glaubt man gern angesichts von Googles Market Share.

Drei Dinge sind mir in dem Artikel besonders aufgefallen. Zum einen der Punkt

„We don’t do things by hand. When you actually build algorithms to solve problems, not only do you benefit the users you are most conversant with, the U.S. users, but our algorithms go around the world. By building this algorithmic antidote and observing what signals make it possible, we can make improvements to our system worldwide.”

Liegt natürlich auf der Hand, dass man bei Google in Anbetracht der Datenmenge von so einer Arbeitsweise abhängig ist. Würde man jeden Fehler einzeln per Workaround lösen (bspw. durch per Hand gesetzte Synonyme oder Blacklists), lernt der Algorithmus nichts dazu und es entsteht zusätzliche Arbeit. Dadurch erklärt sich aber auch manch vermeintlich langsames Reagieren des Google Index‘ - der Fehler ist bereits erkannt, die Lösung hat sich jedoch vom Algorithmus über den nächsten Crawl noch nicht bis zur Aktualisierung des Index‘ vorgekämpft.

Der nächste Punkt, der mir auffiel:

„A few years ago, our engineers were noticing that on acronyms, we were returning lots of good results but the bolding on the page was not sufficient. If you type CIA, it could mean Central Intelligence Agency, or it could mean Culinary Institute of America. If we did not highlight that this result will go to the government agency, and that result is related to food, users were taking more time to click, wasting more of their time. Could we shave off 30 or 40 milliseconds off in their reaction time? Within a few weeks, we had an experiment, users were liking it, the clickthrough rates were great, and their response times were down.”

Hier wird die Response Time, die vergeht, bis ein bestimmtes Resultat auf einer SERP geklickt wird, als Ranking Faktor herangezogen. In diesem Beispiel allerdings nur, um eine Navigational Search zu bewerten, inwieweit sich dieser Faktor auch für andere Suchen eignet, könnte man mal diskutieren – eine sehr schnell geklickte Site muss schließlich nicht zwingend auch die gewünschten Ergebnisse enthalten. Für die Usability der SERP ist es allerdings ein sehr guter Indikator – wie schnell finden sich die User darauf zurecht.

Ein spannendes Detail der täglichen Arbeit beschrieb Singhal auch noch:

„One of the tools that we developed recently is when we were doing our freshness work, and we are still doing it: It was getting hard for engineers to [prove] something happened on Google. But by the time they complained about something that happened, our freshness algorithms would catch up. Other engineers would read their email 10 minutes later, and say, it’s working fine for me. This was becoming incredibly frustrating for engineers.
So they developed a tool called Replay where they can freeze time retrospectively and take a picture of it. I can say, What would have happened had I run this query at 12:49? Then we can go debug all the systems and say, Ah, that system failed. Oh, we need to reduce latency over there.“

Hat also der Freshness-Algorithmus bereits die SERP verändert und der nächste Mitarbeiter kann schon nach 10 Minuten den Fehler nicht mehr reproduzieren (bei Suchen mit hohem QDF-Faktor), lässt sich an jeder Maschine einfach der Snapshot beliebig zurückstellen und das entsprechende System mit der alten SERP debuggen.

Das volle Interview findet ihr hier.