Posted:
Wie bereits Anfang des Jahres angekündigt beginnen wir heute mit der weltweiten Einführung unseres Updates für die Mobilgeräte-Optimierung. Im Zuge dieser Einführung verbessern wir das Ranking von für Mobilgeräte optimierten Seiten in den Ergebnissen der mobilen Suche.
Nutzer können jetzt noch einfacher qualitativ hochwertige und relevante Ergebnisse finden, wo die Texte ohne viel Aufwand direkt lesbar sind, die Tippziele genügend Abstand bieten und die Seiten nicht anzeigbare/abspielbare Inhalte und horizontales Scrolling vermeiden.

Screen Shot 2015-04-07 at 2.20.01 AM.png
Das Update rund um Mobilfreundlichkeit vom 21. April hilft dabei, dass Seiten, die auf Mobilgeräten gut lesbar und nutzbar sind, besser in den Ergebnissen der mobilen Suche gefunden werden können.



Dieses Update:
  • wirkt sich nur auf das Ranking in Suchergebnissen auf Mobilgeräten (Smartphones) aus,
  • betrifft Suchergebnisse in allen Sprachen weltweit,
  • gilt für einzelne Seiten, nicht für ganze Websites 
Das Update rund um Mobilfreundlichkeit ist zwar eine wichtige Änderung - wir verwenden jedoch weiterhin eine Anzahl verschiedener Signale in den Suchergebnissen. Der Zweck einer Suchanfrage ist dabei immer noch ein sehr starkes Signal: Selbst wenn eine Seite mit qualitativ hochwertigen Inhalten noch nicht mobilfreundlich ist, kann sie weiterhin gut ranken, wenn sie relevante Inhalte zur jeweiligen Suchanfrage bietet.


Um zu überprüfen, ob eure Website für Mobilgeräte optimiert ist, könnt ihr die einzelnen Seiten mit dem Test auf Optimierung für Mobilgeräte prüfen oder den Status eurer gesamten Website anhand des Berichts "Nutzerfreundlichkeit auf Mobilgeräten" in den Webmaster-Tools ermitteln. Falls die Seiten eurer Website nicht für Mobilgeräte optimiert sind, können die Zugriffe über Google von Mobilgeräten aus erheblich abnehmen. Aber keine Sorge: Sobald eure Website für Mobilgeräte optimiert ist, werden eure Seiten automatisch erneut verarbeitet, also gecrawlt und indexiert.  Ihr könnt diesen Vorgang auch beschleunigen, indem ihr "Abruf wie durch Google" mit der Option "An Index senden" verwendet. Eure Seiten können dann beim Ranking als für Mobilgeräte optimiert betrachtet werden.
Noch Fragen? Schaut euch unser FAQ an oder besucht unser Forum für Webmaster.

Post von Takaki Makino und Doantam Phan
(Veröffentlicht von Sven Naumann, Search Quality Team)

Posted:

Wir möchten euch hier einige häufig gestellte Fragen zum Update rund um Mobilgeräte beantworten. Zur Erinnerung: Im Februar haben wir angekündigt, dass mit diesem Update das Ranking von für Mobilgeräte optimierten Seiten ‒ also Seiten, die auf Mobilgeräten lesbar und gut nutzbar sind ‒ in den Ergebnissen der mobilen Suche weltweit verbessert wird. (Umgekehrt kann sich das Ranking von Seiten, die nur für große Bildschirme konzipiert sind, in den Ergebnissen der mobilen Suche deutlich verschlechtern.) Damit alle auf dem neuesten Stand sind, findet ihr hier die häufigsten Fragen:

