Willkommen zur Google Grants Site Clinic

Willkommen zu unserer Site Clinic im Rahmen von Google Grants! In der Google Einführung in Suchmaschinenoptimierung haben wir bewährte Vorgehensweisen zusammengefasst, um die Indexierbarkeit und Crawlability von Websites zu verbessern. Auf Basis dieses Dokuments haben wir nun die Website einer Nichtregierungsorganisation analysiert und geben Tipps, wie man die Website verbessern könnte.

Unser NGO-Partner ist das Projekt Schwarz-Weiß e.V., ein kleiner, gemeinnütziger Verein zum Wohle von Waisenkindern in Kenia. Die Website www.kenia-hilfe.com ist ein zentraler Bestandteil der Organisation, um Aktivitäten zu präsentieren sowie dringend notwendige Spenden zu sammeln.

Für die Analyse der Website haben wir einige Fragen gestellt: Kann der Googlebot auf alle Seiten zugreifen und sind diese korrekt bei Google indexiert? Wo liegen die Problemfelder? Hat die Website eine XML-Sitemap? Sind die Titel-Tags aussagekräftig? Ist die Meta-Description beschreibend? Wurde die Website benutzerfreundlich gestaltet? Schließt robots.txt wesentlichen Content aus? Gibt es auf der Website fehlerhafte Links? Haben die Bilder Alt-Text?

Wir werden hier im Google Webmaster-Zentrale Blog eine mehrteilige Analyse der Website auf Basis der Einführung in Suchmaschinenoptimierung veröffentlichen.

  • Im nächsten Post zum Thema gehen wir auf die technische Struktur der Website ein. Neben der URL-Struktur werden auch Titel- und Meta-Tags analysiert sowie Weiterleitungen überprüft.
  • Im dritten Blogpost untersuchen wir, wie der Content von www.kenia-hilfe.com "ins richtige Licht" gerückt werden kann.
  • Abschließend widmen wir uns potenziellen Problemen mit Duplicate Content.

Zwar beziehen wir uns in diesen Blogposts auf eine bestimmte Website, aber die Prinzipien, über die wir sprechen, sollten für alle Leser und die meisten Websites brauchbar sein.

Falls ihr Fragen habt, die sich direkt auf eure Website beziehen, schaut doch in unserem Forum für Webmaster vorbei!

Stay tuned!

Post von Michael Schwarz, Search Quality Team

Dienstag, 29. Dezember 2009 um 09:30

​Das Webmaster-Zentrale-Team wünscht frohe Festtage

2009 neigt sich langsam dem Ende zu. Wir möchten diese Gelegenheit nutzen, um uns bei allen Lesern zu bedanken!

Dieses Jahr ist viel passiert:

Die Hilfe für Webmaster ist auf eine neue Plattform umgezogen, die speziell für Google-Hilfe-Foren entwickelt wurde. Und erst kürzlich haben wir unsere Top-Beitragenden aus dem Forum auf unserem Blog vorgestellt.

Uli Lutz aus unserem Team hat die SES Berlin besucht, und bei der SMX München waren auch John Mueller und Kaspar Szymanski mit von der Partie. Bei beiden Events hatten wir die Möglichkeit, mit vielen von euch persönlich zu sprechen, was uns sehr gefreut hat!

Hier im Blog habt ihr regelmäßig Matt Cutts in Videos zu Gesicht bekommen. Wir haben euch außerdem über zahlreiche Neuerungen informiert.

Besonders interessiert haben euch:
  • Der neue Sitemap-Generator, der unterschiedliche Herangehensweisen zum Auffinden von URLs einsetzt
  • Die Vorstellung von Rich Snippets: sie bieten den Usern auf einem Blick eine praktische Zusammenfassung von Informationen zu ihrem Suchergebnis
  • Die Einführung kanonischer URLs, um Duplicate Content zu vermeiden

Wir hoffen, dass auch Themen wie “Was tun, wenn meine Website gehackt wurde?” oder die Tipps zum Reputationsmanagement hilfreich waren, und dass ihr auch weiterhin vorbeischaut.

