schema.org-Markup für Organisationslogos

Heute präsentieren wir das schema.org-Markup für Organisationslogos, mit dem ihr eure Seite ab jetzt mit einem Bild verknüpfen könnt. Damit möchten wir euch die Möglichkeit geben, ein Bild auszuwählen, das als euer Logo in den Suchergebnissen von Google erscheinen soll.

Mit dem schema.org-Markup für Organisationen könnt ihr unsere Algorithmen auf den Speicherort eures bevorzugten Logos hinweisen. Ein Unternehmen mit der Startseite www.example.com kann das folgende Markup für auf der Startseite sichtbare Elemente hinzufügen:

<div itemscope itemtype="http://schema.org/Organization">
<a itemprop="url" href="http://www.example.com/">Startseite</a>
<img itemprop="logo" src="http://www.example.com/logo.png" />
</div>

Das Markup in diesem Beispiel lässt Google wissen, dass dieses Bild das Logo der Organisation auf der ebenfalls angegebenen Startseite darstellt und, falls möglich, in den Google-Suchergebnissen verwendet werden soll. Diese Art von Markup ist ein guter Hinweis für unsere Algorithmen, dass dieses Bild bevorzugt verwendet werden soll, wenn zum Beispiel der Knowledge Graph auf der rechten Seite bei einer Suchanfrage eines Nutzers erscheint.

Bei Fragen findet ihr wie immer Unterstützung im Webmasterforum

Post von RJ Ryan, Google Engineer (Veröffentlicht von Johannes Mehlem, Search Quality Team)

Donnerstag, 16. Mai 2013 um 09:55

Einführung von "x-default hreflang" für internationale Webseiten

Manche Startseiten von internationalen Websites bieten verschiedene Lokalseiten an, zu denen der User meist entweder weitergeleitet wird oder per Landesauswahl gelangt. Wir stellen heute den neuen rel-alternate-hreflang-Verweis vor, mit welchem der Webmaster bevorzugte Startseiten bestimmen kann. Diese Funktion wird von Google und Yandex unterstützt.

Das folgende Beispiel verdeutlicht wie dieser Verweis in der Praxis ausieht. Angenommen eine Website example.com bietet Inhalte für Nutzer weltweit an:


http://example.com/en-gb: Für englischsprachige User in UK
http://example.com/en-us: Für englischsprachige User in USA
http://example.com/en-au: Für englischsprachige User in Australien
http://example.com/: Die Startseite zeigt dem User eines Landesauswahl an und ist als Standardseite für User weltweit definiert

In solchen Fällen kann der Webmaster für eine solche Gruppe an Seiten Verweise für mehrere Webseiten mittels rel-alternate-hreflang in Sitemaps oder per HTML-Link-Element wie folgt vornehmen:

<link rel="alternate" href="http://example.com/en-gb" hreflang="en-gb" />
<link rel="alternate" href="http://example.com/en-us" hreflang="en-us" />
<link rel="alternate" href="http://example.com/en-au" hreflang="en-au" />
<link rel="alternate" href="http://example.com/" hreflang="x-default" />

Der neue x-default hreflang Verweis signalisiert unseren Algorithmen, dass die Seite nicht auf User einer bestimmten Sprache oder eines Ortes abzielt. Gleichzeitig wird die Seite als Standardseite gesehen, sofern keine besser geeignete Webseite vorliegt. In unserem Beispiel wäre das zum Beispiel die Seite für französischsprachige User weltweit oder die Seite in den Suchergebnissen für englischsprachige Google-Sucher bei google.ca (Google Kanada).

Der gleiche x-default hreflang-Verweis funktionert auch für Websites, welche die Inhalte an den ermittelten Aufenthaltsort des Besuchers oder die 'Accept-Language' Information im Header anpassen. Mit dem x-default hreflang-Verweis würde wieder der Effekt erzielt, dass die Algorithmen verstehen dass die Seite nicht auf eine bestimmte Sprache oder bestimmten Ort ausgerichtet ist.

Bei Fragen oder Anmerkungen könnt ihr wie immer gerne im Webmasterforum posten.

Post von Pierre Far, Webmaster Trends Analyst (Übersetzung von Johannes Mehlem, Search Quality Team)

Montag, 15. April 2013 um 18:08

5 häufige Fehler bei der Verwendung von rel=canonical-Tags

Mit dem rel=canonical-Tag in einem Link könnt ihr eure Inhalte als bevorzugt gegenüber anderen indexierten duplizierten Inhalten hervorheben. Diese Funktion wird von mehreren Suchmaschinen inklusive Yahoo!, Bing, und Google unterstützt. Die rel=canonical-Angabe hilft dabei, bestimmte Eigenschaften von Duplikaten zusammenzuführen, z. B. die eingehenden Links und bestimmt darüber hinaus, welche URL-Version in den Suchergebnissen bevorzugt gezeigt werden soll. Jedoch kann die Verwendung des rel=canonical Tags auch knifflig sein, vor allem wenn es nicht besonders offensichtlich ist, ob ggf. eine falsche Einbindung vorliegt.