Allgemeine Fragen

  1. Betrifft diese Änderung auch das Ranking auf Desktopcomputern bzw. Tablets?

    Nein, dieses Update hat keine Auswirkungen auf die Suche mit Tablets oder Desktopcomputern. Betroffen ist die Suche mit Mobilgeräten (Smartphones) in allen Sprachen weltweit.

  2. Handelt es sich um eine Änderung auf Seitenebene oder auf Websiteebene?

    Es handelt sich um eine Änderung auf Seitenebene. Wenn beispielsweise zehn Seiten eurer Website für Mobilgeräte optimiert sind, aber die restlichen Seiten nicht, kann nur bei den zehn optimierten Seiten ein positiver Effekt auftreten.

  3. Woher weiß ich, ob Google eine Seite meiner Website als "für Mobilgeräte optimiert" ansieht?

    Einzelne Seiten können mit dem Test auf Optimierung für Mobilgeräte getestet werden.


    Einzelne URLs mit dem Test auf Optimierung für Mobilgeräte in Echtzeit testen

    Informationen zur Optimierung für Mobilgeräte auf Websiteebene erhaltet ihr im Bericht über die Nutzererfahrung auf Mobilgeräten in den Webmaster-Tools. Die Angaben darin basieren auf dem Stand des letzten Crawlens und Indexierens eurer Webseiten.



    Der Bericht über die Nutzererfahrung auf Mobilgeräten bietet einen Überblick über die Mobilgeräte-Optimierung der gesamten Website.

  4. Leider werden meine für Mobilgeräte optimierten Seiten erst nach dem 21. April fertig sein. Wie lange dauert es, bis die Mobilgeräte-Optimierung im Ranking berücksichtigt wird?

    Wir prüfen die Optimierung für Mobilgeräte einer Seite jedes Mal, wenn sie gecrawlt und indexiert wird. Ihr braucht also nicht auf ein weiteres Update zu warten. Sobald eure Seite für Mobilgeräte optimiert ist, könnt ihr einfach warten, bis der Googlebot für Smartphones die Seite automatisch crawlt und indexiert. Ihr könnt den Vorgang aber auch beschleunigen, indem ihr die Funktion "An den Index senden" im Tool "Abruf wie durch Google" verwendet. Dieses Tool findet ihr in den Webmaster-Tools. Bei einer großen Anzahl an URLs ist es sinnvoll, eine Sitemap einzureichen. Wenn ihr in euren mobilen Inhalten bestehende URLs verwendet (z. B. beim Responsive Webdesign oder der dynamischen Bereitstellung), fügt auch das lastmod-Tag in die Sitemap ein.


  5. Das Update wird ja zum 21. April eingeführt. Wenn ich dann am 22. April keine Veränderung des Traffics bemerke, bedeutet dies, dass das Ranking meiner Website nicht beeinflusst wurde?

    Am 22. April könnt ihr noch nicht mit Sicherheit feststellen, ob sich das Update zur Optimierung für Mobilgeräte auf das Ranking eurer Website ausgewirkt hat. Wir beginnen zwar am 21. April mit der Einführung des Updates, aber es wird bestimmt mindestens eine Woche dauern, bis alle Seiten im Index durchlaufen wurden.


  6. Ich habe eine tolle mobile Website, aber der Test auf Optimierung für Mobilgeräte ergibt, dass meine Seiten nicht für Mobilgeräte optimiert sind. Warum?

    Wenn eine Seite für die Nutzung auf Mobilgeräten konzipiert wurde, aber den Test auf Optimierung für Mobilgeräte nicht besteht, liegt dies meistens daran, dass der Googlebot für Smartphones wichtige Ressourcen wie CSS und JavaScript nicht crawlen kann. Anhand dieser Ressourcen wird ermittelt, ob die Seite auf einem Mobilgerät lesbar und verwendbar und somit für Mobilgeräte optimiert ist. Dieses Problem könnt ihr folgendermaßen lösen:

    1) Überprüft, ob im Test auf Optimierung für Mobilgeräte blockierte Ressourcen angegeben sind (oft in Verbindung mit nur teilweise gerenderten Bildern).
    2) Erlaubt dem Googlebot das Crawlen der erforderlichen Dateien.
    3)Prüft erneut, ob eure Seite den Test auf Optimierung für Mobilgeräte besteht.
    Verwendet die Funktion "An den Index senden" im Tool "Abruf wie durch Google", und übermittelt eure aktualisierte robots.txt-Datei um das erneute Verarbeiten der aktualisierten Seite zu beschleunigen. Ihr könnt auch einfach warten, bis eure Seite automatisch erneut gecrawlt und indexiert wird.



    Wenn eine mobile Seite den Test auf Optimierung für Mobilgeräte nicht besteht, liegt dies meistens daran, dass der Googlebot für Smartphones wichtige Ressourcen wie CSS und JavaScript nicht crawlen kann, anhand derer die Optimierung für Mobilgeräte ermittelt wird.

    Wir empfehlen Websiteinhabern immer,  Googlebot das Crawlen aller Ressourcen einer Seite zu ermöglichen, einschließlich CSS, JavaScript und Bildern. Nur so können wir die Seite richtig rendern, indexieren und wie in diesem Fall ermitteln, ob sie für Mobilgeräte optimiert ist.


  7. Was ist, wenn ich zu einer Website verlinke, die nicht für Mobilgeräte optimiert ist?

    Eure Seite kann auch dann als "für Mobilgeräte optimiert" gelten, wenn sie zu einer nicht für Mobilgeräte optimierten Seite verlinkt, die beispielsweise für größere Bildschirme auf Desktopgeräten konzipiert ist. Von einer für Mobilgeräte optimierten Seite zu einer Seite nur für Desktopgeräte zu wechseln, bietet zwar nicht die beste Nutzererfahrung, aber da hoffentlich immer mehr Seiten für Mobilgeräte optimiert werden, sollte dies mit der Zeit seltener vorkommen.


  8. Vergibt Google ein besseres mobilgeräteoptimiertes Ranking an Seiten, die Responsive Webdesign verwenden (bei dem dieselbe URL und HTML für die Desktopversion und die mobile Version verwendet werden), im Gegensatz zu separat gehosteten mobilen Websites (z. B. www für die Desktopversion und m.example.com für die mobile Version)?

    Nein, die Optimierung für Mobilgeräte wird genau gleich beurteilt, egal ob ihr Responsive Webdesign (RWD), separate mobile URLs oder die dynamische Bereitstellung für eure Konfiguration verwendet. Wenn ihr für eure Website separate mobile URLs oder die dynamische Bereitstellung verwendet, empfehlen wir euch, mithilfe des Leitfadens für Mobilgeräte sicherzustellen, dass eure mobilen Seiten richtig von Google gecrawlt und indexiert werden.


  9. Werden meine Seiten oder die Website aus den Ergebnissen der mobilen Suche herausfallen, wenn sie nicht mobilfreundlich sind?

    Das Update rund um Mobilfreundlichkeit ist zwar eine wichtige Änderung - wir verwenden jedoch weiterhin eine Anzahl verschiedener Signale in den Suchergebnissen. Der Zweck einer Suchanfrage ist dabei immer noch ein sehr starkes Signal: Selbst wenn eine Seite mit qualitativ hochwertigen Inhalten noch nicht mobilfreundlich ist, kann sie weiterhin gut ranken, wenn sie relevante Inhalte zur jeweiligen Suchanfrage bietet.


    Spezifische Fragen
  10. Was ist, wenn meine Besucher nur mit Desktopcomputern auf meine Seiten zugreifen? Dann brauche ich eigentlich keine mobile Website, oder?

    Das stimmt nicht ganz. Statistiken zeigen, dass immer mehr Menschen nur noch Mobilgeräte verwenden, weil sie entweder nie ein Desktopgerät hatten oder ihre vorhandenen Desktopgeräte nicht mehr ersetzen. Außerdem verzeichnet eine Website, die nicht für Mobilgeräte optimiert ist, vielleicht genau deshalb nur wenige mobile Besucher.

    Das Update zur Optimierung für Mobilgeräte betrifft die mobile Suche für alle Websites, unabhängig von deren Zielgruppe, Sprache und Region oder dem Verhältnis zwischen Traffic von Mobilgeräten und Desktopcomputern.


  11. Ich erhalte bei einigen Seiten einen Fehler zur Nutzererfahrung auf Mobilgeräten, weil auf den Seiten ein YouTube-Video eingebettet ist. Was kann ich tun?

    Achtet bitte genau darauf, wie ihr YouTube-Videos einbettet. Wenn ihr noch die "Old School"-Variante mit <object>-Einbettungen auf der mobilen Seite verwendet, solltet ihr für eine umfassendere Kompatibilität zu <iframe>-Einbettungen wechseln. YouTube verwendet jetzt standardmäßig den HTML5-Player im Web. Ihr könnt also Videos mit den <iframe>-Tags über die Funktion "Teilen" auf der Wiedergabeseite oder über die YouTube iFrame API so einbetten, dass sie für Mobilgeräte optimiert sind. Wenn ihr über eine komplexere Integration verfügt, sollte diese für Mobilgeräte optimiert sein, da sie das Gerät anweist, die  systemeigene Unterstützung zu verwenden.

    Überprüft bei Flash-Inhalten von anderen Websites als YouTube, ob es ein entsprechendes HTML5-Tag zur Einbettung oder ein Code-Snippet gibt, damit ihr kein zugehöriges Plug-in verwenden müsst.


  12. Gibt es einen genauen Standard für die Größe von Tippzielen?

    Ja. Wir empfehlen, dass primäre Tippziele mindestens 7 mm hoch bzw. breit sind und sekundäre Tippziele einen Mindestabstand von 5 mm aufweisen. Die Fingerspitzen eines Erwachsenen sind durchschnittlich etwa 10 mm breit. Mit diesen Abmessungen erhaltet ihr darum eine nutzerfreundliche Oberfläche und setzt gleichzeitig den verfügbaren Platz gut ein.


  13. Wir denken darüber nach, zur schnellen Optimierung für Mobilgeräte eine abgespeckte Version unserer Website mit separaten mobilen Seiten zu erstellen, bis unsere neue responsive Website fertig ist. Könnte es damit Probleme geben?

    Beachtet zunächst, dass wir drei mobile Konfigurationen unterstützen und eure Website nicht notwendiger Weise responsive sein muss, um für Mobilgeräte optimiert zu sein. Was die Frage angeht: Bitte seid beim Erstellen einer "abgespeckten" Version eurer Website vorsichtig. Die Seite mag zwar für Mobilgeräte formatiert sein, aber wenn eure Besucher gängige Aktionen nicht problemlos durchführen können oder die Seite insgesamt nicht reibungslos funktioniert, kann dies für eure Besucher frustrierend und den Aufwand nicht wert sein. Falls ihr eine temporäre mobile Website erstellt, achtet darauf, die Website ordnungsgemäß umzuziehen, sobald die RWD-Version fertig ist. Ihr müsst dann beispielsweise alle Links aktualisieren, sodass sie nicht mehr auf die separaten mobilen URLs verweisen, und mit einer 301-Weiterleitung mobile URLs an die entsprechende RWD-Version weiterleiten.