Das gesamte Webmaster-Zentrale-Team wünscht euch frohe Festtage und viel Erfolg im neuen Jahr!

Das Webmaster Zentrale Team wünscht frohe Festtage

Post von Jörg Pacher, Search Quality Team

Montag, 21. Dezember 2009 um 09:59

Wie stelle ich am besten Content abhängig vom Standort des Users zur Verfügung?

Heute spricht Matt Cutts über den Unterschied zwischen Cloaking, Geo- und IP-Delivery.






Wir haben eine Frage von Martokus aus Sofia, Bulgarien. Martokus fragt:

"Wie stelle ich am besten unterschiedlichen Content abhängig von der Länder-IP zur Verfügung, beispielsweise aus rechtlichen Gründen?"

Also, es gibt viele Missverständnisse über den Unterschied zwischen Cloaking und Geo- oder IP-Delivery.

IP-Delivery gibt den Content abhängig von der IP-Adresse aus. Das klingt logisch, oder?

Cloaking zeigt Usern anderen Content als Googlebot. Cloaking ist also eine Art von IP-Delivery, aber nicht jede IP-Delivery ist Cloaking.

Und eine besondere Art von IP-Delivery, die nicht unter Cloaking fällt, zeigt Usern unterschiedlichen Content in verschiedenen Ländern. Google macht das auch. Wenn ihr Google in Frankreich aufruft, dann leiten wir euch wahrscheinlich zu google.fr. Wenn ihr Google in Deutschland aufruft, dann leiten wir euch wahrscheinlich zu google.de. Wir schauen also auf die IP-Adresse des Users und wir sagen "Wisst ihr was? In Deutschland ist google.de wohl nützlicher für diesen User." Was aber wichtig zu verstehen ist, wir haben keine gesonderte Behandlung für Googlebot bei länderabhängiger IP-Delivery. Und genauso wenig solltet ihr gesondert mit Googlebot umgehen. Behandelt ihn nicht wie ein besonderes Land. Macht im Großen und Ganzen nichts anders für Googlebot. Nehmt einfach die IP-Adresse, über die Googlebot gekommen ist, und behandelt sie genauso, wie ihr irgendeinen anderen User von derselben IP-Adresse behandeln würdet. Wir würden also in der Regel von den USA aus das crawlen, was Content aus den USA enthält.

Es ist kein Cloaking, dem User Content abhängig von der IP-Adresse zu zeigen, da ihr Googlebot nichts anderes zeigt als einem normalen User. Ein User aus den USA und Googlebot aus den USA würden dieselbe Seite erhalten, und demnach ist es kein Cloaking. Macht euch also bei IP-Delivery keine Sorgen in Bezug auf die IP-Adresse eurer User, solange ihr sichstellt, dass ihr denselben Content an User und an Googlebot liefert, dann ist das in keiner Weise problematisch und gilt auch nicht als Verletzung unserer Qualitätsrichtlinien für Webmaster.

Übersetzung von Claudia, Search Quality Team

Freitag, 18. Dezember 2009 um 10:33

Bezahlte Links in JavaScript-Code

In diesem Video spricht Matt Cutts über bezahlte Links, die über JavaScript implementiert wurden.




Wir haben eine gute Frage von Majico aus London, UK. Majico fragt:

"Google kann jetzt JavaScript-Links finden. Was passiert mit all den gekauften Links, die in JavaScript-Code stecken. Wird Google diese Links von nun an abstrafen?"

Diese Frage wurde mir auf der SMX Advanced in Seattle gestellt, aber ich beantworte sie gerne nochmals.

Google ist beim Crawling von JavaScript immer besser geworden, bis zu dem Punkt, dass URLs, die sich innerhalb von JavaScript befinden und von denen ihr dachtet, sie würden nicht gecrawlt, jetzt möglicherweise indexiert werden. Es hat sich herausgestellt, dass hauptsächlich Werbe-Netzwerke Links in JavaScript verwenden und wir wissen mit den bekannten Fällen umzugehen. Also: wir wissen über alle bekannten Werbe-Netzwerke Bescheid und können sie auch sehr gut handhaben.