Während der Webmaster links die "red velvet" Seite im Browser sieht, bemerken Suchmaschinen das unbeabsichtigte "blue velvet" rel=canonical, wie rechts dargestellt.

Wir empfehlen die folgenden Praxis-Tipps für die Verwendung von rel=canonical:
  • Die Mehrheit der Inhalte auf der duplizierten Webseite sollte auch auf der kanonischen Version vorhanden sein.
    Ein "Test" kann hier sein, wenn ihr euch vorstellt, die Sprache des Inhalts nicht zu verstehen: Wenn ihr das Duplikat direkt mit der kanonischen Version vergleicht, taucht dann ein Großer Prozentsatz der Worte des Duplikats auch auf der kanonischen Version auf? Wenn ihr die Fremdsprache beherrschen müsstet, um eine Ähnlichkeit festzustellen, da das Thema sich zwar ähnelt aber die Wortwahl sich nicht gleicht, könnte das rel=canonical-Tag unter Umständen nicht von Suchmaschinen interpretiert werden.
  • Vergewissert euch, dass die rel=canonical Zielseite auch wirklich existiert (dies bedeutet weder ein Fehlerstatus noch "falsche" 404-Fehler)
  • Überprüft ob die rel=canonical Zielseite eventuell fälschlicherweise ein noindex Robots-Meta-Tag enthält
  • Gewährleistet, dass ihr tatsächlich die URL mit rel=canonical in den Suchergebnissen sehen wollt (und nicht das Duplikat)
  • Fügt den rel=canonical-Link entweder im <head>-Bereich der Seite oder im HTTP-Header ein
  • Verwendet nicht mehr als ein rel=canonical pro Seite, da bei mehreren Tags alle verwendeten rel=canonical auf einer Seite ignoriert werden

1. Fehler: rel=canonical auf die erste Seite einer nummerierten Reihe an Seiten angewandt

Beispielsweise könnte eure Webseite folgende Seitenstruktur verwenden:
  • example.com/article?story=cupcake-news&seite=1
  • example.com/article?story=cupcake-news&seite=2
  • und so weiter
Sofern die zweite oder eine spätere Seite einen rel=canonical Link auf die erste Seite setzen sollte, so wäre dies nicht effektiv, da es sich bei diesen Seiten nicht um Duplikate handelt. In diesem Fall würden die Inhalte der zweiten oder der entsprechendenden späteren Seite nicht indexiert werden.


Gute Inhalte (z.B. "cookies are superior nutrition" and "to vegetables") gehen verloren, wenn rel=canonical von einer der Folgeseiten auf die erste Seite der Reihe linkt.

Für eine Abfolge an Seiten oder nummerierte Webseiten empfehlen wir entweder ein rel=canonical von den Serienseiten zu einer einseitigen Version aller Inhalte oder Seitennummerierung mit rel="prev" und rel="next".


rel=canonical von Seiten einer Reihe zur Gesamtansicht


Sofern rel=canonical nicht zur Gesamtansicht verlinkt, können rel="prev" und rel="next"-Tags für nummerierte Webseiten verwendet werden.

2. Fehler: Absolute URLs als relative URLs verwendet


Das <link>-Tag erlaubt wie die meisten HTML-Tags absolute sowie relative URLs. Der Pfad von relativen URLs bezieht sich auf einen Pfad von der aktuellen Webseite ausgehend. Zum Beispiel “images/cupcake.png” gibt an vom aktuellen Pfad in den "images" Ordner zu gehen und dann zu "cupcake.png". Absolute URLs beschreiben den gesamten Pfad inklusive "http://".

Das folgende Tag <link rel=canonical href=“example.com/cupcake.html” /> (ein relativer URL-Pfad, da kein "http://") geht von http://example.com/example.com/cupcake.html als gewünschter kanonischer URL aus, obwohl dies sicherlich nicht beabsichtigt wäre. In solchen Fällen können unsere Algorithmen das rel=canonical ggf. ignorieren. Dies bedeutet, dass der Webmaster seine Absicht nicht erfolgreich umsetzen konnte.

3. Fehler: Unbeabsichtigte oder mehrfache Verwendung von rel=canonical

Gelegentlich begegnen wir rel=canonical Zielseiten, welche mit hoher Wahrscheinlichkeit unbeabsichtigt sind. In sehr seltenen Fällen ist dies bedingt durch Rechtschreibfehler. Häufig kopiert einer der beschäftigten Webmaster eine Seite ohne die Zielseite des rel=canonical-Tags anzugleichen. Die Webseite des Webmasters verwendet dann rel=canonical für das Website-Template zum Beispiel.


