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 Google, Microsoft 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)

Labels: , ,

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)

Labels:

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
Labels: , ,

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)

Labels:

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)
Labels: ,