Nun zu den verkauften Links, die JavaScript-Code benutzen: Ihr könnt das Nofollow-Attribut auch in eurem JavaScript-Code einsetzen. Ihr könnt immer robots.txt verwenden und URLs blockieren, die andernfalls indexiert worden wären, oder eine URL-Weiterleitung, die erfolgen würde. Dann crawlt Google die blockierte Seite nicht, weil wir der blockierten URL-Weiterleitung nicht folgen und den JavaScript-Code nicht erreichen können. Das wären einige sichere Wege. Wir denken aber, dass der größte Anteil der gekauften Links ohnehin nicht über JavaScript erstellt wird. Normalerweise sind das völlig normale Textlinks oder ähnliches. Dafür haben wir einen Großteil unserer Zeit aufgewandt.

Aber wenn ihr gekaufte Links habt und diese momentan über JavaScript laufen, wäre es eine gute Idee, sie zu überprüfen und zu sagen:" Okay, habe ich etwas, das von robots.txt blockiert wird, damit Suchmaschinen es nicht versehentlich crawlen, ausführen, den JavaScript-Code entdecken und in Folge neue Link finden?" 2009 strafen wir das noch nicht ab, wir könnten damit aber anfangen, obwohl es meiner Erfahrung nach kein großes Problem ist, denn der größte Anteil davon sind große Werbe-Netzwerke und Dinge, mit denen wir bereits gut umgehen können. Also wie immer:

wenn ihr Textlinks verkauft, stellt sicher, dass diese Links keinen PageRank vererben, und dass sie Suchmaschinen nicht beeinflussen. Es gibt zahlreiche einfache Wege, dies zu bewerkstelligen. Die haben sich nicht geändert seit wir über bezahlte Links reden: die Verwendung von robots.txt, die Verwendung des Nofollow-Attributs, und so weiter.

Übersetzung von Jörg, Search Quality Team

Donnerstag, 17. Dezember 2009 um 13:53

Kann ich davon profitieren, falls Content von der eigenen Site gescraped wurde?

Im heutigen Video spricht Matt darüber, ob es Situationen gibt, wo man davon profitieren kann, falls Content von der eigenen Site gescraped wurde.



Transkript:
Biz (USA) fragt: "Ist es möglich, davon zu profitieren, falls Content von der eigenen Site gescraped wurde?"

Nun, wenn ihr sicherstellt, dass eure Seiten Links zu euch haben oder die Artikel zu euch linken falls ihr gescraped wurdet, dann kann es passieren, dass der gescrapte Content zu euch verlinkt. Sollte es sich dabei um einen erfolgreichen Scraper oder Spammer handeln, dann können euch diese Links sogar weiter helfen.

Es gibt Leute, die Scraper wirklich hassen und versuchen, rigoros gegen sie vorzugehen und ihren gesamten Content zu eliminieren und vom Web-Host zu verbannen.
Ich neige eher dazu, mir keine allzu großen Sorgen darüber zu machen, weil in der absoluten Mehrzahl der Fälle, eure Originalseite vorn platziert wird - und nicht der Scraper. Außerdem: Wenn der gescrapte Content eure Links enthält, dann verlinkt er auch auf eure Site. Also im schlimmsten Fall wird es euch nicht wirklich schaden, aber in manchen Ausnahmen kann es euch sogar ein wenig helfen.

Normalerweise braucht ihr euch keine großen Sorgen über Scraper zu machen. Sie haben meist keinen großen Einfluß auf das, was User zu sehen bekommen. Wenn ihr also doch einen Scraper entdeckt, der besser rankt als ihr, dann könnt ihr eine "Digital Millennium Copyright Act"-Anfrage (DMCA request) stellen. Oder aber, falls es sich um einen echten Spammer mit wirren, sinnlosen Texten handelt, könnt ihr natürlich auch einen Spam-Report einschicken - das kann eine andere Möglichkeit sein, gegen diesen Scraper vorzugehen.

Übersetzung von Sven, Search Quality Team

Dienstag, 15. Dezember 2009 um 12:49

Anzeige der Website-Performance in den Webmaster-Tools

