Google Webmaster Zentrale Blog

Bessere Seitentitel in Suchergebnissen

2012-01-26T12:51:00.002Z

Seitentitel sind ein wichtiger Teil der Suchergebnisse: Sie stellen die erste Zeile jedes Ergebnisses dar und sind die Links, auf die die Nutzer der Google-Suche klicken, um zur entsprechenden Website zu gelangen. Wir empfehlen daher Webmastern immer, eindeutige und aussagekräftige Seitentitel (und Meta-Beschreibungen für Snippets) zu verwenden, um den Nutzern der Google-Suche auf den ersten Blick zu vermitteln, wovon die Seite handelt.

Wir nutzen unterschiedliche Signale bei der Entscheidung, welche Titel wir Nutzern zeigen. Wir verwenden vor allem das <title>-Tag, sofern es vom Webmaster festgelegt wurde. Bei einigen Seiten trifft jedoch ein einziger Titel möglicherweise nicht auf alle Suchanfragen zu. Aus diesem Grund haben wir einen Algorithmus entwickelt, der alternative Titel generiert, sodass Nutzer einfacher relevante Seiten finden. Unsere Tests haben gezeigt, dass diese alternativen Titel häufig relevanter für die Suchanfragen sind und die Klickrate für das Ergebnis erheblich verbessern. Das hilft sowohl den Nutzern der Google-Suche als auch den Webmastern. In etwa der Hälfte der Fälle ist dies der Grund, weshalb wir alternative Titel einblenden.

Alternative Titel erscheinen aber auch, wenn Webmaster im HTML-Code einer Seite keinen Titel oder keinen aussagekräftigen Titel angegeben haben. Eine Seite mit dem einfachen Wort "Startseite" sagt beispielsweise nicht viel über den Inhalt der Seite aus. Ein anderer häufiger Grund ist, wenn ein Webmaster nur einen Titel für beinahe alle Seiten einer Website verwendet und ihn entweder exakt dupliziert oder nur minimal abwandelt. Unser letzter Grund sind sehr lange oder schwer verständliche Titel, die wir manchmal durch knappere und aussagekräftigere Alternativen ersetzen.

Weitere Informationen dazu, wie ihr bessere Titel und Meta-Beschreibungen verfassen könnt, und zu den Signalen, die wir zur Erstellung alternativer Titel verwenden, findet ihr in dem kürzlich aktualisierten Hilfeartikel zu diesem Thema. Wir versuchen auch, Webmaster zu informieren, wenn wir Titel finden, die mit der Funktion "HTML-Vorschläge" der Webmaster-Tools verbessert werden könnten. Diese Funktion findet ihr links im Menü im Abschnitt "Diagnose".

Fragen oder Feedback könnt ihr uns wie immer gerne über die Webmaster-Hilfe zukommen lassen.

Post von Pierre Far, Webmaster Trends Analyst (Veröffentlicht von Uli Lutz, Search Quality)

Verbesserung am Algorithmus für das Seitenlayout

2012-01-24T15:01:00.000Z

Da wir in den Suchergebnissen möglichst viele Websites von hoher Qualität liefern möchten, gab es vor kurzem eine Algorithmusänderung. Diese bezieht sich speziell auf das Layout einer Webseite und die Menge an Inhalt, die auf einer Seite sichtbar ist, sobald man auf ein Ergebnis klickt.

Wie bereits erwähnt (englisch) haben sich einige Nutzer bei uns beschwert, dass sie die gesuchten Inhalte nicht sofort finden konnten, nachdem sie auf ein Ergebnis geklickt haben. Die Nutzer möchten die Inhalte sofort sehen, ohne erst auf der Seite herunterscrollen zu müssen, vorbei an unzähligen Anzeigen. Daher sind Websites, die nicht viel Inhalt "above the fold" haben, also Inhalt, der ohne Scrollen sichtbar ist, möglicherweise von dieser Änderung betroffen. Wenn man auf eine Website klickt und der zuerst angezeigte Teil der Website nicht viel Inhalt aufweist, sondern überwiegend Werbung enthält, ist das keine gute Nutzererfahrung und die Website wird möglicherweise abgewertet.

Natürlich platzieren viele Websites Anzeigen "above the fold", denn diese Werbung ist wirksam und unterstützt die Publisher bei der Monetarisierung ihrer Online-Inhalte. Diese Algorithmusänderung wirkt sich nicht auf Websites aus, die Anzeigen im normalen Rahmen "above the fold" platzieren, sondern hauptsächlich auf Websites, deren Seitenanfang vollkommen mit Werbung überfrachtet ist und auf denen der Originalinhalt nur schwer zu finden ist. Die Algorithmusverbesserung betrifft Websites mit wenig oder keinen sichtbaren Inhalten, die ohne Scrollen sichtbar sind, oder Websites, deren Inhalte zu einem großen Teil von Anzeigen verdeckt werden.

Weniger als 1% aller Suchen weltweit sind von dieser Änderung spürbar betroffen. Das heißt, ein typischer Nutzer wird bei weniger als einer von 100 Suchen eine Neuordnung der Ergebnisse auf der Suchseite feststellen. Wenn ihr vermutet, dass eure Website von der Algorithmusänderung für das Seitenlayout betroffen ist, überprüft bitte, wie der Platz "above the fold" auf euren Seiten genutzt wird und ob der Seiteninhalt verdeckt oder für die Nutzer nur schwer erreichbar ist. Mithilfe des Tools Browsergröße, das euch neben vielen anderen Tools zur Verfügung steht, könnt ihr sehen, wie eure Website mit unterschiedlichen Bildschirmauflösungen dargestellt wird.

Solltet ihr euer Seitenlayout aktualisieren, greift der Algorithmus für das Seitenlayout die Änderungen automatisch auf, sobald wir genügend Seiten eurer Website erneut gecrawlt und verarbeitet haben. Wie lange das dauert, hängt von mehreren Faktoren ab, unter anderem von der Anzahl der Seiten auf eurer Website und davon, wie effizient eure Inhalte vom Googlebot gecrawlt werden können. Bei einer normalen Website kann das mehrere Wochen dauern.

Unsere Empfehlung an Website-Inhaber lautet nach wie vor, eine möglichst gute Nutzererfahrung (englisch) auf den Websites anzustreben, anstatt auf spezielle Algorithmusoptimierungen zu setzen. Diese Änderung ist nur eine von über 500 Verbesserungen, die wir für dieses Jahr planen. Wie immer sind Fragen und Feedback in unserem Webmaster-Hilfeforum herzlich willkommen.

Post von Matt Cutts, Distinguished Engineer (Veröffentlicht von Uli Lutz, Search Quality)

Daten zu Suchanfragen mit Python herunterladen

2012-01-20T16:18:00.000Z

An alle Entwickler, die sich für einen skript-basierten Zugriff auf Daten zu Suchanfragen ihrer Websites in den Webmaster-Tools interessieren – wir haben gute Neuigkeiten für euch! Ihr erhaltet ab sofort über ein offenes Python-Skript aus dem Projekt webmaster-tools-downloads Zugriff auf eure Daten zu Suchanfragen im CSV-Format. Über die Webmaster-Tools-API sind Daten zu Suchanfragen momentan nicht verfügbar. Diese Funktion wurde allerdings häufig von API-Nutzern angefragt, weshalb wir sie für das nächste API-Update in Betracht ziehen. Für diejenigen von euch, die sofort auf ihre Daten zu Suchanfragen zugreifen wollen, zeigen wir, wie ihr mit dem Python-Skript eure Daten zu Suchanfragen herunterladen und in eine Google-Tabelle in Google Docs hochladen könnt.

Beispiel für die Verwendung des Python-Skripts zum Herunterladen der Daten zu Suchanfragen
1) Falls es auf eurem Computer noch nicht vorhanden ist, ladet Python herunter und installiert es.
2) Ladet danach die Google Data APIs-Python-Client-Bibliothek herunter und installiert sie.
3) Erstellt einen Ordner und fügt dort das Skript downloader.py ein.
4) Kopiert das Skript example-create-spreadsheet.py und fügt es in den Ordner ein, in dem auch "downloader.py" abgelegt ist. Bearbeitet "example-create-spreadsheet.py" und ersetzt die Beispielwerte für "website", "email" und "password" mit gültigen Werten für eure in den Webmaster-Tools bestätigte Website.
5) Öffnet ein Terminal-Fenster und gebt in der Befehlszeile "python example-create-spreadsheet.py" ein, um das Skript "example-create-spreadsheet.py" auszuführen:

python example-create-spreadsheet.py
6) In Google Docs erscheint eine neue Tabelle mit euren Daten zu Suchanfragen.

Wenn ihr eure Daten zu Suchanfragen in einer CSV-Datei herunterladen möchtet, ohne die Daten in eine Google-Tabelle hochzuladen, verwendet im obigen Beispiel example-simple-download.py statt "example-create-spreadsheet.py".

Ihr könnt diese Skripts ganz einfach konfigurieren, sodass sie täglich oder monatlich ausgeführt werden. So könnt ihr eure Daten zu Suchanfragen über einen längeren Zeitraum archivieren und abrufen, als das bei den Webmaster-Tools momentan mit einem Monat der Fall ist. Erstellt dazu beispielsweise einen Cronjob oder verwendet den Windows-Taskplaner.

Beachtet bei diesem Beispiel, dass Nutzername und Passwort im Skript selbst enthalten sind. Wenn ihr dieses Skript in einer Produktionsumgebung ausführen möchtet, solltet ihr Best Practices für die Sicherheit einsetzen und beispielsweise verschlüsselte Anmeldedaten von Nutzern verwenden, die aus einer sicheren Datenspeicherquelle abgerufen wurden. Das Skript verwendet für die Kommunikation mit dem API HTTPS, um diese Anmeldedaten zu schützen.

Seht euch das Skript zum Herunterladen von Daten zu Suchanfragen an und setzt diese in euren eigenen Skripts oder Tools ein. Wenn ihr Fragen habt oder uns Feedback geben möchtet, könnt ihr das gerne im Webmaster-Hilfeforum tun.

Von Jonathan Simon, Webmaster Trends Analyst (Veröffentlicht von Uli Lutz, Search Quality)

Was tun bei Malware?

2012-01-18T14:55:00.002Z

Wir haben heute ein interessantes Thema für euch: Matt Cutts spricht über Malware, und was man tun kann, wenn die eigene Website betroffen ist.

Vielleicht seid ihr verärgert oder frustriert, wenn ihr dieses Video seht. Das tut mir leid. Heute geht es um Malware und gehackte Websites. Ihr glaubt gar nicht, wie oft so etwas vorkommt! Sogar die Website von Donald Trump wurde gehackt. Ebenso die Website von Al Gore. Das kann passieren. Aber bitte zeigt euren Nutzern keine Malware. Es gibt kostenlose Tools und Ressourcen von Google sowie Hilfsmittel im Web, die euch beim Aufräumen helfen.

Zunächst zur Diagnoseseite "Safe Browsing". Wenn ihr nach "Safe Browsing Diagnoseseite" sucht, findet ihr die notwendigen Infos, um auf die Seite zuzugreifen. Dann könnt ihr herausfinden, ob diese URL oder Website mit Malware infiziert ist.

Hier ein Beispiel: google.com/safebrowsing/diagnostic?site=mattcutts.com. Ersetzt einfach [mattcutts.com] durch eine andere Website, um zu sehen, ob diese von Malware betroffen ist. Auch Statistikdaten zu Malware auf der Domain werden angezeigt.

Wie das Ganze funktioniert, ist ziemlich interessant. Bei einer Suche nach "Ghost in the Browser" (so heißt das auf Englisch), findet ihr jede Menge Infos dazu. Und die bringen wirklich genaue Ergebnisse. In den letzten 5 Jahren habe ich keinen einzigen Fehler gesehen. Mit einer Ausnahme: Da haben wir alles im Web für etwa eine Stunde als Malware markiert. Aber das war eine andere Panne.

Für die Diagnoseseite "Safe Browsing" werden die Daten des Malware-Teams herangezogen. Man muss aber klar zwischen Malware- und Webspam-Team unterscheiden, obwohl wir uns sehr respektieren. Das Malware-Team konzentriert sich hauptsächlich auf mögliche Malware und Virenscanner, um Webseiten zu finden, die eventuell mit Malware infiziert sind.