Empfehlungen

Wenn ihr eure Website noch gar nicht für Mobilgeräte optimiert habt, ist es noch nicht zu spät. Informiert euch jetzt über die ersten Schritte im Leitfaden zur Optimierung von Websites für Mobilgeräte.


Website-Optimierung für Mobilgeräte unter https://developers.google.com/webmasters/mobile-sites/

Wenn ihr schon eine mobile Website habt, könnt ihr mithilfe des Berichts über die Nutzererfahrung auf Mobilgeräten in den Webmaster-Tools sicherstellen, dass eure Webseiten von Google als "für Mobilgeräte optimiert" angesehen werden.

Noch Fragen? Dann postet sie unten oder besucht den Bereich "Mobile Websites" im Webmasterforum.

Post von Maile Ohye, Developer Programs Tech Lead
(Veröffentlicht von Sven Naumann, Search Quality Team)

Posted:
Tag für Tag werden Tausende von Websites gehackt. Gehackte Websites können Nutzern Schaden zufügen, indem sie beispielsweise Schadsoftware verbreiten, personenbezogene Daten sammeln oder die Nutzer ohne deren Wissen auf andere Websites weiterleiten. Daher möchten Webmaster gehackte Websites auch schnell bereinigen, doch kann die Beseitigung der durch einen Hack verursachten Schäden ein komplizierter Prozess sein.