Anmerkung: Dieser Post dient als Ergänzung unserer vorherigen Ankündigung des "Website-Leistung"-Features.

Hier folgt ein kurzer Blick auf die individuellen Bereiche des "Website-Leistung"-Features in den Webmaster-Tools:

Leistungsübersicht

Die Leistungsübersicht im Website-Leistung Feature der Webmaster-Tools.
Die Leistungsübersicht zeigt eine Kurve der aggregierten Geschwindigkeitswerte für die Website - basierend auf den Seiten, die am häufigsten von Besuchern mit der Google-Toolbar und aktiviertem PageRank-Feature besucht wurden. Da wir die Daten der Google-Toolbar verwenden, braucht ihr euch keine Sorgen darüber zu machen, dass wir eure Site von einem Ort aus testen, der nicht relevant für eure Besucher ist. Wenn eure Site z. B. in Deutschland gehostet ist und alle eure User aus Deutschland kommen, dann wird unsere Grafik die Ladezeiten darstellen, wie sie in Deutschland auftreten. Auf ähnliche Weise ist in diesen Werten sichtbar, ob eure Besucher meist Telefon- oder IDSN-Einwahl nutzen oder über einen Breitbandanschluß verfügen. Falls nur wenige eurer User die Google-Toolbar nutzen, kann es sein, dass wir keine Daten in den Webmaster-Tools anzeigen können.

Die Linie zwischen dem roten und grünen Bereich auf der Grafik ist das 20. Perzentil - nur 20 % der Sites, die wir geprüft haben, sind schneller. Die Website im Bild ist ziemlich nah an der 20 % Marke - an welchen Seiten sollten wir daher zuerst arbeiten?

Beispielseiten mit Ladezeiten

Beispielseiten mit Angabe der Ladezeiten.
In diesem Bereich sind Beispielseiten zu finden, mit der Angabe der durchschnittlichen, aggregierten Ladezeiten von Usern bei ihrem Besuch der Website. Diese Zahlen können von euren eigenen Aufrufen abweichen, da sie auf verschiedenen Browsern, Internetverbindungen und Orten beruhen. Mithilfe dieser Liste könnt ihr Seiten erkennen, die überdurchschnittliche Ladezeiten aufweisen, also Seiten, die die User bremsen.

Da die Ladezeiten der Seiten auf tatsächlichen Zugriffen der User basieren, kann es sein, dass es sich dabei auch um Seiten handelt, die vom Crawling ausgeschlossen sind. Auch wenn Googlebot diese Seiten nicht crawlen kann, ist es doch möglich, dass diese Seiten einen beträchtlichen Anteil der Nutzererfahrung auf eurer Site ausmachen.

Bedenkt dabei auch, dass es zu gelegentlichen Spitzen kommen kann - es ist also gut, die Ladezeiten über einen kurzen Zeitraum zu verfolgen, um zu erkennen, was normal ist. Wenn ihr dauerhaft hohe Ladezeiten seht, bedeutet das wahrscheinlich auch, dass eure User hohe Ladezeiten haben (ob aufgrund langsamer Netzwerkverbindungen oder aus anderen Gründen). Das ist also etwas, das ihr ernst nehmen solltet.

Vorschläge von Page-Speed

Vorschläge von Page-Speed in den Webmaster-Tools.
Diese Vorschläge basieren auf dem Page-Speed-Plug-in für Firefox / Firebug. Zur Ermittlung der Details für die Beispiel-URLs, rufen wir die Seite inklusive aller eingebetten Ressourcen mit Googlebot ab. Falls wir nicht in der Lage sind, den gesamten eingebetten Content mit Googlebot abzurufen, kann es sein, dass wir keine vollständige Analyse bieten können. Ähnlich verhält es sich, wenn die Server einen leicht veränderten Content für Googlebot als für User liefern - dies kann einen Einfluß darauf haben, was wir hier anzeigen. Es kann z. B. sein, dass manche Server unkomprimierten Content an Googlebot liefern, so wie das bei älteren Browsern passiert, die keinen gzip-komprimierten eingebetteten Content unterstützen (das passiert z. B. aktuell bei der "ga.js"-Datei von Google Analytics).