Also, auf dieser Seite gebt ihr euren Domain-Namen ein, im Format "example.com". Ihr bekommt alle Statistiken dazu. Seht euch die Informationen genau an. Manchmal ist die Domain tatsächlich infiziert. Oder es stellt sich heraus, dass es nicht eure Domain, sondern die Domain eines Drittanbieters erwischt hat. Wenn ihr Anzeigen oder Skripts verwendet, JavaScript oder irgendwelche Inhalte von anderen Domains für eure Website übernommen habt, könnt Ihr einiges an Informationen dazu finden. Entweder entfernt ihr dann die Inhalte des Drittanbieters oder ladet sie einfach nicht mehr. Somit wird auf eurer Website keine Malware mehr angezeigt. Kurz danach verschwindet die Warnung. Die Diagnoseseite "Safe Browsing" ist wirklich nützlich.

Den zweiten Punkt, den ich erwähnen möchte, ist die Möglichkeit einer Malware-Überprüfung. Registriert eure Website bei den Google Webmaster-Tools, unter google.de/webmasters. Identifiziert euch einfach als Inhaber der Website und klickt auf die Seite "Diagnose". Dort gibt es den Tab "Malware". Nachdem ihr aufgeräumt habt, beantragt ihr eine Überprüfung. Die Überprüfung wird nicht in Echtzeit durchgeführt, sondern dauert in der Regel ein paar Stunden, also nicht allzu lange. Wer gestresst ist, weil die Website gehackt wurde und Malware verteilt wird, will nicht unbedingt tagelang auf eine Lösung warten. Es kann also ein paar Stunden dauern, aber prinzipiell geht es relativ schnell. Das Ergebnis der Überprüfung zeigt die URLs auf eurer Website, die vermutlich mit Malware infiziert sind. Damit erfahrt ihr genau,wo ihr Hilfe zur Diagnose bekommt, wie ihr die Fehler suchen und beheben könnt.

Wenn aus irgendeinem Grund trotzdem noch Malware vorhanden zu sein scheint, geben wir euch weitere Beispiele von URLs, die wahrscheinlich noch infiziert sind. So könnt ihr relativ schnell aufräumen und Malware entfernen.

Es gibt noch ein drittes empfehlenswertes Tool. Es ist eher auf gehackte Seiten als auf Malware ausgerichtet und heißt "Abruf wie durch Googlebot". "Abruf wie durch Googlebot" ist eine weitere Funktion der Google Webmaster-Tools unter google.de/webmasters. Ihr nehmt eine bestimmte Seite, für die ihr zuständig seid oder deren Inhaber ihr seid, und klickt auf "Abruf wie durch Googlebot". Der Googlebot ruft den Inhalt dieser Seite ab. Ihr seht genau, was dem Googlebot zurück gegeben wurde, zum Beispiel eine 301-Weiterleitung. Ihr seht den Inhalt und könnt ihn auf Hackerangriffe und Malware prüfen. Das kann sehr hilfreich sein. Der Googlebot sieht auf einigen Seiten den gehackten Inhalt, den man als normaler Nutzer nicht sehen kann. Das ist ein gemeiner Trick.

Es gibt einige Stellen, an denen ihr suchen könnt. Oft verstecken sich die Details zum Beispiel in .htaccess-Dateien. Möglicherweise findet ihr dort das gesuchte Element. SQL-Injektionen sind auch ein heißer Tipp. Falls ihr zum Beispiel eure URL-Parameter oder die URL-Eingabe nicht richtig unter Kontrolle habt, können Tabellen, oder Malware usw.eingeschleust werden. Darauf solltet ihr definitiv achten. Verliert nicht die Geduld, wenn ihr das Problem nicht auf Anhieb findet.

Schaut nicht nur auf eure Quelldateien. Der Quellcode kann scheinbar vollkommen in Ordnung sein. Wichtig ist, was im Browser angezeigt wird. Der Abruf wie durch Googlebot zeigt, was die Nutzer sehen. Häufig findet ihr in eurem Quellcode keinen Hinweis auf die Infizierung. Egal, ob es sich um Mod Rewrite, .htaccess oder ähnliches handelt –man sieht die Malware erst, wenn man als Endnutzer zugreift. Darauf solltet ihr achten.
Ihr solltet euer System immer aktualisieren. Wenn ihr Wordpress verwendet, installiert alle Patches. Egal mit welchem CMS ihr arbeitet, nutzt immer die neueste Version. Bei einem Fehler kann eure Website wieder gehackt werden. Und das bringt uns zum nächsten Punkt: Spätestens sobald eure Website bereinigt ist, solltet ihr euer Passwort ändern. Wählt ein richtig schweres, kompliziertes Passwort. Verwendet auf keinen Fall 1, 2, 3, 4, 5, 6. Vermeidet "Liebe". Vermeidet "Gott" .Vermeidet "Passwort". Vermeidet "Lass mich rein". Nehmt am besten eine schwer zu erratende Kombination. Damit erschwert ihr den Hackern den Zugriff auf eure Website.

Werft auch einen Blick auf kostenlose Websites wie unmaskparasites.com. Diese Website ist ziemlich hilfreich, um herauszufinden, welche Arten von Angriffen derzeit verbreitet sind. Der Betreiber gibt ausführliche Infos zu Malware und zeigt, wie sie konkret aussehen kann. Patches und Updates sind das oberste Gebot. Verwendet starke Passwörter.

Wenn ihr diese Warnungen erhaltet, stellt fest, ob es sich um eure Website oder die eines Drittanbieters handelt. Verwendet die Diagnoseseiten "Safe Browsing" und die Malware-Überprüfung. Sobald ihr die Seiten gefunden habt, bereinigt sie. Seid gründlich. Reicht die Website ein und wartet, bis Google grünes Licht gibt. Mit "Abruf wie durch Googlebot" erfahrt ihr, ob eure Website gehackt wurde. Achtet auf SQL-Injektion. Achtet auf .htaccess-Dateien. Dies sind die häufigsten Zugriffsformen.
Es ist frustrierend und ärgerlich. Es fällt schwer, sich einzugestehen, dass die eigene Website gehackt wurde oder Malware enthält. Viele wollen es auch nicht wahrhaben. Der Quellcode ist doch in Ordnung. Aber meistens verstecken sich die Details an seltsamen Stellen wie in JavaScript, oder in verschleiertem JavaScript, das ziemlich undurchsichtig ist. Es geht um Dinge, die relativ normal aussehen. Sie enthalten Domains, die wie Google Analytics aussehen, von denen ihr normalerweise JavaScript herunterladen würdet. Aber ein einzelnes Zeichen weicht ab. Damit kann wirklich Schaden angerichtet werden. Das wieder in Ordnung zu bringen, kann euch echt den Tag vermiesen.

Google nimmt das sehr ernst. Wenn ein Webmaster unbeabsichtigt Malware an seine Nutzer verteilt, ist das unangenehm. Die Nutzer beschweren sich dann bei Google. Wir haben uns also ein paar Dinge überlegt, mit denen Nutzer besser geschützt werden. Wir hoffen, dass euch diese Tools helfen, Ordnung zu schaffen und eure Website wieder vollkommen zu bereinigen. Und wir hoffen, dass danach alles glatt läuft. Viel Erfolg!

Veröffentlicht von Uli Lutz, Search Quality Team

Der neue Smartphone-Googlebot-Mobile

2011-12-22T10:20:00.000Z

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)

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.

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

Tipps für Hostanbieter und Webmaster

2011-12-20T05:40:00.000Z

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:

Wir bieten detaillierte Hilfe zur Kontrolle des Googlebot-Crawling mithilfe des Robots-Exclusion-Protokolls und durch die Konfiguration von URL-Parametern.
Wenn ihr Bedenken habt, dass ein Rogue Bot den Googlebot-User-Agent verwendet, bieten wir eine Möglichkeit, um zu verifizieren, ob ein Crawler tatsächlich ein Googlebot ist.
Wenn ihr die Frequenz des Googlebot-Crawlings auf eurer Website ändern möchtet, könnt ihr eure Website in den Webmaster-Tools verifizieren und die Crawling-Frequenz des Googlebot ändern. Hostanbieter können außerdem die Inhaberschaft ihrer IP-Adressen verifizieren.

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:

Safe Browsing-Alerts für Netzwerkadministratoren, die für Hostanbieter nützlich sind
Malware-Benachrichtigungen in den Webmaster-Tools für individuelle Websites
Eine Safe Browsing-API für Entwickler

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)

Kann ich auch ohne SEO gut ranken?

2011-12-16T13:09:00.000Z

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

Erhöht AdWords das Ranking meiner Website?

2011-12-15T13:17:00.002Z

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

Neues Markup für mehrsprachige Inhalte

2011-12-13T11:00:00.002Z

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.

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)

Ist Vertrauenswürdigkeit ein Ranking-Signal?

2011-12-08T16:02:00.000Z

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

Wirkt sich HTTPS negativ auf mein Ranking aus?

2011-12-05T11:55:00.000Z

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

+1-Schaltfläche – noch schneller

2011-12-01T14:00:00.004Z

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)

Die Evolution der Suche in sechs Minuten

2011-11-30T11:25:00.002Z

Heute teilen wir einen Blogpost mit euch, den unsere Kollegen von "Inside Search" veröffentlicht haben. Er gibt einen schönen Überblick darüber, wie sich die Suche entwickelt hat und wohin ihr Weg geht.

Diesen Sommer haben wir ein Video gepostet (englisch), dass einen Blick hinter die Kulissen unserer Suche wirft. Es erklärt die Methode hinter dem Suchranking und der Evaluation. Mit dieser Methode nehmen wir rund 500 Verbesserungen im Jahr vor. Wie schon häufig zuvor besprochen, ist das eine ganze Menge an Änderungen und es ist manchmal schwer, alle zu verstehen.

Unser letztes Video aufgreifend, zeigen wir euch heute die Evolution der Suche in einer Kurzgeschichte. Wir heben ein paar Meilensteine der letzten Dekade hervor und geben einen Vorgeschmack auf die Zukunft. (Englisch, Zusammenfassung siehe unten)

Unser Ziel ist es, euch immer schneller und schneller Antworten zu liefern, um eine nahtlose Verbindung zwischen euren Fragen und den Informationen, die ihr sucht, herzustellen. Das bedeutet, dass ihr nicht über jedes unserer neuen Features informiert sein müsst, um in den Genuss zu kommen, es zu benutzen. Schreibt einfach wie immer in das Suchfeld und ihr erhaltet die Antworten, nach denen ihr sucht.

Das Video zeigt allerdings ein paar wichtige Trends für all jene unter euch, die genauer wissen wollen, wie sich die Suche entwickelt hat:

Universelle Ergebnisse: Mit der universellen Suche - welche Ergebnisse wie Bilder, Videos und News zusätzlich zu Webseiten wiedergibt - helfen wir euch unterschiedlichste Informationen an einer Stelle gebündelt zu erhalten. Wir haben damit weitergemacht, die Suche umfangreicher zu gestalten und es euch zu ermöglichen auch Produkte, Plätze, Patente, Bücher, Karten und mehr zu finden.

Schnelle Antworten: Heutzutage werdet ihr mehr auf Google finden, als nur eine Liste von Links zu Webseiten. Ihr findet schnelle Antworten zu einer großen Auswahl an Themen wie Flugzeiten, Sportergebnissen, Wetter und vielen mehr oben auf der Seite. Im Zuge der Verbesserung unserer Technologie fangen wir an, euch auch schwerere Fragen zu beantworten - direkt auf der Seite mit den Suchergebnissen.

Die Zukunft der Suche: Wir haben uns zudem darauf fokussiert schnellere Wege des Suchens zu entwickeln, die euch Zeit sparen. So haben wir einige Sekunden bei Suchen mit Google Instant eingespart oder helfen euch mit Google Voice Search auf eurem Smartphone zu suchen. Suchen sollte so einfach sein, wie zu denken, und die Zukunft sieht vielversprechend aus!

Für das Video haben wir auch noch eine Zeitleiste mit Features der Suche erstellt. Es ist nicht die erste Zeitleiste, die wir gemacht haben, aber wir denken, dass diese die verschiedenen universellen Ergebnisse und schnellen Antworten gut kategorisiert, die wir über die Jahre eingeführt haben:

