Webmaster-Zentrale Blog
Offizielle Informationen zum Crawling und zur Indexierung von Webseiten und News für Webmaster
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