Wir versuchen, Webmastern die Wiederherstellung nach einem Hack mit Funktionen wie Sicherheitsprobleme, der Hilfe für Webmaster bei gehackten Websites und einem Bereich in unserem Forum nur für gehackte Websites zu erleichtern. Vor Kurzem sprachen wir mit zwei Webmastern, deren Websites gehackt wurden, um mehr darüber zu erfahren, wie sie ihre Websites bereinigen konnten. Wir stellen ihre Geschichten hier in der Hoffnung vor, dass sie anderen Webmastern, die Hackerangriffen zum Opfer gefallen sind, einige hilfreiche Anstöße geben können. Außerdem möchten wir mit diesen Geschichten und weiterem Feedback unsere Dokumentation für gehackte Websites verbessern, um deren Bereinigung künftig für alle einfacher zu gestalten.


Fallstudie 1: Website eines Restaurants mit mehreren bei Hacks injizierten Skripts

Für eine mit WordPress erstellte Restaurantwebsite ging im Webmaster-Tools-Konto des Restaurants eine Nachricht von Google mit der Warnung ein, dass die Website von Hackern verändert wurde. Zum Schutz von Google-Nutzern wurde die Website in den Suchergebnissen von Google als gehackt gekennzeichnet. Sam, die Webmasterin der Website, sah sich den Quellcode an und bemerkte auf der Website zahlreiche ungewöhnliche Links mit pharmazeutischen Begriffen wie "Viagra" und "Cialis". Ihr fielen zudem viele Seiten auf, auf denen die Meta-Beschreibungstags im HTML-Code zusätzliche Inhalte wie "Valtrex in Florida kaufen" aufwiesen. Außerdem enthielten viele Seiten – ebenfalls im HTML-Code – versteckte div-Tags mit Verlinkungen zu zahlreichen Websites. Keinen dieser Links hatte Sam hinzugefügt.