Die Zeitleiste zeigt ungefähr die Zeitpunkte, an denen wir spezielle Verbesserungen der Such-Feature vorgenommen haben. Ihr könnt ein größeres Bild herunterladen, wenn ihr auf diesen Link klickt.

Es war spannend während der letzten Dekade ein Teil der Evolution der Suche zu sein und wir sind begeistert darüber, was als nächstes veröffentlicht wird. Wenn die Vergangenheit ein guter Indikator ist, wissen wir nicht wie die Suche 2020 aussehen wird, aber wir wären nicht überrascht, wenn sie ganz anders als heute aussieht.

Gepostet von Ben Gomes, Google Fellow (Übersetzung von Dominik Zins, Search Quality)

Ist SEO Spam?

2011-11-23T16:28:00.000Z

Heute räumt Matt Cutts mit dem Vorurteil auf, dass Google SEO durchweg als negativ ansieht, und zeigt eine Vielzahl wichtiger Betätigungsfelder für die Suchmaschinenoptimierung auf.

Hallo. Heute werde ich über Suchmaschinenoptimierung (SEO) und Spam berichten und die Frage beantworten, ob Google SEO als Spam betrachtet. Die Antwort lautet: Nein. Wir betrachten SEO nicht als Spam. Da einige sehr technisch orientierte Nutzer dieser Ansicht vielleicht widersprechen, will ich sie etwas ausführlicher erläutern.

SEO steht für Search Engine Optimization. Das bezeichnet nichts anderes als den Versuch, eure Seiten so gut wie möglich in Suchmaschinen darzustellen. So gibt es zahllose sinnvolle, qualitativ gute White-Hat-Verfahren für Suchmaschinenoptimierer. Ihr könnt zum Beispiel sicherstellen, dass eure Seiten gecrawlt werden können und zugänglich sind. So wie Nutzer eure Seite finden sollen, indem sie auf Links klicken, finden auch Suchmaschinen Seiten, indem sie auf Links klicken.

Suchbegriffe müssen auf die Anfragen der Nutzer abgestimmt sein. Wenn ihr Fachjargon oder Begrifflichkeiten verwendet, die nicht jeder kennt, hilft euch ein guter SEO, festzustellen, welche Suchbegriffe möglicherweise überarbeitet werden müssten. Im Rahmen der Nutzerfreundlichkeit liegt auch gutes Design der Website in eurem Interesse. Das hilft sowohl Nutzern als auch Suchmaschinen. Außerdem könnt ihr an der Geschwindigkeit eurer Website arbeiten. Einerseits ist die Geschwindigkeit einer von vielen Faktoren, die das Ranking einer Website bei Google beeinflussen. Andererseits fördert eine schnellere Website auch die Benutzerfreundlichkeit.

Es gibt also ein großes Betätigungsfeld für SEOs: Von der Unterstützung bei der Konzeption der Website-Architektur und grundlegenden Designüberlegungen über URL-Struktur, Vorlagen und weitere Vorkehrungen, die ermöglichen, dass die Website gecrawlt werden kann, bis hin zur ROI-Optimierung. Dazu kommen Kosten-Nutzen-Analysen, A/B-Tests und Überlegungen, mit welchem Text die beste Conversion erzielt werden kann, um nur einige Beispiele zu nennen. Diese White-Hat-Methoden sind allesamt vollkommen vertretbar.

Gibt es auch SEOs, deren Vorgehensweisen wir nicht zustimmen? Sicher. Gibt es nicht auch SEOs, die Black-Hat-Methoden anwenden, Websites hacken, überflüssige Keywords verwenden, mit Textwiederholungen täuschen oder Umleitungen missbrauchen? Auf jeden Fall. Unser Ziel besteht jedoch darin, die bestmöglichen Suchergebnisse zu liefern. SEOs können dazu entschieden beitragen, indem sie kooperieren und Suchmaschinen dabeiunterstützen, Seiten besser zu finden.

SEO ist nicht gleich Spam. SEO kann äußerst nützlich sein. SEO kann aber auch missbrauchtund übertrieben werden. Wir sind der Meinung, dass Nutzer sich in einer idealen Welt über derartige Probleme keine Sorgen machen müssten. Doch bisher sind Suchmaschinen nicht so klug wie Menschen. Wir arbeiten daran. Wir versuchen herauszufinden, was Nutzer ausdrücken wollen. Wir erforschen Synonyme, Vokabular und Wortstammfunktion, sodass Nutzer nicht ein bestimmtes Wort kennen müssen, um zu finden, was sie suchen. Bis wir das gelöst haben, bietet SEO einen vertretbaren Ansatz, Nutzer mittels Suchmaschinen zu dem zu führen, was sie suchen.

Unser Beitrag dazu sind die Richtlinien für Webmaster unter google.de/webmasters. Dort gibt es ein kostenloses Forum für Webmaster und die ebenfalls kostenlosen Webmaster-Tools. Außerdem gibt es reichlich HTML-Dokumentation. Speziell für den Einstieg in den Bereich SEO haben wir eine Einführung in die Suchmaschinenoptimierung verfasst.

Um es noch einmal zu betonen: Es gibt unzählige saubere Möglichkeiten, das Web mit SEO nutzerfreundlicher zu machen. Es ist schlicht falsch, wenn ihr hört, SEOs seien allesamt kriminell und schlüpfrige Geschäftemacher. Wenn ihr jemanden findet, dem ihr vertrauen könnt, jemand, der euch genau sagt, was und wie er es tut, jemand mit guten Referenzen oder jemand, dessen Arbeit ihr persönlich kennt und schätzt, jemand, der klar sagt, was er tut, kann das echte Vorteile für eure Website bringen.

Hoffentlich konnte ich eine einseitig negative Wahrnehmung von SEO korrigieren. Manch einer ist der Meinung, Google betrachtet SEO grundsätzlich als Spam. Das trifft absolut nicht zu. Es gibt eine Menge hervorragender SEOs. Und solch einen SEO wünsche ich euch für eure Website.

Veröffentlicht von Daniela Loesser, Search Quality Team

Wieso ist meine Website im Ranking gefallen?

2011-11-21T13:21:00.002Z

Was tun, wenn die Website plötzlich im Ranking bei Google abgerutscht ist? Matt Cutts gibt im heutigen Video Tipps, welche Fragen man sich stellen sollte, welche Google-Tools man nutzen kann, um den möglichen Ursachen für den Ranking-Verlust auf den Grund zu gehen.

Die heutige Frage kommt aus Dearborn, Michigan. Ryan möchte wissen: "Mit welcher Methode lässt sich feststellen, warum sich bei meiner Website die Rankings und Zugriffszahlen von Google drastisch verschlechtert haben?"

Eure Zugriffszahlen haben sich also plötzlich drastisch verschlechtert. Als Erstes würde ich eine Suche über site:meinedomain.com durchführen, um herauszufinden, ob die Website bei Google überhaupt nicht angezeigt wird oder Teile davon noch in den Suchergebnissen auftauchen. So könnt ihr auch feststellen, ob eure Website teilweise indexiert wurde. Wenn ihr kein Snippet seht, gibt es vielleicht eine robots.txt-Datei, die das Crawlen blockiert hat. In diesem Fall haben wir eine Referenz zu dieser Seite gefunden und haben das ausgegeben, was uns über einen Link zu dieser Seite angezeigt wurde. Aber wir konnten nicht die Seite selbst sehen oder sie abrufen.

In den Suchergebnissen wird euch außerdem angezeigt, ob eure Website unserer Ansicht nach gehackt wurde oder Malware enthält. Dann erscheint dort eine Warnung .Das führt natürlich zu geringeren Zugriffszahlen, da Nutzer keine gehackte Website oder eine Website mit Malware besuchen möchten.

Als Nächstes würde ich in der Webmaster-Konsole (google.com/webmasters) nachschauen. Meldet euch an und weist nach, dass ihr der Inhaber oder Administrator der Website seid. Mittlerweile erstellen wir viel mehr Meldungen, die über verborgenen Text, geparkte Domains oder Brückenseiten hinausgehen. Wir veröffentlichen mittlerweile die unterschiedlichsten Meldungen, wenn wir denken, dass ein Verstoß gegen unsere Qualitätsrichtlinien vorliegt.

Wenn das Problem nicht angezeigt wird oder ihr keine Meldung seht, besucht unser Webmaster-Forum. Ihr findet einen Link dort hin auf google.com/webmasters. Am Forum beteiligen sich viele Personen, auch viele erfahrene Nutzer, die euch mit Ideen und Vorschlägen weiterhelfen können.

Dabei könnt ihr euch fragen, ob dieses Problem nur eure Website oder auch andere Websites betrifft. Wenn nur eure Website davon betroffen ist, dann verstößt sie möglicherweise unserer Einschätzung nach gegen unsere Richtlinien. Das Problem kann aber auch beim Server oder der Website selbst bestehen, also auf eurer Seite liegen.

Es kann aber auch auf einen veränderten Algorithmus zurückzuführen sein. Wenn mehrere Websites anderer Leute betroffen sind, ist wahrscheinlich ein Algorithmus dafür verantwortlich. Ihr könnt auch bei anderen Suchmaschinen testen, ob eure Website dort aufgeführt wird. Wenn nicht, liegt das Problem wahrscheinlich bei euch.

Möglicherweise habt ihr mit einem Test-Server gearbeitet, der eine robots.txt-Datei oder ein noindex-Tag enthielt, damit der Test-Server unsichtbar blieb, und ihr habt bei der Veröffentlichung das noindex nicht entfernt.

Eine weitere Möglichkeit ist "Abruf wie durch Googlebot". Das findet ihr auch in unserer Webmaster-Konsole. Damit könnt ihr den Googlebot losschicken, um eine Seite abzurufen und sie euch anzuzeigen. Da erlebt man manchmal echte Überraschungen. Manchmal wurde eine Website gehackt oder es gab ein noindex-Tag oder ein rel=canonical-Attribut, das auf eine Hacker-Seite verwiesen hat. Solche Sachen könnt ihr mit "Abruf wie durch Googlebot" herausfinden.

Es gab auch schon Fälle, in denen Leute Cloaking einsetzen wollten, was falsch verwendet wurde und dann total schiefgelaufen ist. Während den Nutzern normale Inhalte angezeigt wurden, erhielt der Googlebot nur leeren Inhalt. Auch in solchen Fällen hilft "Abruf wie durch Googlebot".

Wenn ihr Änderungen an eurer Website, eurem Hosting oder eurem Design vorgenommen habt, kann das auch Probleme verursachen. Überprüft einfach, ob ihr größere Änderungen an eurer Website etwa zur gleichen Zeit vorgenommen habt, beispielsweise am DNS oder Host-Namen. Dadurch können auch Probleme entstehen. Wenn ihr sehr anspruchsvolles Ajax eingesetzt habt, können Suchmaschinen eure Website vielleicht nicht ganz so einfach crawlen und verarbeiten.

Spätestens dann habt ihr hoffentlich herausgefunden, ob nur eure Website oder Teile davon betroffen sind, ob das Problem bei mehreren Suchmaschinen besteht oder ob mehrere Websites davon betroffen sind und es sich deshalb um einen veränderten Algorithmus handelt. Sobald das klar ist und ihr wisst, wo das Problem liegt, könnt ihr einen Antrag auf erneute Überprüfung in Betracht ziehen. Wenn ihr denkt, dass ihr einen Verstoß begangen habt und beispielsweise Cloaking eingesetzt oder eine leere Seite an Google ausgegeben habt, oder verborgener Text oder überflüssige Keywords von euch verwendet wurden, dann könnt ihr einen Antrag auf erneute Überprüfung stellen.

So stellt ihr fest, ob Google manuell gegen eure Website vorgegangen ist. Es ist gut, wenn das nicht der Fall ist. Denn selbst wenn euer Ranking nicht euren Vorstellungen entspricht, wisst ihr wenigstens, dass ein Algorithmus dafür verantwortlich ist. Ihr könnt also einschätzen, welche Probleme ihr noch auf den Algorithmus zurückführen könnt.

Sollten wir manuell vorgegangen sein, informieren wir euch so schnell wie möglich, ob wir eure Website neu eingestuft haben und das Problem bald behoben ist oder ob wir immer noch der Meinung sind, dass ein Problem besteht. So erhaltet ihr mehr Transparenz. Erst seit der letzten Runde mit Webmaster-Videos, also seit etwa einem halben Jahr, geben wir genauere Informationen, nicht nur in unseren Meldungen, sondern auch in unseren Antworten auf Anträge auf erneute Überprüfung. Auch das trägt zur Transparenz bei.