Wenn ihr ein Template verwendet, vergewissert euch, dass das rel=canonical Tag nicht auch kopiert wurde.

Ein weiteres Problem besteht, wenn mehrere Seiten rel=canonical Links zu verschiedenen URLs enthalten. Dies geschieht häufig in Verbindung mit SEO Plugins, die oft standardmäßig und möglicherweise vom Webmaster unbemerkt, einen rel=canonical Link mit der Installation einfügen. Bei mehreren rel=canonical-Tags auf einer Seite wird Google wahrscheinlich alle rel=canonical-Tags ignorieren. Somit wäre eine legitime rel=canonical-Einbindung leider nicht erreicht.

In beiden Fällen hilft es, den Quelltext der Webseite zu überprüfen und gegebenfalls zu korrigieren. Es ist ratsam, Inhalte im gesamten <head> zu überprüfen, da die rel=canonical-Links verteilt sein können.


Überprüft den Quelltext nach Einbindung eines Plug-ins

4. Fehler: Kategorien-Seite linkt mit rel=canonical zu Kategorien-Unterseite

Angenommen, Ihr betreibt eine Webseite über Desserts. Die Webseite verfügt über nützliche Kategorien wie "Gebäck" und "Eis". Die Kategorien-Seiten bieten täglich einzigartige Artikel an. Zum Beispiel werden auf eurer Webseite unter Gebäck "Red Velvet Cupcakes" angeboten. Da die Gebäck-Unterseite fast den gleichen Inhalt wie die "Red Velvet Cupcake"-Seite hat, fügt ihr ein rel=canonical von der Kategorien-Seite zu der Einzelseite mit dem vorgestellten Artikel hinzu.

Dies würde darin resultieren, dass die Gebäck Kategorien-Seite nicht in den Suchergebnissen angezeigt würde. Dies passiert, weil das rel=canonical den Suchmaschinen signalisiert, lieber die kanonische URL anzuzeigen anstelle der duplizierten. Sofern beide Webseiten auffindbar sein sollen, ist es am besten, nur ein selbstverweisendes rel=canonical auf der Kategorien-Seite anzuwenden oder auch gar keines.


Bedenkt, dass die kanonische Webseite auch als bevorzugte URL für die Ansicht in den Suchergebnissen fungiert. Vermeidet rel=canonical Links von einer Kategorien-Seite zu einer Kategorien-Unterseite.

5. Fehler: rel=canonical im <body>

Das rel=canonical-Link-Element sollte nur im <head> eines HTML-Dokuments erscheinen. Um HTML-Parsing-Probleme zu vermeiden, ist es ebenfalls gut, wenn das rel=canonical so früh wie möglich im <head> steht. Wenn wir einem rel=canonical im <body> begegnen, wird es nicht berücksichtigt.

Dieser potentielle Fehler is einfach zu korrigieren. Überprüft einfach, ob sich die rel=canonical-Links im <head> befinden und ob sie so früh wie möglich auftauchen.


Ausschließlich rel=canonical-Tags im <head> haben einen Effekt.

Zusammenfassung

Um das rel=canonical effizient anzuwenden:
  • Vergewissert euch, dass der Großteil der Wörter im Duplikat der Seite auch in der kanonischen Seite auftaucht.
  • Überprüft, ob das rel=canonical-Tag nur einmal (wenn überhaupt) und nur im <head> der Seite verwandt wird.
  • Prüft, ob rel=canonical auf eine vorhandene URL mit guten Inhalten verweist (keine 404, oder sogar eine "falsche" 404-Seite).
  • Vermeidet das rel=canonical-Tag von Landingpages oder Kategorien-Seiten zu Kategorien-Unterseite oder beispielsweise Produkt-Unterseiten, da die Unterseite somit in der Ansicht der Suchergebnisse bevorzugt würde.
Wie immer könnt ihr bei Fragen und Anregungen gerne im Webmasterforum posten.

Post von Allan Scott, Software Engineer, Indexing Team (Übersetzung von Johannes Mehlem, Search Quality Team)

Mittwoch, 10. April 2013 um 15:56

Webmaster-Academy jetzt international


Seitdem die Webmaster-Academy in Englisch im Mai 2012 gestartet ist, wurden die Inhalte nun mehr als eine Millionen Mal gesehen.

Die Webmaster-Academy wurde ins Leben gerufen, um Webmastern dabei zu helfen, überzeugende Websites mit guter Sichtbarkeit in den Google-Suchergebnissen zu erstellen. Die Academy eignet sich sowohl für Anfänger als auch für erfahrenere Webmaster, welche mehr über fortgeschrittene Themen erfahren wollen.

