Wir hoffen, dass ihr nie in die Situation kommt, auf unsere Hilfen für gehackte Websites angewiesen zu sein. Es handelt sich dabei um rund ein Dutzend Artikel und über eine Stunde Videomaterial, was Webmaster dabei unterstützen soll, falls ihre Website manipuliert wurde.
Übersicht: Wie und weshalb werden Websites gehackt (englisch)
Falls ihr mehr dazu erfahren wollt, weshalb Cyber-Kriminelle Websites für Spam-Zwecke hacken, könnt ihr euch die Erklärung von Tiffany Oberoi in Schritt 5: Ermittelt den Schaden (gehackt mit Spam) anschauen.
Tiffany Oberoi, Webspam Engineer, mit Erläuterungen über Sites, die zu Spam-Zwecken gehackt wurden (englisch)
Lucas Ballard, Safe-Browsing Engineer, und ich in einem völlig natürlichen Gespräch über Malware (englisch)
Obwohl wir versuchen, die notwendigen Schritte zur Schadensbeseitigung zu erläutern, bleiben die einzelnen Schritte immer noch relativ schwierig für Seitenbetreiber, die keine fortgeschrittenen Administrator-Kenntnisse oder umfassende Erfahrung mit Quelltexten haben. Deshalb möchten wir uns an dieser Stelle auch ganz besonders bei den Beitragenden in unserem Webmaster-Forum danken, die vielen betroffenen Webmastern bei der schwierigen Beseitigung der Probleme geholfen haben!
Wie ihr vermeiden könnt, überhaupt Hilfe zu gehackten Websites zu benötigen
Genauso wie die Fokusierung darauf, eure Website für eure Besucher nützlich zu machen und Suchmaschninenfreundlich zu gestalten, ist die Sicherheit eurer Website - für euch und eure Besucher - von größter Bedeutung. Bei Seitenbetreibern, die ihre Website nicht ausreichend sicher halten, können Hacker diese Schwachstellen ausbeuten. Falls ein Hacker eine Schwachstelle ausnutzt, dann kann es sein, dass ihr Hilfe zu gehackten Sites benötigt. Um dieses Szenario zu vermeiden, solltet ihr:
Stets daran denken, eure Software auf dem neuesten Stand zu halten
Die Sicherheitsmechanismen aller Applikationen, Plugins, Drittanbieter-Software etc. vor dem Einsatz auf eurem Server verstehen. Eine Sicherheitslücke in einer einzelnen Applikation kann die Sicherheit der gesamten Website gefährden.
Unnötige, nicht verwendete Software entfernen
Die Nutzung starker Passwörter durchsetzen
Alle Geräte, welche auf den Server zugreifen, sicher halten (Betriebssystem-Updates, Browser-Updates)
Reguläre, automatisierte Backups der Website durchführen
Hilfe rund um gehackte Websites könnt ihr hier finden: http://www.google.com/webmasters/hacked. Wir würden uns freuen, euch nicht auf diesen Seiten begrüßen zu müssen!
Post von Maile Ohye, Developer Programs Tech Lead (Übersetzung von Sven Naumann, Search Quality Team)
Damit ihr Fehler vermeiden könnt, die Webmastern häufig bei der Suchmaschinenoptimierung (Search Engine Optimization - SEO) unterlaufen, habe ich ein Video mit einem kurzen Überblick über fünf häufige Fehler gedreht, die ich in der SEO-Branche beobachtet habe. Vor fast vier Jahren haben wir auch alle von euch (unsere Leser) nach euren SEO-Empfehlungen gefragt und unseren Hilfeartikel zu diesem Thema anhand eures Feedbacks aktualisiert. Ein Großteil der Empfehlungen aus 2008 hat heute immer noch Gültigkeit - auf viele weitere Jahre, in denen ihr großartige Websites erstellt!
Falls ihr wenig Zeit habt, hier ist die Zusammenfassung:
Diese häufigen Fehler gilt es zu vermeiden
1. Kein Nutzenversprechen zu haben: Geht nicht davon aus, dass eine Website den 1. Rang einnehmen sollte, ohne dass ihr wisst, warum sie für Nutzer der Google-Suche hilfreich ist (und besser als die Konkurrenz :)
2. Kein ganzheitlicher Ansatz: Hütet euch davor, SEO-bezogene Ziele zu setzen, ohne euch zu vergewissern, dass sie mit den Gesamtzielen eures Unternehmens und den Zielen anderer Abteilungen übereinstimmen. Setzt beispielsweise euer Können nicht nur für die Optimierung von Produktseiten (und der ganzen Nutzererfahrung, sobald diese auf eure Website kommen) ein, sondern auch für die bevorstehende Kampagne eures Marketing-Teams. Wenn also Marketing neue Videos lanciert oder eine interaktivere Website einführt, achtet darauf, dass Nutzer der Google-Suche die entsprechenden Inhalte auch finden können.
3. Zeitraubende Behelfslösungen: Vermeidet es, Behelfslösungen zu implementieren anstatt nach neuen Funktionen oder Best Practices zu suchen, die die Entwicklung vereinfachen könnten (z. B. den Zeitstempel bei einer aktualisierten URL zu ändern, damit sie schneller gecrawlt wird, anstatt die URL einfach über Abruf wie durch Googlebot einzureichen).
4. Gefangen in SEO-Trends: Zieht in Erwägung, weniger Zeit damit zu verbringen, euch mit dem neuesten "Trick" zur Verbesserung eurer Rankings zu befassen, und euch stattdessen auf die grundlegenden Aufgaben/Anstrengungen zu konzentrieren, die euch Besucher einbringen, die gerne wiederkommen.
5. Überlegte Iteration: Bleibt beweglich, anstatt eine Umgebung aufzubauen, in der es durch die Infrastruktur bzw. Prozesse schwierig ist, eure Website zu verbessern oder mögliche Verbesserungen zu testen.
Sechs grundlegende SEO-Tipps
1. Lasst euch etwas Cooles einfallen: Achtet darauf, dass sich eure Website von der Konkurrenz abhebt - in positiver Hinsicht!
2. Spickt eure Inhalte mit relevanten Wörtern: Versucht, die Perspektive der Nutzer der Google-Suche einzunehmen. Welche Suchanfragen würden sie stellen, um euch zu finden? Euer Name/Geschäftsname, Standort, eure Produkte usw. sind wichtig. Es ist auch hilfreich, auf eurer Website dieselben Begriffe zu verwenden, die eure Nutzer eingeben könnten (ihr seid z. B. gelernter "Blumen-Arrangeur", aber die meisten Nutzer der Google-Suche geben eher [Florist] ein), und Fragen, die sie möglicherweise haben, wie etwa zu Öffnungszeiten, Produktspezifikationen oder Erfahrungsberichten, zu beantworten. Es ist hilfreich, wenn ihr wisst, wer eure Kunden sind.
3. Seid clever hinsichtlich eurer Tags und Website-Architektur: Erstellt eindeutige "title"-Tags und Meta-Beschreibungen; nehmt gegebenenfalls Rich Snippets-Markup von schema.org auf. Habt eine intuitive Navigation und gute interne Links.
5. Macht auf euch aufmerksam: Organische Links, +1-Geber, Fans, Follower... Bei jedem Unternehmen gibt es etwas Fesselndes, Interessantes, Unterhaltendes oder Überraschendes, das ihr anbieten oder mit euren Nutzern teilen könnt. Bietet einen hilfreichen Service, erzählt lustige Geschichten, malt ein Bild in leuchtenden Farben und Nutzer werden eure Inhalte teilen und erneut teilen.
6. Bleibt aktuell und relevant: Haltet Inhalte aktuell und zieht Möglichkeiten in Betracht wie die Erstellung eines Auftritts bei sozialen Medien (falls es dort eine potenzielle Zielgruppe gibt) oder die Erstellung einer optimierten mobilen Website, falls eure Nutzer oft unterwegs sind.
Ich wünsche euch allen viel Erfolg!
Autor: Maile Ohye, Developer Programs Tech Lead (Veröffentlicht von Uli Lutz, Search Quality)
Wenn euch unsere Ankündigung vor ein paar Monaten zu rel="next" und rel="prev" für Inhalte in fortlaufenden Sequenzen neugierig gemacht hat, findet ihr in diesem Video weitere grundlegende Informationen zur Seitennummerierung, die eure Fragen hoffentlich beantworten. Inhalte in fortlaufenden Sequenzen sind in Artikeln zu finden, die sich über mehrere URLs oder Seiten ziehen, oder auch in E-Commerce-Produktseiten mit mehreren Seiten. Mit dem Markup rel="next" und rel="prev" könnt ihr Google einen konkreten Hinweis geben, dass diese Seiten als eine logische Sequenz behandelt werden sollen. Dadurch werden ihre Verbindungseigenschaften verstärkt und die Nutzer werden in der Regel auf die erste Seite geleitet. Weitere Informationen findet ihr in unserer Präsentation:
In diesem Video zum Thema Seitennummerierung geht es um die Grundlagen von rel="next" und rel="prev" und die Einsatzmöglichkeiten auf eurer Website.
Folien aus dem Video zur Seitennummerierung
Zusätzliche Ressourcen zur Seitennummerierung findet ihr hier:
Diskussion im Webmaster-Forum (auf Englisch) mit unseren Antworten auf tiefer gehende Fragen der Community. Hier ein paar Beispiele:
Wird mit rel="next" und rel="prev" nur eine Seite der Sequenz (in den meisten Fällen die erste Seite?) in den Suchindex aufgenommen? Oder müssen "noindex"-Tags ab der zweiten Seite eingesetzt werden?
Wenn ihr rel="next" und rel="prev" auf Komponentenseiten einer Sequenz implementiert, werden die Indexeigenschaften der einzelnen Seiten verstärkt und wir versuchen, Nutzer auf die relevanteste Seite/URL zu leiten. Dies ist in den meisten Fällen die erste Seite. Ihr müsst die folgenden Seiten nicht mit einem "noindex"-Tag versehen, außer ihr seid euch sicher, dass diese Seiten nicht in den Suchergebnissen angezeigt werden sollen.
Sollte ich rel="next" und rel="prev" in einen Abschnitt meines Blogs einbauen, auch wenn die Inhalte nicht im engeren Sinn zusammenhängen (aber zeitlich aufeinander folgen)?
Wenn es um die Verwendung von rel="next" und rel="prev" für Blogeinträge geht, die "nicht im engeren Sinn zusammenhängen (aber zeitlich aufeinander folgen)", ist das Markup der Seitennummerierung wahrscheinlich nicht der effektivste Ansatz. Zeitlich aufeinander folgende Seiten sind für unseren Index bei Weitem nicht so relevant wie semantisch zusammenhängender Inhalt, wie im Fall von Seitennummerierung auf Komponentenseiten in einem Artikel oder einer Kategorie. Ihr könnt das Markup gerne bei zeitlich aufeinander folgenden Seiten einbauen, beachtet dabei jedoch, dass dies eurer Indexierung nicht besonders zuträglich ist.
Wir betreiben eine Website für Mietimmobilien. Die Suchergebnisse hängen von einer Reihe von Parametern ab, die die Reihenfolge und die Anzeige spezifischer Ergebnisse beeinflussen. Die Parameter lauten unter anderem "Seitennummer", "Ergebnisse pro Seite", "Reihenfolge" und "Bereichsauswahl".
Es scheint, als ob eure Website mit Mietimmobilien mit den gleichen Problemen zu kämpfen hat wie viele E-Commerce-Websites. Hier ein paar Ideen zu eurer Situation:
1. Es ist toll, dass ihr die Funktion der URL-Parameter in den Webmaster-Tools verwendet, damit eure Website effizienter gecrawlt wird.
2. Es ist möglich, eine Sequenz mit rel="next" und rel="prev" ohne Parameter (oder mit Standardparameterwerten) für eure Website einzurichten. Es ist außerdem möglich, eine parallel laufende Sequenz mit Seitennummerierung einzusetzen, wenn Nutzer bestimmte Parameter auswählen. Zum Beispiel kann eine Seitensequenz mit 15 Einträgen und eine separate Sequenz mit 30 Einträgen eingerichtet werden. Durch die Nummerierung von Komponentenseiten, auch mit Parametern, kann ein präziserer Index für euren Inhalt erstellt werden.
3. Es ist vollkommen in Ordnung, rel="canonical" auf einer Komponentenseite zu verwenden, um auf eine einzelne Gesamtansicht-Seite zu verweisen. Es wird jedoch als nicht zulässig angesehen, "canonical" für die erste Seite einer Sequenz ohne Parameter einzusetzen. Wir können nicht versprechen, diese Verwendung von rel="canonical" zu berücksichtigen.
Wenn ihr also über Inhalte in fortlaufenden Sequenzen verfügt, könnt ihr ohne Probleme bei eurer derzeitigen Konfiguration bleiben und das Markup rel="next" und rel="prev" nicht einsetzen. Solltet ihr jedoch Interesse am Markup für fortlaufende Sequenzen haben und ihr wollt uns einen konkreten Hinweis geben, damit wir eure Website besser verstehen, hoffen wir, dass euch diese Tipps weiterhelfen.
Autor: Maile Ohye, Developer Programs Tech Lead (Veröffentlicht von Uli Lutz, Search Quality)
Videos gehören zu den häufigsten Suchergebnissen auf Google und wir möchten sichergehen, dass eure Videos auch indexiert werden. Deshalb führen wir nun auch die Videounterstützung für schema.org ein. schema.org (auf Englisch) ist ein Gemeinschaftsprojekt von Google, Microsoft, Yahoo! und Yandex und wird ab sofort für die Beschreibung von Videos im Web empfohlen. Das Markup ist sehr einfach und kann auf den meisten Websites problemlos eingefügt werden.
schema.org-Video-Markup wird genau wie sonstige schema.org-Daten hinzugefügt. Ihr legt einfach "itemscope" und "itemtype="http://schema.org/VideoObject"" fest und gebt den Namen, die Beschreibung sowie die thumbnailUrl-Eigenschaften an. Außerdem benötigt ihr die embedURL, also den Speicherort des Videoplayers, oder die contentURL, den Speicherort der Videodatei. Ein typischer Videoplayer mit Markup könnte folgendermaßen aussehen:
Die Nutzung von schema.org wirkt sich nicht auf Video-Sitemaps oder mRRS-Feeds aus, die ihr bereits verwendet. Wir empfehlen, neben schema.org weiterhin eine Video-Sitemap zu verwenden.
Da es nun also mehrere Möglichkeiten gibt, Google über eure Videos zu informieren, erscheint es möglicherweise schwierig, das richtige Format zu wählen. Deshalb haben wir auf unserer neuen Webmaster-EDU-Microsite eine Reihe von Videos und Artikeln zur Videoindexierung zusammengestellt, um die Videoindexierung für euch möglichst einfach zu gestalten.
In dieser Video-Antwort beschäftigt sich Matt Cutts mit der Frage, warum Seiten mit 404 Fehlercode in den Suchergebnissen von Google auftauchen.
Die heutige Frage kommt aus Kansas in den USA.
John Heard möchte wissen:
"Warum braucht Google so lange, um URLs mit dem Fehlercode 404 zu entfernen?"
Das ist eine gute Frage. Der Fehlercode 404 kann auch vorübergehend erscheinen, wenn eine Seite nur kurzzeitig ausfällt. Wenn ihr zeigen möchtet, dass eine Seite vollständig gelöscht wurde und nicht wieder auftaucht, solltet ihr
den HTTP-Statuscode 410 verwenden.
Bei der letzten Überprüfung
im Jahr 2007 wurde zwischen
diesen Codes letztendlich
jedoch nicht unterschieden.
Kommen wir
zurück zur eigentlichen Frage.
Die Antwort lautet:
Webmaster arbeiten
auf ihre eigene Art und Weise.
Sie stehen sich manchmal
selbst im Weg.
Sie entfernen
beispielsweise die Website vollständig
aus den Suchergebnissen.
Oder die Website fällt
nur vorübergehend aus,
doch sie gibt
Code 404 statt 503 zurück.
Statt Websites
mit Fehlercode 404
schnell vollständig zu entfernen,
lassen wir etwas Spielraum
und überprüfen mehrmals,
ob der Webmaster
einen Fehler gemacht hat
oder ob die Website
tatsächlich aus dem Index
entfernt werden soll.
Es gibt keine optimale Lösung,
denn kein Ansatz
stellt alle zufrieden.
Wir versuchen,
die goldene Mitte zu finden,
sehen uns das Feedback an
und überlegen dann,
ob wir die Seite noch
einige Tage testen, um sicher zu sein,
dass sie tatsächlich abgeschaltet wurde.
Ein anderes Beispiel:
Wenn eure Website
vorübergehend ausfällt
und Google den Webserver
jahrelang nicht überprüft,
seid ihr natürlich sauer.
Aus diesem Grund
suchen wir nach einem Kompromiss.
Euer Feedback
hilft uns dabei, vielen Dank!
Wir können natürlich
das Crawl-Team fragen,
ob Websites mit Code 410 inzwischen schneller entfernt werden oder ob sie noch gleich behandelt werden. Derzeit gehen wir aber auf Nummer sicher und überprüfen, ob die Webmaster einen Fehler gemacht haben. Sollte ihr Server überlastet oder der Web-Host falsch konfiguriert worden sein, vermeiden wir so langfristige Schäden und können die Website meist wiederherstellen.
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!
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
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
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
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
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)
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.
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
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
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
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
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
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
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
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
