Webmaster-Zentrale Blog
Offizielle Informationen zum Crawling und zur Indexierung von Webseiten und News für Webmaster
Einführung des Updates für die Mobilgeräte-Optimierung
Dienstag, 21. April 2015
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.
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)
FAQ zum Update für die Mobilgeräte-Optimierung am 21. April
Dienstag, 21. April 2015
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
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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)
Zwei Fallstudien zur Bereinigung von gehackten Websites
Montag, 23. März 2015
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:
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.
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)
Einfachere Website-Entwicklung mit "Web Components" und JSON-LD
Donnerstag, 19. März 2015
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:
In unserem neuesten Artikel unter
html5rocks.com
und in den zugehörigen Codebeispielen
Auf der
JSON-LD-Website
und in den
W3C-Spezifikationen
Im
"Web Components"-Wiki
und in der "Web Components"-Community unter
webcomponents.org
schema.org
In der
Dokumentation für strukturierte Daten
von Google
Post von Ewa Gasperowicz, Developer Programs Engineer, Mano Marks, Developer Advocate, Pierre Far, Webmaster Trends Analyst
(Veröffentlicht von
Johannes Mehlem
, Search Quality)
Schnelleres Ausfüllen von Onlineformularen
Dienstag, 17. März 2015
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 (
v
ollstä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
Aktualisierung der Qualitätsrichtlinien für Brückenseiten
Montag, 16. März 2015
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)
Ressourcenblockierungen mit den Webmaster-Tools aufheben
Mittwoch, 11. März 2015
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
Hilfe
artikel
.
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
#NoHacked
2
2017
1
Accessibility
13
AJAX
1
AMP
7
Android
2
api
1
App-Indexierung
3
Best Practices
99
Bildersuche
2
captcha
1
Chrome
4
Code
12
Crawling
1
Crawling und Indexierung
126
Diskussionsforum
15
Duplicate Content
17
Dynamic Rendering
1
Einsteiger
8
Event
1
events
1
Feedback
1
Geo-Targeting
11
Google Analytics
6
Google Dance
1
Google News
1
Google Places
4
Google-Assistant
1
Google-Suche
59
Google+
9
Hacking
16
Hangouts
1
https
3
JavaScript
3
Kanonische URL
1
Kommentare
1
Konferenz
19
Lighthouse
3
Links
18
Malware
17
Mobile
38
Mobile-first indexing
1
Nachrichten-Center
16
Optimisation
3
PageSpeed Insights
2
Penalties
1
Performance
3
Ranking
1
reCaptcha v3
1
Rendering
2
Rich Snippets
18
Richtlinien für Webmaster
36
robots.txt
7
Safe Browsing
5
Search Console
19
Search Results
1
Security
4
Seitenzugriff
1
SEO
4
Sicherheit
38
Site Clinic
5
Sitemaps
30
Spam Report
9
SSL
1
Structured Data
8
Tools und Gadgets
17
Verschlüsselung
1
Video
132
Webmaster blog
1
Webmaster Community
1
Webmaster-Academy
1
Webmaster-Tools
154
webspam
3
Archiv
2020
Nov.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
2019
Dez.
Nov.
Okt.
Sept.
Juni
Mai
Feb.
Jan.
2018
Dez.
Nov.
Okt.
Sept.
Juli
Juni
Mai
Apr.
Feb.
Jan.
2017
Dez.
Nov.
Juni
Apr.
März
Jan.
2016
Nov.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Jan.
2015
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Mai
Apr.
März
Feb.
Jan.
2014
Nov.
Okt.
Sept.
Aug.
Juni
Mai
Apr.
März
Feb.
Jan.
2013
Dez.
Nov.
Okt.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2012
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2011
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2010
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2009
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2008
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feb.
Jan.
2007
Dez.
Nov.
Okt.
Sept.
Aug.
Juli
Juni
Mai
Apr.
März
Feed
Forum für Webmaster
Webmaster-Sprechstunden
Webmaster-Tools-Hilfe
Developers-Site für Webmaster