Um Webmaster auf globaler Ebene zu unterstützen, wurden die Inhalte der Webmaster-Academy in nun 20 Sprachen übersetzt. Wir hoffen, dass wir nun Webmastern auf der ganzen Welt von Japan bis Deutschland helfen können noch bessere Webseiten zu gestalten. Die Webmaster-Academy kann unter Tipps für Webmaster in der Webmaster-Zentrale erreicht werden.

Fragen und Anregungen könnt ihr wie gewohnt im Webmasterforum posten.

Post von Giacomo Gnecchi Ruscone, Search Quality (Übersetzung von Johannes Mehlem, Search Quality Team)

Donnerstag, 28. März 2013 um 14:24

Vereinfachte Handhabung der Webseitenbestätigung


Um Webmastern zu helfen, bestätigte Inhaber ihrer Webseiten in den Webmaster Tools zu verwalten, haben wie kürzlich drei neue Funktionen eingeführt:
  • Ansicht der Bestätigungsdetails: Ihr könnt nun die verwendete Bestätigungsmethode für Inhaber einsehen. Der Screenshot zeigt die Bestätigungsdetails eines Inhabers, welcher mit HTML-Datei und Meta Tag bestätigt wurde:



    In den Bestätigungsdetails befindet sich ein Link zu der jeweiligen Bestätigungsmethode, welcher hilft die Bestätigung innerhalb der Webseite schnell ausfindig zu machen.

  • Die Bestätigung muss aufgehoben werden bevor ein Inhaber entfernt werden kann: Webmaster-Tools überprüft nun die gewählte Bestätigungsmethode und zeigt eine Fehlermeldung an, sofern die Bestätigung immer noch gefunden wird. Nachfolgend ist eine Fehlermeldung zu sehen, nachdem ein Inhaber entfernt wurde während die Domain-Namen-Anbieter (DNS CNAME) Bestätigungsmethode noch gültig war:

  • Kürzerer CNAME im DNS-Datensatz: Der CNAME als Teil der Domain-Namen-Anbieter Bestätigungsmethode ist nun kürzer, um eine größere Anzahl and DNS-Anbietern unterstützten zu können. Manche Anbieter begrenzen die Anzahl der Zeichen im DNS-Datensatz, so dass manche Benutzer die Domain-Namen-Anbieter Bestätigungsmethode nicht nutzen konnten. Wir haben die benötigte Zeichenanzahl für diese Bestätigungsmethode nun verringert. Bestehende Bestätigungen mit der Domain-Namen-Anbieter Methode bleiben unverändert gültig.
Wir hoffen, dass diese Veränderungen die Arbeit in den Webmaster-Tools vereinfachen. Sofern weitere Fragen bestehen oder ihr uns Rückmeldung geben möchtet, nutzt bitte wie gewohnt unser Webmasterforum.

Post von Pierre Far, Webmaster Trends Analyst (Übersetzung von Johannes Mehlem, Search Quality Team)

Freitag, 22. März 2013 um 11:52

Erstellen von suchmaschinenfreundlichen Mobilwebseiten - nun in mehr als 11 Sprachen


Es ist erfreulich zu sehen, dass mit zunehmenden Webseitenzugriffen von Mobilgeräten viele Webseiten die Inhalte mittlerweile auch entsprechend nutzvoll für Mobilgeräte präsentieren. Um Webmastern zu helfen, ihre Webseiten entsprechend zu optimieren, haben wir im Juni 2012 Empfehlungen für Smartphones, Feature-phones, Tablets und Googlebot-freundliche Seiten veröffentlicht.

Endlich stehen diese nun auch in Arabisch, Portugiesisch (Brasilien), Niederländisch, Französisch, Deutsch, Italienisch, Japanisch, Polnisch, Russisch, Chinesisch (vereinfacht) und Spanisch zur Verfügung. Webmastern aus den USA ist mit der Englischen (UK) Version geholfen.

Wir möchten euch ermutigen die Empfehlungen anzuschauen, eure gewünschte Variante auszuwählen und somit dem Kreis der mobilorientierten Webmaster beizutreten.

Vielen Dank an das fantastische Webmaster-Outreach Team in Dublin, Tokyo und Beijing, welches dies nun ermöglicht hat!

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

Mittwoch, 20. März 2013 um 18:06

Neue Übersicht rund um gehackte Sites


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)

Und falls ihr mehr über Malware erfahren wollt, erklärt Lucas Ballard von unserem Safe-Browsing Team mehr dazu in Schritt 5: Ermittelt den Schaden (gehackt mit Malware).
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)

Montag, 18. März 2013 um 10:13