Auf diese Probleme solltet ihr also achten. Hoffentlich wisst ihr jetzt, welche Analyse-Tools ihr verwenden könnt. Und ich hoffe, dass ihr alle Probleme - egal bei welcher Website - beheben könnt. Denn wenn ihr tolle Inhalte bietet, möchten wir diese Inhalte, soweit möglich und soweit angemessen, in unseren Index aufnehmen, damit auch andere Nutzer sie finden können.

Veröffentlicht von Daniela Loesser, Search Quality Team

Was sollte man beim Umzug auf eine neue Domain beachten?

2011-11-18T11:14:00.000Z

Nachdem Matt Cutts in unserem letzten Video-Post Tipps für den Umzug auf einen neuen Webhost gegeben hat, erklärt er heute, was man alles beachten sollte, wenn man die Domain der Website wechseln will.

Hallo! Heute haben wir wieder eine Videoanleitung für euch. Es geht um ein Thema, das viele interessiert: Wie wechsle ich die Domain meiner Website und erhalte dabei möglichst gut die Rankings? Vielleicht wollt ihr gerade von einer alten zu einer neuen Domain wechseln. Wir besprechen, was ihr dabei bedenken solltet und wie ihr Probleme vermeiden könnt.

Fangen wir an. Wir haben hier eine Website, vielleicht mit einem Unterverzeichnis oder einer Subdomain. Genau genommen haben wir zwei oder drei Websites. Außerdem haben wir eine neue Domain. Im Moment ist es nur eine geparkte Domain. Dazu gebe ich euch gleich zu Beginn einen Rat: Wenn ihr vorhabt, zu einer neuen Domain zu wechseln, parkt die Domain nicht einfach, sondern stellt einige Inhalte unter der Domain bereit. Sei es auch nur eine kleine, abgespeckte Mini-Ausgabe eurer Website. Es reicht sogar schon, wenn ihr nur die Startseite eurer Website bereitstellt. Dadurch macht ihr deutlich, dass es sich nicht um eine von Millionen geparkter Domains handelt.

Also beginnt schon einmal mit der neuen Website. Sie muss nicht toll aussehen. Ihr braucht auch nicht viel CSS, JavaScript und Ähnliches zu verwenden. Es genügen einige Textabsätze, in denen ihr die geplante Website kurz vorstellt oder deren Inhalte beschreibt, nach dem Motto "Hier entsteht die neue Webpräsenz der Firma XY" oder Ähnliches. Der Grund ist: Unsere Algorithmen versuchen, geparkte Seiten zu erkennen und herauszufiltern. Wenn eine geparkte Domain plötzlich normal genutzt wird, versuchen wir zwar, den Wechsel schnellstmöglich zu erkennen. Aber wenn ihr uns für das Crawlen, Sichten und Verarbeiten der Seite etwas mehr Zeit gebt, können wir die Seite wahrscheinlich besser verarbeiten.

Okay. Wir ziehen also um: von einer alten Website - oder genauer gesagt von zwei oder drei alten Websites - zu einer konsolidierten neuen Website. Sicher wollt ihr dabei nicht gleich ins kalte Wasser springen, sondern zunächst einige Tests durchführen. Ihr könntet unter anderem prüfen, ob die neuen Inhalte vorhanden sind oder ob die Inhalte korrekt zur neuen Website verschoben wurden. Ihr könnt mit einem Unterverzeichnis oder mit einer Subdomain anfangen. Für diesen Teil der Website erstellt ihr eine 301-Weiterleitung zur neuen URL. Ich nehme an, dass der Wechsel für immer sein soll. In diesem Fall ist eine dauerhafte, sogenannte 301-Umleitung sinnvoll. Wenn der Wechse lnur vorübergehend sein soll, verwendet ihr eine 302-Umleitung beim Senden der HTTP-Statuscodes.

Okay. Ihr könnt also zunächst versuchen, diesen Teil der Website zum neuen Teil der neuen Website umzuleiten, und testen, ob das Ranking weiterhin in Ordnung ist. Wenn die 301-Umleitung aus irgendeinem Grund in ein 'schwarzes Loch' führt und kein gutes Ranking erzielt, zieht noch nicht mit allen Inhalten um. Findet erst die Ursache heraus. Vielleicht hat der vorherige Besitzer über diese Domain Spam verbreitet und ihr wollt einen Antrag auf erneute Überprüfung stellen oder etwas Ähnliches. Jedenfalls wechselt nicht mit allen Inhalten zur neuen Domain, ohne zuvor bei einem Teil der Website zu testen, ob es funktioniert.

Was ist, wenn ihr mehrere Websites habt, zum Beispiel drei Websites, die ihr alle zu einer Marke oder zu einer Website zusammenfassen möchtet? Das kommt häufig vor und ist gar kein Problem. Ihr könnt auch hierfür 301-Umleitungen verwenden. Beginnt mit der Domain mit den geringsten Besucherzahlen. Wenn ihr zum Beispiel diese drei Websites zusammenführen möchtet, beginnt mit derjenigen mit den geringsten Besucherzahlen. Erstellt eine 301-Umleitung und prüft, ob alles gut läuft und der Wechsel problemlos funktioniert. Dadurch schützt ihr eure Domain mit den höchsten Besucherzahlen vor einem Risiko. Wenn alles gut geklappt hat, richtet ihr die 301-Umleitung für die nächstgrößere Website ein. Zuletzt holt ihr die größte Website mit ins Boot.

Okay. Was ihr außerdem bedenken solltet: Wenn ihr der Eigentümer oder Verantwortliche für alle diese Websites seid, könnt ihr die Bestätigungscodes hinzufügen und eure Website in der Webmaster-Zentrale registrieren. Dann könnt ihr die Statistiken für alle Websites abrufen.

Als weiteren Punkt prüft ihr, wer Verknüpfungen zu eurer alten Domain erstellt hat. Ihr braucht auf keinen Fall jeder einzelnen Person zu schreiben, die jemals auf eure Domain verwiesen hat, und darum bitten, den Link für die neue Domain zu aktualisieren. Aber für die wichtigsten Verknüpfungen zu eurer alten Website könnte sich das lohnen. Wenn zum Beispiel die New York Times, das ZDF, die Süddeutsche Zeitung, Wikipedia oder eine andere große Website auf eure Website verweist, widmet diesen Anbietern etwas Aufmerksamkeit. Schreibt dem Eigentümer oder bearbeitet die Wikipedia-Seite mit dem Hinweis, dass eure Seite zu einer neuen URL umgezogen ist.

Die Suchmaschinen sollten zwar allen 301-Umleitungen folgen, aber so könnt ihr es noch einfacher machen, indem ihr das Problem früher abfangt. So können selbst neue Suchmaschinen, die den alten Link nicht kennen, den Link berücksichtigen. Das wirkt sich positiv auf das Ranking aus.

Was gibt es noch zu sagen? Wenn ihr plant, zu einer neuen Domain zu wechseln und gleichzeitig eure Website-Vorlage zu ändern, sodass sich die Benutzeroberfläche der Website ändert und so weiter, könnte es sinnvoll sein, diese beiden Prozesse zu trennen. Denn durch die Umleitung ändert sich ja bereits die URL eurer Website. Wenn ihr die Website gleichzeitig völlig umgestaltet und dann der Wechsel aus irgendeinem Grund nicht gut läuft, wäre das ungünstig.

Vielleicht habt ihr einiges mit AJAX oder JavaScript programmiert und die Seite enthält nur wenig indexierbaren Text. In dem Fall könnt ihr am Ende kaum feststellen, ob der Wechsel zur neuen Domain oder die Neugestaltung der Website die Ursache des Problems ist. Ihr solltet also solche Prozesse möglichst entkoppeln, indem ihr zunächst nur einen Teil der Website oder die Website mit den geringsten Besucherzahlen verlagert und prüft, ob alles funktioniert wie geplant.

Das waren also einige Faustregeln. Wenn möglich, ist es auch hilfreich, die alte Website noch eine Weile online zu lassen. Ich habe einen Test durchgeführt ,bei dem ich von mattcutts.com zur Domain dullest.com umgezogen bin. Ich habe die alte Website weitere 6 Monate online gelassen, also genug Zeit für die 301-Umleitungen und die gesamte Umstellung, sodass alles korrekt verarbeitet wird. Das hat sehr gut funktioniert. Wenn ihr solche Änderungen langsam, vorsichtig und überlegt durchführt, sollte alles gut ablaufen.

Ich kenne zahllose Berichte über Websites, die zu neuen Domains gewechselt sind und bei denen alles glatt über die Bühne ging. Durch die genannten Schritte könnt ihr definitiv etwas dazu beitragen. Denn wenn dann etwas schief geht, könnt ihr feststellen, an was es lag: an der Neugestaltung der Website oder an der Umstellung auf die neue Domain. Behaltet einfach diese Faustregeln im Hinterkopf, wenn ihr zu einer neuen Domain wechselt. Viel Erfolg dabei!

Veröffentlicht von Daniela Loesser, Search Quality Team

Wie zieht man auf einen neuen Webhost um?

2011-11-16T11:51:00.000Z

Matt Cutts gibt heute ein paar Tipps, was man beim Wechsel von einem Webhost auf einen neuen beachten sollte.

Hallo zusammen, meine Name ist Matt Cutts. Heute möchte ich erklären, wie man mit seinem Content von einem Webhosts zu einem anderen umzieht. Möglicherweise seid ihr ja mit eurem aktuellen Anbieter nicht zufrieden und möchtet zu einem anderen Anbieter wechseln. Der Domain-Name bleibt dabei unverändert. Ganz gleich also, ob "mattcutts.com" oder "example.com": Der Domain-Name ist derselbe. Allerdings wird euch aufgrund des Wechsels zu einem neuen Host auch eine neue IP-Adresse zugewiesen. Wie genau läuft das ab?

Zunächst gibt es da eine wunderbare Erfindung namens DNS, auch Domain Name Server genannt. Dieser Server ordnet einen Namen, beispielsweise "example.com", einer IP-Adresse zu. Wird der DNS nun nach "example.com" abgefragt, verweist er auf diese spezielle IP-Adresse, von der eine entsprechende Antwort kommen sollte. So funktioniert das Ganze. Das Leben ist schön. Alle sind glücklich.

Aber was passiert nun, wenn ihr den Webhost wechselt? Dann ändert sich ja die IP-Adresse. Der Content kann derselbe sein. Eigentlich sollte er auch derselbe sein. Jetzt soll "example.com" aber auf den neuen Speicherort verweisen. Folgendes ist dabei zu beachten: Für den DNS ist die TTL relevant. TTL steht für "Time to live". Diese bestimmt im Wesentlichen, für wie lange die IP-Adresse für einen bestimmten Domain-Namen nach dem Abruf im Cache verbleibt. Normalerweise wird sie für einen Tag gespeichert. Nach dem Abruf der IP-Adresse von "example.com" bleibt also genau ein Tag Zeit, ehe die Adresse erneut abgerufen werden muss.

In einigen Fällen kann die festgelegte TTL aber deutlich verringert werden. Etwa auf einen Zeitraum von fünf Minuten. Kein Problem, wenn es euch nicht auf Anhieb gelingt, die TTL zu verringern. Es ist bloß eine nette kleine Verbesserung. Alle, die in den kommenden fünf Minuten vorbeischauen, können nach fünf Minuten schon sehen, wie schnell sich die Dinge ändern können.

Geht am besten folgendermaßen vor: Legt, wenn möglich, einen geringen Wert für die TTL fest beispielsweise fünf Minuten. Nun zum Content. Dem zaubern wir ein Lächeln ins Gesicht. Vielleicht eine Sommersprosse. Jetzt seht ihr zwei lächelnde Gesichter vor euch, denn ihr möchtet den Content vom alten Host auf den neuen Host hochladen. Dahinter steckt die Idee, dass die Nutzer immer euren Content finden – unabhängig von der jeweiligen IP-Adresse. Unter idealen Voraussetzungen könntet ihr eure Website an beiden Speicherorten belassen. Bei statischem Content wäre das kein Problem. Einfach eine Sicherung erstellen. Den Content spiegeln. Dynamischer Content stellt da schon eine größere Herausforderung dar. Die ganze Angelegenheit lässt sich aber relativ schnell über die Bühne bringen. Wickelt die Sache beispielsweise hier über ein Backend ab, und dasselbe Backend kann dann wieder als Ziel dienen.