Wenn es um angezeigte Probleme im Zusammenhang mit Code von Drittanbietern geht, wie z. B. Websiteanalyse-Skripte, kann es auch ein Faktor sein, wie weitverbreitet diese Skripte im Web sind. Falls sie sehr verbreitet sind, ist die Wahrscheinlichkeit hoch, dass der Browser eines durchschnittlichen Users bereits den DNS-Lookup und Inhalt des Skriptes im Cache hat. Obwohl wir diese Skripte mit separaten DNS-Lookups anzeigen, werden sie in der Praxis (weil bereits gecacht) kaum eine Rolle für die eigentliche Ladezeit spielen.

Wir bieten diese Vorschläge als hilfreichen Leitfaden bezüglich erster Schritte der Performance-Verbesserung einer Site und empfehlen darüber hinaus die Nutzung des Page-Speed-Plug-ins (oder eines vergleichbaren Tools), wenn ihr direkt an eurer Site arbeitet. Dadurch seid ihr besser in der Lage, mögliche Schwachstellen zu erkennen und es ist einfacher, direkt zu sehen, wie bestimmte Modifikationen am Server die gesamte Ladezeit verändern können.

Bei Fragen zu den Webmaster-Tools oder diesem neuen Feature könnt ihr gern unseren Artikel in der Hilfe für Webmaster lesen oder in unserem Forum für Webmaster suchen und posten. Außerdem bieten wir eine Diskussionsgruppe zu Page-Speed (Englisch). Wir hoffen, diese Informationen sind euch dabei behilflich, eure Website noch schneller zu machen!

Your site's performance in Webmaster Tools (English version)

Post von John Mueller, Webmaster Trends Analyst, Google Zürich (Übersetzung von Sven, Search Quality Team)

Freitag, 11. Dezember 2009 um 14:21

Was mache ich, wenn meine Website gehackt wurde?

Das heutige Video mit Matt Cutts handelt von einer Website, die trotz Antrag auf erneute Überprüfung nach einem Hack-Angriff nicht mehr wie vorher in den Suchergebnissen erscheint.



Frage von Laura Thieme aus Columbus, Ohio:

"Ich habe einen Kunden, dessen Website gehackt wurde. Anscheinend hat der SEO-Berater gesagt, dass die Sache bereinigt worden sei, obwohl das nicht stimmte. Insgesamt 30 000 Viagra/Cialis-Seiten wurden entfernt, aber bei den SERPs, den Suchergebnissseiten, gab es keine Verbesserung. Wir haben auch eine erneute Überprüfung beantragt. Was sollen wir jetzt unternehmen?"

Ich würde noch einen Antrag auf erneute Überprüfung stellen. Ich würde auch eine "site:"-Suche machen und auf [site:example.com] nach [viagra], [cialis], [porn], [free sex] und anderen typischen Spam-Begriffen suchen, die euch einfallen, um sicher zu sein, dass wirklich alle Seiten weg sind. Ich würde mir auch die Keywords in den Webmaster-Tools anschauen, um zu sehen, für welche Keywords ihr auftaucht.
Wenn nur eines davon nach Spam oder Porn oder so aussieht, kontrolliert nochmals.

Ihr könntet auch jemanden bitten, einen Blick ins Forum für Webmaster zu werfen und zu fragen: "Ist was falsch mit meiner Website?", denn manchmal kann die Community dort was entdecken. Und vergewissert euch, dass ihr eine möglichst aktuelle Version eurer Software verwendet. Wenn ihr z. B. WordPress benutzt, stellt sicher, dass ihr das neustes Update für die WordPress-Installation habt. Denn manchmal räumt man alles auf, nur um wieder gehackt zu werden. Wenn ihr nach [google webmaster blog gehackt] sucht, findet ihr einige Posts, die wir zum Thema veröffentlicht haben und ihr könnt mehr dazu lesen.

Und wenn ihr sicher seid, dass alles völlig sauber ist, beantragt eine weitere Überprüfung und dann taucht die Website hoffentlich wieder auf.

Übersetzung von Jörg, Search Quality Team

Donnerstag, 10. Dezember 2009 um 17:38