Sam entfernte sämtliche gehackten Inhalte, die sie fand, und reichte danach einen Antrag auf erneute Überprüfung ein. Der Antrag wurde zwar abgelehnt, aber in der Nachricht, die sie von Google erhielt, wurde ihr geraten, nach unbekannten Skripts in den PHP-Dateien bzw. anderen Serverdateien sowie nach Änderungen an der ".htaccess"-Datei zu suchen. Diese Dateien enthalten oftmals von Hackern hinzugefügte Skripts zur Veränderung der Website. Bei diesen Skripts sind die gehackten Inhalte in der Regel nur für Suchmaschinen erkennbar. Für normale Nutzer hingegen bleiben sie verborgen. Sam prüfte alle PHP-Dateien und verglich sie mit den unkompromittierten Kopien in ihrer Sicherung. Datei stellte sie fest, dass den Dateien "footer.php", "index.php" und "functions.php" neue Inhalte hinzugefügt worden waren. Nachdem sie diese Dateien durch die sauberen Sicherungen ersetzt hatte, konnte sie auf ihrer Website keine gehackten Inhalte mehr finden. Sie stellte daraufhin einen weiteren Antrag auf erneute Überprüfung und erhielt von Google tatsächlich die Antwort, dass die Website frei von gehackten Inhalten war.

Doch obwohl Sam die gehackten Inhalte auf ihrer Website bereinigt hatte, wusste sie, dass sie die Website weiterhin gegen künftige Angriffe sichern musste. Sie folgte diesen Schritten, um auch in Zukunft die Sicherheit ihrer Website zu gewährleisten:
  • Das CMS (Content-Management-System), z. B. WordPress, Joomla oder Drupal, mit der jeweils neuesten Version auf dem aktuellen Stand halten und sicherstellen, dass auch die Plug-ins aktuell sind
  • Darauf achten, dass für das Konto, über das auf die administrativen Funktionen des CMS zugegriffen wird, ein schwer zu erratendes und einzigartiges Passwort verwendet wird
  • Für die Anmeldung die Bestätigung in zwei Schritten aktivieren, falls das CMS dies unterstützt. Dieser Vorgang wird auch Zwei-Faktor-Authentifizierung oder Authentifizierung in zwei Schritten genannt. Dasselbe Verfahren wird auch für das Konto empfohlen, das für die Passwortwiederherstellung verwendet wird. Die meisten E-Mail-Anbieter wie GoogleMicrosoft oder Yahoo unterstützen dieses Verfahren.
  • Sicherstellen, dass die installierten Plug-ins und Designs von einer vertrauenswürdigen Quelle stammen – raubkopierte Plug-ins oder Designs enthalten oft Code, der Hackern das Eindringen noch leichter macht!

Fallstudie 2: Professionelle Website mit vielen schwer zu findenden gehackten Seiten

Die Inhaberin eines kleinen Geschäfts, Maria, die auch ihre eigene Website verwaltet, erhielt in ihren Webmaster-Tools eine Nachricht, dass ihre Website gehackt wurde. Die Nachricht enthielt ein Beispiel einer von Hackern hinzugefügten Seite: http://example.com/where-to-buy-cialis-over-the-counter/. Sie sprach mit ihrem Hostanbieter, der sich den Quellcode auf der Homepage ansah, aber keine pharmazeutischen Keywords finden konnte. Als ihr Hostanbieter die Website unter http://example.com/where-to-buy-cialis-over-the-counter/ aufrief, wurde eine Fehlerseite zurückgegeben. Maria erwarb zudem einen Malware-Scandienst, der auf ihrer Website jedoch keine schädlichen Inhalte ermitteln konnte.

Daraufhin rief Maria die Webmaster-Tools auf und wandte das Tool "Abruf wie durch Google" auf die von Google bereitgestellte Beispiel-URL http://example.com/where-to-buy-cialis-over-the-counter/ an. Es wurden keine Inhalte zurückgegeben. Verwirrt stellte sie einen Antrag auf erneute Überprüfung und erhielt eine Ablehnung. Darin wurde ihr geraten, zwei Dinge zu tun:
  1. Die Version ihrer Website ohne "www" zu prüfen, weil Hacker häufig versuchen, Inhalte in Ordnern zu verbergen, die vom Webmaster möglicherweise übersehen werden
Auch wenn es so scheint, dass hinter http://example.com und http://www.example.com dieselbe Website steht, behandelt Google sie als verschiedene Websites. http://example.com wird als "Root-Domain" bezeichnet, http://www.example.com hingegen als Subdomain. Maria hatte http://www.example.com, jedoch nicht http://example.com überprüft. Das ist wichtig, weil es sich bei den von Hackern hinzugefügten Seiten um Seiten ohne "www" wie http://example.com/where-to-buy-cialis-over-the-counter/ handelte. Nachdem sie http://example.com überprüft hatte, konnte sie die gehackten Inhalte in den Webmaster-Tools unter der bereitgestellten URL mit "Abruf wie durch Google" sehen.
  1. Die ".htaccess"-Datei auf neue Regeln zu prüfen