Gehen wir aber von einem einfachen Fall aus. Angenommen, eure Website enthält nur statischen Content. Die TTL ist auf einen geringen Wert festgelegt. Und euer Content befindet sich bei zwei verschiedenen Hosts. Nun müsst ihr die DNS-Einstellung so ändern, dass auf die neue IP-Adresse verwiesen wird. Erkennbar an der gestrichelten und der durchgehenden Linie. Das bedeutet, dass Nutzern nun beim Aufruf von "example.com" die IP-Adresse für den Content beim neuen Host angegeben wird.

Gelegentlich kommt der Googlebot vorbei. Generell versuchen wir, die IP-Adresse für einen bestimmten Domain-Namen jeden Tag zu aktualisieren. Also ungefähr nach 500 bis 1000 Content-Abrufen. So funktionierte die Heuristik zumindest in der guten alten Zeit und mindestens einmal am Tag überprüfen wir, ob sich die IP-Adresse auch tatsächlich geändert hat. Die TTL ist auf eine geringen Wert festgelegt. Der Content befindet sich auf beiden Hosts. Die DNS-Einstellung ist geändert und verweist auf die die neue IP-Adresse. Nun möchtet ihr wissen, ob der Googlebot, und die Nutzer euren Content unter der neuen Adresse vorfinden. Ist die TTL auf einen eher geringen Wert festgelegt, fünf oder zehn Minuten, könnt ihr dabei zu sehen, wie die Nutzer zur neuen Website strömen. Habt ihr die TTL nicht festgelegt, lässt sich ungefähr nach einem Tag erkennen, dass die Nutzer zur neuen Adresse wechseln. Es kann zwar je nach Browser Abweichungen geben, aber normalerweise läuft das so ab.

Sobald ihr feststellt, dass der Googlebot auf euren Content unter der neuen Adresse zugreift, sollte alles gut gelaufen sein. Es schadet auch nichts, den Content eine Zeit lang an beiden Speicherorten vorzuhalten. Allerdings werden sich dann die Zugriffszahlen verändern. Beim alten Host werden die Zugriffe durch Bot und Nutzer zurückgehen und beim neuen Host deutlich ansteigen. Sobald das passiert und sich nur noch wenige Nutzer zum alten Host verirren, könnt ihr den Content unter dieser IP-Adresse löschen.

Wenn ihr also nicht mit eurem derzeitigen Host zufrieden seid, könnt ihr zu einem anderen Host wechseln. Es ist gar nicht so kompliziert oder riskant. Das Ändern der DNS-Einstellung zum Verweisen auf eine neue IP-Adresse ist eine gute Übung. So erhaltet ihr ein paar nützliche Einblicke. Es ist sogar sinnvoll, denn die Einstellung wird immer wieder überprüft. Und jedes Mal, wenn sich die Einstellung geändert hat, ziehen Bot und Nutzer zum neuen Host. Ich hoffe, die Informationen haben euch weitergeholfen. Viel Glück bei der Migration auf neue IP-Adressen!

Veröffentlicht von Daniela Loesser, Search Quality Team

Sind Rechtschreibung und Grammatik wichtig für das Ranking?

2011-11-14T16:11:00.001Z

In seiner heutigen Video-Antwort erklärt Matt Cutts, ob Rechtschreibung und Grammatik einen Einfluss auf die Bewertung und das Ranking von Websites in den Google-Suchergebnissen haben.

Die heutige Frage kommt von Blind Five Year Old aus San Francisco, Kalifornien, und ist wirklich faszinierend. "Spielen für die Bewertung des Inhalts und der Qualität einer Seite Rechtschreibung und Grammatik eine Rolle?"

Eine sehr gute Frage. Es ist schon eine Weile her, seitdem ich das überprüft habe, aber zumindest zu jenem Zeitpunkt hatten sie keinen Einfluss auf das Ranking. Rechtschreibung und Grammatik gehören also nicht zu den über 200 Kriterien, die wir zur Bewertung der Qualität einer Seite heranziehen. Aber ich denke, es ist eine Überlegung wert, sie in die Kriterien aufzunehmen.

Beispielsweise haben wir vor einiger Zeit bemerkt, dass der PageRank einer Seite, also der von uns vorgeschlagene Beliebtheitswert für eine Seite oder Website, stark mit einer guten Rechtschreibung zusammenhängt. Die Rechtschreibung auf Websites mit hohem PageRank ist also in den meisten Fällen besser als auf Websites mit niedrigem PageRank. Was ziemlich bemerkenswert ist, wenn man mal darüber nachdenkt.

Wir haben das weiter untersucht, und jemand, besser gesagt eine Gruppe, hat Lesestufen entworfen. Damit seht ihr, ob eine Seite die Lesestufe 3. Klasse oder die Lesestufe 12. Klasse hat. Eine solche Inhaltsanalyse wäre als mögliches Qualitätskriterium überaus interessant.

Ich kann euch versichern, dass es immer Probleme mit der Berechnung geben wird, egal bei welchem Kriterium. Nehmt beispielsweise Rechtschreibung und Grammatik. Die heutige Frage setzt bereits voraus, dass es sich um Rechtschreibung und Grammatik einer bestimmten Sprache handelt. Um Rechtschreibung und Grammatik zu bewerten, muss man also herausfinden, in welcher Sprache die Seite verfasst wurde. Und selbst mit dem weltbesten Tool zur Sprachbestimmung werden bei Milliarden von Dokumenten möglicherweise doch ein paar Seiten übersehen. Und dann denkt man, dass die Rechtschreibung und die Grammatik dieser Seite extrem schlecht sind, doch es stellt sich heraus, dass sie eigentlich nur in Ungarisch und nicht in Englisch verfasst wurde. Oder vielleicht sind auch nur ein oder zwei Absätze in Ungarisch statt in Englisch verfasst worden.

Es ist also nicht so, dass Rechtschreibung und Grammatik automatisch perfekte Kriterien sind. Deswegen führen wir soviele Bewertungen durch. Wir machen viele Tests, um festzustellen, ob es sich um einen Qualitätsgewinn handelt und ob unser Eindruck bestätigt wird. Aus unserer Erfahrung können wir festhalten: Je höher der PageRank einer Seite, desto besser sind Rechtschreibung und Grammatik.

Wenn ihr auch auf diese Aspekte Zeit verwenden könnt, erstellt ihr nicht nur gute Inhalte, die Bestand haben werden, sondern punktet auch bei euren Besuchern. Nutzer können einschätzen, ob eine Seite auf die Schnelle oder sehr gewissenhaft erstellt wurde. Ob jemand die Seite korrigiert und die Qualität überprüft hat oder die Ersteller Experten auf diesem Gebiet sind.

Ich versuche, auf Rechtschreibung und Grammatik zu achten, auch beim Twittern. Manchmal macht man Fehler, aber man sollte in dieser Beziehung einfach aufmerksamer sein. Vielleicht nicht unbedingt im Hinblick auf das Ranking, aber einfach, weil es die Nutzererfahrung verbessert und bei Nutzern gut ankommt. Sie werden eure Website eher als Lesezeichen speichern oder nochmal besuchen oder ihren Freunden davon erzählen. Ich hoffe, das hilft euch weiter.

Veröffentlicht von Daniela Loesser, Search Quality Team

Was ist Cloaking?

2011-11-11T11:27:00.000Z

Im heutigen Video klärt Matt Cutts einige Fragen zum Thema Cloaking und geht dabei u.a. auf Geotargeting und Mobilgeräte ein.

Hallo zusammen! Ich bin's, Matt Cutts. Heute möchte ich euch etwas über das Thema Cloaking erzählen. Viele haben dazu Fragen: Was genau ist Cloaking? Wie definiert Google Cloaking? Warum ist Cloaking riskant? Und so weiter. Es gibt zwar ausführliche HTML-Dokumentation und wir haben viele Blogposts darüber veröffentlicht, aber ich möchte das Thema noch einmal kurz und prägnant in einem Video behandeln. Dabei beantworte ich einige der Fragen und nenne euch ein paar Faustregeln, damit ihr mit eurer Website immer auf der sicheren Seite seid.

Zunächst also zur Frage: Was ist Cloaking? Cloaking bedeutet im Grunde, dass den Nutzern anderer Content gezeigt wird als dem Googlebot. Wenn ihr zum Beispiel einen Webserver habt und ein Nutzer will eine Seite aufrufen, dann wird dem Nutzer die Seite angezeigt. Soweit alles wunderbar. Nun kommt der Googlebot und fordert ebenfalls eine Seite an. Ihr stellt dem Googlebot eine Seite zur Verfügung. In den allermeisten Fällen erhält der Googlebot denselben Content wie die Nutzer. Soweit passt alles. Falls jedoch dem Googlebot anderer Content angezeigt wird als den Nutzern, liegt Cloaking vor. Das wäre auf jeden Fall riskant für eure Webseite, denn es verstößt gegen unsere Qualitätsrichtlinien. Wenn ihr einmal in Google nach "Qualitätsrichtlinien" sucht, findet Ihr eine ganze Liste der Kriterien. Es gibt viele Hilfedokumente, in denen ihr genau nachlesen könnt, ob ein Risiko für eure Webseite besteht.

Ich will kurz auf das Wichtigste eingehen. Warum halten wir bei Google Cloaking für etwas Schlechtes, das vermieden werden soll? Die Antwort geht weit zurück, in die Anfangsphase der Suchmaschinen. Damals haben viele Betreiber von Webseiten Cloaking als Mittel zur Täuschung und Irreführung eingesetzt. Das lief dann zum Beispiel so ab: Gegenüber dem Googlebot gab der Webserver, der Cloaking nutzte, eine Webseite über Zeichentrickfilme zurück, vielleicht Walt Disney-Filme oder Ähnliches. Wenn dagegen ein Nutzer die Seite besuchte, gab der Webserver Pornos oder Ähnliches zurück. Wenn man also in Google nach Disney-Filmen suchte, wurde man zu einer Seite geführt, die scheinbar Zeichentrickfilme beinhaltet - wenn man auf den Link klickte, erschienen aber Pornos. Das kann eine sehr unangenehme Erfahrung sein. Viele Nutzer haben sich darüber beschwert. Es ist alles andere als benutzerfreundlich.

Daher haben wir beschlossen, dass alle Arten von Cloaking gegen unsere Qualitätsrichtlinien verstoßen. Es gibt also kein "gutes" Cloaking .Wenn jemand Cloaking in besonders irreführender oder täuschender Weise verwendet, setzen wir uns am meisten ein. Dann wird das Webspam-Team aktiv. Aber jede Form von Cloaking verletzt unsere Richtlinien.

Okay. Kommen wir als Nächstes zu einigen Faustregeln, mit denen ihr immer auf der sicheren Seite bleibt. Man kann sich Cloaking so vorstellen: Eine Seite wird abgerufen, zum Beispiel mit Wget oder cURL. Von der abgerufenen Seite wird ein Hash-Wert erzeugt. Dabei wird der gesamte Content der Seite in einem einzigen Zahlenwert ausgedrückt. Nun kommt der Googlebot ins Spiel, und zwar in Form eines Googlebot-User-Agents. In den Webmaster-Tools gibt es sogar eine Funktion namens "Abruf wie durch Googlebot". Damit ruft ihr eine Webseite wie mit dem Googlebot ab und erzeugt davon ebenfalls einen Hash-Wert. Falls die beiden Hash-Werte unterschiedlich sind, könnte es ein Problem geben. Dann besteht vielleicht ein Risiko für eure Webseite. Natürlich werden manche Seiten dynamisch erzeugt. Das betrifft zum Beispiel die Zeitstempel oder wechselnde Werbeanzeigen. Daher gilt die Regel nicht immer wie in Stein gemeißelt.

