Posted:

Da die Zahl der Smartphone-Nutzer ständig wächst, gibt es auch immer mehr Websites, deren Inhalte für die Ansicht auf Smartphones optimiert sind. Heute freuen wir uns, euch mitteilen zu können, dass der Googlebot-Mobile jetzt zusätzlich zu seinen bisherigen Funktionshandy-User-Agents mit einem Smartphone-User-Agent crawlt. So können wir mehr Smartphone-Inhalte abdecken und Smartphone-Nutzern eine bessere Sucherfahrung bieten.
Hier die wichtigsten User-Agent-Zeichenfolgen, die der Googlebot-Mobile jetzt verwendet:

  • Funktionshandy-Googlebot-Mobile: 
    • SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (kompatibel; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
    • DoCoMo/2.0 N905i(c100;TB;W24H16) (kompatibel; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)

  • Smartphone-Googlebot-Mobile: 
    • Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; en-us)
    • AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7 (kompatibel; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
    • Update October 2013: Der neue Googlebot-Mobile für Smartphone-User-Agent ist: Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (kompatibel; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
Die vom Smartphone-Googlebot-Mobile gecrawlten Inhalte werden hauptsächlich verwendet, um die Nutzererfahrung bei der mobilen Suche zu verbessern. Beispielsweise kann der neue Crawler Inhalte entdecken, die für die Ansicht auf Smartphones optimiert sind, sowie Smartphone-spezifische Weiterleitungen.

Eine weitere neue von uns eingeführte Funktion, die diese Signale verwendet, dient dem Überspringen der Weiterleitung für Smartphone-optimierte Seiten. Wenn wir in unseren Suchergebnissen eine URL entdecken, die Smartphone-Nutzer zu einer anderen URL weiterleitet, die Smartphone-optimierte Inhalte bietet, ändern wir den Link in den Suchergebnissen so, dass er direkt auf die endgültige Ziel-URL verweist. So wird die zusätzliche Latenz, die auf die Weiterleitung zurückzuführen ist, vermieden und beim Aufruf der Zielseiten solcher Suchergebnisse eine durchschnittliche Zeitersparnis von 0,5 bis 1 Sekunden erreicht.

Da alle Googlebot-Mobile-User-Agents sich als bestimmte Mobilgerätetypen identifizieren, behandelt bitte jede Googlebot-Mobile-Anfrage genauso wie die Anfrage eines menschlichen Nutzers mit demselben Telefon-User-Agent. Diese und andere Richtlinien sind in unserem vorherigen Blogpost  beschrieben und gelten immer noch, außer denjenigen, die sich auf Smartphones, die wir heute aktualisieren, beziehen. Falls eure Website den Googlebot-Mobile aufgrund der Tatsache, dass er nur mit Funktionshandy-User-Agents crawlt, speziell behandelt hat, empfehlen wir euch dringend, diesen Grundsatz zu überprüfen und diejenigen Inhalte zu liefern, die dem User-Agent des Googlebot-Mobile entsprechen, sodass sowohl eure Funktionshandy- als auch eure Smartphone-Inhalte richtig indexiert werden.
Solltet ihr weitere Fragen haben, stellt sie bitte in den Webmaster-Hilfeforen.

Update 9 August 2013:
Wenn eine Website separate URLs für Desktop- und Smartphone-User verwendet und wir korrekte rel-alternate-media annotations (Link zu englischsprachigen Inhalten) auffinden, welche die Desktop und Smartphone Seiten verbinden, dann können unsere Algorithmen die Smartphone Seite als Zielseite in den Suchergebnissen verwenden.

Gepostet von Yoshikiyo Kato, Software Engineer (Veröffentlicht von Dominik Zins, Search Quality)

Posted:

Einige Webmaster haben in unseren Foren Fragen zu hosting-bezogenen Problemen gestellt, die ihre Websites betreffen. Wir möchten euch einige Probleme und unsere Vorschläge zur Behebung darlegen, um sowohl Hostanbieter als auch Webmaster bei der Erkennung, Diagnose und Behebung dieser Probleme zu unterstützen.

Blockieren von Googlebot-Crawling. Dies ist ein häufig auftretendes Problem, das in der Regel durch eine falsche Konfiguration in einer Firewall oder einem DoS-Schutzsystem und teilweise auch durch das Contentmanagement System entsteht, das die Website benutzt. Schutzsysteme sind ein wichtiger Teil von gutem Hosting und werden häufig konfiguriert, um ein ungewöhnlich hohes Aufkommen an Serveranfragen zu blockieren. Dies erfolgt teilweise automatisch. Da der Googlebot häufig mehr Anfragen durchführt als ein menschlicher Nutzer, können diese Schutzsysteme den Googlebot blockieren und ein Crawling eurer Website verhindern. Verwendet bei diesem Problem die Funktion "Abruf wie durch Googlebot" in den Webmaster-Tools und sucht nach weiteren in den Webmaster-Tools angezeigten Crawling-Fehlern.
Wir stellen Webmastern und Hostanbietern, die Googlebot-Crawling besser kontrollieren möchten, verschiedene Tools zur Verfügung, die außerdem die Crawling-Effizienz verbessern:


Weitere Informationen dazu findet ihr in unseren häufig gestellten Fragen zu Crawling und Indexierung.

Verfügbarkeitsprobleme. Ein ähnliches Problem ist die Nichtverfügbarkeit von Websites, wenn der Googlebot (und Nutzer) versuchen, auf die Website zuzugreifen. Dazu gehören DNS-Probleme, überlastete Server, die zu Zeitüberschreitungen und abgelehnten Verbindungsversuchen führen, falsch konfigurierte Content Distribution Networks (CDNs) sowie zahlreiche andere Fehler. Wenn der Googlebot auf derartige Probleme stößt, melden wir diese in den Webmaster-Tools als Fehler durch nicht erreichbare URL oder Crawling-Fehler.
Ungültige SSL-Zertifikate. Damit SSL-Zertifikate für eure Website gültig sind, müssen sie mit dem Namen der Website übereinstimmen. Zu den am häufigsten auftretenden Problemen gehören abgelaufene SSL-Zertifikate und falsch konfigurierte Server, bei denen alle Websites auf diesem Server das gleiche Zertifikat verwenden. Die meisten Webbrowser versuchen, die Nutzer in diesem Fall zu warnen, und Google versucht, die Webmaster durch das Versenden einer Nachricht über die Webmaster-Tools auf dieses Problem hinzuweisen. Das Problem kann behoben werden, indem ihr sicherstellt, dass SSL-Zertifikate verwendet werden, die für alle Domains und Sub-Domains eurer Website gültig sind, mit denen der Nutzer interagiert.

Wildcard-DNS. Websites können so konfiguriert werden, dass sie auf alle Anfragen der Sub-Domains reagieren. Beispielsweise kann die Website unter example.com so konfiguriert werden, dass sie auf Anfragen von foo.example.com, made-up-name.example.com und sämtliche anderen Sub-Domains reagiert.
Dies kann in einigen Fällen erwünscht sein, zum Beispiel wenn auf einer nutzergenerierten Content-Website für jedes Konto eine eigene Sub-Domain eingerichtet wird. In anderen Fällen möchte der Webmaster dieses Verhalten jedoch vermeiden, da es dazu führen kann, dass Content unnötigerweise in verschiedenen Hostnamen dupliziert wird. Außerdem kann das Googlebot-Crawling beeinflusst werden.
Zur Minimierung der Probleme in Wildcard-DNS-Einrichtungen könnt ihr eure Website entweder so konfigurieren, dass sie nicht verwendet werden, oder ihr konfiguriert euren Server so, dass er nicht auf nicht vorhandene Hostnamen antwortet. Dazu kann er entweder den Verbindungsversuch ablehnen oder eine HTTP 404-Fehlermeldung zurückgeben.

Falsch konfiguriertes virtuelles Hosting. Bei diesem Problem geben mehrere Hosts und/oder Domain-Namen, die auf dem gleichen Server gehostet werden, stets die Inhalte von nur einer Website zurück. Mit anderen Worten gibt der Server, obwohl er mehrere Websites hostet, immer nur eine Website zurück, unabhängig von der Anfrage. Zur Diagnose des Problems müsst ihr überprüfen, ob der Server richtig auf den HTTP-Header des Hosts reagiert.

Duplizierung von Content über hosting-spezifische URLs. Viele Hosts bieten zu Test-/Entwicklungszwecken URLs für eure Website an. Wenn ihr beispielsweise die Website http://a.com/ auf dem Hostanbieter example.com hostet, bietet der Host möglicherweise über eine URL wie http://a.example.com/ oder http://example.com/~a/ Zugriff auf eure Website. Wir empfehlen euch, diese hosting-spezifischen URLs durch ein Passwort zu schützen und so den öffentlichen Zugriff zu verhindern. Selbst wenn diese URLs zugänglich sind, berücksichtigen unsere Algorithmen in der Regel die Absicht des URL-Webmasters. Falls unsere Algorithmen die hosting-spezifischen URLs auswählen, könnt ihr diese durch die korrekte Implementierung von Autorisierungstechniken so beeinflussen, dass sie die bevorzugten URLs auswählen.

Soft Error-Seiten. Einige Hostanbieter zeigen Fehlerseiten unter Verwendung eines HTTP 200-Statuscode (also "Erfolg") anstelle eines HTTP-Fehlerstatuscode an. Beispielsweise könnte die Fehlerseite "Seite nicht gefunden" eine HTTP 200-Fehlermeldung anstelle von 404 zurückgeben, wodurch sie eine Soft 404-Seite wird, oder die Meldung "Dienst nicht verfügbar" kann eine 200-Fehlermeldung statt des korrekten 503 HTTP-Statuscodes zurückgeben. Wir setzen alles daran, Soft Error-Seiten zu erkennen, wenn unsere Algorithmen jedoch die Soft Error-Seiten eines Webhosts nicht erkennen, werden diese Seiten möglicherweise mit Fehler-Content indiziert. Dies kann zu Problemen beim Ranking oder der domainübergreifenden Auswahl von URLs führen.

Der zurückgegebene Statuscode lässt sich leicht überprüfen: Überprüft einfach die vom Server zurückgegebenen HTTP-Header mithilfe eines beliebigen Tools wie "Abruf wie durch Googlebot". Wenn eine Fehlerseite die Meldung HTTP 200 zurückgibt, ändert die Konfiguration so, dass der korrekte HTTP-Fehlerstatuscode zurückgegeben wird. Achtet außerdem auf Soft 404-Berichte in den Webmaster-Tools auf den Crawling-Fehlerseiten im Diagnosebereich.

Content-Änderung und Frames. Webmaster stellen teilweise mit Erstaunen fest, dass ihre Seiteninhalte durch Hostanbieter geändert wurden, und zwar in der Regel durch Einfügen von Skripts oder Bildern auf der Seite. Webhosts können eure Inhalte auch anbieten, indem sie ihn über Frames oder iFrames in andere Seiten einbetten. Wenn ihr überprüfen möchtet, ob ein Webhost euren Inhalt unerwartet ändert, überprüft einfach den Quellcode der Seite, wie er vom Host wiedergegeben wird, und vergleicht ihn mit dem Code, den ihr hochgeladen habt.
Bedenkt, dass einige serverseitige Codeänderungen sehr nützlich sein können. Beispielsweise kann ein Server, der das mod_pagespeed Apache-Modul von Google oder andere Tools verwendet, euren Code in minimierter Form zurückgeben, um den Page Speed zu optimieren.

Spam und Malware. Wir haben festgestellt, dass einige Webhosts und Bulk-Sub-Domain-Dienste häufige Quellen von Malware und Spam geworden sind. Wir versuchen, beim Schutz unserer Nutzer und bei der Suchqualität stets sehr gezielt vorzugehen, wenn wir jedoch feststellen, dass ein großer Teil der Websites auf einem bestimmten Webhost Spam oder Malware verbreitet, sehen wir uns unter Umständen gezwungen, Maßnahmen für den gesamten Webhost zu ergreifen. Damit ihr in Bezug auf Malware immer auf dem neuesten Stand bleibt, bieten wir:



Wir hoffen, dass diese Liste sowohl Hostanbietern als auch Webmastern bei der Diagnose und Behebung dieser Probleme hilft. Beachtet im Übrigen auch die qualitativen Aspekte von Hosting, wie die Qualität des Dienstes und den hilfreichen Support. Wenn ihr weitere Fragen habt, könnt ihr diese wie gewohnt in unserem Webmaster-Hilfeforum stellen.

Von Pierre Far, Webmaster Trends Analyst (Veröffentlicht von Dominik Zins, Search Quality)

Posted:
Im heutigen Video beantwortet Matt Cutts die Frage eines Users, der wissen möchte, ob Seiten wegen fehlender SEO benachteiligt werden oder gar Penaltys erhalten.



Die heutige Frage kommt aus Buckinghamshire, Großbritannien. Tinperson möchte wissen: "Google scheint Websites zu bevorzugen, die von Experten erstellt wurden, die alle SEO Best Practices und sämtliche Tipps von Google anwenden. Die vielen Websites mit tollen Inhalten, die technisch weniger ausgefeilt sind, werden deshalb hoffentlich nicht benachteiligt?"

An diesen Websites werden definitiv keine manuellen Aktionen durchgeführt, die ihren PageRank herabstufen würden. Sie werden also nicht benachteiligt. Wir versuchen auszugleichen, wenn ihr hochwertige Inhalte habt, aber technischen Fehler gemacht habt.

Oft werden wir gefragt, warum es keine Extrapunkte für W3C-Validierung gibt. Ganz einfach deshalb, weil es viele Inhalte ohne Validierung gibt, die aber trotzdem richtig gut sind. Nur weil bei einer Website technisch alles bis ins letzte Detail stimmig und die HTML-Struktur perfekt ist, heißt das noch lange nicht, dass die Inhalte auch gut sind.

Ihr könnt schon mit einfachen Dingen viel erreichen: Erstellt zugängliche Inhalte, die gecrawlt werden können und gute Titel haben. Aber auch wenn ihr technisch weniger versiert seid und in dieser Richtung Fehler macht, wollen wir eure Inhalte zeigen, wenn sie gut sind. Wenn ihr Inhalte einbettet, die wir erst extrahieren müssen, oder wenn wir JavaScript verarbeiten müssen, um Links zu finden, oder wenn etwas Improvisation erforderlich ist, weil ihr eure Seiten nicht betitelt habt und wir einen Titel erstellen oder erraten müssen, dann tun wir das. So müsst ihr euch nicht um SEO kümmern, aber wir finden eure guten Inhalte trotzdem.

Natürlich hilft es uns, wenn ihr euch die Zeit nehmt, eure Inhalte zugänglich und nützlich zu gestalten. Wir wollen euch aber keinesfalls benachteiligen, wenn ihr bei SEO nicht alles richtig macht und euch beispielsweise nicht um alle URLs kümmert. Auch wenn ihr euch nicht mit SEO auskennt, könnt ihr gute Inhalte haben.

Vor allem möchten wir Inhalte liefern, die bei den Leuten ankommen, also gute, ansprechende Inhalte. Deshalb möchten wir den Googlebot von Jahr zu Jahr besser machen. Wir erarbeiten neue Methoden, um Seiten in den Index aufzunehmen und auszugeben. Daran arbeiten wir ständig, und wir hoffen, dass wir unsere Sache gut machen.

Veröffentlicht von Daniela Loesser, Search Quality Team

Posted:
Im heutigen Video beantwortet Matt Cutts die Frage, ob ein AdWords-Account und das Schalten von AdWords-Anzeigen einen positiven Einfluss auf das Ranking einer Website haben.



Die heutige Frage kommt aus der Bay Area in Kalifornien. Sie lautet: "Erhalte ich durch den Kauf von AdWords höhere Rankings durch den Algorithmus?"

Die Antwort lautet "Nein". Ihr habt keine Vorteile in den organischen oder redaktionellen Suchrankings von Google, wenn ihr AdWords kauft. Es gibt also keinen Anstieg. Durch den Kauf von AdWords wird nichts am Algorithmus geändert und ihr erhaltet keine höheren Rankings in den organischen Suchergebnissen. Zählt also nicht darauf.

Erstellt stattdessen ansprechende Inhalte, die Links anziehen, denn das ist wirklich gut. Durch den Kauf von AdWords gehen eure organischen Rankings nicht nach oben.

Veröffentlicht von Daniela Loesser, Search Quality Team

Posted:
Viele Websites richten sich an Nutzer auf der ganzen Welt. Es gibt unterschiedliche Strategien, wie Inhalte entsprechend der Sprache und/oder Region des Nutzers bereitgestellt werden können. Seit dem letzten Jahr unterstützen wir explizite Vermerke für Webseiten, auf denen der gleiche Inhalt mithilfe unterschiedlicher Sprachvorlagen dargestellt wird.
Nun ergänzen wir die Unterstützung mehrsprachiger Inhalte um eine verbesserte Verarbeitung in den folgenden beiden Konfigurationen:

  • Überregionale Websites, die im Wesentlichen dieselben Inhalte verwenden. Beispiel: englischsprachige Webseiten für Australien, Kanada und die USA, bei denen jeweils nur die Preise unterschiedlich sind
  • Überregionale Websites mit vollständig übersetzten Inhalten oder voneinander stark abweichenden einsprachigen Inhalten für verschiedene Regionen Beispiel: eine Produkt-Webseite in deutscher, englischer und französischer Sprache

Sprache und Standort spezifizieren
Unsere Unterstützung des Linkelements "rel="alternate" hreflang wurde dahingehend erweitert, dass nun Inhalte verarbeitet werden, die übersetzt oder für verschiedene geografische Regionen bereitgestellt werden. Mit dem hreflang-Attribut können die Sprache und nach Wunsch das Land sowie URLs entsprechender Inhalte angegeben werden. Mit der Angabe dieser alternativen URLs möchten wir erreichen, dass wir Signale für diese Seiten konsolidieren und den Nutzern bei der Suche die passende URL bereitstellen können. Alternative URLs können zur selben Website oder einer anderen Domain gehören.

Seiten mit dem Vermerk versehen, dass sie im Wesentlichen die gleichen Inhalte aufweisen
Bei Seiten, die im Wesentlichen die gleichen Inhalte in derselben Sprache aufweisen, sich jedoch an verschiedene Länder richten, könnt ihr mit dem Linkelement "rel="canonical" eure bevorzugte Version angeben. Anhand dieses Signals erkennen wir, dass in den Suchergebnissen primär diese Version erscheinen soll. Die lokalen URLs sehen die Nutzer dann, wenn sie für diese geeignet sind. Es wäre beispielsweise denkbar, dass ihr eine Produktseite auf Deutsch habt, die Nutzer, die auf den Google-Websites für Deutschland, Österreich und die Schweiz suchen, jedoch mit einer jeweils eigenen Version ansprechen möchtet.
Update: Um die Implementation zu vereinfachen, empfehlen wir die Verwendung von rel="canonical" für diese Fälle nicht mehr.

Verwendungsbeispiel
Anhand folgender URLs möchten wir euch erklären, wie das funktioniert:

http://www.example.com/: die allgemeine Startseite einer Website auf Spanisch
http://es-es.example.com/: die spanischsprachige Version für Nutzer in Spanien
http://es-mx.example.com/: die spanischsprachige Version für Nutzer in Mexiko
http://en.example.com/: die allgemeine englischsprachige Version

Auf allen diesen Seiten kann das folgende Markup zum Einsatz kommen, um die Sprache und wahlweise die Region anzugeben:
<link rel="alternate" hreflang="es" href="http://www.example.com/" /><link rel="alternate" hreflang="es-ES" href="http://es-es.example.com/" /><link rel="alternate" hreflang="es-MX" href="http://es-mx.example.com/" /><link rel="alternate" hreflang="en" href="http://en.example.com/" />
Falls ihr ein Sub-Tag für die Region angebt, gehen wir davon aus, dass ihr die jeweilige Region ansprechen möchtet.
Beachtet bitte, dass diese Vermerke immer für eine URL gelten. Verwendet für diese beiden Linkelemente unbedingt die spezifische URL und nicht die der Startseite.

Weitere Hilfe
Wenn ihr Unterstützung bei der richtigen Implementierung überregionaler und mehrsprachiger Websites braucht, findet ihr weitere Informationen wie immer in unserer Hilfe im Artikel zu diesem Thema oder im Webmaster-Hilfeforum.

Autor: Christopher Semturs, Software Engineer, Search Infrastructure, Google Schweiz (Veröffentlicht von Dominik Zins, Search Quality)

Posted:
Im heutigen Video erklärt Matt Cutts, was es mit Begriffen wie Vertrauen, Ruf oder Autorität im Zusammenhang mit dem Ranking von Websites bei Google auf sich hat.



Die heutige Frage kommt aus Kanada. JZ Becker möchte wissen: "Könntest du etwas zu Ranking-Signalen wie Vertrauenswürdigkeit sagen? Google-Mitarbeiter erwähnen diese Signale manchmal, aber es gibt zu diesem Thema keine offizielle Dokumentation von Google."

Eine sehr gute Frage. Vertrauenswürdigkeit ist bei uns eine Art Sammelbegriff. PageRank ist die bekannteste Variante davon. Es geht darum, die Wichtigkeit von Links einzustufen. Mit vielen hochwertigen Links gewinnt ihr bei Google an Vertrauen.

Es gibt auch andere Signale. Für unser Ranking verwenden wir über 200 verschiedene Signale. Sie befassen sich entweder mit der Vertrauenswürdigkeit oder damit, wie gut ein Ergebnis für eine Anfrage ist, also wie passend es ist. Wie hoch ist eure Quote beim Informationsabruf ausgehend von der Eingabe der Nutzer? PageRank zählt zuden Algorithmen, mit denen Ruf, Vertrauenswürdigkeit und Autorität einer Website ermittelt werden sollen.

Wir haben kein spezielles "Vertrauenswürdigkeits-Ranking" oder so etwas wie ein "Kompetenz-Ranking". Wir versuchen nur ganz allgemein zu zeigen, welchen Ruf eine Website hat, bzw. inwieweit wir glauben, dass eine Seite oder Website hohe Qualität bietet. All diese Aspekte.

Im Grunde genommen möchte man eine Website mit gutem Ruf haben. Aber genauso möchte man eine Website oder eine Seite anbieten, die der Anfrage der Nutzer entspricht. Idealerweisehat man beides. Die Website hat einen sehr guten Ruf und liefert den Nutzern genau die Ergebnisse, nach denen sie gesucht haben.

Wir verwenden also viele unterschiedliche Begriffe wie Vertrauenswürdigkeit, Ruf oder Autorität. PageRank ist dafür ein spezielles Beispiel. Aber wir verstehen das eher im allgemeineren Sinn. Es handelt sich nicht um einen speziellen Algorithmus. Wir versuchen herauszufinden, inwieweit Nutzer eine Seite als hochwertig einstufen würden. Auch, wenn sie die Suchanfrage dazu gar nicht kennen. Wie nützlich ist diese Website für sie? Liefert die Website alle Antworten, die man sich von ihr erhofft hat? Ich hoffe, das hilft euch weiter.

Veröffentlicht von Daniela Loesser, Search Quality Team

Posted:
In seiner heutigen Video-Antwort beschäftigt sich Matt Cutts mit dem Thema Seiten-Geschwindtigkeit und ob die Verwendung von HTTPS in diesem Zusammenhang einen negativen Einfluss auf das Ranking einer Seite hat.



Heute gehen wir auf eine Frage von Gary Tamas aus Zürich ein. Sie bezieht sich darauf, dass HTTPS grundsätzlich langsamer ist als HTTP. Google legt aber großen Wert auf Geschwindigkeit. Wirkt sich ein Wechsel zu HTTPS entsprechend nachteilig auf eine Website aus?

Nein, keine Sorge. An sich ist es sogar empfehlenswert, eine Website auf HTTPS umzustellen. HTTPS bzw. SSL ist eine sichere HTTP-Version, die zwischen eurem Browser und dem Webserver übertragene Daten verschlüsselt. So verhindert ihr, dass euer Chef, euer ISP oder der Staat ausspionieren kann, was sich über eure Verbindung abspielt, sofern sie nicht auf "Mission: Impossible" machen und einen Man-in-the-middle-Angriff starten. Das kommt allerdings eher selten vor.

Aber zurück zur Frage. HTTPS ist grundsätzlich langsamer als HTTP. Das liegt zum Teil an den zusätzlichen Verschlüsselungsprozessen, die HTTPS erfordert. Allerdings verlangsamen viele beteiligte Prozesse die Sache unnötig. Also hat eine Reihe von Leuten aus dem Google Chrome-Team an neuen Protokollen gearbeitet. "Speedy" heißt eines von ihnen. Und "False Start" ein anderes, das es ermöglicht, ohne eine Verbindung herstellen, eine Bestätigung beziehen und dann eine Verbindung zum verschlüsselten Senden der Daten herstellen zu müssen, die Daten direkt verschlüsselt zu senden. Und so wird nun fleißig gearbeitet, weil bisher nicht daran gedacht wurde, die Prozesse für SSL oder HTTPS zu beschleunigen. In vielen Fällen ist es ein Kinderspiel, in anderen Fällen ist das eine arbeitsintensivere Aufgabe, aber die Arbeit lohnt sich vermutlich.

Ich würde mir bezüglich einer Penalty also keine Gedanken machen. Nur bei einer von 100 Suchanfragen, d. h. bei einer von 1000 Websites, ist die Geschwindigkeit so gering, dass sie sich auf ihr Ranking auswirkt, während HTTPS wirklich eine sinnvolle Sache für die Nutzer ist. Wenn ihr beispielsweise nach PayPal sucht, werdet ihr feststellen, dass PayPal HTTPS verwendet.

Wir haben uns unseren Indexing Code angesehen und versucht sicherzustellen, dass niemand, der eine HTTPS-Version für seine Website verwendet, benachteiligt wird. Wir werden auch weiterhin so verfahren, um dafür zu sorgen, dass auf unserer Seite alles reibungslos abläuft. Wenn ihr eine neue Website plant und sie von vornherein sicher gestalten wollt, ist es nicht verkehrt, sich für HTTPS zu entscheiden.

Und wir suchen nach neuen Wegen, HTTPS noch schneller zu machen und Best Practices weiterzugeben. Außerdem suchen wir nach Möglichkeiten wie z.B. mod_pagespeed, einem Plug-in von Apache, das kurz gesagt alles beschleunigt. Und dann gibt es noch den Page Speed-Dienst, den wir kürzlich eingeführt haben und der für eine Beschleunigung sorgt, wenn jemand auf eure Inhalte zugreifen möchte und eurer DNS so eingestellt ist, dass eine Steuerung durch Google erfolgt. Und Google kann alle Inline-Images neu schreiben und das JavaScript usw. für euch minimieren, wodurch ihr 25 bis 60 Prozent der Zeit für die Seitenverarbeitung einsparen könnt.

Wir werden also weiterhin versuchen, HTTPS schneller zu machen. Wir werden weiterhin versuchen, das Web schneller zu machen. Und wir hoffen, dass ihr dabei seid.

Veröffentlicht von Daniela Loesser, Search Quality Team

Posted:
Einer unserer zehn Grundsätze hier bei Google lautet: Schnell ist besser als langsam. Diesen Leitsatz berücksichtigen wir bei allem, was wir machen – und die +1-Schaltfläche ist keine Ausnahme. Seit dem Start der Schaltfläche haben wir ständig an der Verbesserung der Ladezeit gearbeitet. Wir freuen uns, zwei Updates ankündigen zu dürfen, mit denen die +1-Schaltfläche verbessert und die Ladezeit beschleunigt wird.

Als ersten Schritt haben wir einige Änderungen eingeführt, dank derer die Schaltfläche um bis zu drei Mal schneller auf eurer Website dargestellt wird. Ihr braucht dazu keinen Finger zu rühren. Lehnt euch einfach entspannt zurück und beobachtet das schnellere Laden der Schaltfläche.

Zusätzlich zu den Verbesserungen der Schaltfläche haben wir noch ein neues asynchrones Snippet für euch im Angebot. Damit wird +1 noch schneller. Mit dem asynchronen Snippet wird eure Website weiter geladen, während der Browser das +1-JavaScript herunterlädt. Durch das parallele Laden der beiden Elemente stellen wir sicher, dass die Ladezeit eurer Seite nicht negativ durch die HTTP-Anforderung zum Abrufen von JavaScript für die +1-Schaltfläche beeinflusst wird. Falls ihr die Schaltfläche bereits implementiert habt, ist es notwendig, den Code mit dem neuen asynchronen Snippet zu aktualisieren. Danach werdet ihr eine deutliche Verbesserung der allgemeinen Ladezeit feststellen.

Zur Erstellung eines neuen asynchronen Snippets verwendet das Tool zur +1-Konfiguration. Im Folgenden findet ihr ein Code-Beispiel, das ihr zur verbesserten Leistung auf eurer Seite nach dem letzten -Tag einfügen könnt.



Falls ihr die +1-Schaltfläche noch nicht in eure Website implementiert habt, könnt ihr jetzt mit voller Kraft loslegen. Das ist eure Gelegenheit! Nutzer können Freunden eure Website empfehlen und somit mehr relevante Zugriffe der Google-Suche einbringen. Falls Ihr die Schaltfläche bereits verwendet, findet ihr hoffentlich Gefallen an der erhöhten Geschwindigkeit. Unser Team arbeitet weiterhin unermüdlich an der Verbesserung der +1-Schaltfläche, denn unser Leitsatz „Schnell ist besser als langsam” gilt heute mehr denn je.

Habt ihr noch Fragen? Dann schaut doch einfach im Webmaster-Forum vorbei. Updates zur +1-Schaltfläche erhaltet ihr in der Google Publisher Buttons Announce Group. Tipps und Tricks für Fortgeschrittene findet ihr auf unserer Google Code-Website.

Post von David Byttow, Software Engineer (Veröffentlicht von Dominik Zins, Search Quality)