Maria sprach mit ihrem Hostanbieter, der ihr zeigte, wie sie auf die ".htaccess"-Datei zugreifen konnte. Sie bemerkte sofort, dass die ".htaccess"-Datei seltsame Inhalte aufwies, die sie nicht hinzugefügt hatte:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (google|yahoo|msn|aol|bing) [OR]
RewriteCond %{HTTP_REFERER} (google|yahoo|msn|aol|bing)
RewriteRule ^([^/]*)/$ /main.php?p=$1 [L]
</IfModule>

Der Hacker hatte die mod_rewrite-Regel eingefügt, die ihr oben seht. Durch sie werden alle Nutzer, die über bestimmte Suchmaschinen und Suchmaschinen-Crawler auf die Website gelangen, an die Datei "main.php" weitergeleitet, von der sämtliche gehackten Inhalte generiert werden. Solche Regeln können auch Nutzer weiterleiten, die die Website auf einem Mobilgerät aufrufen. Am selben Tag konnte sie dann auch beobachten, dass bei einem neuen Malware-Scan verdächtige Inhalte in der Datei "main.php" gefunden wurden. Noch dazu bemerkte sie im FTP-Nutzerbereich ihrer Website-Entwicklungssoftware einen unbekannten Nutzer.
Sie entfernte die Datei "main.php", die ".htaccess"-Datei und den unbekannten Nutzer aus dem FTP-Nutzerbereich – und schon war ihre Website nicht mehr gehackt.
Schritte zur Vermeidung künftiger Hacks
  • Verwendet möglichst kein FTP für die Übertragung von Dateien auf eure Server. FTP verschlüsselt Traffic nicht, also auch keine Passwörter. Verwendet stattdessen SFTP, denn zum Schutz gegen Eindringlinge, die den Netzwerk-Traffic ausspähen, verschlüsselt SFTP alles, einschließlich eures Passworts.
  • Prüft die Berechtigungen für sensible Dateien wie ".htaccess"-Dateien. Bei Bedarf kann euch eventuell euer Hostanbieter helfen. Mit der ".htaccess"-Datei könnt ihr eure Website verbessern und schützen, doch sie kann auch für bösartige Hacks genutzt werden, wenn es jemandem gelingt, auf sie zuzugreifen.
  • Seid wachsam und achtet auf neue und unbekannte Nutzer im Administrationsbereich oder an anderen Orten, an denen sich möglicherweise Nutzer befinden, die eure Website manipulieren können.
Wir hoffen, dass eure Website niemals gehackt wird. Falls doch, haben wir in unserer Hilfe für Webmaster bei gehackten Websites zahlreiche Ressourcen für gehackte Webmaster zusammengestellt. Wenn ihr weitere Hilfe benötigt oder eure eigenen Tipps teilen möchtet, könnt ihr in unserem Forum für Webmaster posten. Falls ihr im Forum Beiträge postet oder für eure Website einen Antrag auf erneute Überprüfung einreicht, gebt darin bitte das #NoHacked-Tag an.

Post von Julian Prentice und Yuan Niu, Search Quality Team
(Veröffentlicht von Johannes Mehlem, Search Quality Team)

Posted:
JSON-LD ist ein JSON-basiertes Datenformat zur Implementierung strukturierter Daten, die Inhalte auf eurer Website für Google und andere Suchmaschinen besser verständlich machen. Wenn ihr zum Beispiel eine Liste von Ereignissen, Cafés, Personen usw. habt, könnt ihr diese Daten strukturiert mithilfe des in Webseiten eingebetteten schema.org-Vokabulars  als JSON-LD-Snippet auf euren Seiten einfügen. Anhand der strukturierten Daten kann Google eure Seiten besser verstehen und eure Inhalte in Suchfunktionen wie zum Beispiel Ereignisse im Knowledge Graph und Rich Snippets hervorheben.

"Web Components" sind eine neuartige Technologie zur Definition von individuellen, wiederverwendbaren Widgets für Benutzeroberflächen und deren Verhalten. Jeder Webentwickler kann eine "Web Component" erstellen. Zunächst definiert ihr eine Vorlage für einen bestimmten Teil der Benutzeroberfläche, die ihr in die Seiten importiert, auf denen die "Web Component" verwendet werden soll. Mit einem "Custom Element" wird das Verhalten der "Web Component" definiert. Da ihr die Anzeige und Logik für einen Teil der Benutzeroberfläche in der "Web Component" bündelt, könnt ihr das Paket auf anderen Seiten und mit anderen Entwicklern wiederverwenden und so die Webentwicklung vereinfachen.