Als weitere einfache Methode könnt ihr überprüfen, ob der Code eures Webservers Elemente enthält, mit denen gezielt nach einem User-Agent von Googlebot oder nach der IP-Adresse des Googlebots gesucht wird. Denn wenn ihr einen besonderen oder sehr ungewöhnlichen Vorgang bezüglich des Googlebots ausführt -egal ob für dessen User-Agent oder dessen IP-Adresse - könnte das bedeuten, dass ihr potenziell dem Googlebot und den Nutzer nunterschiedlichen Content präsentiert. Und genau das soll ja vermieden werden. Diese Punkte solltet ihr also im Hinterkopf behalten.

Viele Webmaster, die keine schlechten Absichten verfolgen, mit Cloaking also nichts zu tun haben wollen und kein Risiko eingehen möchten, stellen uns die Frage: Was ist mit Geotargeting und mobilen User Agents, also mit Handys z.B.? Da habe ich gute Nachrichten für euch: Darüber müsst ihr euch keine Sorgen machen. Lasst mich kurz erklären, warum bei Geotargeting und bei der Seitenverarbeitung für Mobiltelefone kein Cloaking vorliegt.

Okay. Bisher waren wir von einem einzigen Nutzer ausgegangen. Nehmen wir nun einmal an, der Nutzer kommt aus Frankreich. Außerdem gibt es einen zweiten Nutzer, sagen wir aus Großbritannien. Im Idealfall ist euer Content unter den Domains ".fr" und ".uk" in verschiedenen Sprachen verfügbar, da ihr die Webseiten übersetzen lassen habt. Es ist wirklich hilfreich für einen Nutzer mit einer französischen IP-Adresse, den Content auf Französisch angezeigt zu bekommen. Das ist viel benutzerfreundlicher.

Beim Geotargeting wird bei jeder Anfrage an den Webserver überprüft, aus welchem Land die zugehörige IP-Adresse stammt, zum Beispiel aus Frankreich. Dem Nutzer wird dann die französische Version gesendet oder er wird zur ".fr"-Version der Domain weitergeleitet. Wenn die Browsersprache des Nutzers dagegen Englisch ist oder die IP-Adresse zum Beispiel aus den USA oder Kanada stammt, dann ist die englische Version wahrscheinlich am besten geeignet. Es sei denn natürlich, der Nutzer kommt aus dem französischen Teil Kanadas. Es wird also eine Entscheidung auf der Grundlage der IP-Adresse getroffen.

Solange ihr euch nicht ein bestimmtes Land ausdenkt, zu dem der Googlebot gehört - etwa Googlandia oder Ähnliches - führt ihr keine besondere oder ungewöhnliche Aktion für den Googlebot aus. Zurzeit, das heißt zum Zeitpunkt dieses Videodrehs, führt der Googlebot das Crawling von den USA aus durch. Der Googlebot würde also von eurer Webseite genau wie ein Besucher aus den USA gehandhabt. Der Content würde auf Englisch dargestellt. Gewöhnlich empfehlen wir, den Googlebot genau wie einen normalen Desktop-Browser zu behandeln - also wie Internet Explorer oder einen anderen für eure Website häufig verwendeten Desktop-Browser.

Geotargeting - also das Ermitteln der IP-Adresse und eine entsprechend angepasste Reaktion - ist völlig in Ordnung, solange ihr nicht speziell auf die IP-Adresse des Googlebots reagiert, also auf diesen sehr engen IP-Bereich. Es geht stattdessen nur darum, abhängig von der IP-Adresse eine möglichst hohe Benutzerfreundlichkeit zu erzielen.

Ähnlich ist es, wenn jemand eure Webseiteüber ein Mobiltelefon abruft, zum Beispiel mit einem iPhone oder Android-Gerät. Dann stellt eure Webseite fest, dass es sich um einen ganz anderen User Agent handelt. Er besitzt ganz andere Funktionen. Es ist völlig in Ordnung, auf diesen User Agent zu reagieren und ihm eine kompaktere Version eurer Website zu liefern, die für den kleinen Bildschirm besser geeignet ist. Auch hier gilt: Das Entscheidende ist, ob ihr den Googlebot wie einen Desktop-Nutzer behandelt, das heißt es erfolgt keine besondere oder ungewöhnliche Reaktion speziell auf diesen User Agent. Dann ist alles okay mit eurer Website. Es wird also entsprechend den Funktionen des Mobiltelefons eine angepasste Seite zurückgegeben, aber ihr versucht nicht, den Googlebot oder den Nutzer zu täuschen oder irrezuführen. Ihr behandelt den Googlebot nicht irgendwie anders aufgrund dessen User Agents. Dann ist alles in Ordnung.

Eine letzte Sache möchte ich noch erwähnen - quasi für die "Power User" unter euch: Einige Webmaster treffen die Entscheidung nicht anhand der genauen User Agent-Zeichenfolge oder anhand des genauen IP-Adressbereichs des Googlebots, sondern zum Beispiel, indem sie die Cookies überprüfen. Wenn ein Nutzer nicht auf Cookies reagiert oder mit JavaScript anders umgeht, behandeln sie dies als Sonderfall. Die Nagelprobe lautet auch hier: Verwendet ihr das als Ausflucht, um den Googlebot anders zu behandeln, also ihn auszusondern und dann eine ganz andere Aktion auszulösen?

In all diesen Fällen ist die grundlegende Frage also: Behandelt ihr die Nutzer genauso wie den Googlebot? Unser Ziel ist es, eure Webseite im Wesentlichen so zu erfassen und wiederzugeben, wie sie die Nutzer sehen. Wir möchten, dass die Endnutzer dasselbe Ergebnis erhalten, egal ob sie auf ein Google-Ergebnis klicken oder die eigentliche Webseite aufrufen. Daher gilt: Der Googlebot darf nicht anders behandelt werden. Cloaking bedeutet eine schlechte Erfahrung für Nutzer und verstößt gegen unsere Qualitätsrichtlinien. Diese Sache ist uns wichtig. Es gibt kein "gutes" Cloaking. Wir möchten wirklich sichergehen, dass die Nutzer eine Webseite so sehen, wie sie der Googlebot gesehen hat.

Okay. Ich hoffe, das war hilfreich für euch. Ich hoffe, es ist etwas klarer geworden, was Cloaking ist, und ich konnte euch einige Faustregeln vermitteln. Im Grunde solltet ihr aus diesem Video einfach die Frage mitnehmen: Enthält meine Webseite besonderen Code, der spezifisch nach dem User Agent"Googlebot" oder nach der IP-Adresse des Googlebots sucht und diesen irgendwie anders behandelt? Wenn ihr den Googlebot genau wie alle anderen Nutzer behandelt, also eine Version der Webseite sendet, die an den Standort oder mobile User Agents angepasst ist, ist das in Ordnung. Nur wenn ihr speziell nach dem Googlebot Ausschau haltet und dann etwas anderes ausführt als sonst, geht ihr für eure Webseite ein Risiko ein.

Weitere Dokumentationen dazufindet ihr auf unserer Website. Wahrscheinlich enthalten auch die Metadaten dieses Videos entsprechende Links. Ich hoffe, es ist etwas klarer geworden, was wir über Cloaking denken, warum wir es ernst nehmen und wie wir bei unserer Entscheidung darüber, wann Cloaking vorliegt, die Auswirkungen in ihrer Gesamtheit berücksichtigen. Das Entscheidende ist für uns letztlich die Benutzerfreundlichkeit. Wenn euer Code also irgendetwas enthält, das den Googlebot deutlich anders behandelt als die Nutzer, dann wird das wahrscheinlich Probleme aufwerfen. Ich hoffe, das hilft euch weiter.

Veröffentlicht von Daniela Loesser, Search Quality Team

GET- vs. POST-Methode und die Erfassung von mehr Inhalten im Web

2011-11-10T18:20:00.000Z

Google muss seine Crawling- und Indexierungsmethoden an die ständige Weiterentwicklung des Webs anpassen. Wir haben die Indexierung von Flash verbessert, eine robustere Infrastruktur namens Caffeine aufgebaut und in bestimmten Fällen sogar damit angefangen, Formulare zu crawlen. Da sich JavaScript und AJAX im Web immer größerer Beliebtheit erfreuen, stoßen wir zunehmend auf Webseiten, für die POST-Anforderungen eingesetzt werden müssen. Das gilt entweder für den gesamten Seiteninhalt oder ist erforderlich, weil auf den Seiten Informationen fehlen bzw. diese Seiten ohne die über eine POST-Anforderung ausgegebenen Ressourcen unbrauchbar dargestellt werden. Bei der Google-Suche entstehen dadurch natürlich Nachteile. Wenn wir Schwierigkeiten haben, Inhalte zu finden und zu indexieren, können wir Nutzern nicht die umfassendsten und relevantesten Ergebnisse präsentieren.

Grundsätzlich empfehlen wir die GET-Methode, um die für eine Seite erforderlichen Ressourcen abzurufen. Sie ist unsere bevorzugte Crawling-Methode. Wir haben Versuche unternommen, POST-Anforderungen in GET-Anforderungen umzuschreiben. Das funktioniert in manchen Fällen, häufig sind die vom Webserver ausgegebenen Inhalte für GET und POST allerdings vollkommen unterschiedlich. Es gibt natürlich gute Gründe, die POST-Methode zu verwenden. Beispielsweise könnt ihr zu einer POST-Anforderung mehr Daten hinzufügen als zu einer GET-Anforderung. GET-Anforderungen werden zwar häufiger verwendet. Um mehr Inhalte im Web zu erfassen, kann der Googlebot jedoch nun POST-Anforderungen verarbeiten, wenn wir davon überzeugt sind, dass dieser Vorgang sicher abläuft und angebracht ist.

Wir vermeiden bei einer Website sämtliche Schritte, die zu einer ungewollten Aktion seitens der Nutzer führen könnten. Unsere POST-Anforderungen setzen wir vor allem dazu ein, Ressourcen zu crawlen, die eine Seite automatisch anfordert. Im Prinzip wird dabei die Anzeige nachgeahmt, die auch Nutzer in ihrem Browser sehen. Mit einer besseren Heuristik wird sich dieser Prozess im Laufe der Zeit weiterentwickeln, aber das ist unsere aktuelle Vorgehensweise.

Wir möchten euch an einigen Szenarien für POST-Anforderungen zeigen, wie wir unsere Crawling- und Indexierungsmethoden an die Weiterentwicklung des Web anpassen.

Beispiele für POST-Anforderungen vom Googlebot

Crawlen einer Seite über eine POST-Weiterleitung

Crawlen einer Ressource über eine POST-XMLHttpRequest-Anforderung

<html>
<head>
<title>Leckerer Eisbecher</title>
<script src="jquery.js"></script>
</head>
<body>
Auf dieser Seite geht es um einen leckeren Eisbecher.
<div id="content"></div>
<script type="text/javascript">
$(document).ready(function() {
$.post('karamellsosse-info.html', function(data)
{$('#content').html(data);});
});
</script>
</body>
</html>

So kann eure Website besser gecrawlt und indexiert werden

unserer Hilfe

Verwendet die GET-Methode für den Abruf von Ressourcen, es sei denn, ihr müsst aus einem bestimmten Grund zur POST-Methode greifen.

Bestätigt, dass wir die Ressourcen crawlen dürfen, die zur Darstellung eurer Seite erforderlich sind. Wenn im oben stehenden Beispiel karamellsosse-info.html durch eine robots.txt-Datei blockiert wird, wird sie vom Googlebot nicht abgerufen. Genauer gesagt: Wenn der JavaScript-Code, der die XMLHttpRequest-Anforderung sendet, in einer externen JS-Datei hinterlegt ist und diese Datei von einer robots.txt-Datei blockiert wird, können wir nicht erkennen, dass zwischen leckerer-eisbecher.html und karamellsosse-info.html ein Zusammenhang besteht. In diesem Fall haben wir also Schwierigkeiten, selbst wenn karamellsosse-info.html nicht direkt blockiert ist. Im Web sind uns sogar schon viel kompliziertere Verkettungen von Abhängigkeiten untergekommen. Google kann eure Website besser erfassen, wenn ihr dem Googlebot erlaubt, alle Ressourcen zu crawlen.

Webmaster-Tools Labs

Vorschau

