Webmaster-Zentrale Blog
Offizielle Informationen zum Crawling und zur Indexierung von Webseiten und News für Webmaster
#NoHacked: Kein Ziel von Hackern werden
Montag, 27. Juli 2015
Wenn ihr irgendetwas online veröffentlicht, sollte Sicherheit eine eurer obersten Prioritäten sein. Hacking-Angriffe können nicht nur eurem Online-Ruf schaden, sondern auch dazu führen, dass wichtige und private Daten verloren gehen. Im vergangenen Jahr haben wir einen Anstieg der Hacking-Angriffe auf Websites um 180% verzeichnet. Wir arbeiten intensiv daran, diesem Hacking-Trend entgegenzuwirken. Auch ihr könnt einiges tun, um eure Inhalte im Web zu schützen.
Ab heute setzen wir unsere
#nohacked-Kampagne
fort. Über die kommenden Wochen erhaltet ihr Tipps, wie ihr eure Website vor Hacking-Angriffen schützen könnt, und wir erklären genauer, wie solche Hacking-Kampagnen funktionieren. Ihr könnt der #nohacked-Kampagne auf
Twitter
und
Google+
folgen.
Wir starten die Kampagne mit einigen grundlegenden Tipps dazu, wie ihr eure Website im Web schützen könnt.
Kontosicherheit erhöhen
Für den Schutz eurer Website ist es unbedingt notwendig, ein starkes Passwort zu verwenden, das schwer zu knacken ist. Verwendet für euer Passwort eine Kombination aus Buchstaben, Zahlen und Symbolen oder eine Passphrase. Außerdem ist die Passwortlänge wichtig. Je länger das Passwort ist, desto schwerer ist es zu entschlüsseln. Es gibt viele Ressourcen im Web, mit denen ihr die Passwortstärke testen könnt. Testet ein Passwort, das eurem ähnelt, um die ungefähre Passwortstärke zu kennen. Achtet aber darauf,
niemals euer tatsächliches Passwort auf anderen Websites einzugeben.
Dasselbe Passwort sollte außerdem nicht mehrfach verwendet werden. Angreifer versuchen oft, bekannte Kombinationen aus Nutzernamen und Passwort zu verwenden, die sie aus offengelegten Passwortlisten oder gehackten Diensten erhalten haben, um damit so viele Konten wie möglich zu manipulieren.
Wir empfehlen darüber hinaus die Aktivierung der
Zwei-Faktor-Authentifizierung
für Konten, die diese Funktion unterstützen. Damit könnt ihr die Sicherheit eures Kontos deutlich erhöhen und euch vor diversen Angriffen auf euer Konto schützen. In zwei Wochen werden wir ausführlicher auf die Vorteile der Zwei-Faktor-Authentifizierung eingehen.
Website-Software regelmäßig aktualisieren
Häufig gelingt Hackern der Angriff auf Websites aufgrund von unsicherer Software auf der Website. Prüft eure Website regelmäßig auf veraltete Software und achtet vor allem auf Updates, die Sicherheitslücken schließen. Wenn ihr einen Webserver wie Apache, nginx oder eine kommerzielle Webserversoftware verwendet, stellt sicher, dass ihr immer die neuesten Patches für eure Webserversoftware installiert. Wenn ihr ein
CMS (Content Management System)
oder Plug-ins oder Add-ons auf eurer Website verwendet, aktualisiert diese immer auf die neueste Version. Außerdem solltet ihr die Sicherheitsankündigungen für eure Webserversoftware und ggf. euer CMS abonnieren. Denkt auch darüber nach, Add-ons oder Software, die ihr auf eurer Website nicht braucht, komplett zu entfernen. Diese können nicht nur potenzielle Risiken bergen, sondern auch die Leistung eurer Website beeinträchtigen.
Sicherheitsrichtlinien des Hostanbieters erfragen
Beachtet bei der Auswahl eines Hostanbieters unbedingt, welche Sicherheitsrichtlinien bei dem Hostanbieter gelten und wie er mit der Wiederherstellung gehackter Websites umgeht. Falls ihr einen Hostanbieter nutzt, fragt nach, ob er On-Demand-Support bei websitespezifischen Problemen anbietet. Ihr könnt euch auch online informieren, welche Erfahrungen Nutzer mit dem Anbieter bei der Wiederherstellung manipulierter Websites gemacht haben.
Wenn ihr einen eigenen Server habt oder VPS-Dienste (Virtual Private Server) nutzt, solltet ihr auf den Umgang mit möglichen Sicherheitsproblemen vorbereitet sein. Serveradministration ist eine komplexe Sache und eine der Hauptaufgaben eines Serveradministrators besteht darin, sicherzustellen, dass der Webserver und die Content-Management-Software immer gepatcht und auf dem neuesten Stand sind. Wenn ihr die Serveradministration nicht unbedingt selbst übernehmen wollt, kann es sich lohnen, bei eurem Hostanbieter nachzufragen, ob er solche Administrationsdienste anbietet.
Mit Google-Tools über mögliche gehackte Websiteinhalte auf dem Laufenden bleiben
Es ist wichtig, Tools zu haben, die euch bei der Überwachung eurer Website proaktiv unterstützen können. Je früher ihr über einen Hacking-Angriff Bescheid wisst, desto schneller könnt ihr etwas dagegen unternehmen.
Wir empfehlen allen, die noch nicht angemeldet sind, die
Anmeldung bei der Search Console
. Über die Search Console weist Google euch auf Probleme bei eurer Website hin. Wir informieren euch dann zum Beispiel auch, wenn gehackte Inhalte auf eurer Website gefunden wurden. Ihr könnt auch
Google Alerts
auf eurer Website einrichten, um bei verdächtigen Ergebnissen für eure Website benachrichtigt zu werden. Wenn ihr beispielsweise eine Website für Haustierzubehör mit dem Namen www.example.com habt, könnt ihr einen Alert für [site:example.com günstige software] einrichten. Dann werdet ihr benachrichtigt, wenn auf eurer Website plötzlich Hacking-Inhalte zu günstiger Software erscheinen. Ihr könnt mehrere Alerts für unterschiedliche Spambegriffe auf eurer Website einrichten. Wenn ihr nicht sicher seid, welche Spambegriffe ihr verwendet sollt, könnt ihr bei Google nach
häufigen Spambegriffen
suchen.
Wir hoffen, diese Tipps helfen euch, eure Website online zu schützen. Folgt unseren sozialen Kampagnen und teilt Tipps & Tricks zur Sicherheit im Web unter dem Hashtag #nohacked.
Falls ihr noch Fragen habt, könnt ihr diese auch in unserem
Forum für Webmaster
posten.
Post von Eric Kuan, Webmaster Relations Specialist und Yuan Niu, Webspam Analyst
(Veröffentlicht von Sven Naumann, Search Quality Team)
Neuigkeiten zur Autovervollständigungs-API
Freitag, 24. Juli 2015
Die Google-Suche bietet einen Dienst zur automatischen Vervollständigung, mit dem Suchanfragen vorhergesagt werden, bevor ein Nutzer die Eingabe beendet. Seit Jahren integrieren diverse Entwickler die Ergebnisse der automatischen Vervollständigung in ihre eigenen Dienste, wobei sie eine nicht offizielle und nicht veröffentlichte API verwenden, für die auch keine Beschränkungen gelten. Entwickler, die diese API zur automatischen Vervollständigung entdeckt haben, konnten somit die Dienste zur automatischen Vervollständigung unabhängig von der Google-Suche integrieren.
Bei vielen Gelegenheiten hat Reverse Engineering eines Google-Dienstes mit einer unveröffentlichten API durch die Entwicklercommunity hervorragende Ergebnisse hervorgebracht. Beispielsweise wurde die Google Maps API Monate, nachdem sich herausstellte, was kreative Entwickler durch Kombinieren von Kartendaten mit anderen Datenquellen geschaffen hatten, zu einer offiziell unterstützten API. Wir unterstützen derzeit
mehr als 80 APIs
, die Entwickler verwenden können, um Google-Dienste und -Daten in ihre Anwendungen zu integrieren.
Es treten jedoch manchmal Situationen auf, in denen die Verwendung einer nicht unterstützten und nicht veröffentlichten API das Risiko nach sich zieht, dass diese API irgendwann nicht mehr verfügbar ist. Die jetzige Situation ist eine davon.
Wir haben die automatische Vervollständigung als Zusatzfunktion zur Suche entwickelt. Jedoch war nie beabsichtigt, dass diese Funktion für andere Zwecke als zur Vorhersage von Suchanfragen verwendet wird. Im Laufe der Zeit haben wir festgestellt, dass gewisse Anwendungsmöglichkeiten von Datenfeeds zur automatischen Vervollständigung außerhalb der Suchergebnisse zwar nützlich sein könnten, der Inhalt unserer automatischen Vervollständigung jedoch für Ergebnisse der Websuche optimiert ist und auch nur im Zusammenhang mit diesen verwendet werden soll. Außerhalb des Kontextes einer Websuche bietet diese Funktion Nutzern keine nennenswerten Vorteile.
Da wir die Integrität der automatischen Vervollständigung als Teil der Suche aufrechterhalten möchten, schränken wir unautorisierten Zugriff auf die nicht veröffentlichte API zur automatischen Vervollständigung ab dem 10. August 2015 ein. Wir möchten sichergehen, dass Nutzer die automatische Vervollständigung so verwenden können, wie von uns beabsichtigt – als einen Dienst, der eng mit der Suche verbunden ist. Wir sind der Ansicht, dass dadurch die beste Nutzererfahrung für beide Dienste geboten wird.
Für Publisher und Entwickler, die den Dienst zur automatischen Vervollständigung weiterhin für ihre Website verwenden möchten, bieten wir eine Alternative an. Mit der benutzerdefinierten Suchmaschine von Google (Custom Search Engine – CSE) können Websites die Funktion zur automatischen Vervollständigung in Verbindung mit der Suchfunktion beibehalten. Alle Partner, die bereits CSE von Google verwenden, sind von dieser Änderung nicht betroffen. Andere, die die Funktion zur automatischen Vervollständigung nach dem 10. August 2015 nutzen möchten, können sich über die Anmeldeseite für CSE informieren.
Post von Peter Chiu im Namen des Autovervollständigungs-Teams
(Veröffentlicht von Sven Naumann, Search Quality Team)
Google+: Fallstudie zu App-Download-Interstitials
Donnerstag, 23. Juli 2015
Viele mobile Websites nutzen App-Interstitials als Werbung, um Nutzer zum Herunterladen ihrer systemeigenen mobilen Apps zu animieren. Systemeigene Apps können zur Verbesserung der Nutzererfahrung führen und bieten Gerätefunktionen, die derzeit noch nicht einfach über einen Browser zugänglich sind. Zahlreiche App-Eigentümer sind deshalb überzeugt, dass sie Nutzer ermutigen sollten, die systemeigene Version ihrer Website bzw. ihres Onlinedienstes zu installieren. Unklar ist, wie aggressiv die Apps beworben werden sollten, zumal ein ganzseitiges Interstitial dazu führen kann, dass Nutzer nicht sofort an den gewünschten Inhalt gelangen.
Bei der mobilen Version für Google+ wollten uns die eigene Nutzung von Interstitials einmal genauer anschauen. Interne Nutzerstudien zeigen, dass sie für die Nutzer wenig zufriedenstellend sind, und Jennifer Gove hat in einem
tollen Vortrag
bei der IO-Entwicklerkonferenz im letzten Jahr die Gründe für diese Enttäuschung der Nutzer noch einmal genauer erläutert.
Obwohl uns unser Gefühl sagt, dass wir das Interstitial entfernen sollten, verlassen wir uns bei unseren Entscheidungen lieber auf Daten. Wir wollten also feststellen, wie sich das Interstitial auf unsere Nutzer auswirkt. Unsere Analyse ergab Folgendes:
9 % der Aufrufe unserer Interstitial-Seite führten dazu, dass die Schaltfläche "App herunterladen" gedrückt wurde. Dabei ist zu beachten, dass ein Teil der Nutzer die App möglicherweise bereits installiert hat oder überhaupt keine App Store-Downloads durchführt.
69 % der Nutzer verließen unsere Seite. Diese Nutzer riefen weder den App-Store auf noch wechselten sie zu unserer mobilen Website.
Auch wenn sich 9 % zunächst nach einer großartigen CTR für eine Kampagne anhören, ging es uns eher um die Anzahl der Nutzer, die unser Produkt wegen der Beeinträchtigung ihrer Nutzererfahrung verlassen hatten. Angesichts der vorliegenden Daten beschlossen wir im Juli 2014, ein Experiment durchzuführen und auszuprobieren, wie sich das Entfernen des Interstitials auf die eigentliche Produktnutzung auswirken würde. Wir fügten ein Smart App-Banner hinzu, um die systemeigene App weiter auf weniger aufdringliche Weise zu bewerben, wie im Abschnitt
Häufige Fehler vermeiden
unseres Leitfadens für Mobilgeräte beschrieben. Die Ergebnisse waren überraschend:
Die Anzahl der Nutzer, die an einem Tag auf unserer mobilen Website aktiv waren (1-day active), war um 17 % gestiegen.
Die Anzahl der Installationen der systemeigenen G+ iOS-App blieb weitgehend gleich (-2 %). (Die Anzahl der Installationen über Android-Geräte bleibt hier unberücksichtigt, weil Google+ auf den meisten Android-Geräten bereits installiert ist.)
Aufgrund dieser Ergebnisse beschlossen wir, das Interstitial dauerhaft zu entfernen. Wir sind der Ansicht, dass der Anstieg der Nutzerzahl für unsere Produkte unterm Strich eine positive Veränderung darstellt und wollen euch an dieser Erkenntnis teilhaben lassen, in der Hoffnung, dass auch ihr die Nutzung von Interstitials zu Werbezwecken noch einmal überdenkt. Lasst uns diese Reibungspunkte entfernen, damit das mobile Web nützlicher und nutzerfreundlicher wird!
(Seit dieser Studie haben wir eine nochmals verbesserte Version der mobilen Website gestartet, die aktuell gänzlich ohne App-Banner auskommt. Das Banner kann weiterhin auf iOS 6 und früheren Versionen gesehen werden)
Gepostet von David Morell, Software Engineer, Google+
(Veröffentlicht von Sven Naumann, Search Quality Team)
Handhabung neuer Top-Level-Domains in der Google-Suche
Dienstag, 21. Juli 2015
Da immer mehr neue generische Top-Level-Domains (
gTLDs
) verfügbar sind, möchten wir euch einen kurzen Überblick darüber geben, wie sich diese auf die Google-Suche auswirken. Wir haben festgestellt, dass es viele Fragen und Unklarheiten zum Einsatz neuer Top-Level-Domains (TLDs) wie .guru, .how oder der markenspezifischen gTLDs .MARKE gibt:
Frage
:
Wie wirken sich die neuen gTLDs auf die Suche aus? Wird Google seine Suchalgorithmen ändern, um diesen TLDs einen Vorzug zu geben? Welche Rolle spielen die TLDs letztendlich in der Suche?
Antwort: Unsere Systeme machen in der Regel keinen Unterschied zwischen neuen gTLDs und den bereits vorhandenen wie .com und .org. Keywords in einer TLD stellen keinen Vor- oder Nachteil in der Suche dar.
F
:
Wie werden
internationalisierte Domainnamen
in TLDs wie .みんな gehandhabt? Kann der Googlebot diese TLDs crawlen und indexieren, damit sie in der Suche gefunden werden können?
A: Ja. Es gibt keinen Unterschied in der Verwendung dieser und anderer TLDs. Ihr könnt dies ganz einfach über eine Suchanfrage wie [
site:みんな
] überprüfen. Google gibt der
Punycode
-Version eines Hostnamens den gleichen Stellenwert wie der nicht kodierten Version. Ihr braucht also keine Weiterleitungen oder separate kanonische URLs zu verwenden. Was ihr für den restlichen Teil der URL beachten solltet: Verwendet UTF-8 für den Pfad und die Abfragezeichenfolge der URL, wenn diese andere als ASCII-Zeichen enthält.
F: Hat eine markenspezifische TLD (.MARKE) einen höheren oder niedrigeren Stellenwert als .com?
A: Nein. Wir machen keinen Unterschied zwischen diesen TLDs und anderen gTLDs. Für beide müsst ihr die geografische Ausrichtung einstellen und konfigurieren. Marken-TLDs werden beim Crawlen, Indexieren oder Ranking von URLs nicht bevorzugt behandelt.
F: Wie werden die neuen TLDs für Regionen oder Städte wie .london oder .bayern gehandhabt?
A: Auch wenn diese TLDs regionsspezifisch zu sein scheinen, werden sie dennoch als gTLDs eingestuft. Dies entspricht auch unserem Ansatz für regionale TLDs wie .eu und .asia. Möglicherweise kann es hier zu einem späteren Zeitpunkt Ausnahmen geben. Dies hängt davon ab, wie die TLDs schlussendlich in der Praxis eingesetzt werden. Weitere Informationen zu
internationalen und mehrsprachigen Websites
und zum
Festlegen einer geografischen Ausrichtung in der Search Console
findet ihr in unserer Hilfe.
F: Wie werden
ccTLDs
(Ländercode-Top-Level-Domains) eingesetzt? Gibt Google ccTLDs wie .uk, .ae als lokalen Domains Vorrang, wenn ein Nutzer in einem dieser Länder sucht?
A: Standardmäßig werden die meisten ccTLDs (mit einigen
Ausnahmen
) eingesetzt, um eine geografische Ausrichtung der Website zu erzielen. ccTLDs sind ein Hinweis darauf, dass die Website im jeweiligen Land wahrscheinlich relevanter ist.
Weitere Informationen zu internationalen und mehrsprachigen Websites
F: Kann ich von Google Unterstützung hinsichtlich der SEO-Anpassung bei der Verschiebung meiner Domain von .com zu einer neuen TLD erwarten? Wie verschiebe ich meine Website, ohne das Ranking in der Suche oder meinen Verlauf zu verlieren?
A: In unserer Hilfe findet ihr umfassende
Informationen zum Website-Umzug
. Diese Umzüge werden von uns wie alle anderen Website-Umzüge eingestuft. Es kann einige Zeit dauern, bis Domainänderungen für die Suche verarbeitet werden. Zudem erwarten Nutzer, dass E-Mail-Adressen langfristig gültig sind, daher solltet ihr eine Domain auswählen, die auch auf lange Sicht euren Anforderungen entspricht.
Wir hoffen, eure Fragen mit diesen Informationen zur Handhabung der neuen Top-Level-Domains beantwortet zu haben. Falls ihr noch Fragen habt, könnt ihr sie gerne hier posten oder
in unserem Forum für Webmaster
stellen.
Post von
John Mueller
, Webmaster Trends Analyst
(Veröffentlicht von Sven Naumann, 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