JSON-LD und "Web Components" sind eine wirklich gute Kombination. Das "Custom Element" fungiert als Präsentationsebene und die JSON-LD fungiert als Datenschicht, die vom "Custom Element" und den Suchmaschinen genutzt wird. Demzufolge könnt ihr "Custom Elements" fürjeden schema.org-Typ erstellen, beispielsweise für schema.org/Event und schema.org/LocalBusiness.
Eure Architektur würde dann so aussehen: Eure strukturierten Daten sind in eurer Datenbank gespeichert, zum Beispiel die Standorte eurer Niederlassungen in eurer Kette. Diese Daten sind als JSON-LD-Snippet in eurer Webseite eingebettet, sodass sie vom "Custom Element" zur Anzeige für "echte" Besucher und vom Googlebot zum Abruf für die Google-Indexierung genutzt werden können.

Weitere Informationen zu "Custom Elements" und deren Erstellung findet ihr hier:

Post von Ewa Gasperowicz, Developer Programs Engineer, Mano Marks, Developer Advocate, Pierre Far, Webmaster Trends Analyst
(Veröffentlicht von Johannes Mehlem, Search Quality)

Posted:
Viele Websites setzen Formulare ein, um wichtige Ziele zu erreichen, wie etwa den Abschluss einer Transaktion auf einer Shoppingwebsite oder die Registrierung auf einer Nachrichtenwebsite. Für viele Nutzer sind Onlineformulare gleichbedeutend mit dem wiederholten Eingeben allgemeiner Informationen wie Name, E-Mail-Adresse, Telefonnummer oder Adresse auf verschiedenen Websites im Web. Diese nicht nur lästige, sondern auch fehleranfällige Pflichtübung kann viele dazu veranlassen, den Vorgang ganz abzubrechen. Da immer mehr Nutzer mit Mobilgeräten statt mit Laptops oder Desktopgeräten im Internet surfen, sind einfach und schnell auszufüllende Formulare unerlässlich. Seit drei Jahren gibt es das Attribut "autocomplete" für die automatische Vervollständigung in Chrome. Mit diesem Attribut können Formulare schneller, einfacher und intelligenter ausgefüllt werden. Chrome unterstützt ab sofort das Attribut "autocomplete" für Formularfelder gemäß dem aktuellen WHATWG-HTML-Standard. Webmaster und Webentwickler können Eingabeelementfelder mit allgemeinen Datentypen wie "name" oder "street-address" kennzeichnen, ohne Änderungen an der Benutzeroberfläche oder am Back-End vorzunehmen. Zahlreiche Webmaster konnten die Formularausfüllquote auf ihren Websites steigern, indem sie ihre Formulare für die automatische Vervollständigung auszeichneten.

Die Auszeichnung eines E-Mail-Adressfelds in einem Formular für die automatische Vervollständigung würde beispielsweise folgendermaßen aussehen (vollständiges Beispielformular):

 <input type="email" name="customerEmail" autocomplete="email"/>



Es ist sehr wichtig, Websites für die Anzeige und Nutzung auf Mobilgeräten zu optimieren. Wir hoffen, dass zukünftig viele Formulare mit dem "autocomplete"-Attribut ausgezeichnet werden. Weitere Informationen findet ihr in unseren Spezifikationen zum Hinzufügen von Labels und Benennen von Eingaben in den Web Fundamentals. Bei Fragen könnt ihr wie immer einen Beitrag in unseren Hilfeforen für Webmaster posten.

Post von Mathieu Perreault, Chrome Software Engineer, und Zineb Ait Bahajji, Webmaster Trends Analyst (Veröffentlicht von Johannes Mehlem, Search Quality)

*Dieser Post ist ein Update zu dem folgenden Post: http://googlewebmastercentral-de.blogspot.com/2012/02/formulare-ausfullen-schneller-einfacher.html

Posted:
Das Google Search Quality Team entwickelt kontinuierlich neue Methoden zur Bekämpfung von Webspam. Dies betrifft auch Brückenseiten.

Wir sind seit Langem der Ansicht, dass Brückenseiten, die ausschließlich für Suchmaschinen erstellt wurden, die Qualität der Sucherfahrung beeinträchtigen können.

Zum Beispiel wird Nutzern unter Umständen eine Liste von Suchergebnissen angezeigt, die alle auf dieselbe Website führen. Wenn ein Nutzer auf ein Ergebnis klickt, die Website wieder schließt, weil sie nicht die gewünschten Informationen enthält, das nächste Suchergebnis probiert und auf genau derselben Website landet, ist das eine wirklich frustrierende Erfahrung.

Websites versuchen zunehmend, ihren "Fußabdruck in der Suche" zu maximieren, ohne einen eindeutigen Mehrwert hinzuzufügen. Brückenseiten treten als Seiten auf einer Website, in Form mehrerer Domains oder als Kombination von beidem in Erscheinung. Um die Qualität der Suchergebnisse für unsere Nutzer zu verbessern, werden wir in Kürze eine Rankinganpassung im Hinblick auf Seiten dieser Art vornehmen. Für Websites mit einem groß angelegten und etablierten Einsatz von Brückenseiten könnte diese Änderung weitreichende Folgen haben.