Stellt sicher, dass an den Googlebot der gleiche Inhalt ausgegeben wird, den Nutzer auch in ihrem Webbrowser sehen. Beim Cloaking werden unterschiedliche Inhalte an den Googlebot und an die Nutzer gesendet. Diese Methode verstößt gegen unsere Richtlinien für Webmaster, da sie unter anderem dazu führen kann, dass wir nicht relevante Ergebnisse an Nutzer der Google-Suche ausgeben. In diesem Fall werden Nutzern in ihrem Browser vollkommen andere Inhalte angezeigt als die, die wir gecrawlt und indexiert haben. Wir haben bei zahlreichen POST-Anforderungen festgestellt, dass Webmaster unabsichtlich Cloaking eingesetzt haben. Doch auch dann handelt es sich um einen Verstoß. Das Cloaking führte selbst bei minimalen Abweichungen zu JavaScript-Fehlern, die eine präzise Indexierung unmöglich machten, und das Cloaking somit seinen Zweck vollkommen verfehlte. Zusammengefasst heißt das also, dass ihr einen großen Bogen um Cloaking machen solltet, wenn ihr eure Website für die Google-Suche optimieren möchtet.

Mit der Vorschau

Mozilla/5.0 (compatible; Googlebot/2.1;
+http://www.google.com/bot.html)

Denkt daran, wichtige Inhalte, also Inhalte, die indexiert werden sollen, als Text einzufügen, der direkt auf der Seite zu sehen ist und angezeigt wird, ohne dass Schritte seitens der Nutzer erforderlich sind. Die meisten Suchmaschinen basieren auf Texten und funktionieren deshalb am besten mit textbasierten Inhalten. Wir arbeiten ständig daran, unsere Crawling- und Indexierungsmethoden auf verschiedenste Art und Weise zu verbessern. Trotzdem bleibt es eine verlässliche Strategie, wichtige Informationen als Text einzufügen.

So kontrolliert ihr eure Inhalte

robots.txt-Datei

Vorschau-FAQ

Es geht voran

Hilfe-Forum zur Verfügung.

Autor: Pawel Aleksander Fedorynski, Software Engineer, Indexing Team, und Maile Ohye, Developer Programs Tech Lead (Veröffentlicht von Dominik Zins, Search Quality)

Zugriff auf Daten aus Suchanfragen für eure Websites

2011-11-07T14:00:00.000Z

SSL-Verschlüsselung findet im Web immer häufiger Verwendung. Im Rahmen unserer Verpflichtung, das Web noch sicherer zu machen, haben wir angekündigt, dass die SSL-Suche auf https://www.google.com für Nutzer, die bei google.com angemeldet sind, zum Standard etabliert wird. Dieses neue Konzept wird in den nächsten Wochen umgesetzt.

Was bedeutet diese Änderung für Webmaster? Derzeit kann bei einer Webseite, auf die über organische Suchergebnisse von http://www.google.com (ohne SSL) zugegriffen wurde, festgestellt werden, dass der Nutzer über google.com auf die Webseite gestoßen ist und welche Suchanfrage gestellt wurde. Technisch gesehen gibt der Browser des Nutzers diese Information über das HTTP-Referrer-Feld weiter. Im Gegensatz dazu kann bei organischen Suchergebnissen aus der SSL-Suche nur festgestellt werden, dass der Nutzer über google.com auf die Webseite gestoßen ist.

Webmaster können über Webmaster-Tools immer noch auf eine Unmenge an Daten aus Suchanfragen für ihre Webseite zugreifen. Bei Webseiten, die in Webmaster-Tools hinzugefügt und bestätigt wurden, können Webmaster

Sich die Top 1000 Suchanfragen sowie die Top 1000 Zielseiten des Tages für die letzten 30 Tage anzeigen lassen,
Sich für jede Suchanfrage die Impressionen, Klicks, die Klickrate und die durchschnittliche Position in den Suchergebnissen der letzten 30 Tage ansehen und vergleichen,
Die Daten im CSV-Format herunterladen.

Außerdem haben Nutzer der Berichte zur Suchmaschinenoptimierung in Google Analytics auf die gleichen Daten aus Suchanfragen wie in Webmaster-Tools Zugriff und können von den ausführlichen Funktionen zur Berichterstellung profitieren.

Wir arbeiten weiter daran, wie wir die Bereitstellung von Daten aus Suchanfragen in Webmaster-Tools verbessern können. Solltet ihr Feedback oder Fragen haben, teilt uns dies bitte über das Webmaster-Hilfeforum mit.

Gepostet von Anthony Chavez, Product Manager (Veröffentlicht von Dominik Zins, Search Quality)

Domainübergreifende Auswahl von URLs steuern

2011-11-04T14:15:00.004Z

Auf Inhalte kann oft über verschiedene URLs zugegriffen werden, die sich nicht immer in der gleichen Domain befinden müssen. Ein von uns in den letzten Jahren oft zitiertes Beispiel dafür ist die Bereitstellung von identischen Inhalten unter mehr als einer URL, man spricht auch von dupliziertem Content. Wenn wir bei Google eine Gruppe von Seiten mit doppelten Inhalten entdecken, wählen wir mittels Algorithmen eine repräsentative URL für diese Inhalte aus. Eine Gruppe von Seiten kann URLs von der gleichen oder von verschiedenen Websites enthalten. Wenn die repräsentative URL aus einer Gruppe mit verschiedenen Websites ausgewählt wird, bezeichnet man das als domainübergreifende Auswahl von URLs. Ein einfaches Beispiel: Angenommen, die Gruppe enthält eine URL von a.com und eine URL von b.com. Wenn unsere Algorithmen die URL von b.com auswählen, wird die URL von a.com eventuell nicht mehr in unseren Suchergebnissen angezeigt und verzeichnet daraufhin möglicherweise geringe Zugriffszahlen über die Suche.

Als Webmaster habt ihr großen Einfluss darauf, welche URL von unseren Algorithmen ausgewählt wird. Euch stehen aktuell unterstützte Methoden zur Kennzeichnung der bevorzugten URL wie das Element rel="canonical" oder 301-Weiterleitungen zur Verfügung. Die Auswahl durch unsere Algorithmen stimmt in den meisten Fällen mit der der Webmaster überein. Trotzdem kam es auch schon vor, dass Webmaster nicht wussten, warum die jeweilige Auswahl getroffen wurde, und wissen wollten, was sie in einer solchen Situation tun können.

Weil wir bei der domainübergreifenden Auswahl von URLs Transparenz schaffen möchten, führen wir zurzeit neue Webmaster-Tools-Nachrichten ein, mit denen ihr als Webmaster darüber informiert werdet, wenn unsere Algorithmen eine externe URL statt eine URL von eurer Website auswählen. Nähere Informationen über diese Nachrichten findet ihr im Artikel zu diesem Thema in unserer Hilfe. In diesem Blog-Beitrag stellen wir euch verschiedene Szenarien vor, in denen es zu einer domainübergreifenden Auswahl von URLs kommen kann, und sagen euch, was ihr tun könnt, um eine möglicherweise falsche Auswahl zu korrigieren.

Häufige Ursachen für eine domainübergreifende Auswahl von URLs
Eine domainübergreifende Auswahl von URLs durch unsere Algorithmen kann auf viele Ursachen zurückgeführt werden.

Meistens wird eine URL von unseren Algorithmen aufgrund von Signalen ausgewählt, die Webmaster zur Kennzeichnung der gewünschten URL gesetzt haben. Wenn ihr als Webmaster beispielsweise unsere Richtlinien und Best Practices beim Umzug eurer Website befolgt, signalisiert ihr damit, dass die URLs auf eurer neuen Website ausgewählt werden sollen. Wenn beim Umzug eurer Website diese Nachrichten angezeigt werden, wurde eure Kennzeichnung von unseren Algorithmen verarbeitet.

Es gibt allerdings immer wieder Beschwerden von Webmastern, wenn unsere Algorithmen die falsche URL auswählen. Wenn bei eurer Website eine domainübergreifende Auswahl getroffen wird, die eurer Ansicht nach falsch ist, weil sie nicht euren Vorstellungen entspricht, gibt es je nach Ausgangslage verschiedene Methoden, um dieses Problem zu beheben. Nachfolgend sind einige der häufigsten uns bekannten Gründe für eine falsche domainübergreifende Auswahl von URLs sowie dazugehörige Lösungen aufgeführt:

1. Doppelte Inhalte einschließlich internationaler Websites: Oft verwenden Webmaster mehr oder weniger die gleichen Inhalte in einer Sprache auf mehreren Domains. Manchmal geschieht das unabsichtlich, manchmal aber auch, um die Inhalte geografisch auszurichten. Häufig richten Webmaster für example.com und example.net die gleiche Website auf Englisch ein, oder eine deutschsprachige Website wird auf .de, .at und .ch gehostet.

Je nach Website und Zielgruppe könnt ihr eine der aktuell unterstützten Methoden zur Kanonisierung verwenden, um unseren Algorithmen zu signalisieren, welche URLs ausgewählt werden sollen. Zu diesem Thema findet ihr folgende Artikel:

Bevorzugung von Versionen, speziell das Element rel="canonical" und 301-Weiterleitungen
Internationale und mehrsprachige Websites und mehr über den Umgang mit internationalen Websites
Über das Element rel="alternate" hreflang="x"

2. Konfigurationsfehler: Bestimmte Konfigurationsfehler können zu einer falschen Auswahl durch unsere Algorithmen führen. Mögliche Konfigurationsfehler:

a. Falsche Kanonisierung: Falsche Methoden zur Bevorzugung von Versionen, mit denen auf URLs auf einer externen Website verwiesen wird, können dazu führen, dass die externe URL von unseren Algorithmen ausgewählt und in unseren Suchergebnissen angezeigt wird. Das haben wir beispielsweise bei falsch konfigurierten Content-Managment-Systemen oder bei von Webmastern installierten CMS-Plug-ins beobachtet.

Findet zur Lösung dieses Problems heraus, wie genau auf eurer Website die bevorzugte kanonische URL falsch gekennzeichnet wird. Das kann beispielsweise auf eine falsche Verwendung des Elements rel="canonical" oder eine 301-Weiterleitung zurückzuführen sein. Dieser Fehler muss dann behoben werden.

b. Falsch konfigurierte Server: Manchmal wird beim Hosting falsch konfiguriert und für URLs der Website b.com werden Inhalte der Website a.com zurückgegeben. Ähnlich verhält es sich, wenn zwei voneinander unabhängige Webserver identische Soft 404-Fehlerseiten zurückgeben, die von uns möglicherweise nicht als solche erkannt werden. In diesem Fall nehmen wir an, dass der gleiche Inhalt von zwei verschiedenen Websites zurückgegeben wird, weshalb von unseren Algorithmen die URL von a.com fälschlicherweise als die kanonische URL für b.com ausgewählt wird.

Findet heraus, in welchem Bereich der Server-Infrastruktur eurer Website eine falsche Konfiguration vorliegt. Vielleicht gibt euer Server den HTTP-Statuscode 200 (erfolgreich) für Fehlerseiten aus oder er ordnet Anfragen von verschiedenen auf ihm gehosteten Domains falsch zu. Sobald ihr die Ursache für das Problem gefunden habt, korrigiert zusammen mit euren Serveradministratoren die Konfiguration.

3. Schädliche Angriffe auf Websites: Bei einigen Angriffen auf Websites kann ein Code eingefügt werden, der eine unerwünschte Bevorzugung von Versionen verursacht. Dieser schädliche Code kann beispielsweise bewirken, dass die Website eine HTTP-301-Weiterleitung zurückgibt oder dass im HTML-Tag bzw. dem HTTP-Header ein domainübergreifendes rel="canonical"-Linkelement eingefügt wird, das auf eine URL mit schädlichen Inhalten verweist. In diesem Fall wird von unseren Algorithmen möglicherweise die schädliche URL bzw. die Spam-URL statt der URL auf der manipulierten Website ausgewählt.

Befolgt in solchen Fällen am besten unsere Anleitung zum Bereinigen eurer Website und sendet anschließend einen Antrag auf erneute Überprüfung. Cloaking-Angriffe könnt ihr mit der Funktion "Abruf wie durch Googlebot" der Webmaster-Tools aufdecken. Eure Seiteninhalte werden euch damit so ausgegeben, wie sie dem Googlebot angezeigt werden.

In Ausnahmefällen kann es vorkommen, dass von unseren Algorithmen eine URL von einer externen Website ausgewählt wird, die eure Inhalte ohne eure Erlaubnis hostet. Wenn ihr denkt, dass eine andere Website eure Inhalte kopiert und dabei gegen das Urheberrechtsgesetz verstößt, könnt ihr vom Host der Website verlangen, dass eure Inhalte entfernt werden. Außerdem könnt ihr beantragen, dass Google die rechtsverletzenden Seiten aus den Suchergebnissen entfernt. Füllt dazu einen Antrag gemäß dem US-amerikanischen Urheberrechtsgesetz (Digital Millennium Copyright Act) aus.

Wenn ihr Unterstützung bei der Suche nach der Ursache für die falsche Auswahl oder bei der Fehlerbehebung braucht, findet ihr weitere Informationen wie immer in unserer Hilfe im Artikel zu diesem Thema oder im Webmaster-Hilfeforum.

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

Website-Check beim Online Motor Deutschland

2011-11-02T10:50:00.000Z

Wir, Kaspar und Uli vom Search Quality Team, hatten vor kurzem die Möglichkeit, beim Online Motor Deutschland in Berlin eine Reihe von Website-Checks zu veranstalten, und wir hatten viel Spaß dabei!

Online Motor Deutschland ist eine Initiative von Google und zahlreichen Partnern, um kleinen und mittelständischen Unternehmen dabei zu helfen, das Internet erfolgreich für sich zu nutzen. Berlin war vorerst das letzte Event, aber es sind trotzdem noch viele hilfreiche Informationen auf der Event-Seite zu finden.

In den Site-Clinics hatten die Besitzer von Webseiten die Möglichkeit, ihre Webseiten einzureichen, und wir haben ihnen dann Tipps gegeben, wie sie die Sichtbarkeit ihrer Seite in den Suchergebnissen bei Google verbessern können. Wir haben über 30 Webseiten analysiert, und insgesamt haben rund 500 Webmaster und Webseitenbesitzer die 7 Workshops besucht, die wir gehalten haben.

Für diejenigen unter euch, die eine neue Webseite aufsetzen wollen oder ihre Webseite suchmaschinenfreundlicher gestalten wollen, sind hier die zehn wichtigsten Tipps, die wir auf der Veranstaltung geteilt haben:

Meldet euch unter google.com/webmasters/tools/ bei den Google Webmaster-Tools an. Die Google Webmaster-Tools bieten euch kostenlos detaillierte Berichte über die Präsenz eurer Seiten in der Google-Suche. Fügt zunächst eure Webseite hinzu und bestätigt sie dann. Anschließend könnt ihr sofort Informationen abrufen. Andere nützliche Ressourcen für Webmaster findet ihr in der Google Webmaster-Zentrale unter google.com/webmasters
Versetzt euch in die Lage eines Besuchers eurer Webseite. Achtet darauf, dass eure Seite die Begriffe enthält, nach denen tatsächlich gesucht wird. Die Begriffe sollten in natürlicher Sprache im Text vorkommen und nicht nur in Aufzählungspunkten oder isolierten Keyword-Listen genannt werden.
Verwendet geeignete, für die einzelnen Seiten relevante Titel, da diese in den Suchergebnissen direkt sichtbar sind. Ihre Überschriften (<h1>, <h2> usw.) sollten außerdem aussagekräftig und passend sein.
Erstellt geeignete Beschreibungs-Meta-Tags. Qualitativ hochwertige Beschreibungen können als Snippets, also als Seitenauszüge, in den Google-Suchergebnissen angezeigt werden und so maßgeblich zur Qualität und zum Umfang des Suchvolumens beitragen.
Damit Nutzer besser erkennen können, worum es auf euren Seiten geht, benennt URLs möglichst einfach und nutzerfreundlich: example.com/produkte/widget.html vs. notexample.com/asdasd/rewiruewr?asd=2131209840392.
Besonders wichtige oder aktuelle Seiten sollten von einer anderen Seite eurer Webseite verlinkt sein, die bereits in Google indexiert ist. Fügt zum Beispiel auf der Startseite eurer Webseite einen Link zur Seite "Neue Sonderangebote!" ein.
Erstellt die Hauptnavigation und Kerninhalte eurer Webseite als Text, optional könnt ihr JavaScript und Flash zur Verbesserung einsetzen.
Verwendet ALT-Attribute für Bilder. Da der Googlebot keine Bilder erkennt, ist eure Mithilfe zur korrekten Kategorisierung gefragt. ALT-Attribute sind wie Meta-Tags für Bilder: Sie stellen direkt im Tag zusätzliche Informationen bereit und werden angezeigt, wenn ein Nutzer das Bild nicht sehen kann. Anhand dieser Attribute erkennt der Googlebot auch den Inhalt des Bildes besser.
Um sich zu vergewissern, dass eure Webseite von Crawlern gelesen werden kann, ruft sie mit einem Mobiltelefon auf, oder, sofern ihr technisch sehr versiert seid, mit einem Textbrowser. Alternativ könnt ihr es auch mit dem Lynx-Webbrowser versuchen.
Behaltet das wichtigste Ziel im Auge: eine positive Nutzererfahrung. Natürlich ist es wünschenswert, Zugriffe über Google und andere Suchmaschinen zu erhalten, aber unterschätzt die Wirksamkeit von Lesezeichen, Empfehlungen und Weiterleitungen durch die Besucher eurer Webseite nicht. Testet und analysiert Veränderungen des Designs und der Nutzerfreundlichkeit mit Tools wie Google Analytics und dem Google Website-Optimierungstool.

Für weiterführende Informationen möchten wir euch noch unsere Einführung in die Suchmaschinenoptimierung und unsere Hilfe für Webmaster ans Herz legen. Und falls doch noch Fragen offen bleiben, im Webmaster-Forum gibt es viele sachkundige und hilfsbereite Webmaster, die ihr Wissen gerne mit anderen teilen!

Das Online Motor Deutschland Zelt in Berlin von außen...

… und von innen.

Kaspar und Uli analysierten Weibseiten von kleinen und mittelständischen Unternehmen.

Geposted von Uli Lutz und Kaspar Szymanski, Google Search Quality (Veröffentlicht von Dominik Zins, Search Quality)

Wie bestimmt Google die kanonische Quelle von Content im Web?

2011-10-31T15:26:00.000Z

In Matt Cutts' heutiger Video-Antwort dreht es sich um das Thema Duplicate Content, welches viele von euch immer wieder beschäftigt. Matt Cutts erklärt, welche Signale Google benutzt, um zwischen identischen Inhalten auf verschiedenen Websites zu unterscheiden und den Urheber festzustellen.

Die heutige Frage kommt aus Chicago, Illinois. Willy F. möchte wissen: "Wie bestimmt Google die kanonische (canonical) Quelle von Inhalten?"

Das ist eine gute Frage. Wir hatten immer unterschiedliche Antworten darauf, da wir ständig an neuen Algorithmen und Methoden arbeiten, um genau zu bestimmen, woher Inhalte ursprünglich stammen. Ich möchte euch die Signale vorstellen, die wir dazu verwenden. Ein Signal ist beispielsweise, wann und wo wir Content zum ersten Mal gesehen haben. Wenn Inhalte verfasst und veröffentlicht und von uns gecrawlt werden und zwei Jahre später an einer anderen Stelle wieder auftauchen, ist sehr wahrscheinlich unser erster Fundort die Quelle.

Es gibt viele Blogs und Content-Management-Systeme, die ping-fähig sind, wie WordPress oder Blogger. Sobald ihr einen Beitrag postet, aktualisiert oder veröffentlicht, könnt ihr einen Ping an Blog- und Echtzeit-Suchmaschinen oder an Google senden. Damit können wir den Zeitpunkt, zu dem der Beitrag gepostet wurde, eindeutiger bestimmen und ihn somit unter identischen Inhalten identifizieren.

Dann gibt es natürlich noch PageRank. Bei identischem Content wird man der etablierten Website mit dem guten Ruf die Urheberschaft zuschreiben, und nicht etwa einer kurzlebigen Website, die man noch nie gesehen hat, weil sie ganz neu ist, und die einen etwas dubiosen und minderwertigen Eindruck macht.

rel="canonical" ist natürlich ein sehr eindeutiges Signal, den bevorzugten Standort für Inhalte zu kennzeichnen. Eine weniger explizite Methode stellt rel="author" dar. Mit diesem Attribut könnt ihr im Web kennzeichnen, dass Inhalte von euch stammen, oder auf euer Autorenprofil verweisen. Ihr könnt also mit einem Hinweis zeigen, woher Inhalte stammen und ob sie aus bekannten Quellen kommen.

Theoretisch kann man auch Signale auf Website-Ebene verwenden. Wenn wir denken, dass eine bestimmte Website allgemein viel kopiert, und der selbe auf dieser und auf einer anderen Website auftaucht, denken wir eher nicht, dass die Website mit dem vielen Kopierten die Quelle ist, sondern die Website, die schon über längere Zeit einzigartige Inhalte hervorgebracht hat.

Es sind also viele Faktoren denkbar. Es ist so knifflig, da der Googlebot das Web gewissermaßen nur in Stichproben crawlt. Das Web ist unendlich und kann sich innerhalb weniger Millisekunden verändern. Deshalb ist es schwer, beim Crawlen herauszufinden, wann und wo genau Inhalte zum ersten Mal aufgetaucht sind. Wir versuchen dabei, unser Bestes zu geben. Das gelingt uns nicht immer, und dann freuen wir uns über euer Feedback. Es gibt jedenfalls viele verschiedene Hinweise, Signale und Möglichkeiten, um die kanonische bzw.ursprüngliche Quelle von Inhalten zu bestimmen.

Veröffentlicht von Daniela Loesser, Search Quality Team

Brauche ich eine robots.txt, wenn ich Crawler gar nicht blocken will?

2011-10-28T09:42:00.000+01:00

Heute beantwortet Matt Cutts eine Webmaster-Frage zum Thema robots.txt. Eine robots.txt-Datei ist nützlich, um das Crawling und Indexieren des Contents durch Suchmaschinen zu steuern und einzuschränken. Ist eine robots.txt-Datei jedoch auch nötig, wenn man überhaupt keine Crawling-Einschränkungen haben möchte?

Die heutige Frage kommt aus Pennsylvania. Corey S. fragt: "Was ist besser? Eine leere robots.txt-Datei, eine robots.txt-Datei mit "User Agent: * Disallow" ohne Einschränkungen oder gar keine robots.txt-Datei?"

Sehr gute Frage, Corey. Ich denke, die beiden ersten Varianten sind die besten. Keine "robots.txt"-Datei zu haben, ist ein bisschen riskant. Nicht allzu riskant, aber schon ein bisschen. Ohne Datei gibt manchmal der Webhost die 404-Fehlermeldung aus, und das kann zu sehr seltsamem Verhalten führen. Und zum Glück entdecken wir so etwas ohne Probleme, also liegt auch hier das Risiko bei nur 1 %.

Wenn möglich würde ich aber eine robots.txt-Datei verwenden. Ob sie leer ist oder ob ihr festlegt "User-Agent: * Disallow" ohne Einschränkung, was heißt, dass jeder alles crawlen kann, ist ziemlich egal. In syntaktischer Hinsicht behandeln wir beide genau gleich.

Ich persönlich fühle mich mit "User-Agent: * Disallow:" wohler, weil eindeutig festgelegt ist, dass alles gecrawlt werden darf. Wenn sie leer ist, dann... Es war offensichtlich kein Problem, die robots.txt-Datei zu erstellen, deshalb wäre es toll, diesen Hinweis zu haben, der sagt: "Genau so, wie es hier steht, soll das Verhalten aussehen". Es könnte ja auch sein, dass jemand aus Versehen den gesamten Inhalt der Datei gelöscht hat.

Wenn ich die Wahl hätte, würde ich mich für eine robots.txt-Datei mit "User-Agent: *" entscheiden, in der alle Einschränkungen genau festgelegt sind. Ich denke aber, eine leere Datei ist vollkommen OK. Komplett ohne Datei besteht das wirklich geringe Risiko, dass euer Webhost seltsam oder ungewöhnlich reagiert, z. B. mit der Meldung "Sie haben keine Berechtigung, diese Datei zu lesen". Dann wird's komisch.

Das ist also nur ein ganz kleiner Tipp, wie ihr eine robot.txt-Datei erstellt. Vorausgesetzt, ihr habt nichts dagegen, dass der Googlebot eure Inhalte crawlt.

Veröffentlicht von Daniela Loesser, Search Quality Team