Um unsere Richtlinien noch verständlicher für Webmaster zu machen, haben wir in unseren Qualitätsrichtlinien erläuternde Beispiele hinzugefügt und unsere Definition von Brückenseiten überarbeitet.

Stellt euch bei Seiten, die als Brückenseiten angesehen werden könnten, folgende Fragen:
  • Dienen sie der Optimierung für Suchmaschinen und dazu, Besucher auf den tatsächlich nutzbaren oder relevanten Teil eurer Website zu leiten, oder sind sie ein wesentlicher Bestandteil der Nutzererfahrung eurer Website?
  • Sollen die Seiten einen Rang für allgemeine Suchbegriffe erhalten, obwohl die Inhalte auf der Seite sehr spezifisch sind?
  • Duplizieren die Seiten nützliche Zusammenfassungen von bereits auf der Website zu findenden Elementen wie Orte oder Produkte, um die Zugriffe über die Suche zu steigern?
  • Wurden diese Seiten einzig und allein erstellt, um die Zugriffe über Partnerwebsites zu steigern und Nutzer weiterzuleiten, ohne einen sichtbaren Mehrwert in Bezug auf Inhalte oder Funktionen zu schaffen?
  • Führen diese Seiten ein "Inseldasein"? Ist es schwierig oder unmöglich, von anderen Teilen eurer Website zu ihnen zu gelangen? Werden Links auf solche Seiten von anderen Seiten der Website oder des Website-Netzwerks nur für Suchmaschinen erstellt?
Wenn ihr Fragen oder Feedback zu Brückenseiten habt, besucht die Foren der Webmaster-Zentrale.

Post von Brian White, Google Webspam Team
(Veröffentlicht von Johannes Mehlem, Search Quality Team)

Posted:
Webmaster verwenden auf Webseiten häufig verlinkte Bilder sowie CSS- und JavaScript-Dateien, um sie ansprechender zu gestalten und mehr Funktionen bereitzustellen. Wenn das Crawlen dieser Ressourcen unterbunden wird, kann der Googlebot sie beim Rendern dieser Seiten für die Suche nicht verwenden. Die Google Webmaster-Tools bieten jetzt einen Bericht über blockierte Ressourcen, mit dessen Hilfe ihr solche Probleme identifizieren und lösen könnt.



Am Anfang dieses Berichts stehen die Namen der Hosts der auf eurer Website verwendeten blockierten Ressourcen, beispielsweise JavaScript- oder CSS-Dateien und Bilder. Wenn ihr auf die Zeilen klickt, seht ihr die Liste der blockierten Ressourcen und danach die Seiten, auf denen sie eingebettet sind. Dabei werdet ihr durch die Schritte geführt, mit denen ihr eine Diagnose ausführen und sicherstellen könnt, dass wir den Seiteninhalt crawlen und indexieren können.
Im aktualisierten Abschnitt Abrufen und rendern könnt ihr nachlesen, inwiefern diese blockierten Ressourcen wichtig sind. Wenn ihr das Abrufen und Rendern einer URL anfordert, seht ihr jetzt Screenshots, die zeigen, wie die Seite für den Googlebot und für einen regulären Nutzer dargestellt wird. So könnt ihr die Probleme leichter erkennen, die bewirken, dass eure Seiten für den Googlebot anders aussehen.

Die Webmaster-Tools versuchen, euch nur die Hosts zu zeigen, bei denen ihr eventuell auch Einflussmöglichkeiten habt. Daher seht ihr in dem Bericht momentan keine Hosts, die von vielen verschiedenen Websites verwendet werden, wie beispielsweise beliebte Analysedienste. Da es aus bestimmten Gründen, die in der Regel nicht mit der Technik zusammenhängen, zeitaufwendig sein kann, alle robots.txt-Dateien zu aktualisieren, empfehlen wir euch, mit den Ressourcen anzufangen, die die größten optischen Unterschiede bewirken, wenn sie blockiert sind. Weitere Informationen zu den notwendigen Schritten findet ihr in unserem Hilfeartikel.

Wir hoffen, dass diese neue Funktion euch das Identifizieren von auf eurer Website verwendeten blockierten Ressourcen und das Aufheben der Blockierung erleichtert! Fragen könnte ihr gerne in unseren Hilfeforen für Webmaster posten.

Post von John Mueller, Webmaster Trends Analyst, Google Schweiz
(Veröffentlicht von Johannes Mehlem, Search Quality Team)